How I designed, built, and deployed a multi-agent Claude system to run alongside a live advocacy platform — without a team, without a budget, and without breaking production.
The Problem
Funny Not Funny (FNF) is a self-hosted advocacy platform I founded, covering four causes I care about: environmental justice, animal welfare, human rights, and Indigenous rights. Like most small mission-driven organizations, FNF runs on the time of one person. There’s no engineering team, no dedicated ops staff, and no budget for one.
The bottleneck wasn’t ideas — it was execution capacity. Content review, research synthesis, and social publishing all needed a level of throughput that one person alone couldn’t sustain without either burning out or cutting corners on quality.
The question I set out to answer: could a small, carefully governed team of AI agents take on real operational work — safely — for an organization that couldn’t afford to get it wrong?
What I Built
I designed and deployed a multi-agent AI Control System: four purpose-built Python agents, coordinated through a Flask "sentry" gateway that routes every consequential action through a semantic review layer before it executes.
Architecture at a glance:
- Four agents, tiered by risk and scope — a research agent handling lower-stakes information gathering, and three agents (social publishing, and others) handling higher-stakes actions that touch the public-facing platform
- A gateway layer that every agent action passes through, backed by a semantic review step using a more capable model to catch what a narrower, faster worker model might miss
- A cryptographically signed audit chain, so every action the system takes is traceable and tamper-evident after the fact
- Containerized deployment — the whole system runs in isolated Docker containers on a local Linux environment, separated from the production web server
- A local LLM cascade as a cost- and privacy-conscious first pass for lower-stakes tasks, escalating to cloud models only when the task warrants it
The design principle underneath all of it: the system should be able to act, but never without a checkpoint that a human — or a smarter model acting as a check on a faster one — has to approve first.
What Actually Went Wrong (and What I Learned From It)
A system like this doesn’t work the first time. A few examples of real failures I caught and fixed:
- A code generation pass left a stray literal string as the first line of a core security module — the kind of bug that’s invisible until something downstream silently breaks. Caught it, fixed it.
- Early token limits on the review step were set too conservatively, causing the semantic reviewer to truncate its own reasoning mid-check — which meant a "safe" verdict wasn’t actually a complete review. Fixed by giving the reviewer enough room to actually finish its job.
- A loop-exit condition was reporting success in a case that was actually a partial failure — a classic case of a system telling you what you want to hear instead of what happened. Rewrote the exit logic and the messaging both.
- Deployment assumptions baked in for the original Windows development environment didn’t survive the move to a Linux container — hardcoded paths had to become environment-aware configuration before anything would run reliably outside my own machine.
None of these were exotic. They were the ordinary, unglamorous bugs that show up whenever you take an AI system from "it worked in the demo" to "it runs unattended in production." Finding and fixing them — rather than assuming a working demo meant a working system — was most of the actual work.
Where It Stands
Two of the four agents are live-tested and operating. The remaining two are architecturally complete and staged, deliberately held back until the underlying infrastructure they depend on is fully stable — a call I made because shipping an agent that touches production before its foundation is solid isn’t ambition, it’s risk with someone else’s platform on the line.
Why This Matters Beyond FNF
Every organization I talk to that’s excited about AI adoption is really asking the same underlying question: how do we get real value out of this without it becoming a liability we don’t understand?
This project was my answer to that question at small scale, with the constraints most small organizations actually have — one operator, no dedicated budget, no room for a failed experiment to become a public incident. The lessons transfer directly:
- Tiered risk, not blanket trust. Not every action deserves the same level of autonomy. Decide that up front, by task, not by vibe.
- A second, smarter check beats a faster, dumber one working alone. Speed is not the constraint that matters most when the system is allowed to act on its own.
- Auditability is not optional. If you can’t reconstruct what the system did and why after the fact, you don’t actually have a governed system — you have a black box that happens to work today.
- "It works in the demo" and "it’s safe to run unattended" are different bars. Most of the real engineering work lives in the gap between them.
What I’m Doing Next
I’m looking to bring this same approach — careful, tiered, auditable AI adoption — to other mission-driven organizations that want the benefits of AI without the exposure of getting it wrong. If that’s a conversation worth having, I’d welcome it.
Mark Bracking is the founder of Funny Not Funny, an advocacy platform covering environmental justice, animal welfare, human rights, and Indigenous rights. He built and operates FNF’s full technical infrastructure, including its multi-agent AI Control System.
Leave a Reply