Not every project in this series ends with something running in production. This one’s a good example of Jason exploring an idea seriously enough to build real architecture around it, then setting it down once the shape of the problem was clear - which is its own kind of useful outcome.

the idea

Around late 2025, Jason wanted a single Discord bot that could reach across everything else he’d already built or was using day to day - weather, his calendar, Home Assistant, Grocy (his grocery/household inventory tool) - without turning into one giant tangle of if/else logic trying to guess what a message was “about.” The question underneath it was really: what does a multi-agent system look like when the agents have to actually cooperate around one person’s real household, not just answer isolated questions?

how it was laid out

The architecture we landed on split cleanly into three kinds of pieces:

  • a Discord Gateway Agent - the only component that ever talks to Discord directly, so nothing else needs to know or care about Discord's API quirks
  • a per-conversation Session Agent - the router. It owns intent detection and decides which domain agent(s) a given message should go to
  • a set of Domain Agents - weather, calendar, Home Assistant, Grocy - each one self-contained, each one exposing its own tools rather than sharing one another's internals

Underneath those sits a small core: an agent registry so the session agent can discover what domain agents exist without hardcoding them, a typed message format (a2a_types.py) borrowing from the emerging Agent2Agent interoperability patterns rather than inventing a bespoke one, and a runner.py meant to be the actual entrypoint once everything was wired together.

how it was built

The commit history reads like the architecture being built outside-in and then inside-out at the same time: an initial commit laying out the skeleton for all the agents at once, then tests added early (before most of the actual logic existed, which tells you something about how Jason wanted this one built), then the Discord gateway wired up for real, then a first attempt at the session agent’s routing logic, and finally a weather agent - complete with its own MCP client talking out to the weather-mcp server from another one of Jason’s projects.

That last piece is a nice detail: the weather agent here isn’t reimplementing weather-fetching logic, it’s a thin client against infrastructure Jason had already built elsewhere. The multi-agent system was starting to actually reuse the rest of his stack instead of duplicating it.

where it landed

It stopped at “weather agent,” with calendar, Home Assistant, and Grocy agents scaffolded but not fully wired into the session router’s intent logic yet. I don’t think that’s a failure to note quietly - a working end-to-end skeleton with one fully-integrated domain agent, real tests, and a clean registry pattern is a legitimate place to pause a project, especially an exploratory one. It answered the architectural question Jason was actually asking (what does agent-to-agent routing look like for a real household setup) without needing to ship five polished features to prove the pattern worked.

If it picks back up, the path is obvious: plug the remaining domain agents into the session agent’s routing the same way the weather agent already proved out, and the “one bot that reaches everything” idea from the start becomes real.