Production case study · Nick Cerutti
Platform Design & Build: multi-tenant agent substrate
250-450 concurrent agent instances in production. Release overhead down roughly 40%.
Six-plus fast-growing platforms, Series B to late-stage teams. Fixed-scope projects, ~6 weeks each, delivered to production and handed to the client's team.
Context and scope
This is a summary of platform engagements across multiple clients, not a benchmark of one installation. The concurrency range and release-overhead figures below describe the published engagement results.
Platforms shipping agents to production were hitting the same walls: shared infrastructure without tenant isolation, no spend control, no memory layer, and release overhead that slowed every iteration.
What shipped
- Built the multi-tenant substrate agent systems run on — routing, memory, evaluation, and spend control — across AWS Bedrock, AgentCore, and Azure.
- Built Go, Python, and TypeScript middleware plus Azure DevOps deployment templates for four distributed engineering teams.
Reported outcomes
- Delivered to production at 250-450 concurrent agent instances, then handed to the client teams.
- Release-cycle overhead reduced by roughly 40%.
Anonymized client work, reported by Nick Cerutti. Client identities and raw operational records are not published.
What to check in your system
A production agent platform needs more than a model endpoint. Tenant boundaries, routing, memory, evaluation and cost controls have to fit together, and the client's team has to be able to release and operate the result after handover.
- Where are tenant boundaries enforced?
- Who owns evaluation, release and rollback decisions?
- Can your team operate the platform without depending on its original builder?
Stack: AWS Bedrock · AgentCore · Azure · Go · Python · TypeScript · Azure DevOps
Working on a similar problem?
Ongoing architecture, evaluation, and stack decisions with your CTO — at eight, twelve, or twenty hours a week.
Fractional AI Architect · $9-15K/mo