There is a question worth asking at your next steering meeting, and it is more uncomfortable than it sounds. Your ERP now contains AI agents, vendor-supplied ones in finance, service or supply chain, possibly some you built. Who is accountable for validating that they behave correctly?
In most organizations the answer is a pause, then a few names offered tentatively, then a discussion about whether it is really a testing problem or a governance one. Nobody is being evasive. The question genuinely has no answer in most org charts, and it is worth understanding why before trying to fix it, because the reason is structural, and structural problems do not respond to being pointed out.
What follows is about building an agent testing team that actually works: why ownership falls through the gap, the three capabilities that have to meet in one place, whether this needs a centralized function, and a starting allocation of responsibilities you can argue with.
Why Nobody Owns It
For roughly the last decade, the industry moved testing into delivery teams. Central QA departments were dismantled for reasons that were largely sound, they became bottlenecks, sat too far from the work, and created handoffs that slowed everything down. Quality became everyone’s responsibility, embedded in the squad that built the thing.
That model rests on an assumption so obvious nobody stated it: every piece of software belongs to a team.
A vendor’s embedded AI agent belongs to no team. Nobody in your organization built it, so nobody in your organization inherited it.
When Microsoft ships a Copilot into Dynamics 365 Finance, or SAP embeds Joule into a procurement flow, which squad owns validating it? There is no answer, because the allocation rule was authorship and there was no author. The agent arrives in a release, changes behavior in a subsequent release, and sits in a business process that several teams touch and none owns.
Two further properties make the gap wider.
- Agents cross team boundaries by design. A finance agent that queries inventory and triggers a workflow spans three teams’ territory. Embedded ownership works when a system has a boundary; agents are valuable precisely because they do not respect one.
- The risk is enterprise-scale while the ownership model is team-scale. An agent posting to the ledger is a company-level exposure, audit, regulatory, financial. Embedded QA was designed to catch defects in a product increment, not to hold a control that the CFO signs off on.
So the gap is not negligence. It is what happens when a new category of software arrives that the existing allocation rule cannot place. Which means the fix is not more diligence from the current owners, it is a deliberate decision about where this sits.
Where Ownership Currently Lands, and Why Each Placement Fails
In practice, organizations default to one of four homes. Each is a reasonable guess, and each fails in a specific and predictable way.
The functional or ERP team
The most common default: you own Dynamics, so you own its agents. This team has the one thing that cannot be taught quickly, they know what correct looks like for the business process. What they lack is testing discipline and spare capacity. They will validate by using the system and forming an impression, which catches obvious breakage and misses everything quiet. They also have no habit of producing evidence, because nobody has ever asked them to.
The QA function, where one still exists
Has the discipline, the tooling and the instinct for constructing evidence. Lacks domain depth on the specific business decisions an agent is making, and frequently lacks standing, in many organizations the central QA function was reduced precisely because the embedded model replaced it. Asking a diminished team to take on a new enterprise-scale risk tends to produce a coverage plan rather than coverage.
The AI, data or innovation team
Understands agents, non-determinism, prompts, model behavior, why the same input can produce different valid outputs. This is genuine and scarce knowledge. What they usually do not have is the business process context or the control mindset. They will evaluate an agent on quality of output rather than on whether a posting was correct and evidenced, which is a different and insufficient question.
Internal audit or risk
Will reliably ask the right question, show me what this agent did and why, and cannot answer it themselves. Audit is designed to test whether a control exists and operates, not to be the control. When agent validation lands here it becomes a finding rather than a practice, which is how organizations end up with a documented gap and no one closing it.
THE PATTERN Each of the four holds one of the three things agent validation requires, and each is missing the others. That is why moving ownership between them does not help, and why the answer is never simply “give it to QA.” This is an intersection problem, not a headcount problem.
The Three Capabilities That Have to Meet
Validating an agent properly needs three distinct capabilities present on the same problem at the same time.
| Capability | What It Answers | Who Usually Has It |
| Domain judgement | Is this outcome correct for our business? Would a good employee have done this? | Process owners in finance, supply chain, service |
| Validation discipline | How do we establish that reliably, repeatable, and at what scope? | QA and test engineering |
| Control and evidence literacy | What would an auditor or regulator accept as proof this held? | Internal audit, risk, finance control |
| Agent behavior literacy | Why did it do that, and is the variation acceptable? | AI or data teams, the genuinely new one |
The first three exist in every organization of any size, in different departments, reporting to different executives, with different incentives. The fourth is newer and thinner, and it is the one worth deliberately building rather than hoping to hire.
Nearly every failed attempt at an agent testing practice is an attempt to solve this with one of the three. Give it to the process owner and you get domain judgement with no evidence. Give it to QA and you get rigorous validation of the wrong assertions. Give it to audit and you get a well-documented description of the problem.
The practice you are building is not a team. It is a standing arrangement that puts three capabilities on the same question, and the hard part is organizational, not technical.
Does This Need a Testing CoE? The Uncomfortable Answer
The instinct, faced with an intersection problem and an enterprise-scale risk, is to create a central function. A testing center of excellence, or a quality engineering group, owning agent validation across the organization.
This is awkward, because the industry spent a decade arguing that testing centers of excellence were the problem. The critique was real: they concentrated skill away from where the work happened, created queues, and turned quality into something requested from another department rather than built in. A good deal of that critique still stands.
But agent validation has three properties that the embedded model genuinely cannot serve, and they are worth stating plainly:
1. The subject has no team. Vendor agents belong to nobody, so a model that allocates by ownership cannot allocate them at all.
2. The standard has to be uniform. What counts as adequate evidence that an agent behaved correctly cannot reasonably differ between the finance squad and the supply chain squad, because the auditor asking will not distinguish between them.
3. The scarce skill cannot be replicated per team. Agent behavior literacy is thin enough that spreading it across eight squads means having it nowhere.
So there is a real case for centralizing something. The mistake, and it is the same mistake the original centers of excellence made, is centralizing the wrong thing.
Centralize the standard. Federate the execution.
What belongs in the center is the definition of what “validated” means: the evidence format, the scope boundaries an agent must operate within, the escalation policy, the agent inventory, and the specialist knowledge of how agents misbehave. What belongs in the teams is running the validation and holding the domain judgement, because that is where knowing what correct looks like actually lives and it does not travel.
A central function that writes and runs every test becomes the bottleneck its predecessors were. A central function that defines the standard and equips others to meet it is doing something the embedded model structurally cannot.
Three Operating Models
| Centralised | Embedded | Federated (hub and spoke) | |
| Who validates | A central team, for everyone | Each delivery team, for itself | Teams validate; center sets the standard and holds the scarce skill |
| Strength | Consistent evidence; skill concentrated | Domain judgement close to the work | Uniform standard with local judgement |
| Failure mode | Becomes a queue; loses domain context | Vendor agents owned by nobody; standards diverge | Centre drifts into advice nobody follows |
| Fits when | One ERP, heavy regulation, small delivery estate | Agents are all internally built and team-bounded | Vendor agents across several functions, most organizations |
| Minimum viable | A named team | A named person per team | One named owner plus a written standard |
The last row is the useful one. A federated model does not require a department, a budget line or a reorganization, it requires one accountable person and a document. Organizations routinely defer this because they think it needs headcount, and the deferral is what produces the gap.
Who Owns What: A Starting Allocation
Argue with this rather than adopting it, the value is in having the argument with named people in the room. A is accountable, and there is only ever one. R does the work. C is consulted.
| Activity | Process owner | Validation lead | QA / test eng. | ERP platform | Audit / risk |
| Decide what an agent may and may not do | A | R | C | C | C |
| Maintain the agent inventory | C | A R | R | C | |
| Define what evidence must contain | C | A R | C | C | |
| Author validation scenarios | R | C | A R | ||
| Run validation | C | A R | C | ||
| Triage a failed validation | C | A | R | R | |
| Approve a change to agent scope | A | R | C | C | |
| Monitor behavioral drift in production | C | A | R | R | |
| Hold and retain the evidence | A R | R | C | C | |
| Sign off for audit or regulator | R | R | A |
Three deliberate choices in that table, each of which people will push back on.
- The process owner, not QA, is accountable for what an agent may do. That is a business risk decision about how much authority to delegate where humans belong in agentic testing, and it belongs with the person who owns the process outcome. QA should never be the one deciding how much autonomy finance is comfortable with.
- The validation lead is accountable for drift monitoring, not the platform team. Platform teams watch whether systems are running. Drift is a question about whether decisions are still correct (agent observability), which is a different signal requiring a different owner.
- Audit signs off and does not execute. Keeping audit independent of the validation it relies on is the point. If audit is running the tests, nobody is auditing the tests.
The Skills You Need, and Which Ones Are Actually New
The instinct is to write a job description. Usually unnecessary, three of the four capabilities already exist in the building, and the work is connecting them rather than recruiting.
Already present
Domain judgement sits with your process owners and is the hardest thing to acquire, which is fortunate because you already have it. Control and evidence literacy sits in audit, risk and financial control, and those people are generally glad to be consulted early rather than presented with a gap at year end.
Teachable in weeks
Outcome-based test authoring, expressing what should be true rather than which steps to perform, is a genuinely learnable skill for someone who understands the business process. This is the cheapest capability investment available and the one most often skipped, because organizations assume authoring requires an engineer.
Genuinely new
Agent behavior literacy is the real gap. Understanding that an agent can reach a correct outcome by different routes that identical inputs can produce different valid outputs in agentic QA, that drift is gradual rather than a break, and that a test which fails intermittently may be observing correct non-determinism rather than a defect. Traditional QA instincts actively mislead here: the reflex to eliminate variation is wrong when some variation is legitimate.
The one role worth naming
If you create a single new role, make it the person accountable for answering “what is this agent allowed to do, and how would we know if it exceeded that?”, for every agent in the estate. Not a tester, not an architect. An owner of the question.
In most organizations this is a part-time responsibility attached to someone who already exists, and naming it explicitly is most of the value. Unnamed responsibilities do not get discharged.
The First Ninety Days
1. Name one accountable person. Before any tooling, framework or budget conversation. The gap this post describes is an accountability gap, and it closes the moment someone’s name is against it.
2. Inventory the agents. Including the ones that arrived in a vendor release without anyone deciding to adopt them. Most organizations discover they have more than they thought, and the inventory itself is usually the moment the conversation becomes real.
3. Pick the highest-consequence agent and write down what it may and may not do. One page. This is harder than it sounds and it is where the actual thinking happens, most teams find they cannot answer it for an agent already running in production.
4. Define what evidence looks like, once. Agree with audit what would satisfy them, before building anything. Retrofitting evidence is dramatically more expensive than capturing it.
5. Validate that one agent properly, end to end. One agent done well teaches more about your operating model than a framework covering all of them on paper.
6. Then decide the model. By this point you will know from experience whether the center needs to hold execution where you organization sits today or only the standard, which is a better basis than choosing an org chart first.
Notice that tooling does not appear until step five. That ordering is deliberate: a platform bought before anyone owns the problem becomes a platform nobody operates.
Where Sofy comes in?
A tool cannot solve an ownership problem, and it would be dishonest to suggest otherwise. What it can do is change who is able to do the work, which is the constraint that makes a federated model possible or impossible.
The reason agent validation tends to centralize badly is that authoring has historically required an engineer. If only the central team can write the tests, the central team becomes the queue, and the domain judgement that lives in finance never reaches the validation. Sofy’s AI testing agents change that: because scenarios are expressed as outcomes in plain language, the process owner who knows what correct looks like can author the check themselves.
Three consequences follow, and they map onto the model above. Domain judgement gets into the assertions without a translation step. Execution federates while the standard stays central, because the evidence format is a property of the platform rather than of each team’s discipline. And the evidence exists as a by-product of running validation rather than as a separate reporting exercise, which is what makes audit sign-off a retrieval rather than a project.
What this does not solve
Deciding how much authority an agent should have is a business judgement and always will be. Someone still has to be accountable, and no platform supplies that. Building agent behavior literacy in your people is a learning investment, not a purchase. And if nobody has been named, better tooling produces better-instrumented ambiguity, which is arguably worse than the honest kind, because it looks like progress.
Frequently Asked Questions
Who should own AI agent testing?
Accountability for what an agent is permitted to do belongs with the business process owner, because it is a decision on delegated authority rather than a technical one. Accountability for validating and evidencing that the agent stayed within those limits belongs with a named validation lead. The common failure is assigning both to QA, which leaves QA making risk decisions it has no standing to make.
Do we need a testing center of excellence for agent validation?
You need something central, but probably not what the term usually describes. Centralize the standard, the evidence format, the scope boundaries, the agent inventory and the scarce knowledge of how agents misbehave. Federate the execution, because domain judgement about what “correct” means does not travel out of the business function. A center that writes and runs everything recreates the bottleneck that discredited the model in the first place.
How big does an agent testing team need to be?
Smaller than most organizations assume. The minimum viable version is one accountable person plus a written standard, with validation executed by the teams that already own the processes. Organizations delay because they believe this needs headcount and a budget cycle, and the delay is what produces the gap, naming someone costs nothing and closes most of it.
Should this sit under QA, IT or the business?
The reporting line matters less than the accountability being explicit, but the practical answer is that the validation lead usually works best close to whoever owns ERP or platform, with a hard line of consultation into audit and the process owners. What does not work is placing it where it has no access to domain judgement, which is the most common mistake when it lands in a purely technical function.
What skills do we need to hire for?
Usually none. Domain judgement and control literacy already exist in your process owners and your audit function. Outcome-based test authoring is teachable in weeks to someone who understands the process. The one genuine gap is agent behavior literacy, understanding non-determinism, drift and legitimate variation, and that is better built internally than recruited, because it has to be paired with knowledge of your specific processes.
How does this relate to existing QA team structure?
It sits alongside rather than replacing it. Your existing QA structure was designed around software your teams build, and it continues to work for that. Agent validation is an additional practice covering software nobody in your organization authored, crossing team boundaries, carrying enterprise-level risk. Treating it as an extension of the current QA remit without changing accountability is how it ends up owned in name only.
The Bottom Line
The reason nobody owns agent validation is not that people are avoiding it. It is that the rule the industry used for a decade, the team that built it, tests it, cannot place software that no team built, that spans several teams’ boundaries, and that carries risk at a level embedded QA was never designed to hold.
Which means it will not resolve by itself, and it will not resolve by being raised in a steering meeting as a concern. It resolves when somebody’s name is against the question what is this agent allowed to do, and how would we know if it exceeded that, and when three capabilities that currently sit in three different departments are deliberately pointed at the same problem.
None of that requires a reorganization, a budget cycle or a new job family. It requires one decision that most organizations have been deferring because it looked like it needed all three.