AI chief of staff: one agent that coordinates specialists and tracks everything on a kanban

When a team of two or three people starts using agents, the first reflex is to ask the same one for everything. That works for a question, much less for a job that chains research, checking and writing: the agent mixes up roles, forgets a step, and nobody knows where the request stands. Humans solved this long ago with a chief of staff, someone who takes the request, divides it, checks what comes back and reports. A multi-agent system takes the same idea.

The inspiration: one orchestrator per project

The starting point is a use reported by Hermes Agent users, summarized in a card titled "chief of staff: multi-agent orchestrator per project". The idea: instead of a generalist agent, an agent whose only job is to coordinate specialists, with a project as the shared workspace. The chief neither searches nor writes itself, it splits, delegates, checks and tracks.

What we take from it is the gain in readability. Every request becomes a card, every card has a state, and every deliverable has an address in the wiki. Atako applies this organization with three agents and a kanban, keeping the specialists behind the chief: one contact for you, one thread per request.

What the three agents do

The scenario deploys three agents with distinct roles, talking to each other through Atako's inter-agent channel.

The chief of staff receives your requests. For each one, it creates a card in the project's kanban, in the "To do" column, splits it into a research part and a writing part, then delegates to the relevant specialist, giving the context, the expected result and the deadline. The card moves to "In progress". When a result comes back, it checks it: are the claims sourced, does it answer the request, is it consistent with the company context? If not, it sends the work back with precise remarks. Otherwise, it makes sure the deliverable is published as a wiki page, puts the link in the card and moves it to "Done". Every Monday, it writes a "Weekly review" page with the requests done, in progress and blocked.

The research analyst runs the web research requested by the chief. It favors official sources, cross-checks important facts when possible, dates each source and separates what is established from what is uncertain or not found. It answers to the chief, never directly to you.

The writer turns the research and the instructions into a deliverable: a note, an internal email, minutes. It writes in the project wiki, starting with the conclusion, keeping the sources and adding no fact that is not in the material it received.

What the agents do not do

The limits are part of the design. None of the three agents sends a message outside the company: the writer produces drafts, not sendings. The specialists do not talk directly to humans, which avoids contradictory requests. No agent deletes a card or presents an unverified claim as a fact: when a source is missing, the result says so. And the chief recommends, it does not decide for you, which is the principle of a human-in-the-loop design.

How to set it up in Atako

From the page of this use case, deployment takes four steps.

1. Describe the company. A few lines on what the company does and its priorities this quarter. This context lets every agent judge what matters.
2. Phrase the first request. A concrete request: a note, a comparison, a synthesis. It starts the team's first full round.
3. Deploy. A single action creates the three agents and the "Chief of staff office" project with its kanban. No integration to connect.
4. Follow the first card. The chief creates the card, delegates, checks and moves it to Done. The specialists introduce themselves to the chief, then wait for its requests.

If you do not have an account yet, creating one starts your trial and the scenario is configured right after. If your administrator has not allowed you to create agents, the deployment tells you and stops there.

Where to see the results

You follow the work in three places. In the kanban of the "Chief of staff office" project, each request is a card whose column says where it stands. In the wiki of the same project, the deliverable is a page linked in the card, and the weekly review is added every Monday. On the Atako floor, the three agents appear with their current activity, so you can see who is working on what without asking.

For a new request, write to the chief of staff in its chat. Requests are handled in the same conversation, with the same memory of what has already been done.

Guardrails

Access is deliberately narrow. The three agents have no integration: they reach neither your mailbox, nor your CRM, nor any account. Their only write access is the project created for the scenario, with its kanban and wiki. Exchanges between agents go through an internal channel that remains readable in the app.

Human validation sits at the decision points. You read the deliverable before using it, you ask for a rework in the chat when it does not suit you, and you decide what leaves the company. The chief checks the specialists' work, but you judge the outcome.

What to expect

Expect the first request to take a few minutes longer than with a single agent, the time for the exchanges between the chief and the specialists. The gain shows on the following requests: every job is traced in a card, sources are cited, and the chief has already checked before you read. For a small team, it is the difference between a collection of agent answers scattered across conversations and an office that keeps its files. If a request does not fit the two specialties, say so to the chief: it will tell you what it can do with the team it has.