The developer's agent stack: context, verification, skills, and memory

Most developers judge coding agents by the model. In my experience the model is the smaller variable. The bigger one is what the agent can see, what it can check, and what it already knows about how you work.

An agent with no context guesses at library APIs. An agent with no way to verify claims its work is done. An agent with no standing instructions relearns your preferences in every session. Each of those failures looks like a model problem. Each is a setup problem.

I think about the setup in four layers: context, verification, skills, and memory. This post covers what goes in each layer and the tools I actually use. It also covers what a lead should standardize, so the whole team benefits and not only the enthusiasts.

This is the first post in a short series on working with agents. The second covers skills over prompts. The third covers how I work with agents every day.

Layer 1: context the agent cannot guess

Agents are trained on yesterday’s internet. Your libraries moved since then, and your codebase was never on the internet at all.

Two MCP servers handle most of the external context for me:

• context7 pulls current documentation for a library or framework. The agent reads the API as it is today instead of how it was in its training data.
• deepwiki gives the agent a structured view of a public repository, so it can answer “how does this project do X” without me pasting files.

The internal context lives in the repository. Conventions, layer boundaries, and the review comments a team keeps repeating belong in files the agent reads at the start of a task. I wrote about that in building an agent harness. The short version: fix the repo before you tune the prompts.

Layer 2: a way to check its own work

The failure I see most often is an agent that says it is done before it has proven anything. It writes the code, reads it back, and reports success. Reading code back is not verification.

So the agent needs tools that touch the running system:

• Playwright and Chrome DevTools let the agent open the app, click through the flow it changed, read the console, and inspect network calls. For UI work, I expect the agent to test in the browser before it reports back.
• Observability tools (Sentry, Datadog, groundcover, Rootly) let the agent read real errors, logs, and incident timelines while it debugs. It starts from evidence instead of a guess about what probably failed.

Tests sit in this layer too. An agent that writes a test, watches it fail, and then makes it pass has shown something. An agent that writes code and a passing test in one step may have shown nothing.

Layer 3: skills that encode how you work

A prompt tells an agent what to do this time. A skill tells it how to do a kind of work every time. That difference is the subject of the next post, so here is only the list.

I mostly adapt skills others wrote rather than write my own. Three sets changed how I work:

• pstack, for engineering judgment: architecture before code, parallel attempts at the same task, multi-model review of a diff, and cutting AI tells from prose.
• BMAD, for larger features: a spec-to-story-to-build workflow that keeps a feature coherent across several sessions.
• Writing skills (humanizer and an STE100-style rewrite), because agents write a lot of text that other people and other agents have to read.

My skills live in one folder that more than one agent tool reads. When I switch tools, my way of working comes with me.

Layer 4: memory that outlives the session

Long sessions drift. The agent forgets a decision from an hour ago, or the context fills up with file dumps it no longer needs. I handle that three ways.

First, big reads go to subagents. When a task needs a wide search or a pile of files, a subagent does the reading and returns only the conclusion. The main session keeps its context for decisions.

Second, I start a fresh session per task. Stretching one session across unrelated work is the fastest way to get drift.

Third, decisions get written down. Specs, plans, and memory files carry what was decided into the next session. The chat history does not. If a decision only exists in a conversation, it will be lost.

What a lead should standardize

Individual setups help individuals. A team gets the benefit only when the base is shared. Four things are worth standardizing:

1. Repository rules and context. Build them from the review comments your team keeps leaving. Every repeated comment is a missing rule.
2. A shared set of skills and MCP servers. Everyone should start from the same docs access, the same browser tools, and the same core skills. Otherwise the team has five private workflows and no common one.
3. A default workflow. Spec, review, build, test should be the expected path for agent work. The daily workflow post describes the one I use.
4. Review standards for agent-written PRs. Decide what reviewers check and what “done” means. “The agent said it works” should not count as done.

Start with the layer you are missing

If you add one thing this week, add the layer you lack. If your agent guesses at APIs, add documentation context. If it claims success too early, give it a browser and make it use it. If it ignores your conventions, write them into the repo. If it forgets decisions, write the decisions down.

The model will keep improving without your help. The setup around it will not.