Most Agents Fail Because the Task Was Wrong: Rule of R and the Trust Ladder

Everyone's building agents now, and most of them shouldn't be. Not because agents are bad — because the task underneath them was wrong. The two-hour weekly report that varies every time. The judgment call that needs taste. The thing you do twice a year. Each gets an "agent" built around it, each agent drifts and hallucinates, and the conclusion drawn is "agents aren't ready." The agent was fine. The assignment was wrong.

Here's the shift that matters before any tooling: a chat is a meeting — you talk, it answers, you carry the output to the next step yourself. An agent is an employee — you give it an outcome, it plans, acts, checks its own work, and loops until done. Employees are expensive to onboard and terrible at vague job descriptions. Same for agents.

So this post covers the two questions everyone skips: which tasks deserve an agent at all, and how much autonomy to hand over — a graduated trust ladder that takes you from a draft-only assistant to a scheduled workflow without ever giving the keys away on day one.

What Separates an Agent From a Script

Four capabilities stack up into an agent:

• Diagnose — reads the situation and decides what needs solving (consultant)
• Assemble — plans the steps and picks the tools (architect)
• Take action — executes the work (operator)
• Assess — checks its own output, finds errors, corrects, repeats (the loop)

That last one is the whole difference. Without self-correction you have a script; with it, you have something that behaves like a capable employee — one that notices the invoice total doesn't match and goes back to fix it before you ever see the draft.

But notice what the loop implies: the agent must judge its own work against a standard. If the standard is fuzzy — "make it good" — the loop spins uselessly. Which is why task selection comes first.

The Rule of R: Should This Be an Agent at All?

Run every candidate task through three filters:

Classic passers for a technical operator: inbox triage into action/decision/FYI, invoice reminder drafting, lead-response qualification, weekly metric digests, comment sentiment sorting. Classic failures: pricing decisions, anything involving an apology, "improve our strategy."

The honest math: an agent that saves ten minutes a day pays back a week of build effort in two months. An agent that saves two minutes a week never does. Write the estimate down before building — the Rule of R is a spreadsheet question, not a vibe.

Aim: Define the Outcome, Not the Steps

Agents are better at pathfinding than you are at describing paths. Give the destination, not turn-by-turn directions.

• State the why: "I want my mornings free of email sorting"
• One measurable Definition of Done: not "handle my emails" but "by 9 a.m. daily, inbox contains only items needing my decision; everything else answered, filed, or archived"
• Reverse prompting: tell the agent the outcome and let it interview you for the missing details — it will ask better questions than you'd think to volunteer answers to

The Definition of Done is also the agent's self-assessment standard. The loop can only close tightly around a sentence that can be checked.

Identity and Equipment: Keep the Desk Clean

Two failure sources account for most bad agents: vague identity and thin context.

Identity — three small files, generated by interviewing yourself once:

soul: "direct, warm, allergic to hype; never apologizes twice;
       asks one clarifying question max"
identity: "triage agent for a solo consultant; handles inbound
           email only; escalates money and legal topics"
user: "owner goals: mornings free, no missed deadlines,
       hates phone calls"

Equipment — examples beat instructions. Fifty of your past sent emails teach your voice better than any paragraph of adjectives. Two real escalation cases teach the escalation rule better than a policy doc. Thin context produces confident nonsense; rich context produces boring competence. Choose boring.

And watch for context rot: when the instruction set accumulates contradictory goals and stale permissions, the agent's desk is cluttered and quality degrades. Prune identity files like code — dated, versioned, smaller each quarter.

Narrow: Sub-Agents Beat Mega-Agents

The most common architecture mistake is one agent that writes, researches, files, and sends. Every added responsibility dilutes every other one. Instead:

manager agent (strong model, reasons over the goal)
  ├── triage agent (small local model, sorts mail fast)
  ├── draft agent (mid model, writes in your voice)
  └── audit agent (checks drafts against rules)

Each specialist gets one lane, one identity file, one definition of done — and you can match cost to complexity: a small local model for sorting, your strongest model only where judgment lives. This is also the privacy split: sorting runs fine on Ollama at home; only the genuinely hard reasoning needs the big cloud model, if any.

Trust: The Autonomy Ladder

Never hand over the keys on day one. Autonomy is earned in stages, and each stage has an exit criterion:

1. Draft only. The agent produces work; nothing leaves the machine. You review everything. Exit: five consecutive clean runs.
2. Supervised actions. It prepares the action — email queued, file moved — and waits for your click. Exit: two weeks, no catches needed.
3. Scheduled with guardrails. It runs on a heartbeat (hourly, nightly) inside hard limits: never sends to new addresses, never touches money, always logs what it did.
4. Alert-only. It works; you hear about it only when a rule breaks or confidence drops below a threshold.

guardrails:
  allowed: [draft replies, archive, label, digest]
  forbidden: [send to unknown, delete, payments, external sharing]
  logging: every action appended to daily log
  heartbeat: "0 9 * * *"   # 9 a.m. definition-of-done check

The schedule is where the agent stops being a toy: a 9 a.m. heartbeat against the Definition of Done is the difference between "I built an agent" and "I no longer do this task."

Frequently Asked Questions

What's the actual difference between a chatbot and an agent?

A chatbot answers; you carry the output to the next step by hand. An agent pursues an outcome across multiple steps — planning, acting, and checking its own work against your Definition of Done in a loop, without you in between.

How do I stop the agent from drifting or making things up?

Three practices: rich example-based context (fifty real samples beat any adjective), narrow scope via specialized sub-agents instead of one mega-agent, and periodic pruning of the identity files — context rot comes from accumulated, contradictory instructions, not from agents being inherently unreliable.

Should my first agent be local or cloud?

Start wherever the data is most sensitive and the task is simplest — usually a small local model (Ollama) doing triage or classification. Keep the strongest model for the reasoning-heavy manager role only. That split gives you privacy where it matters and capability only where it's needed.

How long before I can leave it running unattended?

The ladder answers it: five clean supervised runs, then two weeks of queued-action review with no corrections. Most triage-style agents graduate in three to six weeks. If it keeps needing catches at week six, the task failed the Rule of R — rebuild the boundary or do it manually.

Wrap-Up

The agent wave rewards restraint. Pick tasks that are repetitive, rules-based, and worth the build time; aim them at one measurable outcome; give each a narrow identity, real examples, and a single lane; then climb the trust ladder — draft, supervised, scheduled, alert-only — with guardrails that never expire. Do that and agents quietly take real work off your desk. Skip it and you'll join the crowd explaining that agents "aren't ready," when really the assignment never was.