The first failure is always instructive

Here's a pattern that shows up consistently when founders first hand a recurring task to an AI agent: the agent does something technically defensible and completely wrong.

Not wrong in an obvious way. Wrong in the way that only someone who knows how you operate would catch. The agent triaged a support ticket as a feature request instead of a billing issue because the customer phrased it ambiguously. It sent a follow-up to the wrong segment. It escalated something you would have resolved in thirty seconds with no fanfare.

Your first instinct is to blame the model. That's the wrong diagnosis.

The actual problem is that you never documented how you do it. You've been operating by feel, by context, by the kind of pattern-matching that comes from doing the same thing a hundred times. That knowledge is real. It's also invisible — to an agent, to a new hire, to anyone who isn't you.

The agent just made the invisibility visible.

Tacit knowledge is the enemy of delegation

There's a term in organizational theory: tacit knowledge. It's the stuff you know how to do but can't easily explain. How an experienced operator knows which customer emails to answer personally and which to hand to the template. How you know, in thirty seconds of reading a lead profile, whether they're worth a call this week. How you decide what "urgent" actually means.

This knowledge is real. It took real time to develop. It also doesn't transfer.

When you hand a task to a human employee, they pick up some of it through osmosis — watching how you operate, getting corrected on edge cases, absorbing the unspoken rules. It's slow and inconsistent, but it happens.

Agents don't have that affordance. They have what you gave them, and nothing else.

This gap — between what you know and what you can specify — is where agents fail. Not because the model is insufficient. Because the specification was.

What undocumented processes actually look like

You almost certainly have more of these than you think. Here are the categories where they cluster.

Triage and prioritization. You know which support tickets are actually urgent and which are just loud. You know which investor emails to answer today and which can wait a few days without consequence. You know which bugs are drop-everything and which go in the backlog. None of this is written down. It's judgment calls that feel obvious to you and are completely opaque to an agent with no context.

Tone and relationship calibration. How you write to a longtime customer is different from how you write to someone who signed up yesterday. How you handle an angry user who's probably right is different from one who's probably wrong. You do this automatically. An agent will apply whatever register you specified, uniformly, to everyone.

Escalation criteria. When does something stop being the agent's job and become yours? You have a mental model for this. An agent needs that model spelled out. "Use your judgment" is not a specification.

Decision thresholds. At what point does a discount request need your approval? At what cost does a vendor decision need a second look? How much ambiguity in a customer request triggers a clarifying question versus an assumption? These numbers often exist nowhere except inside your head.

The diagnostic question

Before handing any recurring task to an agent, ask: Could a smart contractor who joined this week do this correctly with only what I've provided?

Not a domain expert. A competent, intelligent person with zero context about your business, your customers, your history, or your preferences. Could they execute this task and produce something you'd be comfortable shipping?

If the answer is no, you're not ready to delegate it. Not to an agent. Not to a human. You have a documentation problem that's showing up as an agent problem.

This reframe matters. The question isn't "is this agent smart enough?" It's "have I given this agent enough to work with?" Most of the time, the answer to the second question is no, and the first question was never the issue.

The upside: agent failure is a process audit

Here's what nobody tells you: this is actually useful.

Every place an agent fails is a place where a process only lives in your head. That's not just an agent problem — that's a business resilience problem. An operation that depends on tacit knowledge held by one or two people is fragile. It doesn't scale. It's hard to hand off. When those people leave or burn out, the process evaporates with them.

Deploying agents systematically surfaces these gaps. It forces the question: what are we actually doing here, and can we articulate it?

The businesses that end up using agents successfully aren't the ones with the most sophisticated tools. They're the ones who know their own operations well enough to specify them. Agent deployment is really a process maturity exercise wearing an AI costume.

This is painful in the short term. It's worth it regardless of whether the agents ever work perfectly.

Documenting for agents is different from documenting for humans

A process doc written for a human employee is usually too vague for an agent. Not because the writing is bad — because humans can infer. They read tone, ask clarifying questions, and know what "this looks off" means and escalate accordingly. You can write "use your judgment" and a human will try.

Agents need structure. Specifically, they need:

Trigger conditions. What exactly starts this process? Not "when there's a support ticket" — which tickets? What signals qualify? What's the entry condition?

Available inputs. What information does the agent actually have access to? What can it read, look up, reference? Be explicit. Agents can't consult a resource if they don't know it exists.

Expected outputs. What does "done" look like? Not "a good reply" — what format, what length, what information must it include, what must it never include or assume?

Edge case handling. The cases you'd handle differently from the default. These are almost always the cases you know from hard experience, which means they're tacit knowledge, which means you have to drag them into explicit form deliberately.

Escalation criteria. Specifically what makes this stop being the agent's job and become yours. What signals should trigger a handoff rather than a best guess?

Process docs that actually work for agents look more like technical specifications than the onboarding materials you'd write for a new hire. More work upfront. Substantially better outcomes.

The real bottleneck

Most people who struggle with agent deployment frame it as a capability problem: the models aren't good enough, the tooling is too brittle, the integrations aren't reliable yet.

Some of that is real. The tooling has rough edges. Models have failure modes worth knowing.

But the more common bottleneck is simpler and more fixable: operators who haven't done the work of understanding their own operations well enough to hand them off. The agents are ready for more than they're getting. The humans haven't written it down.

This is actually good news. It means the constraint is one you control.

You don't need a better model. You need a better process doc. Start with your most repetitive task — the one you do by rote, the one you've done a hundred times — and try to write instructions specific enough that a stranger could execute it correctly on the first attempt.

If you struggle to write it down, that's the process you should document first. That's where your institutional knowledge is most at risk. That's where an agent will fail if you hand it off today.

Fix the doc. Then delegate.

Your Agents Can't Run a Process You Never Wrote Down