DEV Community

Christian Anderson
Christian Anderson

Posted on

One AI, six jobs: how I take an idea from a one-line thought to something live, with a team of agents that share a task board

I don't have a chatbot in my homelab. I have a staff.

It's one self-hosted AI agent, but it runs as a set of profiles — a chief of
staff, a builder, a researcher, a writer, a security reviewer, an infrastructure
admin — each with its own system prompt, its own tools, and its own model, all
sharing a single task board. When I have an idea, I don't sit down and build it.
I hand it to the team, and the team moves it along a pipeline until it's live.

This post is how that actually works: the roles, the board, the one rule that
keeps the whole thing honest, and a real walk from "I wonder if…" to "it's
published." It's less a tutorial than a description of a shape you can copy with
whatever agent framework you like — the interesting part isn't the tooling, it's
the division of labour.


The roster

Six profiles. Each knows one job and is deliberately bad at the others.

  • Chief of staff — the default. Doesn't build or research; it routes. Takes a vague idea, breaks it into cards, decides which profile each card belongs to, and reads the results back to me in the morning. It's the only one that talks to me by default.
  • Scout — research. Web search, its own email inbox, the estate's knowledge base. It gathers facts and writes them down. It never builds and never decides.
  • Builder — code. Writes the thing, runs it, iterates. Has the infrastructure tools; the others mostly don't.
  • Security — the adversary. Its whole job is to try to break what the builder made and to refuse to be reassured. It reports findings; it doesn't fix them (that goes back to the builder as a new card), because the reviewer and the author being the same agent is how you get a review that says "looks good."
  • Writer — documentation and publishing. Turns a finished thing into a README, a post, a PDF. Crucially, it's handed the facts; it does not invent them.
  • IT admin — the caretaker. Patching, capacity, drift, backups. Not part of the idea pipeline, but it's the reason the pipeline has somewhere stable to run.

The reason to split one capable model into six narrow ones isn't performance.
It's accountability. A single agent told to "research this, build it, check it's
secure, and write it up" will do all four in the same breath and grade its own
homework on every one. Six agents that hand work to each other across a board
can't — each step has a different author, and a handoff is a natural place to
check the work.


The board is the whole trick

The profiles don't call each other. They share a Kanban board, and that
indirection is what makes it a team instead of a pile of prompts.

An idea becomes a card. A card has an owner (which profile) and a column (what
stage). When the builder finishes, it doesn't "call the security agent" — it moves
the card to review and drops it. The security profile, on its own schedule,
picks up whatever's sitting in review. Findings become new cards in to-build,
owned by the builder. When there's nothing left in flight, the writer's cards in
to-publish come up.

Three things fall out of doing it this way, and all three matter:

  1. Nothing is lost when an agent stops. The state lives on the board, not in a conversation. An agent can crash, be restarted, be swapped for a better model — the work is still sitting in its column.
  2. I can see it. The board is the same board a human team would use. At any moment I can look at what's in review, what's blocked, what shipped.
  3. The handoffs are inspectable. Every transition is a place I could put a gate — and for anything that touches the outside world, I do.

The one rule that keeps it honest

Here is the rule the entire estate is built on, learned the expensive way:

Scripts gather facts. Models never do.

I used to let the research profile go and find things — market demand,
system health, "opportunities." It hallucinated with total confidence: it cited
demand on forums it invented, reported backups that hadn't run as successful, and
once appended a "[SILENT]" tag to a report while breaking the very instruction
that tag referred to. A model asked to gather a fact will, under the slightest
ambiguity, make one up and present it as certain.

So the division of labour has a hard edge in it: the deterministic parts gather;
the model parts phrase.
A monitoring script queries the real state and writes
down real numbers. Then the writer profile is handed those numbers to turn into
prose, and is forbidden to add any of its own. The clever, non-deterministic layer
is allowed to rank, route, and write — it is never the thing that counts or
decides something I can't reproduce.

The Gumroad storefront the writer publishes to is a good example of the edge in
code, not prompt. The list of things it's allowed to sell, the price band it's
allowed to sell them in, and the topics it must refuse — all of those live in a
Python file as data, enforced by functions, not written as a paragraph of
instruction the model could talk itself around. A guardrail in a prompt is a
suggestion. A guardrail in a function is a wall.


A real run: idea to live

Here's the shape of an actual pass through the pipeline — the one that produced
the thing you might have arrived here from.

The idea, in one line: "Write up what I learned from the trading bots that
kept reporting success while doing nothing, and put it somewhere people can read
it."

That's all I gave it. Here's what the team did with it.

  1. Chief of staff broke it into cards: dig up the real numbers from the project (scout), draft the post (writer), build a PDF version (builder), check it for anything that shouldn't be public (security), publish (writer).
  2. Scout pulled the actual figures — the real losses, the specific bugs, the exact failure signatures — from the project's own logs and notes, and wrote them to a facts file. Not "roughly what happened," the numbers.
  3. Writer took only that facts file and drafted the post. Because it was handed the facts, it couldn't drift into a better-sounding story that wasn't true.
  4. Builder rendered a longer version to a PDF, using the same boring deterministic toolchain everything else uses.
  5. Security ran a leak check — real IPs, hostnames, secrets, anything identifying — before anything left the building. This is a gate, not a suggestion. Public means public forever.
  6. Writer published: created the product, attached the file, set it pay-what-you-want, pushed it live, and wired the link back into the post.

Every one of those steps had a different author, and the two that touch the
outside world — the leak check and the publish — are gates I can see on the board.
The model wrote the words. It did not invent a single number, and it did not get
to decide, on its own, that something was safe to make public.

(If you're wondering how self-referential this is: yes. The post you're reading
went through the same pipeline. The team documents the team.)


What I'd tell you to copy

You don't need my stack. The transferable parts are these:

  1. Split one capable agent into narrow roles, so no agent grades its own work. Builder and reviewer must be different profiles. Researcher and writer must be different profiles. The handoff between two narrow agents is worth more than one brilliant generalist.
  2. Put the state on a board, not in a conversation. Then an agent is disposable, the work isn't, and you can see the pipeline.
  3. Gather with scripts, phrase with models. Let the deterministic layer produce every fact; let the model rank, route and write. Never let it count or source.
  4. Put your guardrails in code, not in the prompt. What may be sold, spent, sent, published — as enforced data, past which no amount of clever phrasing can argue.
  5. Make the outward-facing handoffs into gates. Anything that publishes, pays, sends or deletes gets a checkpoint you can watch. Inside the house, agents move freely. At the front door, someone checks.

The result isn't a genius assistant. It's something better for actually shipping:
a small, boring, honest organisation that takes a half-formed idea in the morning
and hands me something real by the time I've read the brief — with every step
authored by a different hand, and the clever one kept firmly in the chair where it
can write but can't lie.


Notes from running a one-machine AI "staff" that turns ideas into shipped things.
The framework doesn't matter; the division of labour does. Specifics are kept
vague on purpose — the shape is the useful part.


🤖 Drafted with AI assistance from my own homelab notes, logs and repos, then reviewed and edited before publishing.

Top comments (0)