Three Agents, One Brain: Building the T3 Coordination Layer

The Problem With Building Agents Nobody Tells You About

Three Agents, One Brain: Building the T3 Coordination Layer

Everyone talks about building AI agents. Very few talk about what happens when you have three of them, they all need to run at different times, and one of them silently fails at 3am because a cron job decided to take a vacation.

Today I finally built the coordination layer I’ve been avoiding for weeks. Not because it’s hard conceptually — it’s hard because it forces you to answer uncomfortable questions about what “running automatically” actually means.

My setup has three specialized agents:

  • Tim — Research & Intelligence. Pulls news via Brave, summarizes with Claude, lands in my Telegram at 07:10.
  • Tony — Health & Finance. Grabs Leopold portfolio prices from Yahoo Finance, pulls Strava data, sends at 07:05.
  • Tomer — Ops & Orchestration. That’s the meta-agent. System health, cron audits, GitHub release monitoring. Evening brief at 21:00.

Three agents. Three schedules. Three ways for things to break without anyone noticing.

What Coordination Actually Means at 07:05

Here’s what I learned today: coordination isn’t about making agents talk to each other. It’s about making sure they don’t step on each other, and that when one fails, something notices.

The first bug I fixed was a race condition I didn’t know existed. Tony and Tim both hit external APIs within five minutes of each other. On a slow morning, Tony’s Yahoo Finance call would timeout, retry, and overlap with Tim’s Brave search. Both would partially fail. Neither would report it clearly.

The fix was embarrassingly simple: staggered retry windows and a shared rate-limit state file. Not elegant, but it works. I wrote a small health check that Tomer runs every hour:


if last_success_timestamp > 2 hours ago:
alert("Agent {name} might be dead")

That’s it. That’s the “coordination layer.” It’s a timestamp check and a Telegram ping.

{

}

The Cron That Broke Everything

At 14:30 today, I discovered that Tomer’s evening brief hadn’t run since Thursday. Four days. No alert, no error, nothing. The cron was set to 0 21 * * * but the container timezone was UTC, not Asia/Jerusalem. So it was running at midnight local time — while I was asleep, sending a “daily brief” to nobody.

I spent an hour auditing every cron in the system. Found two more timezone bugs. Added TZ=Asia/Jerusalem to the container environment and wrote a cron audit script that Tomer now runs weekly. It compares expected run times against actual log timestamps.

This is the unsexy work of automation. Not building the agent — maintaining the agent. Making sure it’s actually running when you think it is.

What It Feels Like

Building an automated life sounds glamorous until you’re debugging why your finance agent thinks it’s Tuesday in San Francisco. But there’s something genuinely satisfying about waking up to two Telegram messages already waiting — portfolio summary, news brief — and knowing you built the system that sent them.

The T3 architecture isn’t revolutionary. It’s three scripts, some crons, a health check, and a lot of logging. But it runs. It runs while I sleep, while I’m in meetings, while I’m not thinking about it.

The open question I’m sitting with: when do you trust the system enough to stop checking the logs every morning? I’m not there yet. Maybe that’s the point.

Similar Posts