Tooling was always make-or-break. Agents just shortened the fuse.
Before AI, the difference between the teams that shipped and the teams that thrashed was rarely talent. It was usually tooling: the one-command build, the test suite you could trust, the deploy that didn't require a ritual — versus hand-running everything and paying for it in toil, drift, and regressions.
Tooling was rarely the headline reason a project lived or died. But trace a failing project back far enough and you'll usually find its absence near the bottom of the spiral.
That's the premise of this article, and it's deliberately an old one: your agents are a new engineering team joining your org — fast, tireless, and overconfident — and the question that predicts their success is the one that always predicted ours. Whatever helped human teams win, your agents need the same. They just need it sooner.
The old law, on a new clock
Now that agents can execute arbitrary commands, there's a tempting idea in the air: tooling matters less. The agent is a machine — just let it do the steps by hand each time. It doesn't get bored. It doesn't get sloppy.
Except it does, in its own way. Agents, like people, make mistakes; engineering around that is a large share of what modern AI engineering actually is. In our org, every repetitive flow we didn't turn into a tool eventually produced an agent error — every single one. Not catastrophes, mostly: a wrong flag, a skipped verification, a command run from the wrong directory. The same small mess untooled humans have always made.
What changed is the clock. The old failure mode had one merciful property: it was slow. Toil compounded a sprint at a time, and there was usually a window to notice and recover. Agents make their mistakes at machine speed, in parallel, and with total confidence — an untooled human team accumulates a mess over quarters; an untooled agent fleet can produce one before lunch. The law is exactly the one we already knew: tooling is make-or-break. Agents just shortened the fuse from months to seconds.
In my last article I argued that scaled-up loop engineering is the SDLC, codified — and that custom tooling is what makes the loops viable. This is that article: the local half of the toolbox, the layer that runs on a laptop before anything touches a cluster. As you read, notice that every piece answers the same question — what did human teams always need? — rebuilt so an agent can hold it.
Skills: procedures as code
A skill is a written procedure the agent loads when the task calls for it. Ours cover things like how to research a topic (verify sources, don't trust training data for anything dated), how to plan an API contract before touching a cross-project interface, how to plan a data migration, and when a change is big enough to warrant a cost analysis first.
The planning skills fire situationally: touch a shared interface and the contract-planning procedure kicks in; touch a schema and the migration plan does. Research skills demand that examples be real, quotes be verbatim against fetched sources, and claims be checked against records instead of memory.
None of this is prompt magic. It's the same move as a team runbook: process knowledge taken out of one person's head and written where every future run inherits it. When an agent produces something below the bar, the fix isn't to correct that one output — it's to encode the correction into the skill so every future run gets it. Skills are where those corrections accumulate.
Agents, teams, and subagents: the org chart is code too
Every project in our org carries its own agent definitions — a roster of roles scoped to that project's stack and conventions. Planning roles run in parallel and read-only: a general planner, a security planner, a test planner, plus database, observability, and rollout planners where the project type calls for them. Execution roles follow: developer, tester, reviewer, debugger.
Two design rules carry most of the weight:
The reviewer never shares context with the implementer. A fresh-context reviewer isn't influenced by the reasoning that produced the bug. Same logic as human code review, and it costs nothing to enforce.
Instructions must live where the agent actually reads them. We learned the hard way that subagents don't inherit the top-level session's instructions — security guidance sitting in a global config was invisible to the role agents doing the work. The fix was structural: the guidance moved into the agent definition templates themselves, so every generated role agent carries it. If a rule matters, it goes in the tooling that spawns the agent, not in a document the agent never sees.
MCPs: the agent's senses and hands
Human developers get an IDE, a browser, and the docs; agents get MCP servers. The ones that earn their keep in local development return answers instead of dumps:
- Current library documentation on demand — training data is permanently stale; a docs-lookup tool means the agent implements against this year's API, not the one it remembers.
- Semantic code search and symbol-level editing, backed by a language server — find references, rename a symbol, jump to a definition. Structural operations instead of regex guesswork.
- Browser automation — drive the actual app, click through the actual flow, take screenshots, read the console. This is what makes UI work verifiable by an agent at all.
- A context interceptor that redirects large command output into an indexed store the agent queries instead of reads raw. Agents degrade when their context fills with log spew — this is log aggregation for models, and it's the difference between an agent that stays sharp for a whole task and one that drowns in its own tool output.
Test harnesses: verification loops an agent can close alone
Remember "the test suite you could trust"? For agents it's even more load-bearing. The loop-engineering guides all agree the first thing to hand off is the check; a test harness is how. Every check an agent can run itself converts a review burden into a stop condition.
Locally that means fast, deterministic harnesses: database-backed unit tests that spin an isolated schema per test, API tests that hit the router in-process with no server to stand up, dispatch tests for every MCP tool the product exposes, and coverage tooling so the agent can find what's untested instead of guessing.
UI gets the same treatment through browser automation: a dedicated end-to-end tester role drives real user flows and captures screenshots as evidence. "It renders" stops being a claim and becomes an artifact.
The standard we hold: if verification requires a human to look, it's a bottleneck; if it requires an agent to merely claim success, it's a fuse waiting to be lit. The harness is what removes both.
Debugging loops: fresh eyes on demand
Debugging gets its own role, and the role has one rule: reproduce first, fix second. A dedicated debugger with fresh context beats the implementer debugging its own work for the same reason the reviewer is separate — it isn't attached to the assumptions that produced the bug.
Two supporting habits make the loop fast. Replay fixtures: capture a real failing scenario once, then iterate against it in seconds instead of re-triggering the failure through the full system. And test-locally-before-anywhere: lint the chart, run the compose stack, curl the endpoint — prove the change works on the laptop before it ships toward an environment where the feedback loop is minutes instead of seconds.
The rule of thumb we operate by
That every-single-one track record produced the operating rule: if an agent does a flow more than a few times, bake it into a skill, an agent definition, an MCP tool, or a harness. Same as we always did for people, only with higher stakes: the operator count and speed went up by orders of magnitude.
Notice none of the toolbox above is exotic. Runbooks, org charts, code navigation, test suites, debuggers. Plain old developer tooling — rebuilt so a new kind of operator can hold it. That's also the quiet answer to "what should my team build first to get value from agents": not a bigger model, not a cleverer prompt. The toolbox. Prompts request. Tooling enforces.
Guess what else you can write? A skill for writing skills — when one is warranted, where it lives, how to tune the description so it actually fires, and the rule that corrections get encoded back into the skill instead of applied to one output. That turns "we're missing a procedure" from a habit your environment has to learn into a documented flow any agent can follow from its first session.
The part where I show my work
One last story, by way of validation.
While putting this article series together, I asked my agent to pull in an article-writing skill. It checked the toolbox: none existed. So it wrote one — voice rules, structure, formatting constraints, a quality bar with fact-checking requirements — and then followed it.
That's the reflex this whole article is about, pointed back at itself: in an environment where procedures are code, a missing procedure is a bug, whoever the operator is.
Building that layer — the skills, the roles, the harnesses agents can actually hold — is the work I do. If your org's agents are outrunning its tooling, let's have a conversation.
written by Claude
directed by David Brandon