The shape of agent infrastructure we wish existed.
Notes on orchestration, evals, and what we are opening up.
We started building agent infrastructure because nothing else did what we needed. This is a working note on what we built and why.
The four things every production agent system needs
Every time we shipped a new product, the same four needs showed up:
- Orchestration. Something has to run long-lived agents in the background, on cron, across retries, with visibility.
- Routing. Model providers go down. Pricing shifts overnight. The agent can't know or care which underlying model executes its instruction.
- Evals. If you can't grade an agent's output, you can't ship the next version with confidence.
- Memory. Long-context isn't enough. Agents need state that survives a session, scoped per entity, retrieved on demand.
Every "agents framework" we tried solved one or two of these and punted on the rest. So we built the four together, with the same primitives underneath, and reused the result across the products we build.
What we kept proprietary, and what we are opening
The agent runtime (the orchestration, routing, eval, and memory layer) is being opened up. Q3 2026.
The product-specific logic (the Otto HR ontology, the Adsial brand-testing rubrics) stays inside each company. The infrastructure underneath is general.
What we are not building
We are not building a no-code agent builder. We are not building a chat UI framework. We are not building yet another LangChain.
What we're building is the boring substrate that lets a small team ship many agent products without rebuilding the same five systems each time.
That's the thing we needed. We're opening it because we suspect we aren't the only ones.