Anatomy of a request

An agent request crosses several components, each with a different responsibility. This example follows an expense claim from a client to a recorded decision.

From request to result

The path from endpoint through workflow

  1. An endpoint receives the claim and checks access.

  2. The component client locates the workflow instance by identity.

  3. A workflow step records progress and calls the policy agent with a recovery strategy.

  4. The agent declares its model request, tools, and session memory.

  5. Sanitizers and guardrails mask configured data and check the input before the model call.

  6. When configured, the model gateway chooses a destination and captures the exchange.

  7. The model asks for a tool that records the claim decision.

  8. A tool-call guardrail checks the request before the runtime invokes the tool.

  9. The entity validates the command and persists its decision event.

  10. The journal makes the event durable; subscribers receive it and cross-region replication distributes it asynchronously.

  11. The tool result returns to the model. Response guardrails check its final reply before it returns through the workflow and endpoint.

  12. The ledger holds the interaction record, including model and tool calls and their outcomes.

  13. A live evaluator assesses the completed interaction and records its verdict. Captured model traffic also feeds cost analysis and training.

Boundaries that matter

A workflow can retry an unfinished step after failure. External work started by the first attempt may already have taken effect, so tools and downstream services must handle retries safely.

Persistence and replication are different boundaries. An acknowledged local write may not yet be visible in another region or a view. Live evaluation is also separate from enforcement: a verdict produced after the interaction cannot change the reply already returned.

Next steps