A team of agents with narrow jobs
03 3 min read
I built an AI assistant I can hand work to the way I'd hand it to a person: I send it text or a voice note in my chat app, and a manager agent routes the work to specialists for email, calendar, documents, maps, research, home automation, and more. This page explains why it is not one model behind a chat box, and how a coordinator, a set of specialists, and strict handoffs make the whole thing dependable enough to run without supervision.
Why not one model behind a chat box #
A single general-purpose chat session is a fine way to answer a question. It is a poor way to run work. Long, mixed tasks blur together in one context window: the research pollutes the writing, the writing style leaks into the code, and a failure anywhere means starting the whole conversation over. The fix is the same one organizations discovered long before software: give each worker a narrow job and make someone responsible for routing.
So the assistant is a team. Separate agents handle research, code, and writing, and a manager agent routes work between them. Each specialist has a small, fixed responsibility, which keeps its prompt short, its context clean, and its output easy to judge. The coordinator is the only part that sees the whole task.
The coordinator decides who works #
Everything enters through the coordinator. It breaks a request into stages, decides which specialist gets each stage, and carries the intermediate results forward. Delegation is what makes the system feel like handing work to a person: I describe the outcome I want, not the steps. The routing logic lives in one place, so adding a new specialist or changing who handles what does not disturb the rest of the system.
The front door is my chat app. A text message goes straight to the manager; a voice note is transcribed first, then routed like any other request. The conversation carries memory, so follow-ups build on what came before, and specialist agents beyond that core trio cover email, calendar, documents, maps, and home automation. From the outside it feels like one assistant; inside, it is a dispatcher with a deep bench.
Handoffs are contracts #
The failure mode of chained language models is quiet drift: stage two happily consumes garbage from stage one and passes polished garbage to stage three. To stop that, every handoff validates structured output. A stage does not receive prose and good intentions; it receives fields it can check. If validation fails, the stage that produced the data retries, not the whole pipeline. Failed stages retry independently, which turns a fragile chain into something closer to a supervised production line.
Publishing with no one reviewing #
The same setup runs a content pipeline that collects source material, writes structured content, and publishes it with no one reviewing. Removing the human from the loop is only responsible if the pipeline can say no on its own, so it gates on a relevance-scoring agent: material that does not clear the bar never reaches the writing stage. Between the gate at the front, the validated handoffs in the middle, and independent retries throughout, the pipeline earns the right to publish unattended.
What it runs on #
The whole assistant runs on n8n. The workflow backbone provides triggers, branching, and the glue between agents and the outside world of APIs, databases, and business tools. Narrow jobs are what make that practical: a specialist with a small, well-defined task demands far less of its model than one generalist doing everything.
The result is an assistant I can hand real work to, and a pipeline that does its job whether or not I am watching.