An AI agent is software that takes a goal, uses tools, and works toward a result with limited supervision. Strip away the mysticism and that’s the whole definition. The interesting question isn’t “what is an agent” — it’s how to build one reliable enough that you’d let it run while you sleep.
We run agents in production across our own portfolio — research agents, content agents, pipeline operators — and the reliability principles below are the distilled version of what that cost us to learn. This guide walks through those principles, then applies every one of them to a concrete first build: a scheduled research agent that produces a daily brief you’d actually read.
The mental model: autonomy is a budget, not a feature
The core design question for any agent is not “how smart is the model” but “how expensive is a mistake, and how cheaply can I catch it?” An agent summarizing news can be wrong occasionally at almost no cost. An agent emailing your clients cannot. The rule we build by:
An agent earns autonomy in proportion to how cheaply its mistakes can be caught.
Everything else in agent design — checkpoints, guards, human review — is just this rule applied to specific steps.
The five reliability principles
1. Deterministic where possible, model-driven where necessary
The single biggest reliability upgrade costs nothing: move work out of the model. Fetching, filtering, formatting, scheduling, deduplicating — these are code, and code doesn’t hallucinate. Reserve model calls for the steps that genuinely need judgment: summarizing, ranking by relevance, drafting. Our production pipelines are mostly ordinary deterministic steps with a few carefully chosen model calls in the middle — that ratio is the design goal, not a compromise.
2. Small tools, clear contracts
Agents work dramatically better with narrow tools (“fetch_feed(url)”, “save_brief(text)”) than with one vague “do_research()” capability. Each tool should have one job, an obvious input, and a predictable output. If you can’t describe a tool’s contract in one sentence, split it.
3. State lives outside the agent
Queues, seen-item lists, statuses, and outputs belong in a store — Airtable, a database, files — that the agent reads and writes. The agent itself should be replaceable mid-run without losing anything. Agents that “remember” in-context are demos; agents that check state are systems.
4. Checkpoints where errors are expensive, guards everywhere else
A guard is an automated check: does the output parse, is it under the length limit, does it contain a source link for every claim? Guards are cheap — use them liberally. A checkpoint is a human: the agent drafts, you approve. Put checkpoints only where the mistake-cost rule demands them, or you’ll become the bottleneck in your own automation.
5. Route models by task difficulty
Not every step deserves your most expensive model. Mechanical steps — extraction, classification, reformatting — run fine on inexpensive models; judgment steps earn the strong ones. This routing discipline routinely cuts agent operating costs by a large multiple, and it matters enough that we wrote it up separately: AI agent costs and model routing.
The build: a daily research agent
The goal: every morning, the agent scans a defined set of sources in your niche, selects what actually matters, and delivers a short brief — each item summarized, linked, and tagged by why it matters. A junior analyst’s first hour of the day, automated.
We’ll build it as a workflow-orchestrated agent in n8n — the architecture applies identically in code if you prefer.
Step 1: Define done, in writing
One sentence: “By 7:30 each morning I have a brief of the 5–8 most relevant items from my sources, each with a two-sentence summary, a link, and a why-it-matters tag.” Every design decision below traces back to this sentence. Agents without a written definition of done drift into doing everything badly.
Step 2: The deterministic shell
Schedule trigger → fetch each source (RSS/API) → merge → drop items already in the seen-list (state, principle 3) → basic filters (date, length, language). No model calls yet; this shell alone is half the agent, and it’s the half that never misbehaves.
Step 3: The judgment core — two model calls
- Relevance ranking (cheap model): for each item, “rate 1–5 how relevant this is to [your written focus], answer with the number and one clause of reasoning.” Keep the top scorers. This is classification — a budget model handles it well.
- Brief writing (strong model, one call): pass the survivors in a single request: “write a two-sentence summary and a why-it-matters tag for each; cite the link; do not add information not present in the source.” One strong call per day costs little; per-item strong calls add up.
Step 4: Guards
Before delivery, code checks: every item has a link that appeared in the inputs (kills invented sources), summaries under length limits, item count within range, output parses. Any guard failure → route to an error path that notifies you instead of delivering something broken. Silent failure is the only unacceptable failure.
Step 5: Deliver, log, and review weekly
Send the brief (email, Telegram, wherever you live), write items to the seen-list, log the run. Then the habit that turns a static build into a good agent: once a week, skim the briefs and adjust — sources that never produce winners get cut, the relevance prompt gets a line of feedback (“less funding news, more technical releases”). Ten minutes weekly compounds into an agent tuned to your judgment.
Where people go wrong with agent frameworks
Frameworks (and there are many) are genuinely useful for complex multi-step reasoning — and genuinely premature for most first builds. The failure pattern: three weeks configuring an agent framework to do what a schedule trigger and two model calls would have done. Build your first agents as explicit workflows where you can see every step; graduate to frameworks when a real need — dynamic tool selection, multi-agent coordination — actually appears. You’ll also then understand what the framework is doing for you, which is the difference between using one and being used by one.
Frequently asked questions
Isn’t this just automation with extra steps?
Mostly, yes — and that’s the compliment. The “agent” part is the judgment core; the automation is what makes it dependable. The industry’s reliability problems largely come from inverting that ratio.
Which model should I use?
Whichever strong model you already have API access to for judgment steps, and a genuinely cheap one for mechanical steps. The routing matters more than the brand — see the cost guide.
How much does an agent like this cost to run?
The daily-brief agent above, routed sensibly, typically runs for cents per day at current API pricing — the strong-model call is once daily and the cheap-model calls are tiny. Verify against current provider pricing; the ratio is the durable fact, not any specific figure.
When do I need multi-agent systems?
Later than the content you’ve been reading suggests. One well-guarded agent per job, coordinated through shared state, covers a remarkable amount of ground. Multi-agent choreography earns its complexity only when single agents demonstrably can’t.
Next: cut agent costs with model routing · five agent use cases for small businesses · or the full AI Agents hub.