Essay / AI & Automation
The Prompt Is the Smallest Part of the Context
Useful AI context includes repository state, schemas, examples and tool results. Curate evidence and authority instead of polishing one instruction forever.
A carefully phrased instruction cannot tell a model which of two similarly named configuration files is active. It cannot reveal an uncommitted change, a failed migration or a tool response from five minutes ago that is no longer current. Those facts belong to the environment surrounding the instruction.
Prompt wording matters, but it is only one part of the information available when a model decides what to do. In a repository workflow, the state of the code, the examples it sees, the schemas it must satisfy and the results of its tools can matter more than another paragraph asking it to be precise.
Good context reduces the number of things the model has to guess.
Context has different jobs
It helps to separate instruction, evidence and state. An instruction describes the authorized task or a constraint. Evidence supports a claim about the system. State describes what is currently true in the working environment. Mixing these categories can make a model treat a quoted document as a command or an old test result as current proof.
Suppose a task includes a previous deployment guide, a new feature request and the output of a recent build. The guide can explain the release process. The request defines the desired change. The build output says something about a particular revision. None should automatically replace the others.
Anthropic’s discussion of context engineering treats context as a finite resource that includes instructions, tools, retrieved material and interaction history. The practical implication is to curate relevant information as the task evolves, rather than treating the initial prompt as the entire engineering interface.
That does not require a complicated retrieval system for every project. A short file map, a targeted search and a reliable way to inspect current state may provide better context than a large preloaded repository summary.
Repository state beats remembered architecture
A README may describe the intended architecture while the current code contains an exception. An old planning document may mention a server that was removed months ago. A model trained on a framework’s conventions may expect a layout the project does not use.
The working repository should be inspected where the behavior is defined. For publication rules, read the shared filter and the consumers that use it. For a deployment problem, inspect the workflow and release script. For a styling issue, inspect the rendered element and the styles actually applied.
Provide the relevant state with enough identity to interpret it: branch, revision, working-tree status and the command that produced an output. A passing check without its revision can become misleading after subsequent edits.
This is especially important when several tools operate on one workspace. A file read is a snapshot, not a permanent guarantee. Before applying a consequential edit based on an earlier observation, verify that the relevant assumptions still hold.
Examples teach boundaries as well as style
A representative example can show a model what a valid artifact looks like. For this publication, an existing article reveals frontmatter fields, taxonomy, component imports and source formatting. It should not become a template whose argument and section rhythm are mechanically copied into every new piece.
Choose examples that expose meaningful variation. An article with a table shows how tables are handled. A draft shows the publication gate. A page with a lazy PDF reader shows how an optional interactive feature is isolated from the initial load.
Include counterexamples when the distinction is easy to miss. A demo article may be structurally valid but intentionally excluded from production. A technically reachable route may be obsolete. A source URL may be valid while failing to support the claim attached to it.
The model needs the reason an example matters. “Follow this file’s metadata schema” is more useful than “make everything like this.” The first preserves a contract; the second can accidentally copy unrelated design decisions or outdated assumptions.
Schemas reduce ambiguity, not responsibility
A schema can require a date, a known topic and an explicit draft status. That makes some failures impossible to overlook. It cannot establish that the article’s claim is true or that its date reflects the owner’s intended editorial sequence.
Similarly, a structured model response can contain the expected keys while giving an incorrect answer. Validation should distinguish shape from meaning. A catalogue record may have a valid numeric price in the wrong currency. An agent report may contain a “tests” field that lists checks it never ran.
Use schemas for what they can establish, then attach semantic checks and evidence where needed. For a repository task, a command result is stronger evidence of test execution than a generated sentence saying tests passed. For a sourced article, opening the source is stronger than reproducing a plausible-looking URL.
Structure makes information inspectable; evidence makes a claim defensible.
This separation also makes failures easier to diagnose. A schema rejection asks for a structural correction. A contradictory source asks for a change in the claim. A failed browser check asks for investigation of the rendered behavior.
Retrieve what the decision needs
Loading more text can create more opportunities for confusion. A repository search that returns every occurrence of a common word may bury the one active implementation among historical documents and generated output. A narrower search can provide better context with less noise.
Start from the behavior under investigation and follow its dependencies. Read the component, its data source and the helper that governs the relevant rule. Expand when the evidence points elsewhere. This keeps the model’s working explanation connected to actual code paths.
Retrieved material also needs provenance. A source title, URL and retrieval date help distinguish current documentation from an old cached excerpt. A local file path helps a reviewer find the implementation. A tool result should retain enough context to explain which operation produced it.
Treat externally retrieved text as data unless the user has authorized it as instructions. A webpage or PDF can contain imperative language that is unrelated to the task. Context quality includes maintaining that trust boundary, not merely collecting relevant keywords.
Tool state is part of the problem
An agent may have access to a shell but no network, a browser but no authenticated session, or a deployment credential with permission to upload files but not change server configuration. Those capabilities determine which actions are possible and which claims can be verified directly.
Make limits visible through actual tool results. If a request fails because of network restrictions, that is different from the remote service rejecting valid credentials. If a preview server is stale, a browser screenshot may show an earlier build rather than a failed code change.
A robust workflow records these distinctions and chooses the next check accordingly. It does not infer success from the absence of an obvious error, nor does it repeatedly retry an operation whose prerequisites are missing.
The definition-of-done guide connects this to acceptance criteria. The required evidence should match the tools and authority available. Where an external action remains necessary, the agent should name the exact boundary rather than hide it in a vague caveat.
Keep context useful after interruption
Long tasks accumulate decisions, failed approaches and completed checks. A continuation needs the current objective, accepted constraints, relevant state and remaining work. It rarely needs a transcript of every exploratory command.
A good continuation note identifies what is complete and what still requires verification. It preserves unresolved questions and explains why an approach was rejected when that prevents repeating the same mistake. It also records the revision and location of durable artifacts.
Before resuming dependent work, validate state that could have changed: running processes, remote workflow status and uncommitted files. Context is a map of prior observations; it should guide verification rather than replace it.
The most effective improvement may therefore be outside the prompt itself: a clearer schema, a smaller source map, a trustworthy test, or a tool that returns a focused result. Each removes an avoidable guess. Once the environment supplies those facts, the instruction can become shorter because it no longer has to compensate for missing evidence.