Executive Summary
- Interleaving reasoning and mutating tool calls in a single loop causes compounding hallucinations.
- A plan must be constructed as an immutable Directed Acyclic Graph (DAG) before mutating actions execute.
- The Action Boundary intercepts proposed tool calls and verifies schemas, rate limits, and authorization.
- Observable action traces provide deterministic auditability without exposing private model reasoning.
- Replanning must be an explicit state transition triggered only when a tool execution violates expected post-conditions.
The failure mode of interleaved reasoning and action
In simple agent frameworks (such as basic ReAct loops), planning and execution are tightly coupled into a single recursive loop. In this model, the agent generates one thought, calls a tool, observes the output, generates the next thought, and immediately calls another tool.
While this works for simple 2-step lookup tasks, it degrades rapidly on complex engineering workflows. When an agent encounters an unexpected observation at Step 4, it often loses track of the overall goal, edits files erratically, and executes mutating commands without understanding the downstream consequences.
This compounding error pattern is known as cascading hallucination. To prevent it, production software must strictly separate the cognitive planning phase from the execution phase.
The ReAct fragility ceiling
Naive ReAct loops cannot handle tasks requiring more than 10 sequential steps. Without an immutable plan DAG, models suffer from goal drift and execute redundant mutations.
Constructing the immutable planning DAG
In a decoupled architecture, the agent begins by generating an explicit, structured execution plan represented as a Directed Acyclic Graph (DAG).
The plan defines each sub-task, its expected inputs and outputs, its tool dependencies, and its verification criteria (post-conditions). Crucially, during this planning phase, the model is strictly forbidden from executing any mutating tools. It can only execute read-only inspection tools (like file reading or database searching).
Once the planning engine produces a valid DAG, the graph is locked and saved to disk. This static artifact serves as the single source of truth for the entire workflow.
Plan-and-Execute architecture boundary
Mutating tools can only be invoked after the planning DAG is structurally verified and locked.
The Action Boundary: Schema, policy & budget gates
The Action Boundary is the physical gatekeeper between the planning model and external systems of record. When the worker begins executing the plan DAG, it submits proposed actions to this boundary.
The Action Boundary evaluates three critical gates before allowing a tool call to proceed: Schema Verification (ensuring all parameters match Pydantic/JSON Schema contracts), Authorization Policy (verifying the task's Non-Human Identity token has permission for this operation), and Execution Budget (ensuring token and dollar limits are not exceeded).
If an action violates any of these gates, execution halts immediately, protecting backend databases from unauthorized or malformed mutations.
Action contract TypeScript schema
Below is a strongly-typed TypeScript schema representing the contract between an immutable plan node and its sandboxed execution.
Observable execution traces vs private reasoning
In enterprise software, opacity is a major liability. However, exposing raw, unformatted model internal reasoning creates security risks and makes logs difficult to parse.
Instead, we record observable action traces. An action trace logs only the structural decisions: the node being executed, the verified tool inputs, the duration, the sandboxed execution environment ID, and the returned status code.
This provides compliance officers and engineering teams with a clear, auditable execution stream that can be queried and analyzed in standard APM and observability dashboards (like Datadog or OpenTelemetry).
Observable trace vs Raw chain-of-thought
| Feature | Dimension | Raw Internal Reasoning | Observable Action Trace |
|---|---|---|---|
| Structure | Unstructured natural language text | Strongly-typed JSON schema envelopes | |
| Auditability | Difficult to parse and query programmatically | Queryable via standard OpenTelemetry spans | |
| Security Risk | Can leak internal system prompts or PII | Sanitized tool parameters & output hashes | |
| Determinism | Probabilistic and non-reproducible | Deterministic record of inputs, outputs & exit codes |
Designing deterministic replanning triggers
What happens when an action fails? If a unit test fails or an API returns a 404, the agent must not blindly retry the same command in an infinite loop.
Replanning must be an explicit, controlled state transition. When an action fails to meet its expected post-conditions, the execution worker pauses, packages the failure observation into a structured diagnostic report, and invokes the Planning Engine.
The Planning Engine generates a delta plan—modifying only the failing node and its downstream dependencies while preserving successfully completed parent nodes. This prevents unnecessary rework and saves token budgets.
Deterministic replanning cycle
Plan-and-Execute implementation checklist
Ensure your agent platform enforces these boundaries before running autonomous tasks.
Plan vs execution checklist
1Planning Space Isolation
- Planning phase is strictly restricted to read-only inspection tools
- Plan DAG is fully serialized and locked before execution begins
- Each plan node defines clear post-condition success criteria
2Action Boundary Enforcement
- Tool parameters are validated against strict JSON schemas
- Execution budget circuit breakers terminate runaway iterations
- Mutating operations run inside isolated ephemeral sandboxes
3Observability & Replanning
- Action traces are emitted as structured OpenTelemetry spans
- Replanning updates only affected downstream DAG nodes
- Audit ledgers record verified inputs, outputs, and exit codes