An agent is one participant in the enterprise's decision.

Written as at 3 November 2026. AI-assisted. The claim, amounts and identifiers are invented, and the interactive trace is scripted: no model runs in this page. Application requires organisation-specific architecture, security, privacy, legal, regulatory, operational, safety, accessibility, commercial and governance review, together with appropriate approvals.

Why the surrounding enterprise matters

An agent can interpret a request, retrieve a document and call an interface. Those are properties of the agent. Whether its proposal should change a record depends on things the agent does not own: who is asking, which version of the facts is current, what the rules say today and which system is allowed to commit the change.

Anthropic's Building effective agents (19 December 2024) distinguishes workflows, where models and tools follow predefined code paths, from agents, where the model directs its own steps and tool use. The page notes that much of its tooling discussion has since changed, so we use it only for that distinction.

The state behind a recommendation can change before anyone acts on it. A policy is superseded, an approval is withdrawn, a payment completes elsewhere. A system that treats retrieved context as permanently authoritative can produce a coherent recommendation whose assumptions have expired.

This is a claim about scope, not a claim that other agentic systems lack memory or contextual awareness. Many use retrieval, persistent state and feedback. CAE places those capabilities inside an explicit account of ownership, authority, operational effect and outcome measurement.

Ten responsibilities

Proposed CAE interpretation. A contextual agentic workflow is easier to reason about as ten cooperating responsibilities. They are responsibilities, not products: one platform may hold several, several services may share one.

Text description of Figure 1. Five groups from top to bottom: accountability (business process and ownership; identity and delegation), knowledge (enterprise data and knowledge; context assembly), reasoning (models and agents; orchestration and tools), control (policy and approval; operational systems, with the Commit Boundary marked between them) and learning (evidence and monitoring; evaluation and controlled change). Feedback returns to the process owner. Identity and policy checks recur along the path.

These are not a pipeline. Identity and policy decisions recur, and monitoring and human oversight can occur at several points. Real implementations also have to handle asynchronous events, failures and systems owned by different teams.

One fictional claim

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.

An invented insurer receives a claim for a damaged hedge trimmer. The customer supplies a receipt, a photograph and a request for AUD 480. An agent prepares a recommendation for an authorised claims officer.

Text description of Figure 2. Eight steps from top to bottom: the owner sets the task; the customer is identified; context is assembled from the claim record, the policy and the purchase record, each with its version; the agent drafts a proposal and lists what it could not verify; an officer approves the exact action; the payment service rechecks current state at the Commit Boundary; the result is paid, rejected or unknown; evidence and outcome measures return to the owner.

1. Ownership. The claims owner decides that the agent may assemble evidence and recommend, an officer approves and a payment service pays.
2. Identity. The customer signs in. That shows who is asking. It does not show the claim is eligible or that payment is approved.
3. Knowledge and context. The claim (version 3), the policy (version 7, with effective dates) and the purchase record are read. The agent receives only what the purpose needs, each reference with its version. The photograph is evidence to assess, not an instruction. A Context Contract, the CAE term for a versioned specification of what context a purpose may receive, makes that selection reviewable.
4. Agent and orchestration. The agent proposes paying AUD 480 and states what it could not verify: the photograph's date. The harness records the step and routes the proposal to a person.
5. Policy and approval. The amount is within the officer's AUD 500 limit. The approval is bound to this claim version, this amount and one request key (K-1). A remembered exception from an earlier claim is a precedent, not permission.
6. Operational system. The payment service owns payment state. What it checks is the next section.
7. Evidence and feedback. Request, sources, approval, checks and result are linked. The owner can compare reopened claims, corrections, time to resolution and officer workload together. These are proposed measures, not results.

The Commit Boundary

The Commit Boundary is a CAE construct: the point where a proposal would produce an externally observable effect, such as money moving, a record changing, an entitlement being granted or a message being sent. Approval happened against version 3 of the claim. By the time the request reaches the payment service the claim may differ. The owning system therefore checks its own current records at that point.

Text description of Figure 3. A proposal carries an approval bound to claim version 3, AUD 480 and key K-1. The owning system checks four things against its own records: the claim is still eligible, the approval and delegation are still valid, policy version 7 and the limit still apply, and K-1 is unused. Accepted: commit once, return a receipt. Rejected: for example the claim was put on hold; nothing is paid and the case returns to context assembly. Unknown: the reply was lost; ask for the status of K-1, record the result if settled, retry with the same key if not found, escalate to a person if unclear. Every path writes evidence.

Trace three outcomes

Step through the same claim under three conditions. Every control is a button and works from the keyboard. The three outcomes are also described in text below the trace.

• Current authority. The four checks pass. The service issues payment P-77 once and returns a receipt matching the key and amount.
• State changed. Another officer put the claim on hold, so it is now version 4. The claim-state check and the approval (version 3) fail. Nothing is paid, the service gives a reason, and the case returns to context assembly. The old approval does not carry over.
• Uncertain response. The service commits but the reply is lost. A timeout does not show whether money moved, so the workflow asks for the status of K-1. Here it is settled as P-77: record it, do not pay again. If the key were not found, a retry with the same key is the usual remedy; if unclear, a person decides.

Source finding, with limits. Key-based retry is a documented pattern, not a universal one. For API version 1, Stripe's idempotent requests reference says it saves the status and body of the first request made with a key and returns them on retries, and that a key reused with different parameters causes an error. The IETF Idempotency-Key header draft (version 08, 22 October 2026) proposes similar behaviour; it is a work in progress, not an RFC. Whether a particular service offers a key or a status lookup is a fact about that service.

Context, memory and authority are different things

Context is information supplied for a task. Memory is information retained from earlier activity. Authority is what an actor may do under current conditions. A remembered exception can help find a precedent. A retrieved policy can carry an effective date that excludes the present case. An identity token can name a service without encoding the business approval a payment needs. CAE's Deterministic Shell / Probabilistic Core is an explanatory model: the model interprets and proposes inside the core, while identity, permitted tools, schemas and action preconditions are enforced in software around it. That depends on complete mediation, correct rules and dependable implementation, and it cannot make a deterministic check decide whether the underlying facts are true.

Improvement is governed, and ACE is a different thing

Observations from completed and interrupted workflows can improve context selection, instructions, tool integration and evaluation, without changing model weights.

Source finding. Zhang and colleagues, in Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models (arXiv:2510.04618, listed as an ICLR 2026 paper; version 3 of 29 March 2026 opened), propose ACE, which treats context as an evolving playbook. They describe three roles: a Generator that produces reasoning trajectories, a Reflector that distils lessons and a Curator that integrates them as incremental updates. They report average gains of 10.6 per cent on agent tasks and 8.6 per cent on finance tasks against strong baselines, and note dependence on the quality of the Reflector and of the feedback signal. ACE is positioned as an alternative to updating weights; which is better depends on the task, data and constraints, and their results do not establish performance in a different enterprise.

CAE interpretation. ACE is a published research method for evolving an agent's context. CAE is a proposed enterprise architecture and operating model. ACE is not a CAE invention, and CAE is not a version of ACE. Neither requires the other. An ACE-style method could sit in the reflection and proposal stages of the loop below, with enterprise controls around it.

Text description of Figure 4. Seven stages in a loop: execution, evidence, reflection, a proposed context update, evaluation, approval and monitoring, returning to execution. Reflection is marked as a place where methods such as ACE may be used, credited to Zhang and colleagues. Approval is emphasised: the accountable owner can reject a change or roll it back.

A reflected lesson is a hypothesis. A proposed update has a scope, source evidence, an owner and a test plan. Evaluation includes failed and denied actions, changed business state and privacy limits. Source finding: NIST's AI Risk Management Framework Core describes measurement tied to the deployment context, monitoring in production and post-deployment plans covering feedback, incident response, recovery and change management. NIST AI 800-4, Challenges to the monitoring of deployed AI systems (6 March 2026), observes that monitoring practices and validated methods are still immature. These sources support context-aware evaluation. They do not endorse CAE.

Questions to take to your own enterprise

Recommendation. Choose one workflow with a clear owner and outcome, trace one case end to end, and test three conditions: a state change between approval and commit, a request the requester may not make, and a lost reply from the owning system.

• Who owns the decision and each exception, by name or role?
• Which source is authoritative for each fact, and how current is it?
• What does the agent receive for this purpose, and what is deliberately withheld?
• What does the owning system recheck at the point of effect, and what does it return when it refuses?
• What happens when a reply is lost, and does the real service support a status lookup?
• Who may approve a change to the workflow, and how is it reversed?

A bounded prototype against simulated services is a reasonable step before any production trial. This is a design suggestion, not a maturity model, and its value depends on the workflow and the organisation's ability to operate the controls it adds.

What this does not establish

A contextual design cannot guarantee that a model's interpretation is correct or that a policy is well written. An audit record does not show that a decision was fair. The claim, the trace and the figures illustrate a way to organise responsibilities and make assumptions testable. They are not an implementation, a benchmark or evidence that the arrangement improves outcomes. The page does not claim that ordinary agents lack memory, that adapting context always beats fine-tuning, or that any architecture guarantees safety or results.

Read further

• The full research article, with the sources and the same figures: From Agentic AI to the Contextual Agentic Enterprise on the Contextual Agentic research site.
• The book The Contextual Agentic Enterprise treats enterprise knowledge and organisational memory (Chapter 4), context engineering and in-context adaptation (Chapter 5), enterprise agent anatomy (Chapter 8), Agentic Flow Mining (Chapter 12), governance, explainability, evidence and human accountability (Chapter 16) and evaluation, reliability, observability and replay (Chapter 17).
• On this site: the CAE capability map, the discovery method, the fictional worked example and governed execution.