Contextual Agentic

Why Enterprise AI Needs a Deterministic Shell

Don't try to make the model deterministic or simply trust it. Let it propose, and put identity, authority, schema, state and commitment in a shell that decides at the Commit Boundary.

·9 min read

Written as at 5 August 2026.

deterministic-shellcommit-boundaryagentic-aiarchitectureai-governance

For: enterprise architects and CIOs. The decision: where determinism belongs once an agent can change production systems.

Agents have joined the change path, and their behaviour won’t repeat on demand

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

Imagine it is 2.10 am on a Saturday. A logistics company’s customer booking API has started refusing requests from its largest freight partner. The on-call engineer opens an incident, and an infrastructure change agent begins to work it: it reads the firewall logs, the change calendar and the partner’s recent notice that its traffic now comes from a new address block, 198.51.100.0/24.

Twenty minutes later the agent has a diagnosis and a fix. Allow TCP 443 from that block to the booking gateway, for twelve hours, under the open incident. It is probably right. The question this piece is about is what should happen between “probably right” and a changed firewall.

That question is no longer hypothetical. Agents are moving from summarising work to performing it, including in regulated workflows. OWASP’s 2026 Top 10 for LLM applications lists “Excessive Agency” at number three. Australia’s Guidance for AI Adoption asks organisations to maintain human control, and the amended EU AI Act applies its Annex III high-risk obligations from 2 December 2027.

Animated diagram of three planes. In the reasoning plane, the model interprets a request, plans and drafts a typed action. In the shell plane, the typed action passes schema validation, an authority lookup and a policy call before reaching the systems of record, with a commit boundary just before them. In the deterministic plane below, the schema registry, the authority store, the policy engine and the evidence log each check the action as it waits at the boundary.
Figure 1. The core proposes in language; the shell decides in code. Animated; shown as a still image if your device is set to reduce motion.

Neither a deterministic model nor a trusted one is on offer

Most teams reach for one of two answers. The first is to make the model behave deterministically: fix the temperature, pin the prompt, freeze the version. That narrows variation without removing it. Output still shifts with the context the agent retrieves, and providers retire model versions on their own schedule. A perfectly repeatable wrong answer would still be wrong.

The second answer is to trust the model and write the rules into its instructions. “Never open a rule broader than a /24. Never touch the payment zone.” These sentences read like controls, but they are advice. A model can misread them, skip them, or be talked out of them by content it retrieves, and the partner’s notice arrived as an email that anyone could have sent.

A third answer, putting a human approval on every step, fails more slowly. At 2 am an engineer approving a summary is not approving the rule that will actually be pushed.

The common error is expecting determinism from the wrong component. The model is valuable precisely because it handles what nobody wrote a rule for. Repeatability, authority and commitment have to come from somewhere else.

The CAE interpretation: put determinism around the model, not inside it

The Contextual Agentic Enterprise (CAE) is my proposed framework for letting people, models, agents and systems act together on enterprise context under delegated authority, with evidence. It is an architectural synthesis, not an industry standard, and its explanatory model for this problem is the Deterministic Shell / Probabilistic Core.

The Probabilistic Core is where the model works. It may interpret, classify, rank, form hypotheses and propose. The Deterministic Shell is everything around it that must behave the same way every time: who is acting and for whom, what shape a valid action takes, what this agent is permitted to do, which state transitions are legal, and whether anything is committed at all. The design goal is that a wrong model output cannot, by itself, make the system unsafe.

The shell is most decisive at the Commit Boundary, the point where a proposal would become an effect other systems or people can observe: money moves, a record changes, access is granted, or a firewall rule goes live. Upstream of that point, mistakes cost time. At it, they become consequences.

At the Commit Boundary the shell evaluates the action that will actually be committed, not the conversation that produced it, and it returns one of four outcomes: permit, deny, escalate to a person, or re-evaluate because an input is stale or inconsistent. None of this is new as security thinking. It applies complete mediation (Saltzer and Schroeder, 1975) and the reference monitor (Anderson, 1972) to a component that reasons in natural language.

Partition any agent decision with five questions

  1. What would change in the world? Name the effect. In our example, a firewall policy on the booking gateway. If nothing external changes, you may not need a Commit Boundary, though sensitive reads can still need mediation.
  2. Which parts are policy, and which are judgement? Rules that state what must always be true (rule width, permitted zones, emergency-change conditions) stay deterministic. Working out why the partner is being blocked is judgement, and belongs to the core.
  3. Is the proposal typed? The agent must emit a structured action: source range, destination, port, protocol, expiry and incident reference, each with a declared type and allowed values. A paragraph of reasoning is not an action.
  4. Does an external check decide, against current state? The shell verifies identity, schema, authority, policy, evidence and state, outside the model, at the moment of commitment.
  5. Does the effect go through a typed adapter? The permitted action reaches the firewall manager through an adapter that accepts only that action type, with an idempotency key and a record of what was committed.

Walk the 2.30 am proposal through step 4. Identity: the agent acts under its own registered identity, on behalf of the on-call engineer. Schema: the rule is well formed. Authority: this agent may add allow rules on the gateway’s edge zone, TCP 443 only, no wider than a /24, expiring within 24 hours, so it passes. Policy: the emergency-change policy requires an open priority-one incident, which exists. Evidence: because email is untrusted, the check requires the address block to match the partner registry, and the registry was updated on Thursday. State: the firewall policy must still be the version the agent read.

Now vary the facts. If the agent had proposed 198.51.0.0/16, 65,536 addresses instead of 256, the shell denies it: that sits outside the agent’s authority however good the reasoning. If the rule touched the payment zone, the shell escalates, and the on-call network lead approves that exact rule rather than a summary. If a colleague pushed a firewall change at 2.25, the shell returns re-evaluate, and the agent must propose again against the current policy.

The shell fails quietly when it drifts into prompts

The most common failure is shell drift. Controls that began as prompt instructions stay there, so each model upgrade changes enforcement without a change record. The /24 limit holds under one model and loosens under the next, and nobody notices until an audit or an incident.

Other failures follow the same pattern. The agent calls a “check policy” tool that it may choose not to call. Approval is stored as a yes/no flag and reused for a modified payload. The adapter accepts free text and runs with a broad administrative credential, the confused deputy that Hardy (1988) described. The check reads state cached at the start of the task rather than at commitment.

The shell also has limits worth stating plainly. It cannot make a proposal correct. A permitted rule based on a misdiagnosis still opens a port for twelve hours; the shell has only bounded how wide and how long. It does not decide what context the agent should see, and it does not stop an agent looping unproductively before it proposes anything. Those need their own constructs.

Each role owns a different part of the partition

Executives decide which decisions stay in rules, which may go to agents, and where human authority sits. Write those delegations down the way you would a financial delegation, with a named owner for each.

Architects design the partition: what the core may do (interpret and propose), what the shell owns (identity, schema, authority, state transitions, commitment), and where each Commit Boundary sits. Every path to a system of record should pass through the shell, with no side door for a service account.

Engineers implement and test a schema-validated proposal, a policy check the agent cannot skip, and a typed adapter. Then test the negatives: a /16 is denied, an edited payload invalidates its approval, a stale policy version forces re-evaluation, and a direct call with the agent’s credential fails.

The shell in one picture, and where the other constructs sit

Left-to-right flow diagram. Requests and context enter the Deterministic Shell, where the Probabilistic Core interprets them and proposes a typed action. At the Commit Boundary six checks run: identity, schema, authority, policy, evidence and state. Four outcomes follow: permit, deny, escalate to a human approver, or re-evaluate, which loops back to the core. Only permitted actions pass through a typed adapter to systems of record. Every stage writes to an evidence record.

The model proposes inside the shell; six deterministic checks at the Commit Boundary decide whether anything reaches a system of record.

The shell is the frame. The other CAE constructs fill in parts of it, and each gets its own Field Note in the coming weeks; the last column says when.

Construct Its role in the shell Treated in (forthcoming Field Note)
Commit Boundary Locates the point where a proposal becomes an effect The Commit Boundary (in two weeks)
Context Contract Declares what context a given agent purpose may receive, before it reasons Context Is Not a Prompt (next week)
Authority Envelope Bounds an agent’s tools, resources, actions, values, duration and kinds of side effect Delegation Is Not Authority (in eight weeks)
Minimum Action-Evidence Bundle (MAEB) A CAE design construct, not a standard: the least evidence a consequential action must carry, scaled to risk The Minimum Action-Evidence Bundle (in five weeks)
Evidence-First Decision Record Keeps claims, evidence, decisions and outcomes retrievable for later reconstruction Evidence-First Decision Records (in three weeks)
Loop Engineering Governs iteration with budgets and stop conditions held outside the model Loop Engineering (in ten weeks)
Agentic Flow Mining (AFM) Finds out how agents, tools and people actually executed Agentic Flow Mining (in eleven weeks)
Governance-to-Action Gap Measures the distance between declared and enforced governance Closing the Governance-to-Action Gap (in four weeks)

Key takeaways

  • Making the model deterministic and trusting the model are both the wrong target; put determinism in the shell around it.
  • The Probabilistic Core interprets and proposes, while the Deterministic Shell owns identity, schema, authority, state transitions and commitment.
  • The Commit Boundary is where the shell decides, and it evaluates the exact action to be committed against current state.
  • Every check returns permit, deny, escalate or re-evaluate, and only a permit reaches a system of record, through a typed adapter.
  • Controls written into prompts drift with each model change, so test the shell with negative cases that a prompt could never guarantee.

Sources and further reading

  • The Contextual Agentic Enterprise, Chapter 3.
  • Saltzer, J. H. and Schroeder, M. D. (1975). “The Protection of Information in Computer Systems”, in Proceedings of the IEEE, vol. 63, no. 9. https://doi.org/10.1109/PROC.1975.9939
  • Anderson, J. P. (1972) Computer Security Technology Planning Study, ESD-TR-73-51, US Air Force.
  • Hardy, N. (1988) “The Confused Deputy (or why capabilities might have been invented)”, ACM SIGOPS Operating Systems Review 22(4). https://dl.acm.org/doi/10.1145/54289.871709
  • OWASP GenAI Security Project (2026) OWASP GenAI LLM Top 10 2026. https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
  • National AI Centre (2025) Guidance for AI Adoption. https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-foundations
  • European Commission (2026) “AI Omnibus enters into force”. https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force

The full architecture is in the book

This piece gives the shell at the level of one decision. The Contextual Agentic Enterprise works through the whole partition: the spectrum from pure rules to bounded autonomy, how thresholds should and shouldn’t route work to people, why replay cannot undo a committed effect, and how the shell carries into legacy systems. More about the book.

This article is part of CAE Field Notes, a series accompanying the book, The Contextual Agentic Enterprise.

Read the book. Contents, editions and availability are on the book page.

Share

← All articles

Related