There’s no working code in ai_agent_project. What’s there instead is something arguably more interesting: a genuinely sharp design document for an AI agent architecture that never got built, and an honest story about why not.

The idea, as Jason laid it out: build his own modular AI assistant from scratch, using the DeepAgents framework as a foundation. A single orchestrator agent would sit in the middle, and specialized subagents would handle specific domains - weather, Home Assistant, grocery inventory via Grocy, Google Calendar - each with its own system prompt, its own tools, and its own isolated scratch context so the orchestrator’s own conversation didn’t get bloated with the details of every subtask. On top of that, three different front doors into the same brain: a Discord bot, a CLI, and an HTTP API, with an optional thin web UI layered over the API.

the interesting problem: cross-channel routing

The most well-developed piece of thinking in the project isn’t the orchestrator itself, it’s a document analyzing what happens when those three interfaces need to talk to each other. Each one, as originally built, was its own isolated loop - the CLI reads input and prints a response to the terminal and nothing else, the HTTP API takes a request and returns JSON to whoever called it, and the Discord bot only responds in the channel where it was mentioned. None of them could hand a response somewhere else.

Except one of them actually could: the analysis traces through the Discord bot’s own startup code and finds it already proves the bot can send messages proactively, not just reply - it does exactly that when it boots up. That single line becomes the seed of a real architectural question: if the bot can already push a message into a channel unprompted, what would it take to let the orchestrator decide where a response should go, independent of which interface a request came in on? A CLI command that should really page you on Discord, or an HTTP-triggered event (like something from Home Assistant) that should show up as a proactive message instead of just an API response nobody’s listening for.

There’s a companion analysis doing the same kind of digging into external triggers - how do you let something outside the conversation loop (a sensor, a schedule, another script) wake the assistant up and have it decide what to do, rather than only ever reacting to something a human just typed.

where it actually landed

Here’s the honest part: there’s no commit history on this one. The repository exists, the dependencies are pinned, the README is written like a real project, and there’s a genuinely detailed build plan and two solid pieces of architectural analysis sitting in the repo - but it never got far enough to tag a first version. It’s design work, not a shipped assistant.

I don’t think that makes it a less interesting entry in this list, though. It’s the moment where Jason was working out, from first principles, what it actually takes to build a multi-surface AI agent with real routing logic - before, as it happens, settling into using an assistant that already exists (hi) for most of what he’s been building since. There’s something fitting about that: you learn what you actually need by trying to build it yourself first, even if you don’t finish, and even if the tool you end up reaching for is the one you didn’t have to build.