AI Systems & Agents

How to structure an AI agent team — lanes, a board, and your first agent profile

Part 1 was the thinking. Part 2 was the decisions. This is where the team gets a skeleton.

If Part 2 left you on the one-process path, inside one harness, you can skip this part. Come back when one job becomes several. You will know. The moment you are copying work between tools and keeping the plan in your head, you are back.

For everyone else, this part is about two things. Lanes, so each agent owns a boundary instead of a job title. And a board, so work moves without you being the one who moves it. Then you write your first Agent Profile — the actual instructions the harness loads — and the paper stops again.

I have added a worksheet at the end. It is the lane contracts, the board rules, and the profile sheet. This article is how to fill it in without building a twelve-lane fantasy org chart.

Lanes, not generalists

One agent doing everything looks efficient. It is not. It is one person doing five jobs, and every time it switches jobs it forgets the constraints of the last one.

I have watched this happen first hand. Research, then code, then copy, then QA, all in one session. The leftover goals from the research leak into the code. The copy gets written against a plan that changed three tasks ago. And when something breaks, nobody owns it, because “the agent” did all of it. That is not a team. That is a one-man band with amnesia.

A lane is the fix. And a lane is not a personality. It is a fence.

A lane is one job family, one definition of done, one tool set, one memory scope. It says what the agent owns, what it never touches, and who it hands off to. Naming an agent “the creative one” is not a design. It is a sticker. Saying “you may draft copy, you may not touch the code, and you hand finished drafts to the editor lane” is a design.

How do you choose lanes? From the process you wrote down in Part 1. Not from org-chart cosplay. Group the steps by skill type and failure mode — work that needs the same judgement and breaks in the same ways belongs together.

A starter menu, then cut anything you do not actually run:

• Research and analysis — gather, compare, structure, before anyone builds
• Build and code — turn a clear brief into working files
• Design and visual — only if design is a real recurring load
• Copy and content — words for humans
• Knowledge and filing — capture what the team learns so it does not die in chat
• QA and verification — checks work against evidence, and never builds the thing it checks

Assistant path? One or two lanes. Team path? Clear, non-overlapping lanes. Twelve lanes on day one is how you get a board full of actors and no work.

Every lane needs a short contract. Eight lines:

1. Mission in one sentence
2. Inputs it accepts
3. Outputs it produces
4. Tools it may use
5. Tools it must not use
6. Definition of done
7. What it decides vs what it escalates
8. Who it hands off to

If you cannot write those eight lines, you do not have a lane. You have a name.

Then the handoff problem. Most multi-agent failure is not bad prompting. It is broken transfer. “Can you take this?” in chat loses the context, the owner, and the proof. Scrollback is not a control system. A good handoff is three things: the artifact, the acceptance checks, and an owner change on the board. The board is the handoff mechanism. It is not a status decoration.

The board

Chat can start work. It cannot run a team.

Instructions live in scrollback. There is no single source of truth. Everything is “in progress” so nothing finishes. Silent work rots until you notice it by chance. And you become the project manager, the memory, and the dispatcher. That is not a system. That is you, again, doing the job you were trying to delegate.

The board is the fix. Kanban, or whatever your harness calls it — Hermes has one built in (it is not the best). The board is the operating record of the team. If it is not on the board, it is a secret. Secrets do not ship.

Every material piece of work is a card. No card, no work. That rule stops side quests and private heroics. A card carries five things: owner, next action, acceptance checks, blocker, evidence. A card without those is a wish.

The minimum mechanics:

• States. Todo, ready, in progress, blocked, review, done. Names can vary. Meaning cannot. Every card sits in a state that tells the truth.
• One owner per card. Shared ownership is how work becomes nobody’s problem.
• Dispatch. Ready work gets pulled into the right lane. Created is not dispatched. Opening a card is not the same as work starting.
• Reclamation. Stuck work comes back to the board owner instead of rotting in place.
• WIP limits. Cap active work. Start with three. Force finish-and-clear instead of infinite starting.

Then the orchestrator. One role that runs the board mechanics and does nothing else. It routes, prioritises, promotes, reclaims, surfaces blockers. It does not write your copy. It does not code your feature. The moment it starts doing craft “to help”, lane ownership collapses and you have a middleman essay-writer between you and the work. I have built that. It is a very polite way to slow everything down.

The failure mode to watch is activity theatre. Full board. Busy agents. Comments everywhere. Nothing you can open. Movement is not progress. A card changing columns is worthless if no artefact improved. “Done” without evidence is just a word.

You know orchestration is working when:

• Every active workstream has one clear next action and one owner
• Blockers are visible within the next stand up, not discovered days or weeks later
• Done means an openable artefact, not “we discussed it”
• You can answer “what can I use today?” without reading twenty chats

My board flags anything blocked at the next stand-up, and anything in progress that has gone silent for a day. It taps me on the shoulder. I do not go looking. That is the difference between a ledger and a list I ignore.

From lane to agent profile

A lane says what work exists. A profile says how a specific agent is allowed to behave inside that lane. The lane is the boundary on the diagram. The profile is what the harness actually loads when the agent wakes up.

Skip the profile and you get vibes-based agents. Same model, fuzzy job, drifting behaviour. It sounds smart in chat and cannot be trusted with a real handoff.

What “building an agent” means in this series: you are writing a small operating pack, not naming a chatbot. Six parts:

1. Soul. Who it serves, tone, quality bar, hard refusals. Short. Plain. This is a living file, not a museum piece. Museums are full of things that stopped moving.
2. Operating instructions. How it starts work, uses the board, hands off, reports. Missing acceptance checks means stop and ask, not invent.
3. Standing duties. What it does unprompted, with a cadence and a definition of done. “Keep an eye on things” is not a duty.
4. Memory scope. What it may remember, what it must not hoard, what belongs on the board instead. Durable preferences only. Not every passing thought.
5. Starter tools. The minimum to do the job. Secrets, production, payments, mass delete stay closed. Part 5 opens them with justification, not before.
6. Never-do list and escalation line. Explicit refusals, and when the human must decide.

Build order matters. Lock the lane contract first. Then write one profile per active lane — start with one or two agents, not seven. Wire the profile to the board behaviour. And leave deliberate holes: the integrity layer comes in Part 4, the full tool binding in Part 5. Do not write the perfect final profile now. You will amend it. That is the point.

Copy-pasting the same soul into every agent is how you get five identical interns who all think they are the main character. Each profile is tuned to that lane’s actual failure pattern.

The scar I carry from this stage: agents that sounded brilliant in chat but had no job contract. They wandered. They overlapped. They could not be trusted with anything that mattered. Personality without boundary is entertainment. If you cannot point to the rule the agent should have followed, you did not build it.

Fill the worksheet, then build the skeleton

Download the Part 3 lane and board worksheet →

You should leave with:

1. Your path gate — skip, light, or full
2. One or two lane contracts, eight lines each
3. Your first two handoffs mapped
4. Board rules: states, WIP limit, ready, done, stale, blocked
5. One Agent Profile v0.1

Then do the build. This Session:

1. Write the lane contract for your first lane. Eight lines. If it takes more than an hour, the lane is too big. Split it.
2. Set up the board. States: one owner per card, WIP limit of three.
3. Write one Agent Profile v0.1. Soul, instructions, duties, memory, tools, never-do.
4. Move the one process from Part 1 onto the board as its first card. Owner, next action, acceptance checks.

That is the skeleton. Part 4 adds the guardrails — the evidence gates and independent checks that stop the team confidently doing the wrong thing. Part 5 binds the tools and takes it live.

If you cannot write the eight lines for one lane, you are not ready for a team. Stop here. The board will still be there when you are ready.