How AI Coding Agents Choose Context

Context selection is a sequence of decisions

A coding agent rarely receives an entire project in one model call. It begins with a user request and a small amount of environment information, then chooses what to inspect. It may search for a symbol, open a file, read a failing test, query diagnostics or recall earlier task history. Each observation can change the next action. The quality of this sequence often determines whether the final patch is correct.

Imagine a request to fix a checkout error. That word may appear in a page, an API route, a webhook and tests. An agent that edits the first matching file may produce a plausible but irrelevant change. One that traces the actual failing request and contract can narrow the cause before writing.

Start from evidence closest to the failure

Useful first clues include an exact error message, stack trace, failing assertion, route name or changed commit. The agent can search for these terms and inspect the relevant implementation. It should distinguish observation from inference: finding a function with a matching name does not prove that function handled the failing request. Callers, runtime wiring and tests provide stronger evidence.

For a new feature, start with the existing pattern and public interface rather than an error. Read one representative implementation and its test, then identify which parts are reusable and which are specific. This avoids pasting a whole directory into context while still respecting project conventions.

Expand only when the hypothesis needs it

After reading an entry point, the agent may need to inspect a data model, validation helper or downstream call. A bounded code-lens view can suggest callers and callees; static analysis cannot prove runtime execution order. Search and indexing are useful retrieval tools, but they can be stale or incomplete. The agent should open current source before making a claim and reread it before editing if the workspace may have changed.

Broad context becomes useful when the task genuinely spans architecture. Even then, choose a map of modules and contracts before dumping implementations. Irrelevant files increase token cost and can distract the model from the failing path. The goal is enough evidence to make the next decision, not maximum prompt size.

History is a clue, not current truth

An agent may recall a previous conversation or episode about the same project. That can save time by preserving why an earlier decision was made. It can also mislead if the branch moved or a test changed. Treat recalled history as a pointer to files and constraints, then verify against the current checkout. Do not apply an old patch solely because a past task said it worked.

Licuse uses local history and episode-oriented context selection. Its current task still needs fresh code reads and test results. Any agent with memory should expose enough source information that the developer can tell whether an answer comes from present code or a historical summary.

Tests create new context

After an edit, a test or typecheck is not merely a final checkbox. Its output is evidence about the hypothesis. A new failure in another package may reveal a missed caller; a passing targeted test may still leave a broader regression. The agent should use those results to decide what to inspect next, not blindly make more changes. Keep test output focused so an enormous log does not crowd out the relevant diagnostic.

When the check passes, inspect the diff and explain what changed. If a command could not run, report that limitation rather than claiming verification. The human reviewer needs an honest chain from request to observed result. Context selection continues until the final answer is supported.

How to evaluate an agent's context strategy

Give two agents the same unfamiliar repository and a bounded issue. Compare which files they inspect before editing, whether they cite real paths, how they handle a misleading search result and whether they refresh a file after it changes. Measure cost and latency, but prioritize the accuracy of the final tested patch. A system that reads fewer files is not automatically better if it misses the decisive contract.

Good context is relevant, current and attributable. The best tools help the agent gather it incrementally and help the user see enough of that process to review the outcome. A maximum context-window specification tells you only how much could fit in one call, not whether the right evidence was chosen.

Three context failures to watch for

First, the agent may select a similarly named but unrelated file and build a confident answer around it. Ask for the runtime call path or test evidence. Second, it may carry stale content from an earlier read after another process edited the file. Require a fresh read before patching. Third, it may bury the decisive error inside a giant log or conversation history. Provide a focused excerpt and ask which observation changed its hypothesis. These checks reveal whether context selection is genuinely adaptive. The useful agent is not the one that reads the most; it is the one that notices when its evidence is weak and retrieves what will resolve the uncertainty. A good final report should name the files inspected, checks run and any remaining uncertainty. This lets a human reviewer distinguish a tested conclusion from a plausible guess. It also makes a later task easier to resume without relying on a long, opaque chat transcript that may omit the decisive source evidence.