Who Does What in a Contextual Agentic Enterprise?

For: chief executives, boards and the leaders and practitioners who work with them. The decision: who owns what before an AI agent takes part in real work.

From isolated AI tools to shared work around an outcome

Most AI tools in an enterprise still sit beside the work: a person asks, reads the answer and decides what to do. An agent changes that. It can read a case, call a tool and propose a change to a system of record, sometimes several times in one run. The question stops being ‘which model?’ and becomes ‘who is responsible for what when software takes part in the work?’

This is the first article in a proposed series, The People and Roles of the Contextual Agentic Enterprise. It sets out a working division of responsibilities, follows one illustrative request through it, explains where an agent harness fits and where it stops, and ends with a 30-day plan. The Contextual Agentic Enterprise (CAE) is a framework proposed by Contextual Agentic: a vendor-neutral way of describing how people, models, agents and systems act together on enterprise context, under delegated authority, with evidence and measurable outcomes. It is not an industry standard.

Two cautions apply throughout. The eight roles below are an editorial recommendation, not a role taxonomy the market has validated. And many organisations will not need new job titles: an enterprise may spread these responsibilities across several teams, while a start-up may hold all of them in two or three people.

What changes when an agent joins a workflow

Three shifts matter more than the technology.

Delegation replaces tool use. A person using a tool is the actor. An agent acts for someone, so someone must define on whose behalf, within what limits, and who may stop it. Recommendation Is Not Authority develops the point: a confident output is not permission to act.

Outcomes cross team boundaries. Context sits in a data platform, the model call in an engineering team, the action in a business system and the risk view in a second line. Each team can do its part well while nobody owns the result.

Evidence and recovery become design requirements. When software acts many times a day, reconstructing what happened, and recovering from a bad or uncertain action, has to be designed in before launch. Evidence-First Decision Records covers the record side.

What an agent harness is, in plain language

Anthropic’s engineers describe an agent harness (also called a scaffold) as the system that lets a model act as an agent: it processes inputs, orchestrates tool calls and returns results (Grace et al., 2026). A second Anthropic post describes the harness as the loop that calls the model and routes the model’s tool calls to the infrastructure that carries them out (Martin, Cemaj and Cohen, 2026). In short, the harness is the code around the model that turns a single response into a working run.

In CAE terms, and as an interpretation rather than a standard, a harness typically takes on some or all of these jobs:

• knowing what the run is for and which identity it runs under;
• assembling the context the task needs, and no more;
• planning and looping, within limits on steps, time and spend;
• checking a proposed action against policy before a tool is called;
• executing the tool call;
• observing the result and recording what happened; and
• feeding evaluation, so quality is measured and not assumed.

Which of these a particular harness does varies by product and design. Two points from the same sources are worth keeping. An evaluation harness is separate infrastructure that runs evaluations, so evaluating ‘the agent’ evaluates the model and the harness together (Grace et al., 2026). And a harness can do security work: Anthropic describes keeping credentials unreachable from the sandbox where model-generated code runs, so that a prompt injection that compromises the sandbox does not expose them (Martin, Cemaj and Cohen, 2026).

Where the harness stops and the enterprise starts

A harness can coordinate one agent’s run and apply checks inside it. It cannot, on its own, be the enterprise’s authority. Three reasons.

The business system holds the truth about current state. A check inside the harness works from a snapshot of an order, a balance or an entitlement. The system of record knows what is true now. That is the idea behind the Commit Boundary, a CAE construct for the point where a proposal would become an effect, and the Deterministic Shell: let the model propose, and make identity, authority, state and commitment deterministic around it.

Controls only bind the paths that use them. Another client, a script or a different agent may reach the same business system. OWASP’s guidance on excessive agency recommends complete mediation: downstream systems check every request against policy, instead of relying on the model to decide what is allowed (OWASP, LLM06:2025).

Exceptions and outcomes belong to people. A harness can route a case to a person. It cannot own the queue, the response time or the decision to change the limit.

None of these controls guarantees safety. A policy gate encodes the rules someone wrote, and rules miss cases. Human review depends on what the reviewer is shown and how much attention it gets: Anthropic reports that users accepted 93 per cent of manual permission prompts in one coding tool, a figure it links to approval fatigue. The same post reports that its automated classifier missed 17 per cent of a set of 52 real overeager actions, and says it is not a replacement for careful human review on high-stakes infrastructure (Hughes, 2026). That is a different setting from a business workflow and the figures do not transfer, but the caution does. Model confidence is not a safety property either. Safety comes from several independent controls, each with a named owner, and some risk remains.

One illustrative example: a refund request

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 online retailer lets customers ask for refunds in chat. A customer reports that a lamp arrived damaged and asks for $140 back on one order. The figure below follows the request through five parties.

The chief executive’s outcome and risk boundaries. The outcome is to resolve valid refund requests within a working day without paying anyone twice or paying without authority. The board’s stated appetite, in this example, is that the agent may prepare any refund and send refunds up to $100 on a delivered order to the refund service, while anything larger needs a named person. The CEO does not design that rule. The CEO decides that it must exist, who is accountable for it, and what the organisation will not accept.

The service owner’s accountability. The head of customer service owns the refund process end to end: cycle time, correct refunds, open exceptions and the authority to pause it. With finance, this owner sets the $100 limit, names the approvers and owns the exception queue. Technology and risk teams support the owner. They do not replace the owner.

The architect’s and engineers’ design. The architect decides that the agent never calls the payment function directly. It submits a typed refund proposal to a gate, and the refund service is the only component that moves money, with one request key per intended refund. Engineers build the harness: the context it may read (the case, the order, the refund policy), the tools it may use (read-only lookups and ‘propose refund’), limits on steps and spend, and a trace of every run. They test against tasks graded on the final state of the order system, not only on what the agent said, an approach set out in Anthropic’s guidance on evaluating agents (Grace et al., 2026).

The agent’s bounded role and the human’s decision rights. The agent reads the message, the order and the policy, and proposes: refund $140, reason ‘damaged on delivery’, evidence attached. It cannot approve its own proposal, raise its own limit or see card details. Because $140 exceeds its limit, the gate sends the exact action to a reviewer, who may approve, change or refuse it. The approval binds to that payload. An approval for $140 on this order is not permission for $400 on another. The reviewer decides what the agent may not, and that decision is only as good as what was put in front of them.

How the target system checks current state and authority. The refund service does not accept the gate’s word. It checks for itself that the order exists, was paid and delivered, and has not already been refunded for the same item. If a colleague had refunded $60 by phone an hour earlier, the service would refuse a $140 request however many upstream checks had passed. It also checks that the approver holds refund authority at this amount now, not when the policy was written, and on whose behalf the agent acts. Delegation standards draw the same line: in OAuth 2.0 Token Exchange, impersonation gives the requester all of a subject’s rights, while delegation lets the requester keep its own identity and carries both parties in the token (RFC 8693). Standards work on agent identity and authorisation is still early; NIST’s National Cybersecurity Center of Excellence has published a concept paper, not a finished guide.

What happens after a timeout, failed action or uncertain outcome. The refund call times out. Was the customer refunded? Nobody knows, and the rule is not to guess. The system does not tell the customer ‘refunded’ or ‘failed’, and it does not submit a new refund. It repeats the request with the same request key. Where a payment provider supports idempotency keys, a repeat with the same key is recognised as the same request: Stripe’s documentation says its v1 API saves the first request’s result and returns it on retries, and an IETF draft specification asks servers to reject a reused key with a different payload and to answer a retry that arrives while the original is still running with a conflict. That draft is a work in progress. Without such support, the gate asks for the refund’s status and reconciles. If the outcome is still unknown after an agreed time, the case goes to the owner’s exception queue and the customer is told the refund is being processed. A refund that fails outright is a named exception, with a person informed and no silent retries beyond a cap. The wider recovery questions are covered in Checkpointing Is Not Rollback.

What evidence is recorded and how the outcome is measured. For each request the record holds the customer’s message, the context version, the proposal, the policy decision, who approved which payload, the request key, the refund service’s response and the final order state. The measures belong to the owner: refunds that were correct and not reversed or disputed (the accepted outcomes), time to resolution, open exceptions, how often reviewers changed or refused a proposal, and cost per accepted outcome, including review time and retries. These are proposed management measures, not proof that the workflow is safe or valuable. Productivity Is Not Headcount Reduction explains why the denominator matters.

Who does what: eight roles and their first actions

The table is a starting point for a conversation, not an organisation chart. Titles vary, and one person may hold several of these hats.

How a small team combines these roles

A start-up does not need eight people. It needs each responsibility to have a name beside it. One founder may be product owner, engineer and service owner at once. Three habits help. Keep a second check in the business system (a payment limit, a database permission) so the founder’s attention is not the only control. Avoid having one person write the rule, approve the exception and review the evidence for high-impact actions, or record that concentration as a known risk and revisit it as the company grows. And keep a one-page record of limits, approvers and the stop procedure, so the knowledge does not live in one head.

An enterprise has the opposite problem: responsibilities are split across teams that each own a slice, and the risk is the gap between slices. The first job there is to name one owner for the outcome and make the handoffs explicit.

A 30-day starting plan

Guidance, not a standard, a method or a guarantee. Adapt it to your organisation, and expect to do parts in a different order. Application requires organisation-specific architecture, security, privacy, legal, regulatory, operational, safety, accessibility, commercial and governance review, together with appropriate approvals.

Week 1: choose and frame. Pick one workflow with a clear outcome, a bounded value at risk, a reachable system of record and a willing service owner. Write the outcome, what is unacceptable, the accountable owner and the approvers.

Week 2: map the path and the authority. Draw the path from request to effect and mark where a proposal would become a change. List the systems the agent can reach. Write limits (amounts, targets, times) and which actions need a person. Decide how the target system will check state and authority for itself.

Week 3: build the smallest version that leaves evidence. Start with read-only tools plus a proposal tool. Add request keys, an exception queue and a record. Build an evaluation set from real past cases, graded on the end state of the system. If a single call or a fixed workflow does the job, use that; Reactive or Agentic shows how to choose.

Week 4: rehearse and decide. Run the awkward cases: a timeout, stale state, a refused approval, a revoked approver, a pause. Review the measures with the owner. Decide whether to stop, continue or widen the limits, and record the decision and who made it.

Thirty days will not produce a production system. It should produce a bounded pilot, a named owner and the evidence for the next decision.

Questions for leadership

1. Which agent-assisted workflows exist or are planned, and who is the named owner of each outcome?
2. What will the organisation not accept, and is that written in terms a system could enforce?
3. For each consequential action, which system decides whether it happens, and does that system check current state and authority itself?
4. Who can approve and who can pause, and has that been tested under time pressure?
5. What do reviewers actually see when they approve, and how would we know if they were approving by habit?
6. If an action times out or its outcome is unclear, what happens, and who is told?
7. What evidence is kept for each action, who can read it, and for how long?
8. How are accepted outcomes and the cost of review and recovery measured, and who reviews them?
9. Where does one person or team hold several of these responsibilities, and was that a choice?

NIST’s AI Risk Management Framework is voluntary, and OWASP publishes a peer-reviewed Top 10 for Agentic Applications for 2026. Neither mandates this role list. Use them as references for the risk conversation, not as proof that the list is complete.

A short glossary

• Agent. Software that uses a model to decide its own steps and tool use towards a goal, as opposed to a workflow, where predefined code decides the path (Anthropic, 2024).
• Agent harness. The system around a model that lets it act as an agent: it handles inputs, orchestrates tool calls and returns results.
• Evaluation harness. Separate infrastructure that runs evaluations and grades the results.
• System of record. The business system that holds the authoritative state, such as the order or the ledger.
• Delegated authority. The limits within which a person or role lets an agent act on its behalf.
• Commit Boundary (CAE term). The point where a proposal would become an externally visible effect.
• Idempotency key. A client-supplied identifier that lets a server recognise a retry as the same request.
• Accepted outcome. A result that is correct, stays correct and is accepted by the owner, not merely a step that completed.

What is sourced and what is proposed

Sourced: the harness and evaluation harness definitions, the credential example, grading the final state, the approval and false-negative figures, complete mediation, delegation versus impersonation, and idempotency-key behaviour. Proposed by CAE: the list of harness jobs, the eight-role view, the refund example and its limits, the 30-day plan and the leadership questions. Test them in your own context.

Sources and further reading

• The Contextual Agentic Enterprise, Chapters 8, 16 and 22 (chapter titles as listed on the book page).
• Grace, M., Hadfield, J., Olivares, R. and De Jonghe, J. (2026) “Demystifying evals for AI agents”, Anthropic Engineering, 9 January 2026.
• Martin, L., Cemaj, G. and Cohen, M. (2026) “Scaling Managed Agents: Decoupling the brain from the hands”, Anthropic Engineering, 8 April 2026.
• Anthropic (2024) “Building Effective AI Agents”, 19 December 2024. The page notes that some of the tooling it describes has since changed.
• Hughes, J. (2026) “How we built Claude Code auto mode: a safer way to skip permissions”, Anthropic Engineering, 25 March 2026.
• OWASP GenAI Security Project, “LLM06:2025 Excessive Agency”, OWASP Top 10 for LLM Applications 2025.
• OWASP GenAI Security Project (2025) “OWASP Top 10 for Agentic Applications for 2026”, 9 December 2025. Landing page only.
• NIST, “AI Risk Management Framework” (AI RMF 1.0, 26 January 2023; under revision).
• NIST NCCoE, “Software and AI Agent Identity and Authorization”, concept paper stage.
• Jones, M. et al. (2020) “RFC 8693: OAuth 2.0 Token Exchange”, IETF, January 2020.
• Stripe, “Idempotent requests”, API reference. One provider’s documented practice, not an endorsement.
• Jena, J., Dalal, S. and Tishkin, D., “The Idempotency-Key HTTP Header Field”, Internet-Draft, version 08, 22 October 2026. A work in progress.

The book develops the operating model

The book sets these ideas out at greater length in its chapters on enterprise agent anatomy, on governance, evidence and human accountability, and on the operating model. More about the book.

This article opens The People and Roles of the Contextual Agentic Enterprise, a series that accompanies the book, The Contextual Agentic Enterprise.