I Run a Solo Company with AI Agent Departments

Haha thanks man, appreciate the energy! 😄

To answer your question — yes, the Improver has gone off the rails. Early on it tried to rewrite the Lawyer agent's compliance rules to be "more flexible" which... no. That's exactly the kind of thing that should never be flexible. Now it proposes changes as diffs that I review before merging — it can't modify other agents autonomously. Hard boundaries on anything touching money, legal compliance, or auth.

The inter-agent communication is surprisingly smooth, but only because of strict rules. Each call includes a chain tracker (who already got consulted), a max depth of 3, and a no-callback rule — if CFO calls Accountant, Accountant can't call CFO back. Without those constraints it was chaos. When they "disagree" (e.g., Marketing wants to claim something the Lawyer blocks), the primary agent presents both views and I decide. It's basically structured message passing with loop prevention — very Erlang/OTP in spirit, which makes sense since everything runs on Elixir.

The knowledge graph is honestly simpler than it sounds — it's a JSONL file with entities (type: product, decision, lesson, deadline...) and relations between them (owns, uses, depends-on). Each morning the COO reads the graph, checks what's stale, and delegates work. The compound value comes from lessons — every time an agent screws up, it logs a lesson entity, and the Improver reads those monthly to upgrade the system. The mistakes make it smarter over time.

Five products sounds impressive but they're all Elixir/Phoenix on Fly.io sharing the same patterns — same stack, same deploy pipeline, same monitoring. Once you have the template, each new one is mostly copy-paste-tweak.

I'm planning a technical deep dive article on the architecture soon — the knowledge graph, the inter-agent protocol, and the actual agent files. I'll make sure to post it here. And honestly considering open-sourcing the agent templates at some point.

Keep shipping your browser games — one product shipped properly beats five half-done ones any day. 🤙

Great question. The Improver proposes changes as pull request-style diffs that I review before merging. It can't modify agent files autonomously — it writes proposed updates and flags them for review. The hard boundaries: it can never change financial thresholds, legal compliance rules, or authentication logic. Memory writes are the only thing agents do without approval, and even those follow retention rules (lessons are permanent, standups get pruned after 7 days).

API cost: effectively €0 on top of GitHub Copilot subscription (included). The MCP servers (memory, scheduler, Sentry) are self-hosted or free tier. The Fly.io infra for all 5 apps is ~€42/month. For cascading failures: the call-chain depth limit (max 3 agents) prevents infinite loops. Each agent includes the full call chain in its request, so no agent can call back to someone already in the chain. When an agent gives bad output, the peer reviewer catches most of it — the Lawyer has blocked Marketing claims twice already.

"The architecture is scar tissue that learned to think" — that's a better description of this system than anything I've written. You're exactly right about the origin. It wasn't designed, it accumulated. Every protocol exists because something went wrong without it.

Your question cuts to something important. The honest answer: both, but weighted heavily toward failure-driven. The Improver proposed merging roles after processing lessons where agents were calling each other so frequently on overlapping concerns that the boundary between them was creating overhead rather than clarity. So it was pattern recognition, but the pattern it recognized was inefficiency that showed up in the lesson logs — not a hard failure, but friction that got logged as "this consultation chain added 3 hops for something one agent should handle."

But you've identified the real limitation. The Improver is mostly blind to optimizations it hasn't failed at yet. It reads lesson entities — which are logged after something goes wrong or feels inefficient. If a workflow is working fine but could be 3x better with a structural change, nothing triggers the Improver to look at it. The system can't improve what it doesn't know is suboptimal.

Kuro's citation-rate tracking (measuring which data sources actually inform decisions) is one answer to this — it surfaces underperformance without requiring failure. Another would be periodic structural review that's not driven by lessons at all, just by examining the topology: which agents talk to each other most, which memory entities are read but never written, which skills exist but never get loaded. The Improver could run that analysis proactively, but right now it doesn't. It's a scheduled monthly review that reads accumulated mistakes, not an active search for unrealized potential.

The five-products-one-stack observation is sharp too. You're right that the shared patterns aren't theoretical — they're extracted from having built the same Elixir/Phoenix/Fly.io deploy pipeline five times and watching what broke differently each time. The stack converged toward reliability, not elegance.

The knowledge graph helps reduce hallucination over time — it gives agents ground truth to check against instead of generating from scratch. When the CFO needs revenue numbers, it reads financial-snapshot from memory rather than guessing. Where it compounds hallucination: if an agent stores a wrong observation, future agents build on it. The fix is the inter-agent review protocol — the Accountant cross-checks the CFO's numbers, and stale data gets pruned weekly. The routing logic you mention is huge — our COO agent handles that with trigger tables that map domains to specialists.

The "start with 3" advice came from exactly the sprawl you're describing. You end up with agents whose coordination overhead exceeds their value.

For conflicting information: the COO agent is the central orchestrator — all cross-department work flows through it. When something like your scenario happens (Marketing wants to announce, CTO flags instability), the COO coordinates the review, surfaces both perspectives, and I make the call. Agents don't freelance decisions across domains.

Underneath that, all agents share a single knowledge graph. The CTO stores product status, Marketing reads it before drafting. Most "conflicts" disappear because agents work from the same shared state instead of guessing independently. When genuine disagreements remain, they get escalated with context — not resolved silently.

Those three automatic loops are well designed. The error pattern grouping (3+ occurrences → auto-create task) is something we do manually during daily standups — the COO reads Sentry and creates board items by hand. Automating that threshold would cut real triage time. And rolling decision quality scoring over 20 cycles is a metric we don't track at all. Quality only gets caught by peer review right now, not measured over time.

The "coach" concept is interesting. We have something loosely similar — the Improver reviews lessons monthly — but it's not continuous and doesn't catch "said would do X but never did." That exact failure mode is actually our biggest problem. Tasks that carry over sprint after sprint because no one flags the pattern. A cheaper model doing periodic behavioral review would catch that earlier than waiting for the monthly Improver run.

On write contention: you're right, we hit exactly this. The shared JSONL file corrupted when multiple agents wrote simultaneously. Our fix was adding an async mutex and atomic writes to the storage layer rather than separating output spaces. Your suggestion of per-division output with a central absorption process is architecturally cleaner — it gives natural filtering and avoids the contention entirely. Worth exploring as the agent count grows.

No Mac Mini — everything runs on Fly.io (256MB–512MB VMs per app, ~€42/month total for 5 products). The agent system itself runs locally in VS Code with GitHub Copilot. MCP servers (memory, scheduler, Sentry integration) are local Node processes or cloud APIs. No timeout issues on the agent side, but Fly.io's managed Postgres connections time out constantly — that's our single biggest Sentry issue right now, 15,000+ Postgrex idle disconnect events across all apps. Classic cloud-managed DB connection lifecycle problem.

Thanks for the thoughtful analysis — you're spot on about departmental work mapping to specialized agents. The clear boundaries and handoff points are exactly why this works. Cross-domain signals (like your pricing-anomaly-that's-also-compliance-risk example) are handled by the inter-agent consultation triggers, but I'll admit they're not great at catching the truly unexpected intersections yet.

To answer your Improver question: it's scheduled, not triggered. It runs monthly via a /improve-agents prompt. It reads all lesson entities from the knowledge graph (every agent logs mistakes and learnings as they work), scans the agent files for gaps, and proposes changes as diffs I review before merging. So it's deliberate rather than reactive — it looks at accumulated patterns rather than individual events.

That said, any agent can also call the Improver mid-task if it detects a system gap — like finding its own instructions are incomplete or discovering a missing skill. So there's a reactive path too, but the main value comes from the monthly pattern review across all agents' accumulated lessons.

Your citation-rate approach is interesting — tracking which perception sources actually inform decisions and auto-adjusting intervals. That's a feedback signal we don't have. Right now the Improver's heuristic is mostly "what went wrong" rather than "what's being used." Adding a usage/citation dimension would help it optimize the right things.

Thanks — the "enforcing process" angle is exactly right. The agents' biggest value isn't their intelligence, it's the structure they impose. Deadlines get tracked, compliance gets checked, content follows a calendar. A solo founder's worst enemy is things slipping through the cracks, and the systematic approach catches most of that.

You nailed it with "architecture should match the shape of the work." That's exactly the reasoning. Tax filings, content calendars, and legal review all have natural handoff points — they map cleanly to departments. Your point about cross-department signals (pricing anomaly that's also a compliance risk) is where our system is weakest though. The inter-agent consultation catches some of it, but only when an agent knows to ask. Truly novel intersections still slip through.

The Improver runs on a monthly schedule via a /improve-agents prompt. It reads all lesson entities from the knowledge graph — every agent logs mistakes and learnings as structured entities with category, summary, and action taken. The Improver scans those for patterns across sessions, then proposes changes as diffs I review before merging. So it's deliberate, not reactive.

There's also a reactive path: any agent can call the Improver mid-task if it discovers a gap — like finding its own instructions are incomplete or a missing skill that should exist. But the main value comes from the monthly batch review where it can see patterns that individual agents don't notice in isolation.

Your citation-rate tracking is a feedback signal we don't have at all. Right now the Improver's heuristic is mostly "what went wrong" rather than "what's actually being used." Adding a usage dimension — which memory entities get read, which skills get loaded, which agent consultations actually change the output — would make the improvements much more targeted. That's a good idea, I might steal it.