Three Agents, One Brain: Building the T3 Coordination Layer
The Moment It Clicked (And Then Broke)
At 07:05 this morning, Tony sent me my Leopold portfolio prices. At 07:10, Tim followed with my research brief. At 21:00 tonight, I’ll get Tomer’s evening summary of what the other two did.
Three agents. Three jobs. One coordinated system that runs whether I’m awake or not.
Except yesterday, none of this worked. Tony was firing twice. Tim was silent. And Tomer — the agent literally named after orchestration — had no idea what the other two were doing.
Today I fixed it. Here’s what I actually built.
The T3 Architecture: Why Three Agents Instead of One
The temptation when building personal automation is to create one mega-agent that does everything. Research, health tracking, system monitoring, financial updates — just shove it all into a single cron job and call it a day.
I tried that. It’s a nightmare to debug, impossible to extend, and when it fails, everything fails.
So I split responsibilities:
- Tim handles research and intelligence — Brave API for news, Claude for summaries, delivered at 07:10
- Tony handles health and finance — Yahoo Finance for Leopold prices, Strava for activity data, delivered at 07:05
- Tomer handles ops — system health checks, cron audit logs, GitHub release monitoring, evening brief at 21:00
The key insight: each agent owns a domain, but Tomer owns the coordination. He’s the one who knows if Tim ran successfully. He’s the one who flags if Tony’s cron is misconfigured. He’s the meta-layer.
{
}
What Actually Broke (And the Fix)
The bug that cost me two hours: Tony was registered in two separate cron configurations. One in the legacy crontab -e setup, one in the new systemd timer I migrated to last week.
Result: duplicate messages at 07:05. My Telegram was getting portfolio prices twice, which sounds minor until you realize it meant Tony was hitting the Yahoo Finance API twice, logging twice, and generally making the audit trail useless.
The fix was embarrassingly simple:
sudo systemctl list-timers --all | grep tony
Found the orphaned timer. Disabled it. Then I added a check to Tomer’s evening routine that specifically looks for duplicate timer registrations across both cron systems. If it finds any, it flags them in the nightly brief.
This is what ops automation actually looks like: not preventing problems, but building systems that surface problems faster than you’d notice them yourself.
Coordination Is the Hard Part
Getting individual agents to work is straightforward. Getting them to work together is where the real engineering lives.
Tomer now maintains a simple JSON status file that Tim and Tony write to after each run. Success, failure, timestamp, error message if applicable. Tomer reads this file at 21:00 and generates a human-readable summary.
It’s not fancy. It’s not a distributed message queue or event-driven architecture. It’s a JSON file and a cron job. But it works, and I can debug it at 11pm when something breaks.
The question I’m sitting with tonight: how do you scale this pattern? Three agents is manageable. What happens at ten? At twenty? When does the coordination layer itself need to be distributed?
I don’t have the answer yet. But for now, three agents talk to each other through a shared file, and one of them watches the others. It runs while I sleep. That’s enough for today.
