Part 1 of 2 — the diagnosis. Part 2 covers the architecture that answers it.
The hard part of enterprise AI is changing. Getting an agent to answer well is no longer the whole problem. Once an agent can retrieve customer data, update a record, issue a refund, send a message, or trigger a workflow, the question shifts from whether it can do the work to whether the business can trust it to do that work repeatedly, within boundaries, and account for what happened afterwards.
That shift is what produces the four realities below. Each lands on somebody: the business running the agent, or the customer on the other end of it. They are set out plainly, along with the approach being taken to each, because they are better understood early than discovered late.
01. Watching your agent creates a second privacy problem
The businessThe customer
To debug an agent you have to capture what it saw and what it said. That means the full prompt and the full response, which is exactly the free text where personal information hides. Instrument thoroughly enough to be useful and the trace store quietly becomes a searchable copy of every conversation customers ever had.
The failure is mundane. Someone opens the observability tool, types a customer surname into the search box, and gets back their chat history, their email address, and the last four digits of a card they pasted into a support thread. Nothing was breached. The instrumentation worked as designed. — documented as a common pattern in OpenTelemetry GenAI instrumentation practice, 2026
Saving raw traces before checking them turns the observability store into a regulated data store, with its own retention, deletion, and access obligations. A deletion request from a customer now has to reach a system nobody thought of as holding customer data. Most teams discover this after the store already exists.
| What Ephanti is building | |
|---|---|
| Redaction before storage | Detection and masking sit at the collection boundary, so sensitive values never reach a store rather than being cleaned up after they land. |
| Two stores, not one | Debug traces belong in a short-retention store. The durable record of what an agent did belongs separately, append-only, on the tenant's retention schedule. |
| Isolation in the data model | Every event carries its tenant from the moment it is emitted, so scoping is structural rather than a filter applied at read time. |
| Deletion that propagates | A customer deletion request has to reach both stores, including the one nobody thinks of as holding customer data. |
Intended outcome: a debugging surface that is not a shadow copy of every customer conversation.
How that split between debug traces and the durable record actually works is covered in Part 2’s capture-once, fork-by-purpose design.
02. The model changes underneath you, and nobody sends a notice
The business
Traditional software dependencies change when you upgrade them. Hosted models do not work that way. Providers update weights, safety policies, and serving infrastructure without changing the API endpoint, so the same two-line call can behave differently on Wednesday than it did on Tuesday.
Teams calling one widely used model through the sycophancy rollout and its correction hit four distinct behavioural regimes over several months from an unchanged endpoint string. No code change, no version bump. For most of them the only signal was users saying the product felt different. — DigitalOcean, on silent versioning in AI inference, 2026
Pinning to a dated snapshot helps and does not solve it, because snapshots get deprecated and most models have a shelf life measured in months. The practical consequence is that an agent which passed review in March may be doing something subtly different in July, and without a baseline nobody can tell whether it changed or the business just got unlucky.
| What Ephanti is building | |
|---|---|
| Version stamped on every action | Recording the model and automation version alongside each decision, so July behaviour can be compared against March rather than argued about. |
| Drift as a trend line | Sampled quality scoring against fixed measures, so degradation shows up as a falling line before it shows up as complaints. |
| One gateway for model access | Routing every call through a single point, so pinning a version, restricting which models a tenant can reach, or moving traffic off a degraded model becomes a configuration change rather than a release. |
| Automatic fallback | When a provider errors, rate limits, or times out, traffic fails over with the reason recorded against that action. |
Intended outcome: the ability to answer whether the agent changed, or the business just got unlucky.
03. Human review stops being review long before anyone notices
The businessThe customer
Putting a person in the loop is the standard answer to agent risk, and it is the right instinct. It also degrades quickly and quietly. Sustained vigilance is a known weak point in aviation and nuclear safety research, and approval queues reproduce the same conditions.
In one published practitioner account, a review queue reached 14,000 pending items within 48 hours against a three-person team clearing about two hundred an hour. Approval latency stretched to 6.4 hours, and by day three the approval rate hit 99.7% — the number you see when people have stopped reading. Research on AI advice in organizations finds something similar: reviewers frequently do not interrogate the reasoning behind a recommendation at all, which means a well-explained recommendation can receive no more scrutiny than an unexplained one. — practitioner write-up, DEV Community, 2026; Harvard Business School working knowledge on AI advice and employee questioning, 2026
The uncomfortable implication is that an approval step can make a business less safe than no approval step, because it produces the appearance of oversight without the substance, and it distributes accountability until nobody holds it.
| What Ephanti is building | |
|---|---|
| Machines check what machines can | Spend caps, rate limits, and consent checks enforced at the moment of the action, so they never become queue items. A person confirming what a rule could have decided is wasted attention. |
| A queue of exceptions, not confirmations | What reaches a person should be what genuinely needed judgment: the held action, the low-confidence answer, the case outside policy. |
| Enough context to decide once | Each item carries what happened, why it stopped, what the agent proposed, and a link to the full sequence, so review does not require investigation elsewhere. |
| Approval rate as a health metric | Treating a rate climbing past ninety percent as a signal that thresholds are too broad, rather than as the agent getting good. |
Intended outcome: oversight that stays real, because the volume stays inside what a person can actually hold.
Part 2 goes into the mechanics of that queue in more depth — where enforcement actually sits, and the five conditions allowed to raise an item at all: see designing an accountable agent architecture.
04. Customer-facing obligations are arriving unevenly
The businessThe customer
Most discussion of agent governance is internal-facing, about what a business can see and control. The other side of the conversation acquired enforceable expectations during 2026, and the pace has been unusual. It is also fragmenting: some laws target companion and mental-health bots narrowly, others impose broad disclosure and transparency duties on conversational AI generally.
Nearly one hundred chatbot-specific bills have been introduced across more than thirty states, alongside federal proposals. More than a dozen states have enacted something, and the definitions vary materially between them. Article 50 of the EU AI Act, whose transparency rules for interactive AI systems require that people be told when they are dealing with one, has applied since 2 August 2026. Its scope and exceptions are their own question.
Scope is where this gets misread. California's SB 243 carries a private right of action of at least $1,000 per violation, and is frequently cited as though it governs customer-service agents. It does not on its face: the statute expressly excludes bots used only for customer service, business operations, productivity, internal research, or technical assistance. The word doing the work is only. Counsel analyses note the test is whether a system is capable of meeting a user's social needs, and that a service chatbot which recalls prior conversations, remembers preferences, tailors recommendations, or checks in proactively may fall inside scope regardless of its stated purpose.
Disclosure and consent are different obligations and are easily conflated. Disclosure is telling a person they are dealing with an AI system. Consent is permission to do something specific with their data or on their behalf. A deployment may owe one, both, or neither depending on jurisdiction and use case. A footer reading “powered by AI” tends not to satisfy a conspicuous disclosure test, and an escalation path resolving to a contact form is not a route to a person. Both remain common. Scope questions require counsel and cannot be settled by reading a headline.
| What Ephanti is building | |
|---|---|
| Disclosure at the channel | Identification configured as a property of the channel rather than written into a prompt, so it cannot drift or be edited away when the automation is updated. |
| Escalation that carries context | A handoff that moves the conversation with it, so the customer does not restart their story. Both a regulatory expectation and the difference between feeling transferred and feeling dismissed. |
| Consent recorded with its ordering | A record showing the wording presented, when it was accepted, and that nothing was requested before it existed. Sequence is the part a transcript cannot establish. |
| Compliance that can be shown | Every disclosure displayed and every escalation taken recorded and exportable, because demonstrating compliance and achieving it are separate problems. |
Intended outcome: the customer knows what they are talking to, and has a route to a person that actually works.
The four, and what answers them
Consolidated, because the delivery matters more than the diagnosis.
| The problem | What Ephanti is building toward | Intended outcome |
|---|---|---|
| 01 Telemetry becomes a copy of every conversation | Redaction before storage, separate stores for debugging and record, tenant scoping in the data model, deletion that reaches both | A debug surface that is not a shadow customer database |
| 02 The model changes without notice | Model and version stamped on every action, continuous sampled scoring, single gateway for pinning and routing, automatic fallback | A trend line that shows drift before customers do |
| 03 Review collapses into rubber stamping | Mechanical checks enforced inline, queue reserved for genuine exceptions, full context per item, approval rate tracked as health | A queue small enough that reviewing it stays real |
| 04 Customer-facing duties are arriving unevenly | Disclosure set at the channel, escalation that carries context, consent recorded with its ordering, everything exportable | Proof of compliance, not just the practice of it |
Why set this out
None of the four is a comfortable topic. Two describe risks that observability itself introduces, one describes a failure mode in the safeguard most buyers ask for first, and the fourth is a moving regulatory picture that no platform can claim to have permanently settled. They are set out anyway because each will be met eventually, and meeting them by surprise costs considerably more than meeting them by design.
Four questions worth asking of any deployment
Including one already running. The four realities above translate directly into things a business should be able to demonstrate about its own stack.
Can you show what your trace store holds, and who can search it?
If the answer involves an engineer checking, the store is holding customer data nobody has classified.
Could you tell whether an agent's behaviour changed last month?
Without model and version recorded against each action, drift and a fix look identical afterwards.
What is the approval rate on your review queue?
A rate climbing above ninety percent is a warning that the thresholds may be too broad, rather than evidence that the agent is simply getting everything right.
Could you produce a record of one automated action from six weeks ago?
Not the transcript. The action, the authority it ran under, and what the customer was told.
These four are not edge cases. They are the conditions an accountable agent platform has to be designed around. Observability tells you what happened. Governance constrains what can happen. Neither, by itself, makes an agent accountable.
Designing an accountable agent architecture. How the four planes fit together, where enforcement sits, and the dependencies underneath them.
Read Part 2 →