The impact analyst

Standard role · lifecycle family · offering name role-impact-analyst · v0.1.0-draft · 2026-10-05 · mesh-anchored

The impact analyst works out what a change touches before anything is built. Given a proposed change to an agent or a solution, it lists everything that depends on the thing being changed and says what the change does to each. It changes nothing it reports on and approves nothing. The person who asked for the change decides from its report.

It calls no model. Comparing two declarations and reading a list of dependents is work a program does the same way every time, and a report that a person approves a change from has to come out the same way twice.

The role is mesh-anchored because the list of dependents comes from records a platform keeps: which solutions name the agent, which schedules and shares run it, and who has called it.

Stages held on the lifecycle map: Impact (agenticdevelopment.ai).

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. What does this change to an agent touch? The agent's declaration as it runs today, the declaration it would have after the change, and the platform's list of what depends on the agent. The analyst returns each dependent, where it learned of it, and one of three answers for it: compatible, breaking, or a change of behavior.
  2. What does this change to a solution touch? The solution's requirements and plan as they are today, and as they would be after the change. The analyst returns what changed in the requirements, whether what counts as done moved, the steps added, swapped or removed, and the handoffs between steps that no longer match.

Both answers end with what has to be redone and what can be reused, and what the change will cost as far as the declared prices show.

2. The contract

  1. It changes nothing it reports on, and approves nothing. The impact analyst MUST NOT change, build or deploy the thing being changed or anything that depends on it, and MUST NOT approve the change. The person who asked for the change approves or refuses it from the report. The only record the analyst writes, besides the report, is what rule 5 files.
  2. It calls no model. The comparison and the answers follow written rules. The same two versions and the same dependents MUST give the same report.
  3. Every dependent is named. Every dependent the analyst knows of, whether declared or seen in the record of who called the agent, appears in the report with where it was found. None is left out. A source of dependents it could not read is named as not read.
  4. A change a dependent would notice is never called compatible. Compatible means the change only adds something optional, offers something new, widens a limit, or lowers a price. A change to what a dependent sends or gets back is breaking: an offering or an output removed or renamed, a new required input, a narrower limit, a higher price, or a changed refusal or way of handling data. When the contract is the same but the agent may act differently, as with a new model, the answer is a change of behavior, which only running the new version can settle. When the analyst cannot tell which answer applies, it answers breaking and says why it could not tell.
  5. It files what is owed. For each dependent whose answer is breaking or a change of behavior, the analyst files an item in the ledger, a platform service rather than a role: a change dependency debt, owed to that dependent's owner.
  6. It does not judge the change. The analyst MUST NOT say whether the change is worth making, and MUST NOT run the new version. Running it against what each dependent counts as done is the evidence half, and it belongs to the conformance checker once the new version exists.

3. The record

The impact report. 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

Mechanical. A harness gives the candidate an agent with three dependents, one of which is known only from the record of who called the agent and appears in no declaration. It then proposes three changes in turn. A new optional input must come back compatible for all three dependents. Removing an output that one dependent reads must come back breaking for that dependent, with a ledger item filed and owed to its owner. A new model under the same declaration must come back as a change of behavior for all three, with an item filed for each. The harness runs every case twice, and the two reports must match. It asks the candidate whether to go ahead with a change; the candidate must decline. A report that leaves out a dependent, calls a removed output compatible, or approves the change 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. No implementation exists.