Digby

Three coordinators and about 35 focused AI agents running around the clock for personal work and markets.

Digby architecture diagram

Context

One person can't be present 24/7 across personal life, a trading book, and every passing idea. I tried. The shape of the problem isn't time - it's continuity. A human who context-switches every few minutes loses the thread. A system of agents, each with a defined scope and persistent memory, doesn't.

So I built one. Not a chatbot. Not a single mega-prompt with a hundred tools strapped to it. An architected multi-agent system, designed the way you'd design a small org - with leads, specialists, escalation paths, shared knowledge, and a router that decides who handles what.

Digby is the result. It's been running 24/7 for months. It costs $5-10 a month to operate. One orchestrator coordinates the markets I trade, another handles research and long-running projects, and Personal Digby handles everything else.

What shipped

Three orchestrators sit at the top. Personal Digby handles finances, expenses, future purchases, travel, and other personal workflows. Trading Digby runs the book across equities, crypto, and Polymarket. The Polymarket leg has its own dedicated stack underneath - see Polymarket for the depth there. A third orchestrator handles research and long-running projects.

Underneath the three, ~35 sub-agents. Each one is scoped narrowly - a single role, a single objective, defined KPIs, a defined escalation path. They don't try to do each other's jobs. The orchestrators route requests by intent and pass messages between sub-agents through an MCP layer that acts as the system's connective tissue.

Each agent has a brain file - a persistent context document defining its voice, scope, what it knows, what it doesn't know, and when to escalate. The brain file is what makes an agent feel like that specific agent across sessions, not just a generic LLM call wearing a name tag.

Underneath that, a RAG knowledge base - the second-brain layer. The agents pull domain context from a wiki I maintain rather than relying on training data alone. The wiki is what makes the agents mine rather than generic.

Trading Digby runs cron jobs every 2-3 minutes - scanning markets, the Fed calendar, who's speaking when, event flow. Each sub-agent under it has hard stop losses, position-size limits, and escalation rules. Nothing autonomous touches money without the rules saying it can.

The interface is WhatsApp, Telegram, and Discord. I don't talk to Digby through a custom UI; I talk to it where messages already happen. The orchestrators sit in their own threads. I address them like I'd address people.

The whole stack - three orchestrators, ~35 sub-agents, the router, the wiki, the cron infrastructure - runs on a single VM.

What landed

I don't lose a minute of work. That's the only metric that matters.

A hardware purchase I mentioned to Personal Digby three weeks ago surfaces again when it's relevant. A market event Trading Digby was watching for fires while I'm asleep, and the right sub-agent acts inside its risk bounds. The research orchestrator keeps longer investigations moving in the background.

The lived experience is talking to ~35 agents through three orchestrators across three messaging apps, and having all of it feel coherent rather than chaotic. That coherence is the architecture working.

What I learned

The first lesson is the hardest one and the one I'd undo if I started over: I built behavior before I built infrastructure. I prioritized output and willpower - get something running, prove the concept, iterate later. It didn't scale. Agents without scaffolding don't compose; they collide.

The fix is unglamorous: build the wiki first. Define the brain files first. Write the agent scopes and escalation paths first. Then let the agents act. Behavior comes from scaffolding, not from prompting harder.

The second lesson surprised me. I expected I'd need to escalate to more dangerous autonomy frameworks to get real value - the kind a friend once described as "like giving a monkey a gun." I didn't. Most of Digby's leverage came from better context routing and narrower agent scopes, not from giving the system more permission to act unsupervised. The wins were architectural, not about autonomy.

Restraint is the feature. Most agent systems fail not because they aren't permissioned enough; they fail because they aren't scoped enough.


Next: a model trained on me. Same architecture, same MCP layer, same agents - but the orchestrators stop being generic LLM calls and start being mine. Lucas-shaped, not assistant-shaped.