One Program That Could Do Everything: Why We Broke It Apart

The cheapest way to build an AI back office is one big program that does everything — read the data, move the money, send the mail, write the drafts. It is also the least defensible thing you can build, because the part that publishes a blog post is the same part that can touch the bank. We took that apart on purpose, and rebuilt it the way we build everything: small, scoped, and made to prove its work.

Here is the architecture, with the client details left at the door.

A router, not a brain

Every request hit a router first. Before any real work happened, a small, fast model read the message and did one narrow job — it named the tools the request actually needed, not the answer. The router looked each tool up in a registry, dispatched to the worker that owned it, and when a request needed more than one, it split the work, ran the pieces, and reassembled them into a single reply. The router carried no keys and did no work. It was a switchboard, not a mind.

One integration per worker

Each capability lived behind its own worker, and each worker owned exactly one integration — banking through Plaid (read-only), payments through Stripe, CRM and messaging through GoHighLevel, publishing through Ghost, mail through Microsoft 365, live web through Perplexity, and structured data and memory in Supabase. The grounding corpus was its own service, so no single worker held the knowledge; they all asked for it. The security win came for free: the worker that published a post had no idea the bank feed existed, and the worker that read transactions had no write scope at all. Least privilege stopped being a policy and became a fact of the wiring.

Keys on a short leash

No secret was ever written into a worker's code. Every credential was pulled at run time from a vault, behind an internal gate that failed closed — if a worker could not prove it was allowed to ask, it got nothing and stopped, rather than falling open and guessing. Third-party access was scoped as tightly as each vendor allowed: financial access read-only, CRM keys scoped per account rather than one master key for everything. The human at the front door was checked with a signed token; the workers checked each other with an internal secret.

Where it ran, and how it checked itself

The whole thing ran at the edge on Cloudflare Workers — each worker its own small deployment, the inference running on Workers AI right next to the code and data, the corpus as vector search at the edge. And every worker that produced something consequential followed one contract: generate, check, and gate. A model drafted the answer, deterministic code ran the checks that needed no model at all, and then a second model — from a different lab entirely — judged whether it held up. Disputed or thin, it went to a human. The author never graded its own work.

Why so many models

There was no single model doing everything, on purpose. Classification ran on a small Llama; planning and long-form on larger Llama and Qwen; generation for the careful domains on Z.ai's GLM; the independent verifier almost always OpenAI's gpt-oss, and where the check was math-heavy, a DeepSeek reasoning model; reconciliation on the frontier models, Claude among them; live web grounding on Perplexity's Sonar. When the writer and the checker come from two different labs, a shared blind spot has to survive two training runs and a deterministic gate in between. One vendor being confidently wrong is no longer enough to ship a mistake — which is exactly the point of building it the expensive way.

The full engineering write-up lives on jessemyers.ai.