The expensive half of a service request was never writing the reply. It was reconstructing what is true across half a dozen systems, and the moment an agent does that assembly it starts deciding which system of record wins.
Watch someone work a real service request end to end and time the parts. The reply is the fast part. What takes the time is the reconstruction: confirming the person is who the ticket says they are, finding the account behind the email address, checking what they are entitled to today rather than what they bought last year, pulling the earlier ticket where somebody already promised them something, and then deciding which of those answers to believe when two of them disagree. I own security and DevOps at a fintech platform serving more than 1,500 financial institutions, which means I see this from both chairs: the pipelines that move the data and the controls that are supposed to govern it. The reconstruction is the work. The reply is a formality at the end of it.
That is why support queues keep surfacing as the first serious agent deployment in shops like mine. Not because drafting text is hard, but because the assembly is expensive, repetitive, and mostly mechanical. Hand it to an agent and the elapsed time collapses. I am not arguing against that. I want to argue about what you just handed over.
Because the assembly was never purely mechanical. Every time a person reconstructed a customer across systems, they made a chain of small precedence judgments. The identity provider is authoritative for who someone is. The entitlement service is authoritative for what they can reach. Billing is authoritative for whether they are paid up, unless the last sync ran after the change, in which case you trust the newer record and open a break. Ticket history is context and never truth. Nobody wrote any of that down. It lives in the heads of the two or three people who have been burned by getting it wrong. An agent cannot inherit tribal knowledge. It has to be told, in text. And the moment you tell it, your firm's record-precedence policy exists in writing for the first time, in an artifact nobody reviewed, versioned, or approved.
Reconstruction is a chain of precedence decisions, and precedence is a policy
Banking supervisors settled this argument thirteen years ago for a narrower domain. The Basel Committee's Principles for effective risk data aggregation and risk reporting (opens in new tab), published in January 2013 and known as BCBS 239, puts the point under Principle 3, Accuracy and Integrity. Paragraph 36(d) is one sentence long: "A bank should strive towards a single authoritative source for risk data per each type of risk." Paragraph 36(c) requires that risk data "be reconciled with bank's sources, including accounting data where appropriate." Paragraph 37 adds a precondition most firms skip: a bank should have "a 'dictionary' of the concepts used, such that data is defined consistently across an organisation."
The footnote is the part I keep coming back to. The Committee explicitly does not demand one data model. Banks "do not necessarily need to have one data model; rather, there should be robust automated reconciliation procedures where multiple models are in use." That is a supervisor conceding you will hold several overlapping versions of the same fact, and insisting the resolution between them be designed and inspectable rather than improvised.
Now hold your own customer-state architecture up against that sentence. Most shops I have seen, including ones with clean audit histories, cannot name the single authoritative source for a given field about a customer. They can name six systems that all hold something like it. The precedence rule a support engineer applies dozens of times a day is not versioned, not owned, and not reviewed. It has never needed to be, because it executed inside a human being who could be asked.
An agent removes that fallback. It executes the rule thousands of times without being asked anything, and it executes whatever rule you happened to write down on the afternoon you wired up the tools.
The precedence rule lands in a tool description, the least governed artifact you own
Here is the mechanical part, and the vendor documentation is blunt about it. In Anthropic's own guidance on defining tools (opens in new tab), the description field is "a detailed plaintext description of what the tool does, when it should be used, and how it behaves." The first best practice on the page reads: "Provide extremely detailed descriptions. This is by far the most important factor in tool performance." It tells you to explain when the tool should be used and when it shouldn't, plus "any important caveats or limitations," and to aim for at least three or four sentences per tool.
Follow that advice honestly for a customer-lookup tool and you will write the precedence policy. There is no way to describe when to call billing_get_subscription versus entitlements_get_state without saying which one to believe. So the tiebreak gets authored in prose, by whichever engineer built the integration, in a string literal in a repository, and from then on it is the firm's operative policy on which record governs an eligibility determination. It is not in the policy management system. It has no approver, no review cycle, and no readership outside the team that wrote it.
Compare that to how the same firm treats a model. SR 11-7, the Federal Reserve and OCC Guidance on Model Risk Management (opens in new tab) from April 2011, is unambiguous that "all model components" (inputs, processing, outputs, and reports) should be "subject to validation," and that a sound development process includes "rigorous assessment of data quality and relevance" plus appropriate documentation. Its guiding principle is effective challenge: "critical analysis by objective, informed parties that can identify model limitations and produce appropriate changes."
A precedence rule is an input specification, and inputs are a model component. If you would not let a developer silently change which table feeds a credit model, you should not let one silently decide which of three systems the agent believes about a member's status. The second decision does the same work as the first, on far more requests per day, with none of the documentation, none of the independent review, and none of the effective challenge.
Integrity is a claim about your records, not about your answer
In consumer finance the framing is sharper, because the rule is written about records rather than outputs. Under 12 CFR 1022.41 (opens in new tab), the CFPB defines integrity, for information furnished to a consumer reporting agency, as information that "is substantiated by the furnisher's records at the time it is furnished." The next section, 1022.42(a), requires each furnisher to "establish and implement reasonable written policies and procedures regarding the accuracy and integrity of the information relating to consumers that it furnishes to a consumer reporting agency," reviewed periodically and updated as needed.
Read that next to an agent that resolved a disagreement between two internal systems and then acted. Substantiated by which records? If the agent read the stale source, the value it acted on is not substantiated by the records that were actually correct at the time, and the firm has no written policy establishing that the agent's choice was the right one, because the choice lives in a tool description instead of a policy. The word "written" is doing real work in that sentence, and a prose blob in a repository is not the artifact a reviewer will accept.
This is the same structural gap I described in the fair-lending piece, arriving one layer lower in the stack. There the binding constraint was that a specific-reason requirement outruns generic explainability. Here it is that an integrity requirement written about records outruns any assurance you can give about the model. You cannot defend the answer without naming the source it came from and showing that naming it was a decision somebody made on purpose.
Owning the connection is not the same as owning the disagreement
I have argued before that every integration needs a named owner, a versioned contract, and a place on a data-flow map built from evidence rather than memory. I still believe it, and it is not sufficient here. Two integrations can each have an owner, a contract, a deprecation window, and per-link telemetry, and still return contradictory answers about the same customer. Both owners are doing their jobs. The contract for link A says nothing about link B. The conflict between them belongs to neither.
So the ownership question has to be asked one level up. Not who owns this connection, but who owns the answer when two connections disagree. In my experience that role exists on no org chart until an agent forces the issue, at which point it lands on whoever is on the incident call. And the disputed field is not a usage metric you can caveat in a footnote. It is whether a person is enrolled, entitled, delinquent, or verified.
Govern the precedence rule, then provision the agent
None of this is an argument against the agent. The assembly work is mechanical, and I would rather my people spend the day on cases that require judgment. It is an argument for treating the precedence rule as a governed artifact, with the same care as the credential you are about to issue. Concretely, before an agent gets read access across systems of record:
- A written authoritative-source matrix, per data element, not per system. One row for each field the agent will assemble, naming the governing source, the acceptable fallbacks, and the staleness window past which it stops being acceptable.
- The precedence rule versioned and approved like a policy, then generated into the tool definition. The rule lives in the policy repository with an owner and a review date. The tool description is rendered from it, so code and approved policy cannot drift apart silently.
- Field-level provenance on every assembled record. Each value carries its source system, its read timestamp, and whether a fallback was used. An assembled customer view with no provenance is an assertion; with provenance it is evidence.
- Disagreement emitted as an event, never swallowed. When two sources conflict, the agent records a reconciliation break with both values and proceeds under the declared rule. Silent resolution destroys the only signal that your data architecture is wrong.
- A named owner for the conflict class, separate from the integration owners. Someone accountable for the tiebreak itself, who reviews the break queue and can change the rule through the normal approval path.
- Corrections routed to the rule, not to the reply. When a reviewer overrides the agent, the required output is a change to the identity rule, the precedence rule, or the routing decision. A corrected draft that leaves the rule untouched has taught nobody anything.
Four of those six are things an audit-defensible pipeline already emits as exhaust if you built it that way: provenance records, deterministic checks standing between the agent and the action, and a system that never lets the model certify its own inputs. The new one is the matrix, and it only becomes necessary when software rather than a person has to make the call.
The Monday version is smaller than the list looks. Open a spreadsheet, put the ten fields your support team looks up most often down the left, and fill in three columns: governing source, acceptable fallback, and how stale that fallback may be before the answer is wrong. Ten rows is an afternoon. The rows you cannot fill in are the finding, and they name the fields no agent should be reading yet.
The matrix is also a checkability test, which connects it to the provisioning gate I run in front of every agent request. If you cannot name the source an answer should have come from, you have no deterministic check to run the answer against, which means you do not yet have a job an autonomous agent should hold.
Measure the disagreement rate, not the deflection rate
One more consequence changes what you report. Once the agent handles assembly, the queue that remains is not a smaller version of the old queue. It is a harder one, concentrated in the cases where systems disagree, policy is ambiguous, or the product is actually broken. Throughput per hour will look worse. That is the correct outcome, and someone should say it out loud before a dashboard gets built that punishes it.
The number I would put in a governance report is the reconciliation break rate: how often the agent found two sources disagreeing about the same field, broken out by field and by source pair, with a trend line. That metric is a direct read on the health of your data architecture, and before an agent was doing the assembly, no instrument in your estate produced it. The agent is not just labor. It is the first thing you own that measures how often your systems of record contradict each other, and it will do so on every request whether or not you decided to look.
I would genuinely like to hear how other people are handling the tiebreak in production agent systems. Did you write the authoritative-source matrix before the agent shipped or after the first bad answer, and where does the precedence rule physically live in your repository today: a policy artifact, a config file, or a paragraph in a tool description that one engineer wrote and nobody has read since?