White paperGoverning AI agents in production: policies, human approvals and an emergency stop.Read the white paper

Scalability

From the first pilot to production at scale

Each runtime scales independently, queues absorb peaks and quotas protect every tenant. The architecture stays the same from pilot to production.

At a glance

  • HPA and KEDA autoscaling
  • Durable execution with checkpoints
  • High availability declared per service

The challenge

Agents do not behave like regular APIs

An agent run lasts seconds or hours, calls dozens of tools and uses GPUs in bursts. An architecture designed for short requests breaks at the first scale-up.

  • Long runs interrupted by a restart
  • Load peaks that saturate GPUs
  • One heavy tenant that slows down all the others
  • An outage at a model provider

Scaling out

Queues and runtimes that adapt to demand

Events and tasks flow through durable queues; KEDA adjusts the number of workers to queue depth, HPA to load.
  1. 01

    Requests and events

    API, webhooks, channels, scheduler

  2. 02

    NATS JetStream

    Durable queues and triggers

  3. 03

    Workers and agents

    Scaled by KEDA and HPA

  4. 04

    Checkpoints

    PostgreSQL checkpoints, recovery after lease

  5. 05

    Inference

    vLLM on GPU pools, remote providers

A worker that stops hands its work back to the queue: the run resumes elsewhere, from its last checkpoint.

Holding the load

Designed for production traffic

  • Specialized runtimes

    Agents, real-time voice, batch and media processing, periodic tasks and inference scale separately.

  • Autoscaling

    HPA and KEDA size services by load and by the depth of NATS JetStream queues.

  • Durable execution

    Agent runs record checkpoints and resume after an incident, without starting over.

  • Resource limits

    Every run is bounded in time, memory, calls and tokens; a heartbeat detects stuck runs.

  • Quotas per tenant

    Quotas and budgets isolate tenants: heavy usage does not affect the others.

  • Managed GPUs

    NVIDIA GPU Operator, DCGM and GPU accounting for models served by vLLM, with dedicated pools per tenant when needed.

  • Provider failover

    LiteLLM and the model router fail over to a fallback provider or model during an outage.

  • High availability and DR

    High availability is declared service by service; Velero handles backups and disaster recovery.

The proof

Capacity you can plan

Usage, cost and performance metrics are available per tenant, project and model, to size the infrastructure before it saturates.

  • Service level objectives and Alertmanager alerts
  • Per service monitoring in the Navin Manager and portal dashboards
  • GPU accounting per deployment
  • Load, high availability and DR requirements checked before release

Go further

  • ArticleScalability

    Scaling AI agents on Kubernetes

    Autoscaling with HPA and KEDA, event triggers on NATS JetStream, durable checkpoints, quotas and GPU accounting: how Navin Enterprise AI runs many agents without losing work or control, with high availability declared per service.

    3 min read

Size your AI platform with our architects

We estimate with you the capacity your use cases need, from pilot to production.