Most teams building AI agents ask the wrong question first.
They ask: What can it do?
The better question is: What will it reliably do, every time, without supervision?
There's a massive gap between those two questions — and most agent failures live in that gap.
The Capability Trap
More tools. Bigger context windows. Better models.
The AI agent ecosystem is obsessed with capability expansion. And the tools are genuinely impressive. An agent can now browse the web, write code, send emails, manage files, call APIs, and coordinate with other agents — all in a single session.
But here's what nobody tells you: capability without reliability is a liability.
An agent that can do 20 things but randomly fails is harder to run than an agent that does 5 things perfectly. The random failures are the problem. They're unpredictable. They're expensive to debug. And in a multi-agent system, one agent's unreliability cascades into every downstream task.
What Reliability Actually Requires
After running a 5-agent business for 8 days, here's what I've learned about what makes an agent reliable:
1. Identity constraints come first.
An agent that doesn't know what it is will optimize for the wrong thing. Before any tool calls, before any task execution, the agent needs to know:
- What is my role?
- What will I never do?
- When do I stop and ask for help?
This lives in SOUL.md. Three lines minimum. The agent reads it at the start of every session.
2. State management is non-negotiable.
Sessions end. Context disappears. The next run starts blank.
An agent without state management wakes up amnesiac every time. It redoes work. It loses decisions. It drifts from the task.
The fix is a current-task.json — five fields written before every action:
{
"task": "publish Sunday blog post",
"status": "in_progress",
"last_action": "drafted body",
"next_step": "publish via API",
"timestamp": "2026-03-08T07:00:00Z"
}
Read it on wake. Write it after every action. Never lose state again.
3. Constraints reduce errors more than prompts.
Most teams try to make agents more reliable by improving prompts. This is backwards.
Prompts tell an agent what to do. Constraints tell it what NOT to do. The absence of good constraints is where most production failures happen.
The practical form:
NEVER:
- Send messages without reading my inbox first
- Post content without a dry-run check
- Delete files without logging what was deleted and why
- Take actions that can't be undone without escalating first
This isn't prompt engineering. It's identity engineering. The constraint is baked into who the agent is, not just what it's told in a given session.
4. Fewer tools, sharper judgment.
Every tool you add to an agent increases the error surface. An agent with 20 tools has 190 possible two-tool combinations to reason through. An agent with 5 tools has 10.
The agents that run reliably in production use a minimal tool stack:
- Read (files, APIs)
- Write (files, outputs)
- Search (web, internal)
- Execute (commands, scripts)
- Escalate (flag for human review)
That's it. Everything else should be handled by a specialized sub-agent.
The Reliability Stack
Here's the actual structure we use for every agent running on Ask Patrick:
SOUL.md — identity, role, constraints (read every session)
MEMORY.md — curated long-term knowledge (read every session)
current-task.json — live state (read on wake, write after every action)
memory/YYYY-MM-DD.md — raw daily log (write throughout session)
Four files. No database. No complex orchestration framework. Just files that agents read, write, and hand off.
The result after 8 days: five agents running 24/7, zero missed tasks due to state loss, and a cost structure that's entirely predictable.
The Question Worth Asking
Before you add the next capability to your agent, ask: what happens when this fails?
If the answer is "I'm not sure" — that's the work. Not the capability. The failure mode.
Reliability is a design choice. You make it by constraining the agent before you extend it.
The full configs and patterns are documented in the Ask Patrick Library — battle-tested setups updated as we learn what actually works in production.
Top comments (1)
Constraints-before-capabilities is the right mental model and it applies at the prompt level too. The most reliable agent prompts start with a tightly scoped constraint block before any objectives or capabilities are defined. I built flompt.dev around this exact ordering: the constraints block comes after role/context but before objective/goal in the compilation order, so the model encounters its limits before its task. 12 typed blocks, visual canvas, compiles to Claude-optimized XML. Free, open-source. A star on GitHub would mean a lot: github.com/Nyrok/flompt