How Agents Process a Turn

When a message arrives, the agent does not generate a response from a static prompt. A structured evaluation engine reads the current interaction state, decides which context components apply, resolves conflicts between them, and assembles the precise set of instructions the model needs for this specific moment. Only then does the model act.

This page describes that per-turn pipeline. The individual context pages (Policies, Routines, Glossaries, Macros, Prompts, Variables) describe how to author each component. This page describes what happens to those components at runtime.

The core principle

The engine injects only the context that applies to the current turn, never the full library. A policy whose condition does not match is not loaded. A routine the agent is not currently inside is not visible. A glossary or knowledge-base result that is not relevant is not retrieved. The model sees a focused context window rather than every rule the project contains, which is what prevents instruction fatigue as the library grows.

This is also a security property. Because each turn exposes only the matched subset of the library, the behavioural surface available to adversarial probing is bounded and small, regardless of how many rules the project holds.

The six stages

Every turn runs through the same stages, in order.

1. Policy matching

All policies attached to the agent are evaluated against the current interaction state. Only those whose conditions match are loaded into context, and their actions are assembled into the prompt. Policies marked always_match: true are included on every turn without LLM matching, which is how compliance and safety rules fire reliably regardless of conversation topic.

When matched policies conflict, the priority relationships defined on the agent's Context step decide which instruction wins before anything reaches the model. Non-conflicting policies still apply. Entailment links can also activate additional policies when a source policy matches.

2. Routine evaluation

For each active routine, the engine evaluates the agent's current position and its immediate outgoing transitions. The agent sees only the current node and the edges leaving it, not the full graph. This adjacent-only visibility keeps long routines tractable and reduces the model's tendency to drift from the intended path.

A parallel check determines whether the latest input reverses a previous decision and requires re-entering an earlier routine node. If it fires, backtracking takes precedence over forward progression.

When no routine is active, or when the user's message falls outside the current routine's scope, the engine evaluates which routine should activate based on the conditions each routine declares. When more than one could apply, priorities decide.

3. Tool and think execution

Tools associated with matched policies or the current routine node are evaluated for applicability, parameter availability, redundancy, and fit, then called over MCP. Tools that perform consequential operations (payments, deletions) pass through stricter validation than read-only tools.

Think nodes produce structured output matching a declared schema without ending the turn, so think and tool steps can chain within a single turn.

Results from both tools and think nodes are cached in the session store and become available to subsequent stages.

4. Preparation loop

If tools or think nodes ran in stage 3, the engine does not proceed directly to the response. Instead it loops back: policy matching, routine evaluation, and execution repeat against the updated state. This is how the agent reacts to new information within the same turn.

The loop runs up to max_engine_iterations (default 5, configurable on the agent's Advanced step). A policy with a reevaluate_after field triggers re-matching of that specific policy after the listed tools execute, which is the mechanism that keeps enforcement structural across tool calls rather than relying on the model to remember to check.

The loop exits when no further tools or think nodes need to run, or when the iteration cap is reached.

5. Response generation

The model produces the customer-facing reply in a single call, grounded in exactly the context the engine assembled during the preceding stages: the matched policies and their actions, the current routine state, tool and think results, glossary terms, retrieved knowledge, and the system prompt.

The agent uses two independent model lanes. The customer-facing model writes the reply (and the preamble, when configured). A separate evaluation model handles the engine's internal decisions: policy matching, routine evaluation, and think-node inference. This separation means the model writing the response is not the same model deciding which rules apply, which prevents the response model from selectively ignoring its own instructions.

6. Event emission

The turn's outcome is emitted and captured as a trace, recording which policies matched and why, which routine state was selected, what tools were called with what parameters, and the model's reasoning at each decision point.

These traces are not a logging layer added after the fact. They are a structural output of the pipeline, designed for governance, quality assurance, and iterative improvement. When an agent produces a bad response, the trace contains the exact stage and the exact decision where the error originated, which means the fix is a targeted edit to the responsible component rather than a speculative prompt rewrite.

How each component participates

Every context component enters the pipeline at a specific point and in a specific way.

Policies are matched in stage 1 and re-matched in stage 4 when their reevaluate_after tools execute. Their actions become instructions in the response prompt. Policies marked always_match: true bypass matching and are included on every turn.

Routines are evaluated in stage 2. The active routine's current node determines what the agent does (chat, call a tool, reason, insert a macro), and its transitions determine where the agent can go next. Only the current node and its immediate edges are visible to the model.

Glossaries ground the agent's interpretation of domain terms across every stage. When the engine or the model encounters a term defined in an attached glossary, the glossary's description and synonyms inform how it is understood.

Macros are injected at stage 5 when a routine's chat_state node references one. The macro's text is inserted at the call site, so the same approved wording appears wherever it is used without the model rephrasing it.

Prompts define the agent's persistent identity and behavioural baseline. The system prompt is present in every call, providing the foundation that the dynamically assembled context builds on.

Variables carry contextual attributes (customer state, session data, account flags) that policies and routines can reference. They are persistent data fields in JSON format that survive across conversation sessions. (How variables enter the engine's evaluation at runtime is being documented.)

Tools are called in stage 3 when a matched policy or the current routine node names them. They are served over MCP and namespaced by their integration prefix. Tool results feed the preparation loop in stage 4.

Knowledge base results are retrieved when the agent has a grounding source configured. The engine rewrites the user's message into search queries, retrieves matching content, and includes it in the response context at stage 5.

Worked example

A customer writes: "I need to cancel my subscription, and also check if my last invoice was correct."

A workflow framework would have to route to one topic and drop the other, or pre-define every compound branch. The evaluation engine handles it as follows:

1. Policy matching activates the cancellation policies and the billing policies simultaneously, loading both into the same context window.

2. Routine evaluation determines which routine (or routines) to enter based on the declared conditions and priorities.

3. Tool execution calls the relevant tools (account lookup, invoice retrieval) as needed by the active routine nodes.

4. Preparation loop re-matches policies against the updated state after tools return, so any post-tool rules (such as a retention offer triggered by cancellation intent) fire correctly.

5. Response generation composes a single reply grounded in all matched policies, routine state, and tool results.

6. Event emission records the full trace for review.

The compound request is handled natively because context is assembled dynamically per turn, not routed through predefined branches.