Will Platforms Die? When Your Customer's Agent Becomes the Interface

A few weeks ago a customer walked me through how he wanted to work with us. He said he could connect his system to ADAM as an MCP server and configure the platform based on his business logic and his own data.

He mentioned MCP almost in passing, like a detail he had already settled. What stayed with me is the assumption underneath it. He expected to configure our platform without ever opening our platform.

That is a different statement from wanting an integration. It is a statement about where he expects the work to happen from now on, and it moved a line on our roadmap that I had been treating as a later problem.

Two architectures hide inside that sentence

Before anything else, this needs to be said precisely, because I have watched the conversation blur it more than once and the two versions are not interchangeable.

In the first version, the customer stands up an MCP server that exposes their business logic and their operational data. ADAM connects to it as a client. We reach out, read what they have, and use it to reason about the configuration on our side. Control stays with us. Their system becomes a source of truth we can consult.

In the second version, we expose our configuration surface as an MCP server, and the customer's own agent connects to it as a client. Their agent proposes and applies changes to our platform directly. Control moves outward. We become something their system operates.

The customer was describing the first shape and assuming the second one. Most people talking about this are doing the same thing. The security model is different, the failure modes are different, and the answer to who is accountable for a bad change is completely different. Anyone building toward this should be able to say which one they mean in a single sentence.

My view is that both end up existing, and the second one is the harder and more interesting problem. That is the one worth designing for now.

Context flows in, controlled change flows out

The reason the first shape matters at all is that most of the information determining whether a configuration is correct does not sit with us.

Their business rules sit with them. Their thresholds, their approval structures, their definition of a good outcome. Their operational data too, the record of what actually happened after an agent finished handling a case. We see the interaction. They see what it earned or cost three steps downstream.

So ADAM optimizing purely inside our boundary works from a partial picture. It can show that agents are closing more cases. It cannot show, on its own, that the way those cases close is suppressing revenue somewhere we never look. If you want the background on how ADAM reasons across agents, we wrote an introduction to ADAM that covers the foundations.

What makes this a two-way street is the second half. Once we can read their context, the natural next question from any customer is why they should come to us to act on it. That is the moment the platform boundary stops being an architectural fact and starts being a product decision.

The interface does not disappear, it changes jobs

Here is where I part ways with the version of this argument that ends in software dying.

If the customer's agent proposes the changes, nobody needs our screens to make a change. That part of the interface really does lose its claim. But every serious operation still needs a place to review what was proposed, catch the exceptions, approve what crosses a threshold, and roll something back when it turns out wrong.

That is not a smaller job. In a regulated operation it is the job. A carrier does not treat a configuration change as a private act between an administrator and a settings page. It is a decision that has to survive an audit, sometimes years after the person who made it changed roles. An agent making changes from outside does not remove that requirement, it multiplies the number of changes that have to satisfy it.

So the interface stops being a place where work is authored and becomes a place where work is judged. Review, exception, approval, rollback. Fewer forms, more evidence.

Every external change needs a lifecycle

Concretely, this is what I think has to exist before any customer agent touches a live configuration.

A change gets proposed, and the proposal carries its reasoning. A change gets tested against the existing case set before it goes anywhere near production traffic. A person approves it, or the policy says it can proceed without one, which is itself a decision someone made deliberately. It deploys. It gets measured against what the numbers looked like before. And it can be rolled back to the previous state without archaeology.

None of those steps are optional, and the ordering is the point. Skip the test step and you have an untracked edit with better manners. Skip the measurement step and you can never tell whether the change was worth making. Skip rollback and every mistake becomes permanent by default.

This is the same principle behind how we think about agent observability more broadly. A system that can change itself is worth exactly as much as your ability to reconstruct what it did.

‍

What arrives from outside should be a business goal

The part I want to push hardest on is what actually crosses the boundary.

Today, if a customer wants something changed, they describe the change. Escalate later, add a check, adjust a rule. Someone translates the business intent into requirements, then into config, then into agent behavior, and by the time it lands three people have interpreted the original goal.

I would rather receive the goal itself. Raise revenue per case on the retention flow. Cut cost per case by fifteen percent. Hold the save rate above the number their board already agreed to. Those are the sentences that get said in the rooms where budget is decided, and right now they have no direct path into a system like ours.

If the goal is the input, the system can work on the how. It reads the current configuration, forms a view about what would move that number, and tests the view instead of asserting it. Two configurations running against each other under production conditions, measured against the stated objective, winner proposed with the evidence attached.

The reason I want this framed commercially rather than as agent quality is that quality metrics are ours and revenue metrics are theirs. A quality score improving is an argument we make. Revenue per case improving is a fact they already track. When the goal that enters the system is the same number their finance team reports on, the whole exchange stops needing translation.

What comes back has to carry a guarantee too. Revenue goes up, and nothing regresses. No segment quietly loses money against the old configuration, no rise in refunds or goodwill spend, no compliance rule broken to get there. A revenue gain bought with a compliance breach is not a gain, and an agent optimizing hard on one number will find that shortcut if nobody closes it.

The failure mode worth naming

I do not want to write this as though the risk is theoretical.

An agent optimizing for a resolution number will find ways to mark things resolved that a person would not call resolved. An agent optimizing for revenue per case will find offers that book well this month and cost more in the next renewal cycle. Optimizing systems locate the gap between the metric and the intent, reliably, because that gap is where the easy wins are.

The defense is not a better model. It is that the objective gets set by someone who owns the operation and lives with the consequences, and the evidence gets presented in a form they can actually interrogate before approving. That is why the review surface matters more as autonomy increases, not less.

Where the moat ends up

If I follow the whole argument out, the thing worth owning is not the configuration screen. It is the governed operational record underneath.

The record of what every agent did. The proof that today's configuration is the one someone approved, and the trail showing what it was before. The test set that says whether a proposed change is safe. The measurement that says whether it worked. Those are hard to build, expensive to build late, and impossible to bolt on after an auditor asks.

A customer's agent can propose anything. What it cannot do is vouch for itself. Somebody has to hold the truth about what happened, and be able to show it to a regulator years later.

That is the product I want us to be. The customer says where they want to go, their system does more of the driving, and we make sure that every mile of it is written down and can be read back.

He saw the shape of this before we said it out loud. The boundary around ADAM was ours, and it turned out to be smaller than what the thing can actually do.

‍