Reasoning: how intent becomes a decision

What does the reasoning plane do?

Four things, in order:

• 1.Decompose the goal. "A PCI payments service, EU residency, staging and prod" becomes workload definitions, network policy, residency constraints, and a rollout sequence.
• 2.Assemble context. Pull what perception says is true and what memory says worked — nothing more, nothing less.
• 3.Check against policy. Reasoning happens inside constraints, not after them: the plan is validated against the policy plane before it is proposed, not repaired after it detonates.
• 4.Emit a decision. A structured artifact — proposed change, rationale, expected effects, confidence, escalation needs — that the rest of the pipeline can validate and a human can audit.

Why must reasoning be inspectable?

Because "the model decided" is not an answer; it is the beginning of an audit question. When an agentic platform proposes a change, the operator's questions are: what did it think the goal was, what state did it believe it was acting on, which policies constrained it, and why this plan rather than another? A reasoning plane that emits only an action — without its justification — makes every incident an archaeology dig. Observable reasoning is a design requirement, not a nice-to-have.

What are the failure modes?

• ✕Ungrounded planning. Reasoning without perception data produces plausible fiction. Grounding failures, not intelligence failures, cause most bad agent behavior.
• ✕Prompting as governance. A politely-worded system prompt is not a constraint. Policy belongs in enforced policy-as-code, where violations fail closed.
• ✕Plans without artifacts. If the plan exists only in a chat log, it cannot be reviewed, diffed, or improved. Decisions must be structured data.

Where does reasoning end and action begin?

At the decision boundary. The reasoning plane proposes; it does not execute. Between proposal and execution stand two gates: identity (who is acting, with what authority) and governance (what is permitted, what needs a human). In the demo, this boundary is visible as OPA feedback loops: the agent proposes, policy responds, the agent revises — three iterations, zero violations.