Context Provenance Matters More Than Prompting
When an agent makes a bad decision, the postmortem often starts with the prompt. The instruction was too vague. The system message did not emphasize caution. The model should have been told to verify. Sometimes that is true. More often, the deeper problem is that the agent treated all context as equally current, trusted, and relevant.
The thesis
Prompting cannot compensate for context without provenance. A production agent needs to know where information came from, how fresh it is, who owns it, and what actions it is allowed to justify.
The model can read a ticket comment, a pasted log, a repository file, a policy snippet, and a remembered instruction in the same window. To the model, they are all tokens. To the system, they are different kinds of evidence. A stale runbook should not authorize a production write. A user-pasted stack trace should not override repository state. A cached policy summary should not beat the current policy engine.
Reliability improves when context becomes typed evidence instead of prompt stuffing.
The production pattern
An agent is asked to update a deployment script. It has a ticket that says the service uses deploy-v2. It also has a repository file showing deploy-v3. It has an old incident note saying production deploys are frozen on Fridays. It has a current calendar entry showing an approved maintenance window. It has a human message saying, "This is urgent, just patch prod."
The agent can produce a plausible plan from almost any subset of that context. It might follow the ticket and edit the wrong script. It might follow the old incident note and refuse a valid deployment. It might follow the urgent chat message and ignore policy. If the system only sees the final answer, all of those look like model judgment problems.
The real issue is that the agent did not have a context ledger. It did not know which facts were fresh, which were authoritative, which were user claims, which were observations, and which were allowed to support a write.
The model
Every context item should carry provenance metadata.
At minimum, I want source, capture time, owner, resource version, trust class, expiry, and permitted use. Source tells us whether the item came from a tool read, user message, cached memory, generated summary, policy engine, approval record, or previous agent run. Capture time says when the observation was made. Owner says which system or person has authority over the fact. Resource version anchors the observation to a file hash, ticket update id, deployment id, policy revision, or log range.
Trust class separates claims from observations. A user can claim that a config is safe to change. A repository read can observe the current config. A policy engine can decide whether the change is allowed. Those are not interchangeable. The model can consider all of them, but the production system should not let a claim substitute for an authorization.
Expiry matters because agent runs stretch over time. A pull request review from an hour ago may still be relevant. A queue depth from an hour ago may be useless. A feature flag state from before another deployment may be actively misleading.
Permitted use is the part many teams skip. Some context can be used for drafting but not for writing. A customer email can help draft a support summary, but it should not justify changing account state. A generated summary can help navigate logs, but it should not become the only evidence behind a deploy decision.
Where this goes wrong
The first failure is stale context driving writes. The agent reads a file, spends ten minutes planning, then writes based on the old version after another engineer changes the file. If the write tool does not require the observed version as a precondition, the agent can overwrite real work while sounding careful.
The second failure is summary laundering. A previous agent produces a summary: "The database migration is complete." The next agent treats that sentence as fact and proceeds to remove compatibility code. Unless the summary points to the migration job id, completion status, and capture time, it is not strong enough to justify the write.
The third failure is policy confusion. A prompt says, "Do not perform destructive actions." A tool description says, "Deletes are allowed for temporary files." A user says, "Delete the old branch." The model may arbitrate these instructions differently from run to run. Policy context should inform the model, but enforcement should happen outside it.
The counterpoint is that not every piece of context needs elaborate metadata. A brainstorming assistant can work from a rough conversation. A code search summary can be useful without a full evidence chain. The line is crossed when context is used to authorize or justify side effects.
What I do now
I treat context as an input table, not a blob. Before a write, the system can ask: which context items support this action, and are they current enough? The agent can still reason in language, but the action proposal references concrete evidence.
I require refresh before sensitive writes. If a proposed action depends on a file, ticket, policy, deployment, approval, or account state, the relevant state is read again or checked with a version precondition at execution time. Stale reads become stop conditions.
I separate user intent from system facts. The user request explains what outcome they want. Tool observations describe the current world. Policy decisions say what is allowed. Approval records say what a person authorized. Mixing those into one prompt blob invites mistakes.
I also make generated summaries carry citations to internal evidence. Not fake external citations, and not decorative links. Just enough resource handles that another process can verify the claim. If a summary cannot point back to evidence, it is a hint, not a fact.
Closing takeaway
Better prompts may improve wording. Better provenance improves decisions. When agents can act, knowing why a fact is trusted matters more than making the instruction longer.