Nobody logs the candidate set

Nobody logs the candidate set.

I've read that story a few times now looking for the moment the harm actually happened, and I don't think it's the sentence. The sentence is just the part we can see. The decision that put a real person in front of a model and told it to have opinions was made earlier, by a step with a boring name like retrieve_context().

I don't know what that pipeline looked like and I'm not going to reverse-engineer it from a screenshot. But I know the gap, because I have the same one.

My traces start too late

When something goes wrong in my own agent, I open the trace and it begins at the request: system prompt, messages, tools, params. Everything upstream of that is a function call with a confident name. The query that produced the context isn't recorded as a decision. It's a line in a stack trace, if it's recorded at all.

Which means the only half of the system I can debug is the half where the cast has already been chosen. The generator is the most observable component in the pipeline and the least responsible one. Every postmortem I've read about an agent doing something awful points at the model, because the model is the part with logs. Selection has no logs because nobody thought selection was a decision.

It is. top_k=10 is a policy. A similarity score is not a judgment about whether a person belongs in a context window. Somebody chose the corpus, the chunking, the embedding model, the freshness of the index, and then wrapped all of it in a default argument nobody revisits. That's a policy nobody signed.

What I'd actually look at

Dump the candidate set. Ids, scores, the query, for a week. Not the vectors, you'll drown. Just what came back and in what order.

I did this for a small internal agent and found it pulling from a source I'd deprecated months earlier, because the index rebuild had quietly kept the old documents. Not dramatic. But it explained three answers I'd spent an afternoon blaming on the model, and I only found it because I stopped reading the output and started reading the input.

Then I wrote an exclusion list. Nothing clever — a list of entities that are out of scope no matter how well they score. It's the least elegant code in the repo and it has done more for output quality than any prompt rewrite I've attempted.

The other thing I want and don't have yet: if the pipeline writes a sentence about a named person, the context should contain a source for that sentence, or the sentence shouldn't exist. Not a citation in the output. A hard requirement that the name came in through a document I can point at. Names that appear in the context without a source are exactly the ones a model will happily elaborate on, because elaboration is what it's for.

Why this is harder than it sounds

Because there's no clean boundary. Retrieval isn't one step, it's six, and the interesting failure happens in the seams — the stale chunk, the entity that got in through a comment, the query that drifted because the agent rewrote it twice before searching. You can't gate a seam.

You can only watch it. So watch it, on purpose, on a schedule, the way you'd watch a slow query or a growing table. Boring instrumentation for a boring problem. It's the least glamorous part of the stack, which is exactly why it's the part nobody built.

Maybe I'm overcorrecting. Plenty of these failures really are the model, and I've written prompts that deserved the blame. But every time I've chased one of these down to the bottom, the model was answering a question somebody else framed for it, with material somebody else picked.

If your agent can name a person, you should be able to point at the exact line where that name entered the context. I can't do that for mine yet. It's above everything else on the list.