The Brain · 04 of 09

Canon Names

What each step is called in the repo, in the API, and everywhere else.

The confusion in this field is mostly vocabulary. Five vendors, five names for the same box. The canon column is the name the repo uses. The API name is what you will see in the Anthropic Messages API, which is the technical ground truth for this house. The aliases are what you will hear elsewhere.

#	Canon (circuit.ts)	Group	API name · technical	Aliases you will hear	Not to be confused with
01	Trigger	gate	the request that starts the run; there is no API object for it	invocation · entrypoint · event · wake · job · tick · turn start · "the user message"	The user message is one kind of trigger, not the definition of one. A cron tick is a trigger with no user.
02	Context	ring	`system` + `tools` + `messages[]` in the request body	prompt · prompt construction · context window · the messages array · conversation · "the prompt" · RAG (the retrieval part)	The context window is the size limit. The context is what you put in it. RAG is one way of filling it.
03	Breaker	inline	your code: `max_turns`, token/dollar ceilings; the API only has `max_tokens` per call	circuit breaker · budget guard · iteration cap · max iterations · loop limit · kill switch · rate limit	`max_tokens` caps one reply. The breaker caps the whole run. Different things.
04	Model	ring	`POST /v1/messages` → one `Message`	inference · completion · generation · sampling · LLM call · "calling Claude" · the API call · a turn	"Turn" is overloaded: some people mean one model call, some mean one user-assistant exchange. Say "pass" for one model call.
05	Decide	ring	read `stop_reason`: `tool_use` vs `end_turn` (also `max_tokens`, `refusal`)	routing · branch · the junction · "did it call a tool" · function-calling check	The model does not "decide to call" anything at this step. It already replied. The runtime reads the reply and decides which way to route.
06	Dispatch	ring	your code: iterate the `tool_use` blocks, look each up by `name`, run its function with `input`	tool executor · tool runner · function executor · harness · runtime · agent loop code · orchestrator · "the scaffold"	Dispatch is not in the model and not in the API. It is your code. The SDK's tool runner is a convenience wrapper around exactly this.
07	Execute	legs	the tool function itself, running; parallel when a reply has several `tool_use` blocks	tool call · function call · action · tool invocation · leg · capability · skill (in some frameworks) · HITL / approval gate / permission prompt (for the gated ones)	A "tool call" is the request the model wrote. Execution is the runtime actually doing it. Vendors use one phrase for both.
08	Return	ring	a `tool_result` block appended as the next user message, one per `tool_use_id`	observation (ReAct) · tool response · function response · tool output · feedback	Errors come back the same way, as text with `is_error: true`. They are not exceptions in the loop.
09	Final	exit	`stop_reason: end_turn` with text content	final answer · completion · assistant message · response · "it's done thinking"	Final is just Decide taking the other branch. It is listed as its own step so the second pass is visible.
10	Validate	exit	your code: parse against a schema; or force it with a tool whose input schema is the output shape (structured output)	structured output · JSON mode · output parser · schema check · guardrails · typecheck · coercion	Guardrails on input (safety filters) are a different thing that lives at Context, not here.
11	Commit	exit	your code: write to the store, respond, release the lock, log usage	persist · side effects · finalize · respond · memory write · "the run is done"	Memory is a store you write at Commit and read at Context. It is not something the model has.

Two more words that are not steps but get used as if they were: harness and scaffold mean the runtime as a whole (steps 01, 02, 03, 05, 06, 08, 10, 11 together). Orchestrator means the same thing when the tools being dispatched are other agents.