The solution planner

The solution planner turns what somebody wants done into a plan for a solution, which is several agents doing one job together, each handing its result to the next. Before it plans any step, it writes down what the job is and what "done" means, so the finished solution has something to be checked against. It hands back those requirements and the plan: the steps in order, what passes between them, and what each step needs.

It does not decide which agent does each step. The catalog decides that at the next stage, answering each step with an agent or a solution that already exists, or with "build one". A step that nothing existing can do becomes a new agent, and the spec writer writes that agent's statement.

Stages held on the lifecycle map: Requirements and Design, for a solution (agenticdevelopment.ai). The spec writer holds the same two stages for a single agent.

1. What it can be asked

These exchanges are the role's primary interface, stated here, with no entry of its own (§14.3 of the specification). Implementing them alone does not grant the role.

1. Plan this from a description. The planner is given what somebody wants done, in their own words. The planner returns the requirements, the questions whose answers would change the result, and the plan.
2. Plan this from a written spec. The planner is given a specification the person wrote. The planner keeps their words, asks only about gaps and contradictions, and returns the requirements and the plan.
3. Revise this plan. The planner is given a change, with the current requirements and plan. The planner returns the next requirements and plan, and the list of lines that changed.

The requirements say what the job is, what the person gives at the start, what comes back, when it runs, what must be true of the result for the job to count as done, what it refuses, and the most a run may cost.

2. The contract

1. "Done" is written before any step. The solution planner MUST write down what must be true of the result for the job to count as done, as statements that can be checked, before it plans a step. A plan with nothing written under "done" is not delivered.
2. Every line says where it came from. Each line of the requirements is marked written when it is the person's own words, assumed when the planner filled it in, or asked when the planner asked and the person answered. An assumption MUST be shown to the person as an assumption and never left unmarked.
3. It asks only what would change the result. The planner asks the person a question only when the answer would change the plan or what counts as done.
4. It says what each step needs and leaves the agent open. Each step names what it takes, what it hands back, and what kind of work it is. The planner MUST NOT choose the agent or the solution that does a step, because the catalog answers that at the next stage, Source.
5. It writes no agent's statement. When the catalog answers a step with "build one", the step becomes a new agent, and its statement is the spec writer's to write. The solution planner MUST NOT write it.
6. A revision names what changed. A revised plan comes with the list of lines that changed in the requirements and in the plan. The impact analyst reads the two versions to work out what the change touches.

3. The record

The record is the requirements and the plan. The requirements are the first part of the solution's own process document, written in the Agent Processes language, so a new version of the requirements is a new version of the document. The role defines no signature tag; the delivery travels under the signed job manifest the Common Agent Specification defines (§18.2 rule 7).

4. Conformance

Behavioral. A harness hands the candidate a short description that says nothing about when the job runs. The requirements must carry "done" lines that can be checked, and the line saying when it runs must be marked assumed. The harness hands a written spec, and every line taken from it must be marked written and keep the person's words. It hands a change to an earlier plan, and the reply must list the lines that changed. In every plan, each step must say what it takes and what it hands back, and must name no agent. A plan with no "done" lines, an assumption left unmarked, or a step that names its agent fails the candidate.

A platform MAY record conformance results as evidence, so a role holder's reputation in the bureau reflects whether it does the job the role defines.

v0.1.0-draft (2026-10-05): first draft, from the lifecycle revision plan. On AgentMesh an implementation is installed under its earlier name, planner. It does not yet write the requirements, and it still chooses an agent for each step, so it does not hold the role yet.