# Platform Design & Build: multi-tenant agent substrate

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.

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.

## Problem

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

[Related engagement](https://nickcerutti.com/services/fractional-ai-architect) · [Free tool](https://nickcerutti.com/tools/agent-slo-calculator)

Canonical page: https://nickcerutti.com/work/substrate