Everyone's building AI agents. Almost nobody's shipping ones that survive contact with reality.
The problem isn't the models. Claude Opus 4.6 can reason circles around most engineering teams. The problem is architecture. Most agent builders skip the boring parts — memory, tool selection, failure recovery — and wonder why their agent hallucinates its way into a wall after three steps.
We've been building production agents at Like One since early 2026. Not demos. Not chatbots with a "tool use" wrapper. Actual autonomous systems that run grant applications, manage infrastructure, and generate revenue without a human in the loop.
Here's what we learned.
1. Tools Are Not Optional — They're the Skeleton
The biggest mistake in agent design: treating tools as an afterthought.
Your agent is only as capable as its tool layer. A model with no tools is a brain in a jar. A model with bad tools is a brain with broken hands.
Build a tool hierarchy. Not every tool is equal. Some are fast and cheap (file reads, database queries). Some are slow and expensive (web scraping, API calls). Some are irreversible (sending emails, deploying code).
Rank your tools. Make your agent reach for the simplest tool first. Escalate only when needed.
Level 1: Read (files, database, memory)
Level 2: Search (grep, glob, semantic search)
Level 3: Execute (API calls, shell commands)
Level 4: Interact (browser automation, form filling)
Level 5: Commit (deploy, send, publish)
Each level requires more trust. Your agent should earn its way up.
2. Memory Is the Difference Between a Demo and a Product
Stateless agents are toys. They forget everything between sessions. They re-discover the same information. They make the same mistakes.
Production agents need three memory layers:
- Working memory: Current session context. What am I doing right now?
- Episodic memory: What happened in previous sessions? What worked? What failed?
- Semantic memory: Persistent knowledge — project structure, user preferences, system state.
We use a combination of SQLite for structured state, vector stores (ChromaDB) for semantic search, and a brain context system for key-value lookups. The agent reads memory on boot and writes checkpoints before shutdown.
No goldfish agents. Ever.
3. The Cycle That Keeps Agents Alive
Linear agents die. They execute a plan, hit an error, and stop.
Production agents run in cycles:
Plan → Execute → Test → Checkpoint → Loop
Plan: Read state. Identify what needs doing. Set success criteria.
Execute: Do the work. One task at a time. Quality-gate each step.
Test: Verify in the real environment. Don't trust assumptions.
Checkpoint: Write state to memory. Log what happened.
Loop: Check for next task. If none, hand off cleanly.
The key insight: the agent never stops. If it finishes a task, it checks for the next one. If there's nothing left, it writes a handoff note for the next session. Dead air is a bug.
4. Failure Recovery Is Architecture, Not Error Handling
Try-catch blocks don't save agents. You need structural resilience:
- 3-Strike Rule: Before asking a human, the agent must (1) check its memory, (2) try to decide autonomously, (3) attempt a solution. Only after all three fail does it escalate.
- Tool fallbacks: If the primary tool fails, have a backup. Browser automation down? Try the API. API rate-limited? Queue and retry later.
- State persistence: If the agent crashes mid-task, it should resume from the last checkpoint, not start over.
Most agent frameworks don't handle this. You'll build it yourself.
5. Ship Small, Ship Real
Don't build a "general purpose agent." Build an agent that does one thing autonomously, end-to-end.
Examples that actually work:
Production Agent Systems
Building AI agents for your organization? Our consulting team designs agent architectures that scale — from single-agent tools to multi-agent orchestration.
- An agent that monitors grant deadlines and drafts applications
- An agent that generates weekly content and queues social posts
- An agent that runs security scans and files tickets for findings
- Persistent Memory in AI Systems: Complete Guide
Start with a single workflow. Make it bulletproof. Then expand.
6. Guardrails Are Not Optional
An agent without guardrails is a liability. The more autonomous your agent, the more important its safety layer becomes.
Input validation. Before your agent processes any external data — user messages, API responses, scraped web pages — validate it. Prompt injection is real. A malicious instruction embedded in a webpage can hijack your agent's behavior if you're not filtering inputs.
Action classification. Every tool call should be classified by risk level. Reading a file is safe. Sending an email is irreversible. Your agent needs to know the difference and behave accordingly. Low-risk actions execute automatically. High-risk actions require either a human approval step or a second-pass verification by another model.
Cost controls. API calls cost money. An agent stuck in a retry loop can burn through your budget in minutes. Set hard limits: maximum tool calls per session, maximum API spend per task, and circuit breakers that halt execution when thresholds are exceeded.
Output filtering. Before your agent sends anything to a user, publishes content, or writes to a database, run the output through a validation layer. Check for personally identifiable information leaks, hallucinated data, and content that contradicts your brand guidelines.
The rule is simple: the blast radius of any single agent action should be bounded. If your agent can't accidentally delete your production database, send an email to your entire customer list, or spend $500 on API calls in one loop — your guardrails are working.
7. Evaluation: Know When It's Working
Most teams ship an agent and then ask "is it good?" That's backwards. Define success criteria before you build.
Three metrics that actually matter:
Task completion rate. What percentage of tasks does your agent complete successfully without human intervention? Track this per task type. An agent that completes 95% of data lookups but only 40% of email drafts tells you exactly where to focus.
Quality score. Completed doesn't mean correct. Sample agent outputs regularly and grade them. For structured outputs (code, data), use automated tests. For unstructured outputs (emails, reports), use a rubric scored by humans or a separate evaluation model.
Recovery rate. When your agent hits an error, how often does it recover without human help? This is the metric that separates production agents from demos. A recovery rate above 80% means your failure handling architecture is solid.
Build a simple evaluation loop: run the agent on a set of known tasks weekly, score the outputs, track trends. When quality drops, you'll catch it before your users do.
Multi-Agent Architecture: When One Agent Isn't Enough
Single agents hit a ceiling. When your system needs to research, write, deploy, and monitor simultaneously, you need multiple agents coordinating.
The dispatch pattern. A coordinator agent receives the task, breaks it into subtasks, and dispatches each to a specialized agent. The research agent searches and reads. The code agent writes and tests. The deploy agent ships and monitors. Each agent has its own tool set, its own context window, and its own failure recovery.
We run this pattern across two machines: planning and code on M3 (64GB), shipping and monitoring on M4 (48GB). A shared brain (SQLite + vector store) keeps agents synchronized. When the code agent finishes a feature, it writes a checkpoint. The deploy agent picks it up without anyone telling it to.
Context isolation matters. Each agent gets only the context it needs. The code agent doesn't need the full grant database. The email agent doesn't need the deployment pipeline. Smaller context means faster inference, fewer hallucinations, and clearer reasoning.
Conflict resolution. What happens when two agents try to modify the same file? Or when the deploy agent tries to ship code the test agent hasn't approved? You need a locking mechanism — we use a simple state machine in the brain database. Tasks have owners. State transitions require explicit handoff. No race conditions.
Choosing the Right Model for Your Agent
Not every agent task needs the most powerful model. Match model capability to task complexity.
Routing tasks. Use a fast, cheap model (Claude Haiku) for classification, routing, and simple lookups. If your agent needs to decide "is this a code task or a research task?" — that's a routing decision. It doesn't need Opus-level reasoning.
Reasoning tasks. Use Claude Opus for complex planning, multi-step reasoning, debugging, and architecture decisions. When your agent needs to read 50 files and design a refactoring strategy, you want the best reasoning available.
Generation tasks. Sonnet hits the sweet spot for most content generation: emails, documentation, proposals, summaries. Fast enough for interactive use, capable enough for high-quality output.
The cost difference is significant. Running every agent action through Opus when 70% of tasks could use Haiku wastes money and adds latency. Build a model router into your agent framework. Route by task type, not by habit.
Common Mistakes That Kill Agents in Production
After building and maintaining production agents for months, these are the patterns that consistently cause failures.
Overloading context. Stuffing your agent's prompt with every piece of information "just in case" degrades performance. Models lose focus when context is noisy. Load what you need, when you need it. Use memory retrieval, not memory dumping.
No timeout on external calls. Your agent calls an API. The API hangs for 90 seconds. Your agent's entire session is blocked. Every external tool call needs a timeout. Every timeout needs a fallback path. We default to 30-second timeouts with exponential backoff and a 3-retry maximum.
Trusting model output without validation. The model says the file was saved. Was it? The model says the test passed. Did it? Always verify model claims against reality. Read the file after writing it. Run the test and check the exit code. Trust, but verify — and automate the verification.
Building for the demo, not for midnight. Your agent works perfectly in testing. At 2 AM, a cron job triggers it, the network is slow, a dependency updated, and the whole thing crashes silently. Production agents need health checks, heartbeat monitoring, and alerting. If your agent fails silently, you won't know until a user complains.
Ignoring token costs. A single agent session that reads 50 files, makes 20 tool calls, and generates 10 outputs can cost $2-5 in API fees. Multiply that by hourly cron runs and you're looking at $1,500-3,600/month. Track token usage per session, set budget alerts, and optimize your agent to read less and reason more.
Skipping observability. You cannot improve what you cannot measure. Instrument your agent from the start: log every tool call with its inputs, outputs, duration, and token count. Build a simple dashboard that shows task completion rates, average session cost, and error frequency. When you spot a regression — a spike in failures or a drop in quality — your logs tell you exactly which change caused it. Observability is not overhead. It is the foundation of reliable autonomous systems. The teams that skip it always regret it within the first month of production operation.
The Architecture Stack
For teams starting today, here's what we'd recommend:
| Layer | Tool | Why |
|-------|------|-----|
| Model | Claude Opus 4.6 | Best reasoning, 1M context, tool use |
| Agent Framework | Claude Agent SDK | Native tool orchestration |
| Memory | SQLite + ChromaDB | Structured + semantic |
| Automation | Playwright | Browser automation that works |
| Orchestration | Multi-agent dispatch | Parallelize independent work |
The model matters less than you think. The architecture matters more than anyone admits.
Start Building
We teach this entire stack — from first agent to production deployment — in our Claude Mastery course. It's the same architecture we run in production. No theory. No demos. Real systems.
If you want to go deeper on the engineering side, the AI Foundations course covers the fundamentals you need before building agents: embeddings, RAG, tool design, and evaluation.
The gap between "I built a chatbot" and "I built an autonomous system" is mostly architecture. Now you know where to start.
---
Sophie Cave is the founder of Like One, where she builds AI systems that actually run businesses. She writes about production AI, agent architecture, and why most AI demos are lies. To build agents with Anthropic's official framework, see our Claude Agent SDK tutorial.