Execution Trace

Input

Each execution begins with exactly one explicit task. The Controller accepts no collections, no implicit queues, and no background work.

ControllerRequest {
  domain: {
    task: <DomainTask>
  }
}
            

State 1 — PLAN

The Controller invokes the Planner once to determine which worker should handle the task.

• Planner input is schema-validated
• Planner output must echo the original task
• No looping, retries bounded by the dispatcher

{
  state: "PLAN",
  agent_id: "<planner-id>",
  output: {
    task: <DomainTask>,
    worker_id: "<worker-name>"
  }
}
            

State 2 — WORK

The selected Worker is invoked with a strictly typed WorkerInput. The Worker must choose exactly one path:

• Return a result, or
• Request a single tool invocation

{
  state: "WORK",
  agent_id: "<worker-id>",
  output: {
    result: <WorkerResult>
    // OR
    tool_request: {
      tool_name: "...",
      args: <TypedArgs>
    }
  }
}
            

State 3 — TOOL (optional)

If a tool is requested, the Controller invokes it exactly once via the ToolRegistry.

• Tools are deterministic and typed
• Agents never invoke tools directly
• Multiple tool requests are rejected

{
  state: "TOOL",
  tool_name: "<tool>",
  input: <ToolArgs>,
  output: <ToolResult>
}
            

After the tool completes, the Worker is invoked once more with the tool result.

State 4 — CRITIC

The Critic evaluates the Worker’s result against the original plan. It does not modify state or retry execution.

{
  state: "CRITIC",
  agent_id: "<critic-id>",
  output: {
    decision: "ACCEPT" | "REJECT",
    feedback: { ... } // required on REJECT
  }
}
            

State 5 — END

The Controller terminates unconditionally. The result is an immutable response object.

ControllerResponse {
  task: <DomainTask>,
  worker_id: "<worker-name>",
  worker_output: <WorkerOutput>,
  critic_decision: <Decision>,
  trace: [ ... ]
}
            

Key Guarantees

• Exactly one task per execution
• Finite, explicit state transitions
• No hidden retries or loops
• All side effects isolated
• Full trace available for audit or replay

Why This Matters

This traceability makes the system:

• Auditable
• Testable
• Cost-predictable
• Resistant to agent misbehavior

The trace is not a debugging artifact — it is a first-class architectural output.