The most useful coding-agent setup I have found is not a giant prompt. It is a small context system.
A prompt is what you say right now. A context system is what the agent can reliably learn before it acts: the task, the repo rules, the current production constraints, the relevant history, and the boundaries for what it may change.
When that structure is missing, even strong models behave like talented contractors dropped into a warehouse with no labels. They can move fast, but they do not know what matters, what is fragile, or which previous decision they are about to undo.
The shape I want
For coding work, I try to separate context into five layers.
1. Goal context
This is the plain-English outcome. Not the implementation. The outcome.
Examples: make the project list rank sunsetted projects last, reduce homepage LCP, add a safe deploy smoke test, explain why a production counter is wrong.
If the goal is vague, the agent should stop and clarify. If the goal is clear, it should keep moving until the loop is closed.
2. System context
This is where the repo explains how it wants to be changed. In practice, this means files like AGENTS.md, local runbooks, deployment notes, coding conventions, and the commands that define done.
This layer matters because every repo has taste. Some systems want generated files committed. Some do not. Some track data in JSON. Some use migrations. Some deploy through GitHub Actions. Some require a local preview before push. The agent needs that before editing.
3. Evidence context
This is the difference between guessing and working from facts.
For a bug, evidence might be logs, a failing test, a reproduction, a screenshot, or a production response. For an SEO task, it might be the rendered HTML, sitemap, robots file, headers, and Lighthouse output. For a product change, it might be the current UI and the data model behind it.
I want the agent to read first, then act. If it cannot show what it inspected, I do not trust the fix.
4. Boundary context
Agents need constraints as much as they need instructions.
Which files are off limits? Is the worktree dirty? Can it push? Can it touch production? Are there user changes that must be preserved? Is the task allowed to create public content, send email, change DNS, or delete data?
Good boundary context prevents the most expensive class of AI mistakes: doing a technically correct thing in the wrong operational scope.
5. Verification context
Every change should know how it will be proven.
Sometimes that is a unit test. Sometimes it is deno task check, a build, a local smoke test, and a production curl after deploy. Sometimes it is a visual screenshot. The important part is that verification is not invented at the end. It is part of the plan from the beginning.
What I avoid
I avoid dumping every document into the context window. More text is not the same as better context.
Old notes, stale architecture comments, unrelated tickets, and half-remembered decisions can make the model worse. The point is not to maximize context size. The point is to retrieve the smallest set of source-backed facts that changes the quality of the action.
The durable asset
Models will keep changing. IDEs will keep changing. The durable asset is the context structure around them.
A good setup lets any strong agent answer the same basic questions before touching code: what am I trying to do, what system am I in, what evidence supports the change, what boundaries apply, and how will I prove it worked?
That is the difference between an impressive demo and a workflow I am willing to use on production software.