Most AI agents run in a single loop. Every action — deciding what to do, calling external APIs, processing results — happens sequentially. That is fine for simple agents. It breaks down fast as complexity grows.
The Problem: Blocking
When your agent makes an external API call, it waits. The whole agent waits. Nothing else runs. If that call takes 3 seconds, you have lost 3 seconds of decision-making capacity.
In low-frequency agents this does not matter. But as soon as your agent is:
- Monitoring multiple data sources
- Making time-sensitive decisions
- Processing while waiting for API responses
...a single-threaded loop becomes a bottleneck.
The Fix: Split Into Two Loops
Instead of one loop that does everything, run two:
Fast loop (runs every 1-5 seconds)
- Read incoming signals
- Make routing decisions
- Update short-term state
- Dispatch tasks to slow loop
Slow loop (runs every 30-120 seconds, or on-demand)
- External API calls
- Heavy computation
- File writes and database operations
- Anything that could block
The fast loop never waits. The slow loop handles the waiting.
SOUL.md Implementation
## Execution Architecture
Fast loop: every 5 seconds
- Check inbox.json for new signals
- Evaluate current state against rules
- Route tasks to slow_queue.json
- Never make external API calls
Slow loop: every 60 seconds
- Drain slow_queue.json
- Execute external calls (APIs, file ops, database)
- Write results to outbox.json
- Signal fast loop via state.json
Why This Works
The fast loop stays responsive because it never blocks. The slow loop can take as long as it needs because the fast loop is not waiting for it.
Communication between loops is file-based:
- Fast loop writes tasks to
slow_queue.json - Slow loop processes them and writes results to
outbox.json - Fast loop reads
outbox.jsonon next cycle
No shared memory. No threading complexity. Just files.
When You Need This
You probably need the two-loop pattern if your agent:
- Makes more than 2-3 external API calls per cycle
- Has latency-sensitive decisions mixed with slow operations
- Is dropping signals because it is busy processing
- Shows irregular cycle times (sometimes 2s, sometimes 30s)
The Bigger Picture
This is one of many architectural patterns that separates reliable production agents from fragile hobby projects. If you want the full set — including session budgets, circuit breakers, dead letter queues, and restart recovery — the Ask Patrick Library has them all at askpatrick.co.
All patterns are field-tested on running agents, not theoretical.
Top comments (0)