Agents should spend tokens on context, not vibes

Most agent failures do not start with the model being stupid.

They start earlier. The user left out a constraint. The repo has two similarly named folders. The task depends on a date, an account, a file, a provider setting, or a preference that never made it into the prompt. The agent can guess, ask, search, open a file, call a tool, or stop. That choice is the product.

Asha.News surfaced a useful research cluster this week around AI agents and uncertainty. The piece that stuck with me was an arXiv paper called "Active Inference as Context Acquisition for AI Agents." The paper frames the problem in a way that feels painfully practical: an interactive agent has to decide when missing context is worth spending tokens to acquire.

Sources: Asha.News share pack on AI agents, Asha.News article with the source trail, arXiv:2608.19202, Active Inference as Context Acquisition for AI Agents, MIT Technology Review on AI drug inventorship.

The missing-context step is an interface decision

The arXiv abstract describes a tradeoff: when a user omits a constraint, preference, file, or task variable, the agent can proceed with a default assumption or spend tokens on a clarifying question, retrieval call, tool call, or prompt trial. The authors formulate that as active inference for context acquisition, with an inner step that updates beliefs about the task and an outer decision that chooses the next context action, task action, or stop action under cost.

That is a research framing. The product version is simpler: the agent needs a budget for not being confidently wrong.

A lot of agent interfaces still treat clarification as a manners problem. Ask too much and the system feels needy. Ask too little and it breaks things. The better framing is cost. What does one more question buy? What does one file read buy? What does one tool call buy? What is the cost of guessing wrong?

That is where UX gets interesting. The interface does not need to expose expected free energy to the user. It does need to make the agent's next move legible.

Ask, retrieve, try, or stop

For a practical agent, I would split missing context into four moves.

Ask when the missing detail lives only in the user's head: preference, intent, risk tolerance, approval, or a choice between two valid outcomes.

Retrieve when the answer is already in the workspace: a config file, prior run log, public docs page, database row, issue, or content entry.

Try when the action is cheap and reversible: run a local test, render a route, validate frontmatter, query an API with read-only scope.

Stop when the next action would be destructive, public, expensive, or identity-sensitive and the missing detail changes the outcome.

The annoying part is that good agents need all four. A system that always asks wastes the user's time. A system that always retrieves can burn tokens on trivia. A system that always tries turns production into a lab bench. A system that never stops is not autonomous. It is reckless with better branding.

Asha.News is useful here because it keeps the trail visible

The Asha.News article did not ask me to trust a floating summary. It linked the source trail: the arXiv paper, the MIT Technology Review piece on AI drug inventorship, and other related sources. That matters because this is exactly the kind of topic where summaries can blur categories.

The patent-law story is about attribution and legal responsibility. The agent-context paper is about decision-making under missing information. They both touch AI uncertainty, but they are not the same claim.

A digest can put them near each other. A useful research product keeps the evidence trail close enough that I can separate them again.

That is also the rule I want for agents. Compression is fine. Just do not destroy the edges between claims.

The product rule I would steal

Build the context layer as a visible state machine.

Not a giant diagram in the UI. A small, inspectable trail: what the agent knows, what it inferred, what it opened, what it still needs, and why it chose the next action. If it asks a question, show why that question beats retrieval. If it reads a file, show the file. If it stops, show the blocked decision.

This is not about making agents timid. It is about making them useful in the boring situations where work actually happens. Ambiguous repo. Missing date. Similar account names. Public post waiting on provider state. Deployment check that passed locally but not in production.

The best agent UX may turn out to be less about giving models more freedom and more about teaching them when context is worth the cost.