AI & ML
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
Christian Anderson DEV Community
1 views
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:
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.
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.
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.
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).
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.
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.
Builder rendered a longer version to a PDF, using the same boring
deterministic toolchain everything else uses.
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.
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:
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.
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.
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.
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.
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.
Read original: https://dev.to/c1-anderson/one-ai-six-jobs-how-i-take-an-idea-from-a-one-line-thought-to-something-live-with-a-team-of-50bj
← Previous
I run my homelab like a small company: the architecture, the org chart, and the rules I only learned by breaking things
Next →
My Grandmother Ran Ajo. I Built the Version Where the Pot Can't Walk Away
Related
chrome-bridge: let any AI agent drive your real logged-in Chrome
AI & ML
0
Dev.to (EN Zone)
From Messy CSV to Clean Dashboard: What I Learned Building My First Power BI + Google Analytics Dashboard (Part 1)
AI & ML
0
Dev.to (EN Zone)
Building Adaptive AI Agents
AI & ML
0
Dev.to (EN Zone)
‘Comet Has Been Gutted’: A Week of Paid AI Features Quietly Disappearing
AI & ML
0
Dev.to (EN Zone)
Comments0
No comments yet — be the first