I Built 51 agents. Then I started removing some.

I spent a good part of last year trying to figure out how I wanted AI coding agents to work.

Like a lot of my projects, I didn't start with a particularly grand plan. I was using Claude Code heavily, finding things that annoyed me, and building tools to fix them.

Eventually that turned into Agency.

Agency had more than 50 specialized agents. There were agents for architecture, frontend work, backend work, testing, security, documentation, product management, and just about every other role I could think of. I added commands for different development workflows, Git worktrees for parallel development, hooks, orchestration, and increasingly detailed instructions for how everything should work together.

It worked.

It was also a lot.

The more I used it, the more I started wondering whether I was solving the wrong problem.

The original idea made sense to me.

If I wouldn't expect one person to be an expert at everything involved in building software, why would I expect one agent to be?

Give the security work to a security agent. Give architecture to an architect. Let a frontend specialist handle the UI. Have another agent review the implementation.

The problem was that all of this machinery had a cost.

Agents needed descriptions so the model knew when to use them. Commands needed instructions. Workflows needed orchestration. Each new capability added more context and more opportunities for the system to make a decision I didn't really need it to make.

I had built infrastructure to help the coding agent do its job, but eventually the infrastructure itself became something the agent had to understand.

That wasn't what I wanted.

Meanwhile, I kept seeing coding agents make the same kinds of mistakes.

An agent would ignore an existing repository abstraction and write directly against the database.

It would instantiate something directly even though the project used dependency injection.

It would fix a small UI problem by restructuring a component that didn't need to be restructured.

Sometimes it would implement something that looked complete until I discovered that part of the implementation was mocked.

My first instinct had been to solve problems like these with more specialized agents and better prompting.

Eventually I realized that most of them didn't require another agent.

If a project always uses a repository for data access, the coding agent needs to know that.

If every change needs to pass the test suite, I shouldn't have to remember to ask the agent to run the tests.

If files need to be formatted after they're changed, a formatter can do that.

If there are commands that are always safe to run, I don't need to approve them for the four hundredth time.

Those aren't intelligence problems. They're harness problems.

CC-Toolkit was my attempt to see how little machinery I actually needed.

Instead of dozens of specialized agents, I reduced things to two broad roles: one for planning and one for implementation.

Instead of trying to put every architectural convention into one enormous prompt, I started using small rules that could be loaded when they were relevant.

Instead of asking the model to remember mechanical steps, I used hooks.

Formatting can happen after a file changes.

Tests can run when the agent thinks it's finished.

Repository state can be injected when a session starts.

Security tools can run automatically.

None of this is particularly sophisticated, and that's kind of the point.

I was moving work away from the model.

This became one of the more important things I took away from the experiment.

Every instruction I give an agent competes with something else for its attention.

A giant project instruction file might contain everything the agent could possibly need to know, but most of it isn't relevant to the task it's doing right now.

The same is true of tools and agents.

If I expose 50 agents because one of them might be useful, the model still has to reason about those 50 possibilities.

I started preferring systems where the agent received the smallest useful set of instructions and capabilities for the thing it was currently doing.

That doesn't mean "less context is always better." It means I stopped treating context as free.

At first, it's tempting to sit down and write every rule you think an agent might need.

I don't do that anymore.

I let the agent fail.

If it makes an architectural mistake once, I correct it.

If it makes the same mistake again, that's evidence that the system needs a guardrail.

Maybe that becomes a rule. Maybe it becomes a hook. Maybe a test should catch it. Maybe the tool itself should make the wrong behavior impossible.

That distinction matters to me because I don't want the harness filled with instructions for hypothetical problems.

I want it to encode things I've actually learned from using the agent.

The harness grows from observed failures.

This also changed the way I evaluated coding agents.

It's easy to blame the model when an agent does something stupid.

Sometimes the model really did make a bad decision.

But sometimes I gave it poor context.

Sometimes I exposed too many tools.

Sometimes the task didn't have a clear completion condition.

Sometimes I relied on a prompt for something that should have been enforced by code.

Sometimes the environment allowed the agent to take a path I never wanted it taking in the first place.

The model is only one part of an agent.

The harness around it determines what the model knows, what it can do, what happens after it acts, and how we decide whether it actually succeeded.

I've become much more interested in that part of the problem.

I still like a lot of the ideas in Agency.

Building it taught me things I probably wouldn't have learned by sitting around designing the "right" agent architecture on paper.

But CC-Toolkit was a reaction to what I learned from actually using it.

Agency asked:

How much useful structure can I build around a coding agent?

CC-Toolkit made me ask almost the opposite question:

How much of that structure do I actually need?

I've continued experimenting since then, and my thinking has changed again.

That's usually how these projects go.

I build something because I have a question. I use it until I start seeing the parts that bother me. Sometimes I fix those parts. Sometimes the thing that bothers me turns into an entirely different project.

The code is useful.

But most of the time, what I'm really after is the answer to the next question.