Your first agent should be boring too

We've made the case that your data stack should be boring. The same argument applies to your first AI agent, for the same reason: what kills these projects is lost trust, far more often than a technical failure. The pattern we keep seeing is a first automation chosen to impress, such as a customer-facing chatbot or an outbound SDR agent, that produces one bad output in week two. Nobody remembers the hundreds of interactions that went fine. Everybody remembers the one email, and the automation program is quietly shelved for a year. Your first agent's real job is to survive long enough to earn a second one.

Pick for survivability, not for the demo

A good first agent scores on four criteria at once:

• High volume. Dozens of instances a day, minimum. Volume is where the payoff lives and where you learn, fast, what the agent actually gets wrong.
• Low blast radius. The worst plausible output costs someone a wasted minute. It never costs a customer, a refund or a public apology.
• Human-reviewable. The output is a draft or a label that a person was already looking at anyway, so review adds no new step.
• A measurable baseline. You know what the task costs today (hours, error rate, backlog), so "is this working" is arithmetic instead of vibes.

Tasks that fit: ticket triage and labeling, draft responses for support or sales, data entry from documents, first drafts of internal reports. Tasks that don't fit, no matter how good the demo looks: anything customer-facing and irreversible, anything that moves money without a gate, and mass outbound of any kind. An error rate that's tolerable at one message is a disaster multiplied across 2,000 recipients. OpenAI's own practical guide to building agents makes the same call, recommending that sensitive, irreversible or high-stakes actions such as large refunds or payments trigger human oversight until confidence in the agent's reliability grows.

Autonomy is a promotion

The other early mistake is treating autonomy as a launch setting. We run every agent up the same ladder:

1. Draft. The agent writes; a human performs the actual action. Zero blast radius, full signal on quality.
2. Propose with approval. The agent stages the real action (the ticket update, the ledger entry), and it executes only when a human clicks approve. This is the pattern OWASP recommends against excessive agency: keep a human approval step for high-impact actions and give the agent only the permissions the task needs. The MCP spec says the same for tool calls, that a human should be able to deny any invocation.
3. Autonomous with audit. The agent acts on its own within hard limits, every action is logged, and a human reviews samples of the log.

Promotion requires a reviewed track record, not a good week. Our rule of thumb is about a month at the current rung with an approval rate above 95% before a gate comes off. Demotion is instant the first time a new class of error shows up. And the audit log is non-negotiable at every rung. An agent doing forty things an hour is unaccountable without one, and unaccountable automation is what gets programs killed.

A worked example: invoice intake

A concrete shape we like as a first project is supplier invoices into the accounting system. Say 200 invoices a month arrive as PDFs and email attachments, and someone re-keys each one (vendor, date, amounts, line items) at three to four minutes apiece. That's roughly 12 hours a month of skilled-person time, with a known error pattern: the transposed digit that surfaces weeks later at reconciliation.

The agent reads each document, extracts the fields, matches the vendor against existing records and proposes the entry through the accounting system's API. That's rung two of the ladder, so nothing posts until a human approves it in a queue. Anything ambiguous escalates instead of guessing: a vendor it hasn't seen, a currency mismatch, line items that don't sum to the total. The blast radius of a wrong draft is one rejected queue item, never a wrong payment. The baseline makes success legible: minutes per invoice and error rate, before versus after. After a quarter at a 98%+ approval rate, it earns a promotion. It can auto-post routine invoices from known vendors under a $500 cap, and the approval gate stays for everything else.

When you don't need an agent at all

If the input is structured and the rule is deterministic, you don't need a model. You need a cron job or a Zapier zap. "When the form is submitted, create the CRM row and post to Slack" is a two-step zap that Zapier's free plan covers at low volume, and its paid plans start around $20 a month. It never hallucinates, and it ships this afternoon. Anthropic's engineering team gives the same advice in Building effective agents: find the simplest solution possible and only add complexity when it's needed, using fixed workflows for well-defined tasks and reserving agents for open-ended ones. An agent earns its keep only when the step requires reading something messy and exercising judgment: which team should own this ticket, what this invoice is actually for, whether this reply addresses what the customer asked. Work up the ladder of cheapness (script, then zap, then agent) and stop at the first rung that solves it.

This is the shape of the automation we build: the typed tools, the approval queue, the audit log and the escalation paths. Then we run it on retainer while it earns each rung of autonomy.

Sources

• A practical guide to building agents, OpenAI
• LLM06:2025 Excessive Agency, OWASP GenAI Security Project
• Tools (MCP specification 2026-07-28), Model Context Protocol
• Building effective agents, Anthropic
• Plans and pricing, Zapier