When AI Became a Client of the Product

The first MCP integration reused the application’s existing service layer instead of inventing a second route into storage. From the product’s perspective, adding an AI client did not create a new authority over persistent state.

Initially, this felt like the central problem. If the AI could discover the right operations and invoke them through the same product services the application already used, the integration had a clean shape. The system still knew how state should be stored, the model could contribute interpretation, and I retained explicit control over decisions that belonged to me.

The limits of that model became clearer once the client started doing more than reading.

Consider a simple request: retrieve the items that are currently active.

To a human using the application, “active” was an obvious concept. Internally, however, it was represented by several states. Someone familiar with the system could look at those states and effortlessly understand which ones belonged together. An AI client could reproduce the same behavior by querying several categories, remembering which ones counted, merging the results and filtering the rest.

It worked, but the interaction exposed something I had not treated as a product defect before. The client was reconstructing a user concept from implementation details. I could make the prompt more explicit, or teach the assistant the mapping, but both approaches would leave the product’s own meaning outside the product.

So active became a first-class product concept.

The client was doing too much product work

The same pressure appeared around identity. A shorthand reference can be perfectly usable when a person is looking at a screen with a title and surrounding context. The tolerance changes when a machine client is about to alter persistent state. At that point, “this is probably the object you meant” is no longer a harmless convenience.

These were small implementation details, but together they changed how I looked at the interface. Human users routinely compensate for missing semantics. We remember conventions, infer what labels probably mean, and learn which internal states belong to the same practical workflow. A capable model can do the same, but every inference the client must reconstruct is product logic that the product itself has failed to express.

The integration was no longer mainly about giving AI access. It was beginning to expose what the product had never needed to state explicitly for a human operator.

One classification defect made that problem much harder to ignore.

An item that belonged to one product domain was repeatedly interpreted as belonging to another because its underlying evidence contained terminology strongly associated with the adjacent domain. The answer was plausible enough that the interesting question was not simply, “Why did the model get this wrong?”

I traced where the interpretation had come from. Some classification was happening early in the workflow, more interpretation happened later during evaluation, and deterministic helpers were also producing related conclusions. None of those mechanisms was unreasonable on its own, but together they meant that several parts of the system could answer effectively the same semantic question.

The workflow had always distinguished facts from interpretation. Source evidence could establish that a record existed, that particular information had been observed, or that an external event had occurred. AI was useful where the evidence needed contextual interpretation, and I retained the ability to override that interpretation when the actual decision was mine.

The defect showed that this conceptual distinction had not been implemented consistently everywhere. One canonical store did not prevent the system from developing several competing sources of meaning.

Once those competing interpretations could influence what the AI retrieved, recommended or attempted next, ambiguity was no longer just interface friction. Ambiguity had become executable: a semantic disagreement inside the product could alter the path a machine client followed.

The answer was not to remove semantic reasoning from AI. In many cases, contextual interpretation was exactly what the model did better than a mechanical rule. The product problem was deciding which questions were semantic, which facts were authoritative, which rules were deterministic, and which decisions still represented human intent.

This made semantic authority a useful design distinction: not only where canonical state lives, but which mechanism is entitled to assign meaning to evidence that may later influence an action.

Source-native facts, semantic interpretations, deterministic policy and human decisions could all coexist, but they could not quietly substitute for one another.

One record, several meanings

It also sharpened a principle I had already been applying elsewhere: an AI recommendation is not automatically a human decision. I explored that boundary more directly in Using AI Without Outsourcing Product Judgment. Here, the same distinction had become part of the machine-facing product contract.

Once the core operations were functioning, a different kind of friction became visible. The AI could complete a task, but the path to completion was often unnecessarily expensive — both in elapsed time and, quite literally, in AI usage credits.

Claude made this particularly visible. A relatively simple task could consume far more credits than seemed reasonable as the assistant fetched one thing, retained several values, called another operation, checked state again and carried the accumulated context into yet another request.

Some of that was simply model usage, but a lot of it came from the way I had shaped the interface. I was asking the AI to repeatedly reconstruct context and product logic that the product itself could have handled more directly.

A seemingly simple workflow might require the assistant to fetch an object, retain several values in context, call another operation, compare the returned state, re-check freshness, pass those values into a later request and only then attempt the change. Each individual step could be justified, yet together they consumed time, context, credits and additional round trips while creating more opportunities for the client to reconstruct product logic incorrectly.

That forced a more useful question: which parts of this interaction actually required AI?

If the product already knows how to validate freshness, that check should not depend on the assistant remembering the right sequence. If an operation requires an exact identity, the product should provide and validate that identity. If several internal states represent one user-level concept, the client should not carry the mapping. Rules the product can enforce consistently belong in the product rather than in the AI’s memory.

This did not make the AI less important. It made its role clearer. The model was useful for interpreting evidence, comparing context, making semantic judgments and proposing next steps. The product was better suited to persistence, identity, deterministic validation and state transitions. Some decisions remained explicitly mine.

The more of its own logic the product expressed, the less product behavior the AI had to reconstruct inside the conversation.

The optimization target changed too. In one short observation window, the client made 26 separate calls. Every call appeared to succeed, yet one of the operations the AI was trying to perform still failed.

Counting successful calls was clearly not enough. The useful questions were whether the intended task completed, whether an operation was legitimately blocked, whether the client needed extra calls to compensate for an unclear interface, and whether the product could have done more of that work itself.

Auditability and logging had already been part of how I approached operational systems. Working through these MCP interactions extended that idea. I increasingly wanted structured evidence about the interaction itself to be available to the AI, so it could help diagnose where an operation failed or where the contract created friction.

That is different from letting the system redesign itself. The product decisions remain mine. The opportunity is to let AI participate in understanding the operation it is already part of, instead of leaving all of that evidence for a later dashboard review.

Looking across this work, I see a direct line back to the home automation evidence layer.

There, the difficult question was: What can AI reliably reason from?

The work eventually produced something close to an evidence contract: the relevant evidence, where it came from, what was missing, what the deterministic system could establish, and where interpretation began.

Direct operational access introduced a second question: What can an AI client legitimately do?

That requires a capability contract. The product has to be explicit about what the client may inspect, which questions it may interpret, what it may request, which operation is allowed to persist state, whose authority that state represents, and what constraints the product enforces regardless of what the model asks for.

From evidence to capability

I did not start the MCP work with that vocabulary or a complete authority framework already worked out. The structure emerged through the implementation: first by watching the client reconstruct concepts such as active, then through the classification defect, and later through the effort to reduce interaction overhead.

The original direction was simpler. I wanted AI to participate more deeply in operational work without requiring me to carry every piece of context and procedure myself. MCP gave me a practical mechanism. Using it changed my understanding of what the surrounding product has to provide for that mechanism to work well.

The home automation work is where I want to take that thinking next. The earlier evidence layer was built around the question Why did this happen? The natural extension is What should the AI be allowed to inspect or do next?

That means moving from AI-assisted explanation toward bounded operational participation: exposing useful capabilities without making the model responsible for reconstructing the system’s semantics, remembering deterministic rules or becoming authoritative over decisions it does not own.

The broader lesson for me is not that AI needs access to more tools. It is that AI becomes a more effective operational client when the product is explicit about what the AI needs to know, what it may do, and what it does not own.