Your Agents Are Doing Exactly What You Asked. That's the Problem.

The Failure Mode Nobody Talks About

When an agent does something wrong, the first instinct is to look for the bug. Check the logs. Review the tool calls. Trace the execution path.

Most of the time, there's no bug. The agent did exactly what you told it to do. Every decision was technically correct. The problem is that what you told it to do wasn't actually what you wanted.

This is different from the "instructions rot" problem — where good specs degrade over time as the business changes. This is worse. These are specs that were never right to begin with, because writing a spec that actually captures what "good" looks like is harder than it sounds.

Here's a concrete example. You build an agent to follow up with deals that have gone quiet for a week. It runs. It follows up. It follows up on deals you've already closed. It follows up with prospects in active negotiation who just haven't replied yet. It sends an email to someone who previously asked to be taken off outreach. None of this was a bug. Every action was technically correct behavior for the spec you wrote. The spec was the bug.

Why We're Bad at This

Human delegation works because humans fill in gaps. When you hand a task to a competent person, you hand it to someone who brings professional norms, situational judgment, and pattern-matching from thousands of prior examples. They know the exceptions without being told the exceptions.

Agents don't fill in gaps. They exploit them. Every gap in your spec is surface area for technically-correct-but-wrong behavior.

The uncomfortable truth: most of us have never had to articulate our own work processes with precision. We just do them. A sales rep who follows up after a week of silence knows not to message a deal they're already actively negotiating, not to touch a won deal, not to reach out to someone who pushed back last month. That knowledge lives in their head, was never written down, and never needed to be — because they're a person, reading context, making judgment calls.

Writing specs for agents means externalizing all of that implicit knowledge. For the first time, you have to be explicit about not just what to do, but when to do it, when not to, what "done well" looks like, and where to stop and ask.

Most founders find this uncomfortable. It forces a confrontation with how much of the business is running on unexamined habit.

What a Bad Spec Looks Like

Bad specs have a predictable anatomy. They're defined by what they're missing.

No outcome definition. "Send follow-up emails" is a task description. "Keep active deals moving forward without annoying people" is an outcome. A spec built around tasks produces agents that complete tasks. A spec built around outcomes produces agents that do the right thing. Not the same.

No exclusion criteria. Specs describe what the agent should do. Almost no specs describe what it should not do. The list of valid-looking actions that are actually wrong is usually longer than the list of correct ones. Exclusions need to be explicit.

No escalation signal. When should the agent stop and ask a human? If your spec doesn't answer this, the agent will never ask — because you never said to. That sounds efficient until the agent does something irrecoverable that would have taken thirty seconds to catch.

No definition of "good enough." An agent executing a spec that doesn't define acceptable output will produce outputs across a wide quality range, with no systematic way to surface the bad ones. The agent doesn't know it produced something atrocious, because you never defined atrocious.

Too much implicit context. The things you think are obvious are exactly the things worth writing down. They're the first things an agent will get wrong.

Speccing for Outcome, Not Action

The useful reframe: don't write "here's what I want the agent to do." Write "here's how I'd evaluate whether the agent did its job well."

Write the rubric first. Work backwards to the actions.

For the follow-up example, the rubric might look like this: the agent did its job if (1) every active deal gets a touchpoint before silence hits two weeks, (2) no closed, churned, or suppressed contacts get messaged, (3) tone matches the relationship — different for a deal three days old than one three months in, (4) nothing ships that you'd be embarrassed by if the prospect forwarded it to their team.

Now you have something to build against. The rubric makes exclusion criteria obvious. It shows you where escalation is needed — anything that risks criterion four should route to human review before sending. Success is concrete and testable.

This isn't just AI operations hygiene. Forcing yourself to write a rubric before building a spec is one of the most clarifying things you can do with a business process. If you can't write the rubric, you don't understand the process well enough to delegate it — to an agent or anyone else.

That's not a comfortable realization. It's a useful one.

The Judgment Gap

There's a class of work where the spec would be infinite, because the right answer changes with every instance in ways that require reading context you can't fully anticipate. Don't try to spec these away.

That's the judgment gap. It's real, it's not going away, and it's where humans belong in the loop.

The practical test: if a thoughtful new hire read only your spec and produced outputs on twenty real examples, would you be satisfied with at least eighteen of them? If yes, you can likely spec it well enough to delegate. If no, you either need to work harder on the spec or keep a human in the loop for the hard cases.

The mistake most builders make is treating all work as binary — either automatable or not. Then they're surprised when the agent handles easy cases brilliantly and destroys the hard ones. The correct frame: most work can be delegated with a good enough spec, some work genuinely requires human judgment for a subset of cases, and the spec should route that subset to a human rather than pretending it doesn't exist.

Design for the 10% exception, not just the 90% case.

What Good Specs Give You Back

Here's the flywheel that isn't obvious until you're inside it.

When you write a spec carefully enough that an agent executes it well, you've done more than automate a task. You've documented a business process in explicit, durable terms. That spec is now institutional knowledge. It doesn't live in anyone's head.

The spec can be versioned. It can be reviewed by someone who wasn't in the room when you built it. It can be handed to a different agent, a different platform, or a new hire who starts next month. It survives turnover, memory loss, and founder inconsistency.

Good specs also compress into alignment tools. Once you've written a rubric for evaluating a follow-up email, you've created something your whole team can align against — not as documentation that lives in a drawer, but as an artifact actively tested every time the agent executes.

Bad specs are a lagging indicator of unclear thinking about your own work. Good specs are clarity, made durable. The discipline is worth it for the clarity alone, independent of what it does for your agents.

The Practical Protocol

A few things that actually improve spec quality, without a full process overhaul:

Do the task manually first. Before writing a spec, run through ten real examples yourself and write down exactly why you made each decision. That decision trail is your spec. Skipping this step is the most common reason first specs fail.

Write the anti-examples. For every spec, write a parallel list of things the agent could technically do that would be wrong. This is the fastest way to surface the implicit exclusion criteria you're carrying in your head.

Ask the worst-case question. "What's the worst thing this agent could do that technically followed this spec?" If you can answer that, your spec is missing a guardrail. Add the guardrail. Ask again. Keep going until you can't answer it.

Review the first batch personally. Not to micromanage — to calibrate. The gap between what you specified and what you got tells you exactly where to revise the spec.

Treat it as a living document. Not because the process changes constantly, but because your understanding of it sharpens once you watch an agent execute it. The spec iteration loop is part of the work, not overhead.

The agents aren't the problem. You asked them to do something. They did it. The question is whether you asked for the right thing — and the only way to find out is to write down what "right" actually means before the agent ships its first output.