--- title: "voxcog: AI agents that hold up in production" description: "How voxcog’s agent runtime was rebuilt around one agent with 55 tools, three model tiers and an evaluation that runs in CI. Delivered August 2026." url: https://torn.studio/en/work/voxcog-ai-agents-in-production locale: en published: 2026-08-31 updated: 2026-08-26 --- # voxcog: AI agents that hold up in production > **Short answer:** Torn Studio built voxcog’s agent runtime: 55 tools behind one agent that fetches them on demand, three model tiers so every call goes to the cheapest one that can do the job, and an evaluation gate that runs in CI on every change. The platform was handed over in August 2026. **Client:** voxcog · **Delivered:** 2026-08-26 **The studio’s relationship to the client:** voxcog is a product Torn Studio built and holds a stake in. The studio ran product management, architecture and the build through to handover in August 2026. ## The brief voxcog needed an agent that could reach the whole product in one conversation — documents, signals, tasks, calendar, research and finished product artifacts — and that could run in production for several tenants at once. ## What made it hard - An earlier build put around forty tools and a long system prompt into every call, which hit the Anthropic ceiling of 50,000 input tokens per minute and locked chat for every tenant at the same time. - The runtime sits on a serverless platform with a 270-second wall clock for the whole turn, so every agent run has to finish inside that budget. - Answers have to be trustworthy after the fact, which means quality is measured continuously and that measurement runs in CI against recorded runs. ## Figures a reader can count | Figures a reader can count | | | | --- | --- | --- | | 55 | tools behind one agent | Registered in one module and countable there. The agent carries a small fixed set in its prompt and fetches the rest when a conversation calls for it. | | 3 | model tiers | Haiku 4.5, Sonnet 4.6 and Opus 4.6, declared in a twelve-line file. Moving a whole lane between tiers is a one-line change. | | 50,000 | tokens per minute, the ceiling | The limit the previous topology kept hitting. The new one carries the same catalogue under the same ceiling by keeping the prompt small. | | 20 | steps at most per run | The cap on the deepest research mode. The comment in the code says it may not be raised until the wall clock is measured again, which makes the cap a decision with a review rule attached. | ## How it was done ### One agent, tools fetched on demand Five specialist agents were replaced by a single conductor carrying a small fixed tool set. It reaches the rest of the catalogue through a search that loads a tool the moment it is needed, which keeps every prompt small as the catalogue grows. ### Three model tiers with clear boundaries Haiku 4.5 triages and answers the simple things, Sonnet 4.6 does the reasoning and writes the artifacts, Opus 4.6 is held in reserve for the heaviest work. Every call goes to the cheapest tier that can do the job, and a 429 is retried according to the server’s own retry-after header. ### Budgets that live in code Every research mandate carries a step cap set by depth — four, six or twenty — sized from a tool call taking around five seconds. The cap sits in one function with its own tests, and the comment above it says twenty may not be raised until the wall clock has been re-benchmarked. ### An evaluation that runs every time A recorded run is stored as an artifact and replayed offline, which gives CI a deterministic gate that needs neither keys nor a database. A nightly judged run and sampled online scoring for relevance, hallucination and tone sit on top of it. **Stack:** Next.js 16, Mastra, Claude Haiku 4.5, Claude Sonnet 4.6, Supabase, Postgres, pgvector, Vitest ## The limits of this proof This shows that an agent platform can be built so it holds up under load and can be measured. It shows nothing about what voxcog is worth in a market: the platform was handed over before launch and had no paying users at handover. ## Common questions ### Why does one agent carry the whole tool catalogue? Five agents meant a piece of reasoning was compressed into prose every time work was handed on, and that compression cost more in quality than the specialisation gave back. One conductor with fetchable tools keeps the whole context in one place. ### How do you stop an agent run from running away? Every mode carries a step cap in code, set from how long a tool call actually takes. The final step forces an answer by switching tool choice off, so a run ends with a reply even when the budget is spent. ### How do you know answer quality holds over time? A recorded run is stored as an artifact and replayed in CI, which gives a gate that is deterministic and runs on recorded material. A nightly judged run and sampled scoring for relevance and hallucination sit above it. ### What does a platform like this cost to run? Cost is driven by which model answers each call, which is why the routing lives in code: simple triage runs on the cheapest model and only the heavy reasoning reaches the expensive one. Moving a whole lane between tiers is a one-line change. ### Can the same design be used on our internal systems? Yes, the pattern is independent of the product. One conductor, a tool catalogue fetched on demand, budgets in code and an evaluation in CI are the same four parts whether the tools read your database or your ticketing system. ### How long did the agent runtime take? The rebuild was planned in April 2026 and the evaluation gate in May, and both were in production before handover in August. The work ran alongside the rest of the platform and was done by one person.