Since January I've been leading ORCA — ORchestrated Co-Lab Agents — the platform behind the line on my landing page about one request setting a team of AI agents to work. The official two-part write-up is now live: part one covers why we built one platform for many agents, and part two goes under the hood. This is the short, personal version: why we stopped building apps and built an orchestrator instead.
A good tool that started feeling too fixed
The story starts with Sensemaker, the text-analysis engine on my work page. It grew past 4,000 officers and 60 million documents analysed — a genuine success — and that success is exactly what exposed the limit. The tool did one thing well, but real work keeps shifting at the edges: data needs cleaning before it's worth analysing, results need merging and reshaping into whatever a director wants to see, and every answer breeds a follow-up question the tool was never designed for.
Each new need forced a bad choice: bolt another feature onto a tool that wasn't meant for it, or ship yet another single-purpose app. We kept choosing the second, and everyone paid. Users paid in what a Harvard Business Review study calls the toggling tax — another name to remember, another URL, another login. Engineers paid in time: prototyping a capability takes a weekend; turning it into a reliable tool people use every day takes months.
One front door, not one giant brain
The tempting fix was a monolith — absorb everything into one big backend. We went the other way: hub-and-spoke. ORCA owns only the shared plumbing — chat, sessions, routing, guardrails, file handling, response streaming — and every capability stays with the team that built it. When a request comes in, a leader agent reads it and hands it to the right member agent, which might call a service over a plain REST API or run code in a sandbox. MCP and agent-to-agent protocols are wired in for teams that already expose tools or full agents of their own.
Sensemaker was the proof. Its engine now runs as an agent inside the chat — same capability, no separate tab, no separate login — and the team didn't rewrite a line of core functionality. That's the deal the platform offers every team: connect an API, and your capability gets a front door for free. Every message also passes through a central guardrail service before any agent sees it, screening for things like harmful content and prompt injection.
When chat turns into routine
Chat is great for shaping work and terrible for repeating it. So the piece I find most interesting is the workflow builder: describe a routine in a sentence, and ORCA generates a structured definition — the inputs it needs, the ordered phases, which agent or tool runs each step — then validates the whole thing before it can be saved. Do the referenced inputs exist? Does every step call a real agent? Only then does it become a reusable tool.
The sweet spot is work that's too repetitive to keep doing by hand but too small or too team-specific to justify a months-long build. Think Zapier or n8n, except the building blocks are agents and the interface is a sentence.
Six months in
I'll be honest about where it stands. MCP and agent-to-agent are wired up but not yet carrying live production traffic. The workflow builder sometimes nails a routine on the first attempt and sometimes needs a human to adjust the steps. It's a platform mid-flight.
But it's already useful, and the useful part isn't a benchmark. It's an officer who didn't spend an afternoon hunting for the right intranet link. It's an engineer who didn't build another login screen around a capability that already existed. Earlier in my career the hard part was training the model; here the models were the easy part. The hard part — and the fun part — is the plumbing that lets a dozen teams' work behave like one product. Sensemaker's real lesson was never "build a better frontend." It was that people need software that changes shape as the work does. So we built the thing that changes shape.