From orchestrator
to team leader

I kept running into the same problem with large orchestrators. One parent model receives a broad goal and must decide how to break it into tasks, write the sub-agent prompts, start the work, review the results, and combine them. The prompt has to describe enough of the final outcome for the parent model to make good decisions. That is hard when the work is still taking shape.

The usual approach can work when the complete request is clear. But when I do not yet know every deliverable, I have found it difficult to write one prompt that delegates the right work without creating unnecessary or conflicting tasks.

The alternative that worked for me is to let a feature specification define each task boundary. As each specification becomes ready, its agent can start work without waiting for a parent model to design the entire delegation plan. When specifications connect, a team leader coordinates the work between them.

Two ways to organize the work

The difference is who defines the work. In the usual model, the parent model decides how to delegate. In this pattern, feature specifications define the task boundaries, and the team leader connects them when the relationships become important.

This works well when the task is short, the boundaries are clear, and one model can follow the work from start to finish. It becomes harder when the work starts to look like a real project. The parent model must choose the delegation, write the goals, manage the work, review the results, and combine them. If the end state is not clear yet, it can create tasks that make sense on their own but conflict when their results are combined.

The team leader pattern

The team leader pattern starts with a feature specification, not a complete delegation plan. The specification defines a bounded goal and gives an agent enough information to begin. Other specifications can become ready later. When they share a decision, dependency, or deliverable, bring them into the shared flow and introduce a team leader to keep the work connected. No agent creates another agent. Each one works on its specification and reports its result or its block.

The team leader has a different job from the other agents. It does not define the feature specifications or create more agents. It watches which goals are complete, which are blocked, and which results need another pass. If one specification depends on another, the leader handles the handoff or asks for the missing piece. It keeps the connected work aimed at the larger result.

This matters when the end state is not fully known at the beginning. The specifications let work begin as decisions become clear. The leader gives later specifications a place to fit and surfaces conflicting assumptions before separate implementations drift apart. It does not invent missing product decisions; it makes those decisions visible.

Why the goal-writer skill matters

A team leader cannot do much with a vague request. “Look into the API” is not a useful handoff between two agents any more than it is between two developers. The worker needs to know what to make, what counts as proof, what it must not change, and what to report if it cannot finish.

The feature specification defines the product boundary. The goal-writer skill turns that boundary into a short brief that an agent can act on and a person can check. It asks for the end state, the check for success, the proof to collect, the limits to respect, and the rule for work that stops before it is done.

Goal:
Review the current onboarding flow and identify the three highest-risk points where a new user can get stuck.

Success criteria:
- Each risk is tied to a specific screen or transition.
- The report separates observed behavior from inference.
- The report recommends one next check for each risk.

Evidence and review:
- Inspect the relevant screens and current implementation.
- Report the files, screenshots, or test steps used.

Blocked handling:
- If the flow cannot be reproduced, report the exact missing state and stop short of guessing.

The leader does not need to watch every move. It does need a clear way to see whether the work is moving and whether the result is good enough to use. Clear goals let agents make progress on their assigned work because the limits are plain.

Where Keystone fits

This is the problem I am building Keystone to address. Keystone is a plain Markdown feature contract that sits beside the code. It gives each deliverable a written boundary: what it must do, what it must not change, and how someone can check the result.

When a Keystone specification is ready, an agent can start from it without waiting for a parent model to invent a task. As more specifications become ready, they give the team leader something concrete to compare. The leader can find conflicting requirements, connect related work, and show where a product decision is still missing.

Keystone does not replace the agents or the team leader. It gives them a shared reference. You can learn more at keystone.michaelwdanko.com or view the open-source repository.

The harness is part of the pattern

A team leader cannot coordinate conversations it cannot see. The harness must expose the feature specifications, task status, results, blocked states, and the decisions made in related conversations. Without that view, the leader is guessing or asking every agent to repeat work that already happened elsewhere.

This does not depend on one model provider. A harness can support the pattern through shared task state, links between conversations, messages, or an event log. The important part is that the leader can inspect the work that already exists before it asks for another change.

How people can use this kind of flow

An agentic flow is simply a set of jobs passed between models, tools, and people. It does not need a large group of agents. The useful question is not how many agents to add. It is which parts of the work can have clear owners and clear results.

• Make one feature specification ready: name the answer, file, decision, or change the current deliverable should produce.
• Start when the specification is ready: let its agent begin without waiting for every later deliverable to be defined.
• Connect related specifications: add a team leader when separate goals share decisions, dependencies, or a final result.
• Turn each specification into a clear goal: give the agent a success check, limits, and a way to report a block.
• Give the leader conversation visibility: let it see specifications, task status, results, and blocks without asking agents to repeat their work.
• Review the whole result: the leader checks whether the separate answers solve the original problem together.

The same pattern could support research, product work, or a hard decision. One agent might gather evidence, another might look for risks, and another might turn the findings into a draft. In a product task, separate agents might review the requirements, make the change, and test it. The team leader keeps those jobs connected without asking any worker to create another worker.

Why this looks familiar to me as a product owner

This model feels familiar because it looks like part of my job as a product owner. I do not write every line or define the whole project before work begins. I make feature specifications ready, help developers understand the goal, and let them start when the work is clear enough to build.

Much of my work happens when those specifications meet. I check whether two implementations fit, notice when one team is waiting on another, make tradeoffs clear, and ask whether the finished work solves the problem we started with. Those are judgment and follow-up tasks, not task delegation.

A team leader for agents would do much the same. It would give each specialist enough context to work without making every agent wait for a complete project plan. It would also keep the connected specifications in view when the results do not fit together.

The pattern can scale with the work

Feature specifications give the pattern a natural unit of growth. One specification can start with one agent. As more specifications become ready, more agents can start without asking a parent model to redraw the whole plan. Add a leader when those specifications share decisions, dependencies, or a final result.

The value comes from keeping the responsibilities distinct: workers own their goals, while the team leader owns coordination, dependencies, and the final handoff. The leader does not require a perfect project plan; it gives separate pieces a way to stay aligned as the product takes shape.

The tradeoffs

I do not think the team leader model should replace the usual model everywhere. The choice depends on the work. A simple task may be best handled by one model that makes a quick plan and collects the answer. A longer job may need a leader who is responsible for keeping the work moving and making the results fit.

The comparison below describes the tradeoffs I see in the pattern. It is most useful when work can start with a clear goal but later deliverables still need to fit together.

Where coordination can be better

Coordination does not have to mean designing the whole delegation plan before work starts. A ready feature specification lets the first agent begin, while the leader gives later specifications a place to fit.

• Less waiting: work can start without predicting every later deliverable.
• Clearer ownership: each agent has one specification, and the team leader has a different job.
• Fewer conflicts: related specifications pass through a shared view before separate implementations drift apart.
• Visible decisions: the leader can surface a missing product choice before it becomes rework.

What coordination gives up

A team leader does not remove the need for good specifications or product judgment. If the shared outcome is unclear, it can surface conflicts but cannot decide which product direction is right. It also adds another role that needs context and attention.

• Specification work: someone must define each feature well enough for an agent to start.
• Incomplete context: the leader can expose a conflict without being able to resolve the underlying decision.
• A new bottleneck: the team leader can slow everything down if every decision has to pass through it.
• More ways to fail: stale status, poor handoffs, and mistakes when joining the results are harder to find.

Not every problem needs a team

Calling it a “team leader” can make the design sound grander than it is. More agents do not create better work by themselves. If a task is self-contained, one agent with a clear goal may be enough. Add coordination when a second deliverable depends on the first or when separate tasks could make conflicting assumptions.

The model is most useful when the work grows in pieces: research that leads to implementation, code that needs review, tests that need to reflect a changing decision, or several deliverables that must return to one product goal. The leader should make those pieces easier to manage, not create new agents when the plan changes.

What makes the pattern work

The pattern depends on more than assigning work. The leader needs a shared view of progress, a clear way to handle blocked tasks, and enough context to judge whether separate results fit the original problem.

It also needs a sensible stopping point. A leader that keeps reopening finished tasks or routes every small decision through itself becomes another bottleneck. The extra coordination should make the work clearer, not simply add another layer.

Bottom line

I am not trying to make AI systems look like companies. I want a better way to run work that already behaves like a project: separate jobs, clear owners, dependencies, and one result.

A clear goal lets each agent make progress on its assigned work. A good team leader keeps those jobs aimed at the same result. The pattern gives that coordination a clear owner without asking each worker to become a planner.