The retrieve demo went well. Natural-language queries came back with relevant results, the assistant handled ambiguous requests without getting confused, narrowing from a broad result set to a specific quote worked as intended. After the session, two requirements arrived that hadn't existed before it.

One was about result count: broad but unambiguous queries were returning too few results. The other was about data: referenced quotes in the assistant's response didn't include the customer and contact details that users needed to actually use them.

The response had the quote. It didn't have the customer. A user picking up a referenced quote to discuss with a client would have to go somewhere else to find out who the client was.

The decision that used to be invisible

If you'd built this same retrieval feature as a conventional UI, a developer would have included the customer data. Not because a ticket said to. Because it's obvious that you'd want to see the customer alongside the quote. There'd be a join, the details would appear in the list, and the feature would go out without anyone ever writing "include customer details" in the acceptance criteria.

When an AI layer mediates the retrieval, the process changes. The model returns what the API returns. If the endpoint doesn't include customer details in its response shape, the model doesn't have them, and they don't appear in the response to the user. The decision that was previously implicit becomes an explicit contract requirement. Somebody has to write it into the spec. And if nobody wrote it in, it doesn't happen.

This is different from a requirements gap in the conventional sense. A requirements gap is when something got missed. This is a category of requirement: decisions that were previously made implicitly during implementation, by developers who bridged the gap between what the spec said and what the feature needed, now have to be stated out loud.

Why AI consumers change the decision surface

I've written before about designing endpoints specifically for AI consumers; the response shape matters in ways that differ from a conventional API, because the model can only reason about what it receives. The flip side is the thing the demo exposed.

In a conventional system, a developer builds the UI and notices the customer data is missing. They add a call, fill in the gap, ship it without ever raising a ticket. The spec stays thin because developer judgment acts as the thickener: wherever there's an obvious gap, someone fills it in.

When the consumer is a model, that gap-filling doesn't happen. The model won't make an extra call on your behalf. It works with what the API gives it. If the response is incomplete, the output is incomplete. The gap that would previously have been bridged by instinct now shows up in a demo as a missing data requirement.

So adding an AI consumer to an existing retrieval flow has a specific effect: it turns the implicit decisions made during conventional implementation into explicit contract requirements. You can't fully anticipate which ones before the AI consumer exists, because those decisions were never made deliberately enough to be anticipated. They surface as gaps: in demos, in testing, in the first real use.

What to do when the demo surfaces one

When a demo reveals a missing requirement, the most useful response is to write it down as specifically as possible. Not "include more customer context" but "the referenced-quote response must include customer name, contact name, and contact role." That specificity matters for two reasons.

First, the model only has what the contract says. Vague requirements produce vague contracts, and vague contracts produce responses that are still incomplete in ways you didn't anticipate. Second, once you've found one implicit decision that didn't make it into the contract, you can look for others in the same area. The customer-details discovery is also a prompt to ask: what else in this response shape was designed for a UI consumer, where the developer would fill in gaps, and now needs to be explicit for an AI consumer?

That review tends to happen iteratively: demo surfaces gaps, gaps become requirements, requirements become contract changes, the next session runs against the updated contract. The rate-limiting factor is how fast each cycle closes. If it takes several weeks, you're likely still showing stakeholders a feature that doesn't match what they thought they were seeing last time.

In this case the follow-up landed in the same release cycle as the demo. The change was specific enough to implement quickly, and keeping the validation environment current meant the next demo could run against the updated behaviour rather than a version from the previous week.

A change that crosses more than one surface

A customer-details requirement on a retrieval response sounds like a backend change. Add the join, update the type, done. In practice it propagates across several surfaces: the backend endpoint has to return the data, the AI service layer has to transform it correctly, the assistant has to surface it, the UI has to display it. Any one of those not landing together means the requirement is only partially met.

This is the same coordination challenge that appears in any cross-service feature. I've written about bugs that hide in cross-service features: the requirement looks simple and the individual changes are simple, but the coupling across surfaces is where things go wrong.

The AI service is one more surface to coordinate, and one that's easy to forget because it doesn't have a UI of its own. You update the backend contract and the frontend, run it, the data still doesn't appear, and eventually you trace it to the AI service holding an old response shape. One extra surface, one that's easy to leave out of the mental model when planning the change.

The pattern the demo exposed wasn't really a missing requirement. It was a hidden decision: something a developer would have done by instinct in a conventional build, made visible by a consumer that can't fill in the gaps by instinct. The requirement was there all along. The AI layer just made it explicit enough to write down.