Nobody gave it the address.

§ 01 · The embarrassing failure

Someone posted on LinkedIn that an event agent couldn't tell them where the event was located. Not the schedule. Not the speakers. Not the session abstracts. The physical address.

The team had done everything right. They'd thought carefully about the conversational experience. They'd connected the right systems. They'd written good instructions. And the agent confidently didn't know where the event was, because nobody had thought to give it that information.

This is the failure mode nobody talks about when they demo agents. Not hallucination. Not broken logic. Not a model limitation. Just: the thing the user needed wasn't there.

It's embarrassing in its simplicity. And it's far more common than anyone admits.

§ 02 · The assumption buried in every build

When you build an agent, you think about capabilities. What can it do? What can it access? What questions should it be able to answer? You design for the use cases you can imagine, instrument for the behaviors you expect, and ship when it works well enough in testing.

What you don't do, almost by default, is audit for completeness.

Nobody stops during the build and asks: what would this agent not be able to answer? What information exists in the world that a reasonable user might expect it to have, that we simply haven't given it? The question feels obvious in retrospect. In practice, it never gets asked — because you're focused on what you're building, not what you're omitting.

The address wasn't missing because of a technical failure. It was missing because everyone involved assumed someone else had handled it. The agent team assumed the data team had it. The data team assumed it was in the system. The system had it in some form, somewhere, for some purposes — just not in a form the agent could use.

The data exists in the organization. The agent just can't reach it, or reach it cleanly, or reach it in a way that surfaces a useful answer.

§ 03 · The wrong question we keep asking

Most teams evaluate their agents by asking: is it working?

It's the wrong question. Working means the logic executes. Working means the conversation completes. Working means no errors in the logs. An agent can be working perfectly and still be failing the people using it — giving confidently incomplete answers, staying silent when it should help, or deflecting questions it has no reason to deflect.

The right question is different: what is my agent actually being asked, and is it answering well?

These sound similar. They're not. The first question is about the system. The second is about the interaction. The first tells you the agent is running. The second tells you whether it's useful.

When you look at what people actually ask, patterns emerge fast. There are categories of questions the agent handles well. There are categories where it hedges or fails or goes quiet. And when you trace those failures back, the cause is almost never the agent logic. It's the information the agent is grounded on — what's there, what's missing, what's out of date, what's structured wrong for the kind of retrieval the agent needs.

The agent didn't fail to answer "where is the event?" because the reasoning was bad. It failed because the answer wasn't in the ground truth it was working from. Fixing that isn't an agent problem. It's a data problem.

§ 04 · The loop nobody told you was the job

Once you accept that agent quality is mostly a data quality problem, the work changes.

It becomes a loop. You look at what users are asking. You identify where the agent is struggling — not just hard failures, but weak answers, hedged answers, answers that are technically accurate but not actually useful. You trace each one back to its root: is the information missing entirely? Is it present but unstructured? Is it present and structured but stale? Each of those has a different fix, and none of those fixes happen in the agent layer.

Then you fix the data. You add what's missing. You structure what's scattered. You establish who owns keeping it current. And then you run the loop again — because new questions will surface new gaps, because content changes, because what users need shifts over time.

This is maintenance. Not maintenance as an afterthought — maintenance as the primary ongoing discipline of running an agent in production.

It's not glamorous work. There's no demo for "we added the event address." Nobody posts about the incremental data cleanup that made the agent meaningfully better for the next hundred conversations. But that's where most of the improvement actually lives.

The organizations whose agents get better over time aren't the ones with the most sophisticated architectures. They're the ones that have made a practice of closing the loop — watching what the agent can't answer, and making sure it can answer it next time.

§ 05 · The groundskeeper problem

In the two previous pieces in this series, I argued that the future of content is agentic access, not better destinations — and then that building the access layer is mostly a data model problem, not an engineering problem.

This is the third part of that argument, and in some ways the most unglamorous: it's never done.

You don't build an agent, verify it works, and move on. You build an agent, put it in front of people, watch what breaks, and fix the underlying data. Then you do it again. The agent logic might be stable for months. The data underneath it won't be. Events move. Speakers change. Information that was accurate in March isn't accurate in October. And every change is a potential gap between what a user asks and what the agent can usefully answer.

There's a job at every venue called the groundskeeper. Their work is mostly invisible. When it's done well, you don't notice it. You only notice when it hasn't been done — when the lights are out, when the field is uneven, when something that should have been maintained wasn't.

Agents need groundskeepers. People whose job is to watch what's being asked, close the gaps, and keep the underlying information current and complete.

That role doesn't have a clean title yet. It's distributed across data teams and content teams and product teams, and nobody feels fully responsible for it.

That's the gap. Not the model, not the protocol, not the interface. The gap is the assumption that once the agent is live, the information work is finished.

It isn't. It's just starting.