Your first agent has just sent you a request. It is not a question about the task. It wants permission to hire a second agent, and it has attached a job description.
That moment is the whole idea of this article. When several AI agents work for you, your job changes. You stop being the operator who types every instruction. You become the board: you set the goal, the limits and the approvals, and the agents do the work. I will show you how to set that up and where it breaks.
If you have used a lead agent inside one coding session, this is the step above it. I describe that smaller case in agent teams in Claude Code: one lead, a few helpers, one afternoon. Here the team stays in place for weeks, wakes up on its own and reports to you through tickets instead of a chat window.
Give goals and limits, not tasks
Most people manage agents the way they use a chat: one instruction, one answer, the next instruction. With five agents that becomes five open windows and no record of who was asked what. Output goes up. So does the feeling of having lost the thread.
The board approach removes that load. You write one high-level request to the lead agent and leave the breakdown to it. A good request has three parts: the outcome you want, the roles it may involve, and the point where it must come back to you. Here is an example you can copy:
Nobody checks the texts before they go out. Hire an agent that checks the facts and the tone of every text before publication. Keep improving the results until you can come back to me and report that the copywriter and the new agent are both done.
You did not say how to hire, which tests to run or in what order. You gave the outcome and the stop condition. The lead agent decides who is needed, creates the tasks and assigns them.
Orchestration tools exist for this kind of setup. Paperclip, an open-source project, is one example. The method does not depend on it. Any tool that gives you the elements below will do.
Give every agent a role, a checklist, a persona and a tool list
An agent without a job description drifts. A useful one has four written parts, kept as plain files you can open and edit:
- Role and instructions: who it reports to and what it owns. A lead agent owns the plan and the hiring requests. A designer owns visuals and nothing else.
- A checklist for each wake-up: the first things it does every time it starts. It reads its open tasks, looks at the current state and checks its own earlier work.
- A persona: how it thinks and speaks. You can tell a lead agent to default to action and protect focus. This is also where you set voice and tone.
- A tool list: exactly which tools and accounts it may use.
The fourth part matters more than people expect. Tool access works like a set of keys: the agent can do only what its keys open, whatever its instructions say. I explain that in keys, not prompts. A copywriter does not need access to your customer database.
Each agent can also run on a different model. A cheaper model can handle routine research while a stronger one leads. Think of the team as an org chart of specialists, not one assistant wearing several hats.
You do not have to write every file up front. Start with minimal versions, watch the first few runs, and edit a file when its agent misreads the job.
Let agents wake on a schedule and keep memory in files
A chat assistant waits for you. A standing team does not. Each agent has a heartbeat: a timer that wakes it every few hours, lets it work, then puts it back to sleep.
One detail shapes everything else. Every wake-up starts with fresh context. The agent remembers nothing from its previous run.
So continuity cannot live in the agent's head. It lives in files and in the task log. On each heartbeat the agent reads its instructions, opens its tasks, reads the comments left since last time, and only then acts. If you want something remembered, write it into the instructions or into a task. Saying it in passing does nothing.
You can also set up routines: recurring jobs, such as a nightly security check on the code. Assign the routine to an agent, set a schedule and an active or inactive switch, and read the run history afterwards. For the mechanics of a single loop and its stop conditions, read agent loops made simple. A schedule is a loop with a clock.
Cap the spending and approve every hire
Two limits keep a team from running away from you.
First, a budget for each agent. Set a monthly spending cap per agent, so a designer cannot quietly burn through your account while you sleep. This is the hard stop from an agent loop, applied to money. The limit sits outside the agent, so the agent cannot argue its way past it. Per-agent spending also shows you which role earns its cost.
Second, approval for hiring. By default a new agent appears only after you approve it. The lead agent writes a request with the role and the capabilities it needs, and the request lands in your inbox. You approve or reject. On approval, the system creates the agent and a linked task to set it up.
You can later let the lead agent hire without asking. I would switch the approval off only after you have watched the team for a while and trust its judgment about roles. A team that hires freely can grow faster than you can review.
The inbox is where you spend most of your board time. It holds approvals and anything an agent needs from you, such as a blocker or a decision. When a task goes beyond an agent's permissions, it stops there and waits.
Read the task log, then steer with comments
Every task, comment and decision lands in a ticket. This is why the system works without chat memory: the ticket log is shared memory for all agents and an audit trail for you.
When you open a ticket, you see what the agent planned, which commands it ran and what it concluded. You do not need to watch it live. You read the log afterwards, the way a board reads a report.
Your steering moves are few:
- Create a ticket and assign it to an agent or a project, with the goal in a sentence or two.
- Comment on an existing ticket. The agent wakes on its next heartbeat, reads the comment and continues.
- Approve or reject what waits in your inbox.
- Edit the instructions when the same mistake appears twice.
Say an agent returns a set of social-media carousels and the first attempt is weak. You do not rewrite them. You comment on the ticket with what is wrong, and the agent revises on its next wake-up. Group tickets into projects once the team grows. A project has a goal, a status and a date, and it keeps quality checks next to the build tasks.
Read before you install, and keep ownership
These systems let you add skills (packaged instructions and scripts) from public repositories with one pasted link. That is convenient and risky. Your agents will follow a skill with the keys you gave them. Skills and agents from the internet can contain mistakes or hostile instructions, and a marketplace's security badge does not replace reading the skill yourself. Install only what you have read, and attach it only to the agents that need it.
Ready-made "company" templates that bring dozens of agents at once deserve the same care. A team you did not design is a team you do not yet understand, so read its roles and tool lists before you import it.
For the wider question of who may do what and who answers when an agent gets it wrong, see governing AI agents before they spread.
My conviction is simple: agents can be fast, but ownership stays with you. A board does not do the work. It makes sure there is a goal, a limit, a record and someone who can say no.
To try it, pick one recurring job in your business, such as a weekly report. Give it one agent with one role, one tool, one budget and one ticket. Run it for two weeks and read the log before you add a second agent.