Who Owns an AI Agent at Your Company: Six Responsibilities and Their Owners

Agentic AI means software that picks its own sequence of actions and calls tools, in place of following a fixed script. When such software runs inside a company, a plain question follows: which human answers for it?

Regulators haven't settled that. In a joint letter numbered SR 26-2, dated April 17, 2026, the Federal Reserve and the Comptroller of the Currency's office which replaced SR 11-7, the model risk-management guidance banks had worked under since 2011. The same letter withdrew the OCC's own bulletins on the subject going back to 1997. A footnote in it says generative and agentic AI fall outside the guidance. And the role of "model owner", which the old text spelled out in detail, doesn't show up anywhere in the new one.

Singapore went the other direction five months before. The Monetary Authority of Singapore's proposed AI risk-management guidelines, whose consultation closed in January 2026 and had no final version at the time of writing, bring AI agents squarely into scope. They warn that an agent with system access may carry out actions at odds with business objectives or customer interests, and they call for independent validation, meaning review by people who didn't build the system, before anything rated high-risk goes live. That text isn't law yet, and it would bind only licensed institutions in one jurisdiction.

Neither document says who inside a company is answerable for an agent once it's running, and that gap can't wait for a regulator to fill it. Software that acts needs an action boundary, meaning a line that separates what it may do on its own from what requires a human. Enforcing that line is a technical matter. Deciding who stands behind it is organisational, and no text covers it. What follows runs through everything an agent might do or get wrong, and for each one names the person who has to account for it. It looks at who signs off, how to fill the roles from existing teams, what operating the agent involves after launch, and what builders must learn. The evidence is regulatory text, studies published since 2024, and companies that attached their names to specific claims.

Six responsibilities, six owners

An agent in production creates six responsibilities, and each needs one accountable owner. Think of a responsibility chart: the accountable person answers for the outcome, a responsible person does the work, and a consulted person gives input without the final say.

• Business and domain. The business owner and the subject-matter experts. The owner is accountable for the use case, and one expert doubles as the standard owner, the person who knows the field well enough to rule on what is correct.
• Product and architecture. The architect, the product manager and the conversation designer.
• Data science and evaluation. This group designs the judge (an automated grader that scores outputs against the standard), reads the errors, and watches for drift, the gradual change in inputs or standards that leaves old tests stale.
• Operations. Keeps the system alive once it has launched.
• The validator. Reviews the system independently and took no part in building it.
• The vendor manager. Owns the contract, a seat that exists only if the company buys instead of builds.

Internal audit sits outside this list, since SR 26-2 says it would generally not duplicate model-risk activities. Several firms cited below (Kaiser Permanente, Thomson Reuters, Morgan Stanley) operate drafting and retrieval tools instead of fully autonomous agents, which makes them the closest public analogues available.

Business owner: approving what the agent may do

That approval spans scope, dollar thresholds and the customers the agent must not touch, tiered by risk as in Singapore's proposal. It also covers funding the system and eventually retiring it. Banks have a partial precedent for seating this role in the business. Under SR 11-7 the model owner was typically in the business unit, according to the OCC's 2021 examiner handbook, although that wasn't universal, and the 2026 revision removed the role with nothing to take its place.

The practical argument is stronger than the precedent. Each decision in that approval, whether a threshold, an excluded customer segment or a retirement date, trades revenue or service against risk. The only one who can make that trade, and be held to it, is whoever is answerable for how things turn out. Whoever sits in the seat needs both the budget and the off switch, and only the business owner has both: risk can stop what it can't fund, and engineering can build what it can't stop. Handing the seat to the builder would let the builder approve its own scope, and handing it to risk would leave nobody accountable for the benefit side. Singapore's wording points the same way, since it defines harm relative to business objectives and customer interests, and only the business can say what those are. Hong Kong's guidance puts the accountability with the board.

Architect: owning the design

The design settles where the agent halts and a human steps in. It consists of the process the agent follows, the handoff points to a person, and the permissions that prevent it from going further. The latter two together are the action boundary made concrete. Two companies placed the handoff in the same place. Kaiser Permanente's doctors edit an ambient-scribe draft before it reaches the medical record, and, per its own announcement, Morgan Stanley's Debrief tool has an advisor edit a meeting summary before anything is written to the customer database. Engineers, or a vendor, can build the permission model and the interface. Even so, the architect keeps the seat, because the position of the line is a design call that must hold up no matter who writes the code.

Standard owner: writing the rubric

A rubric is the checklist stating what a correct answer contains. At Thomson Reuters, senior lawyers at partner level devoted months to rubrics for a retrieval application. Summing up the result, they said was that a good answer has fifteen necessary components while a plausible-looking one has nine. Only a lawyer can distinguish fifteen from nine, which means the rubric consumes a domain expert's hours, and it needs a single owner because criteria shift when several people grade. A research paper on validating LLM validators found that criteria drift once grading begins, and a study by Shreya Shankar and Aditya Parameswaran of people using data-query tools reached the same conclusion, noting that the burden of validation lands on the user.

Setting the standard and measuring against it are two different jobs. Measuring, meaning the daily cycle of evals and error analysis, sits with the engineers and data scientists. They author the judge, assemble the harness (the code that runs test cases through the agent and grades the output) and study the failures that come out. The validator then looks at coverage and judge calibration, without rerunning the build team's tests.

Operations: keeping it running

After launch the work consists of on-call coverage, alert triage, shutdown and recovery, replaying the regression suite (the test cases rerun after every change) and watching usage and cost. Someone from the business joins the on-call rotation because certain alerts are business decisions. Scheduling, severity tiers and escalation belong to the operations owner, who is an engineer.

Validator: checking before launch

The validator's review has three parts. It probes for prompt injection (malicious instructions planted in material the agent reads) and for unauthorised tool calls. It inspects what personal data lands in the agent's trace, the log of its actions step by step. And it keeps an eye on the humans who approve what the agent does.

Vendor manager: holding the contract

The seat appears only when the company buys. A vendor then builds a slice of the system, runs a slice of the operation and produces evidence the validator must examine, and accountability stays where it was. Meanwhile every other owner depends on something that only the contract can deliver. The validator needs audit rights. Operations needs advance notice of model changes, because that is what starts the regression run. The standard owner needs a way to export traces and data, otherwise the company's eval has nothing to grade. The business owner needs exit terms, or shutting the system down becomes a negotiation rather than a decision. The vendor manager secures those four items without performing any of the four jobs. Procurement gets consulted on scope and acceptance and is accountable for neither.

Three of the six, owning the use case, deciding what counts as correct and checking results independently, are things a vendor's implementation team will not fill by itself. Assigning an owner to each is the connection the regulatory texts leave out.

Filling the seats from the teams already there

The roles get staffed from existing people, and order matters because each seat leans on the one before it.

Start with the business owner; until one exists, the project has to wait. That person controls budget, process and the authority to switch the system off, and begins by assigning a risk tier and approving what the agent can do. Engineering talent can't stand in for this role, as nobody else can be held to its trade-offs.

Next, the architect. Ideally this is someone who knows the business process and the system well enough to be answerable for where the agent ends and a human begins. Where that person exists, the seat is theirs. Where nobody fits, an outside party can kick off the work, though the company still has to name an internal recipient, since the seat can't sit vacant even when the work happens elsewhere.

Third comes the standard owner, and the deciding factor is whether the domain expert has actual hours to give. If time is protected, the expert writes the rubric, as the Thomson Reuters lawyers did. If not, product and design people draft it for the expert to sign off, and the standard drifts, since those who know what a good answer looks like aren't the ones putting it on paper. In his shareholder letter Jamie Dimon states the general rule: work that is a sliver of many people's jobs never gets finished, and the mission needs a team devoted to it full time.

Calibrating the judge and tracking drift, the measuring side of this seat, should go to a data or analytics group if the company has one. Otherwise a named member of the build team needs protected hours for it. Banks show how this changes the data-science team's role once the agent's model is supplied by a vendor. Modelling and fine-tuning go to the vendor, so data science can no longer be assumed to be the AI team. What remains is calibration and drift monitoring as a standing function, together with a fresh duty for the credit, fraud, pricing and forecasting models the team keeps building: stating each model's intended population before an agent is allowed to call it as a tool. Insurers and hospitals probably face the same question about their own models, but none of the sources reviewed here addresses them.

Fourth is the validator, and the deciding factor is the point at which compliance gets involved. Compliance can supply risk definitions from the outset, which Chime's compliance team reportedly does, or it can review only at the release gate, in which case a high-risk use case still needs independent validation before deployment, as Singapore's draft demands. For a bank, the model-risk function already in place looks like the easiest route, because SR 26-2 leaves agents uncovered and lets each institution decide. No source from 2024 onward reports a bank taking that step, though.

Fifth is operations, and the deciding factor is who monitors the system once it is live. The next section covers that.

Two items are shared by all use cases. First, the gateway, the one path every agent uses to reach a model, where identity is verified and calls are logged; the operations owner holds it. Wealthsimple has said roughly 80 percent of its LLM traffic passed through its gateway, which leaves open whether the rest is governed. Second, the measurement, meaning the harness and the judge, which data science or analytics owns jointly, since two teams grading themselves with two different instruments produce numbers that can't be compared. The remaining pieces, namely the use case, its rubric, its standard owner and its place on the rotation, stay with the business unit that runs it.

Mostly these seats stretch existing jobs and don't create new ones. A business owner who already carries the P&L adds scope approval. A domain expert adds a rubric to knowledge already in their head. An engineer picks up the judge and harness. Data science, already watching its own models for decay, extends that watch to the agent. Compliance folds risk definitions into a review it already performs. No new hires are implied. Only the validator's seat can't be stretched, since that job ends where building begins.

Running the agent day to day

After launch, six duties run for the life of the system. The operations owner takes four, the standard owner one and the validator one, and each needs a named person and a response time.

Alert triage goes to operations, with a business person on the rotation. Alerts aren't uniform: a permission error, an outage and a wrongly rejected claim each need different judgment, and the last is a business decision. Both Singapore's draft and the EU AI Act ask for an escalation process like this.

Shutdown is approved by the business owner and executed by operations, in four stages: an immediate stop, technical recovery, business correction and permission to restart. The EU AI Act says the overseer of a high-risk system must be able to halt it through a stop button or comparable procedure that leaves it in a safe state. The person who builds the button isn't the person who decides to press it. Closing the chat window doesn't cancel a payment or notification that is already queued, and business correction has no equivalent of a code rollback. So deciding to stop is a business matter, and carrying it out is an operations task.

Regression testing after a model change is a shared effort of data science, engineering and the business, with release signed off by the validator. Morgan Stanley's Assistant is the documented example: it runs on OpenAI models, yet the bank built its own evaluation framework. Advisors and prompt engineers grade a regression suite together daily, and the vendor provided neither the grading nor the standard behind it. The source for this is OpenAI, which gains from showcasing a customer, and it concerns a retrieval application. What starts the process is a change notice from the vendor, which the vendor manager must secure.

Usage and cost fall to operations, and the right unit is the finished task. Retries, evaluation and rework all belong to a task, and one model call is just a piece, so quoting per-call prices tells only part of the cost story.

Returning production failures to the eval is a continuing duty of the standard owner. In a talk republished by Arize, a company that counts Uber as a customer, Uber's conversation designer said the evaluator and its dataset are updated every week, on the reasoning that signal from a stale dataset is worse than none. That's a designer doing work the roles above give to engineers and data scientists. Chime's compliance signals reportedly reach the eval within hours, through an offline run scored after the fact.

Watching the approvers is the validator's ongoing job. Anthropic reports that around 93 percent of permission prompts for its coding agent are accepted, a rate high enough to suggest rubber-stamping and not real checking. It comes from a coding agent rather than a business-process one, so it illustrates the risk without quantifying it here. NIST's generative-AI profile, which is voluntary, suggests recording each time a person overrides the system's output, the same check seen from the opposite side.

These duties never end, and no public account reports the hours any one of them consumes. The rotation, the regression runs and the cost tracking can be bought from outside, which is a question for a later discussion.

What the team must learn, and how high the bar sits

Training raises three questions: what everybody on the team has to be able to do, where a specialist remains necessary, and what level of quality is good enough.

Four skills apply to everyone, whatever the job title:

• looking at traces and eval results first-hand, not relying on someone's summary
• reasoning about distributions of outcomes, not individual examples
• judging the work by the end state it left behind, not by what the agent says it did
• stating a task clearly enough to delegate it, then overseeing the outcome

Goldman Sachs's chief information officer, Marco Argenti, names that last sequence. In his words, leaders must master three management skills: describing a task, delegating it to an AI agent and supervising the results.

One half of the evaluation work still calls for a specialist. The loop of evals and error analysis, the everyday job of grading outputs and tracing failures back to causes, divides into a routine half and an occasional half. The routine half covers writing the judge, building the harness and reading each day's failures. It takes engineering skill and statistical sense, and employers increasingly list it under one title, AI engineer. DeepLearning.AI's Skills Map describes that role from postings and interviews, though its publisher sells the very courses those postings call for. The occasional half is calibrating the judge against human labels and assessing drift, better suited to a data scientist and mostly needed at review time. A non-technology enterprise would sensibly train software engineers for the AI engineer job and keep data science for calibration and for backing the validator's review. No study compares those two setups, and the Skills Map reports only what employers ask for.

The bar is to catch the kind of failure that tooling persistently misses, and that duty rests with the standard owner and the validator. In a 2026 study, Antaripa Saha and Hamel Husain, who teach a paid evals course, ran six automated review systems across 100 production traces holding 39 hand-labelled failures. The top system found 87 percent of the labelled failures, and the misses were systematic, with one class of failure slipping past every system. All of them also flagged failures the human reviewer had overlooked, so the scores don't amount to a ranking, and the data is a single dataset with one expert's labels. The study does show where humans remain needed: the standard owner, whose rubric defines what counts as a failure, and the validator, whose coverage check hunts for precisely what the tools miss.

The capability is built by showing people failures and sustained by scheduled review. Husain and Shankar, who disclose the same paid-course interest, divide the grading between engineers and product managers. Engineers catch technical problems such as retrieval faults and tool errors, while product managers spot product failures, for instance expectations users had that went unmet. A single decision-maker handles everyday grading, which is a different role from the validator's independent review. For buy-in they advise against pitching evals and recommend showing colleagues what turns up when they look at the data. Singapore's draft adds the other part: the capability itself must be reassessed periodically.

What this evidence can and can't support

Each piece of regulatory text and each named case traces to its own source, but the limits matter too. Regulation lists requirements, and SR 26-2 puts agentic AI outside its scope. The studies draw on data-query users, on 39 failures in one dataset and on a small qualitative sample. Kaiser, Thomson Reuters and Morgan Stanley's Assistant are retrieval or drafting tools, not multi-step agents acting on their own. No non-technology enterprise has published its agent team's roster, and the cited firms are those that chose to publish, so quietly failed projects are missing from the sample. Most such enterprises won't agonise over buying an agent platform; they'll choose one of the major cloud vendors and move on. The harder choice is outside help, whether consulting, staff augmentation or a forward-deployed engineer, and what remains once the engagement ends. All six seats stay in-house, and what can be bought is execution.

The Federal Reserve removed the model owner from its guidance in April, and Singapore had proposed five months earlier that an agent with system access be checked by people outside the build team. Neither text names who in a company is answerable for the agent. A company needs six named owners, starting with the business owner, who approves what the agent may do, pays for it and can stop it. Regulators no longer describe that role, yet it can't be left empty, since that approval sets the scope for everyone else's work. Marco Argenti's warning applies: delegating to an agent without being able to supervise it invites disaster, so people need a new sense of quality control and agency.