Your Agents Are Only as Good as What You Tell Them to Care About

Most teams deploying AI agents are copying someone else's homework.

They find a promising setup from a blog post, a DHH tweet, or an Every.to breakdown. They import the prompts, the tools, the workflow structure. Two weeks later they're spending half their day editing outputs and wondering why the agents aren't performing like the case study promised.

I've done this. I watched a consulting client do this. The problem isn't the agents. It's that the specification doesn't belong to you.

The "do-it-all" trap

Agents are generalists by default. Left without tight constraints, a coding agent will handle research, write documentation, make architectural decisions, and suggest refactors you didn't ask for. A project management agent will draft communications, flag risks, update statuses, and send summaries nobody reads.

This isn't a bug. It's how they're trained. The model wants to be helpful across every dimension it can reach.

With a human team member, you take certain things for granted. If you hire someone with strong communication instincts, you don't need to specify "make sure your stakeholder updates are clear." They read the room. They adapt. Years of social context fill in the gaps you never bother to articulate.

Agents don't have that social context. Every assumption you leave unspecified gets filled with a default, and the default is "try everything."

The result is agents that are technically capable but organisationally noisy. You end up reviewing and correcting output that was never in scope in the first place.

The real constraint has shifted

The two-pizza rule solved a real problem: communication overhead. Small teams mean fewer coordination channels, fewer meetings, less friction as decisions move through layers. Amazon built a successful engineering culture on it for 24 years.

But that rule assumed humans were the scarce resource and communication was the bottleneck.

Neither of those assumptions holds anymore.

At Syncio, we're a team of five with agents running across client work, internal tooling, and product development. The constraint isn't headcount. It isn't even compute. It's precision of instruction. The clearer we are about what each agent is responsible for and, critically, what it is not responsible for, the better everything runs.

This is the new leverage point. Not "how many agents do we have" but "how precisely have we defined what each one cares about."

What specification actually looks like

When I built the multi-agent architecture for BlogBuddy, we have four agents running in sequence: an OnboardingAgent, a CalendarAgent, a WriterAgent, and an EditorAgent. Early in the build, the WriterAgent was doing too much. It was making editorial judgements that belonged to the EditorAgent, suggesting scheduling changes that belonged to the CalendarAgent, and generally overreaching into adjacent territory because nothing told it not to.

The fix wasn't a better model. It was tighter scope.

We rewrote the WriterAgent's context to be explicit: your job is to produce a draft matching the brief. You do not evaluate the brief. You do not suggest publishing windows. You do not rewrite the hook unless the EditorAgent sends it back. That's it.

Output quality improved immediately. Not because the model got smarter, but because we stopped asking it to be a generalist.

Think of it like an ERP system. When I built custom ERP at Nebraska, every module had a defined boundary. The inventory module didn't make purchasing decisions. The purchasing module didn't update financial records directly. Those boundaries weren't limitations. They were what made the system reliable at scale. You could trust the output of each module precisely because it wasn't trying to do everything.

Agent specification works the same way. The constraint is the feature.

Why templates from other companies fail

This is the mistake I've seen most often with clients.

A team finds a well-documented agent setup, something from Every.to or a popular GitHub repo, and treats it as a starting point. The prompts look reasonable. The tools make sense. So they drop it in and expect similar results.

It doesn't work. Not because the template is bad. Because the template encodes someone else's priorities, someone else's team skills, and someone else's context.

Every.to's compound engineering workflow is excellent for Every.to. They have two engineers who think in a very specific way about planning, Github issues, and code review loops. The workflow is built around their cognitive patterns and their codebase history. It compresses knowledge that took months to develop.

When you copy it, you get the structure without the knowledge. You get the skeleton without the muscle memory.

I spent hours on one consulting engagement editing imported agent skills before I realised I'd have been better off starting from scratch. The edits weren't improvements. They were translations. I was trying to convert someone else's context into mine, and that's harder than building fresh.

What works is starting from your team's actual working patterns. What do you currently do well? What do people on your team instinctively get right without thinking? Those are the things you don't need to specify. What do people get wrong, or hand off awkwardly, or lose track of? Those are exactly the areas where agent specification adds value, because you're encoding the discipline that the team currently lacks.

Agents amplify what you give them. Start with your own ground.

A practical starting point

If you're building your first agent team, or rebuilding a setup that isn't working, I'd suggest this sequence.

Write down what each agent is responsible for in one sentence. If you can't do it in one sentence, the scope is probably too wide. Then write what each agent is explicitly not responsible for. That second list is where most people skip. It's also where most of the noise comes from.

Finally, run the agent on real work for a week and track every time you edit its output. Most edits will cluster around a few categories. Those categories tell you exactly where your specification is loose. Tighten those boundaries, not the prompts.

The productivity gains in AI-first teams are real. But they come from the clarity of your thinking, not the sophistication of the models. The teams that win aren't the ones with the most agents. They're the ones who know precisely what each agent is there to do.