I Built a Three-Agent System That Actually Runs — Here’s What Coordination Really Looks Like

ByDevin

The T3 Architecture: Three Agents, Three Jobs, One System

I Built a Three-Agent System That Actually Runs — Here’s What Coordination Really Looks Like

Today I shipped something that’s been rattling around in my head for months: a coordinated agent system that actually works. Not a demo. Not a proof of concept. Three agents running on schedules, hitting APIs, and delivering real information to my Telegram at specific times every day.

The lineup:

  • Tim — Research & Intelligence. Brave news search plus Claude summaries. Fires at 07:10 daily.
  • Tony — Health & Finance. Pulls Leopold portfolio prices via Yahoo Finance, integrates Strava data. Fires at 07:05.
  • Tomer — Ops & Orchestration. System health checks, cron audits, GitHub release monitoring. Evening brief at 21:00.

Each agent has a single job. That constraint matters more than any framework choice I made.

What Coordination Actually Means

Here’s the thing nobody tells you about multi-agent systems: the hard part isn’t making agents smart. It’s making them predictable.

I spent three hours today debugging why Tony was sending portfolio updates to the wrong Telegram chat. The root cause? A config file that got copied from Tim’s setup and still had Tim’s chat_id hardcoded. Classic. The fix was trivial — one line — but finding it required tracing through three layers of environment variables and realizing my “unified config” wasn’t unified at all.

Real coordination means:

  • Each agent writes to a shared health log before and after execution
  • Tomer (the ops agent) reads those logs every evening and tells me what ran, what failed, what’s overdue
  • Cron jobs are stored in a single manifest file that Tomer audits against crontab -l output

It’s not fancy. It’s just plumbing that doesn’t lie to me.

What Broke, What Got Fixed

The cron situation was a disaster this morning. I had five scheduled jobs, but only two were actually registered. Turns out I’d been editing the wrong crontab — there’s a difference between crontab -e and editing /etc/cron.d/ files directly, and I was doing both, inconsistently, like an idiot.

Fixed that by writing a reconciliation script that Tomer runs nightly:


crontab -l | grep -E "^[^#]" | sort > /tmp/active_crons.txt
cat /home/devin/agents/cron_manifest.txt | sort > /tmp/expected_crons.txt
diff /tmp/active_crons.txt /tmp/expected_crons.txt

If there’s a diff, I get a Telegram alert. Simple, but it caught two missing jobs today alone.

The other thing that broke: Tim’s Brave API calls were timing out because I was requesting 20 news items when 5 would do. Claude doesn’t need twenty articles to write a morning brief. It needs five good ones. Reduced the payload, reduced the latency from 8 seconds to under 2.

What It Actually Feels Like

Building automation isn’t glamorous. It’s not “set and forget.” It’s more like raising a system that needs constant small corrections until one day you realize it’s been running for two weeks without intervention.

I’m not there yet. But today, for the first time, all three agents ran on schedule. Tony gave me portfolio prices at 07:05. Tim gave me a news digest at 07:10. And tonight, Tomer will tell me everything worked — or exactly what didn’t.

That’s the real goal. Not intelligence. Reliability. An automated life isn’t about removing yourself from the loop. It’s about making the loop legible enough that you can actually trust it.

Open question I’m still sitting with: how do you version control agent behavior when the behavior is partly prompt, partly code, partly cron timing? I don’t have a clean answer yet. If you do, I’d like to hear it.

Similar Posts