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

Article · Scalability

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.

Published on 3 min read

An agent workload does not look like a classic web API: a run can take a while, wait for an approval, call several tools and start sub-agents in parallel. Navin Enterprise AI therefore keeps its runtimes separate so that each one scales at its own pace: agents, real-time voice, batch and media workers, periodic tasks and inference. No runtime holds governance data.

Autoscaling on load and on events

Workloads scale with the Kubernetes Horizontal Pod Autoscaler and with KEDA, which triggers scaling from events. Event triggers (brick C10) run on NATS JetStream, and the message bus between channels and the engine works in memory or on NATS. Multimodal batch and media workers also pick up their jobs from NATS.

Durable execution: no lost work

Every step of a run writes a checkpoint to PostgreSQL and a heartbeat. If a process goes down, the AgentLoop resumes the run from its last checkpoint, and the server worker (python -m eai.worker) spots stale heartbeats, ticks the scheduler, flushes the event outbox and expires quota reservations. The SubagentManager runs sub-agents in parallel and feeds their results back into the parent turn.

Quotas and GPU accounting

Scaling out must not mean spending without limits. Before every model call, the cost is estimated and a quota reservation is taken; after the call, token accounting turns the Usage Event into a measured cost and settles the quota. Resource limits apply to executions, local GPUs are managed by the NVIDIA GPU Operator and GPU time is accounted with the DCGM exporter.

High availability declared per service

In the Navin Manager, every service descriptor of the catalog must declare a high availability block, with its prerequisites and replicas. Installation checks refuse an HA deployment whose requirements are not met, and the dashboard of each service shows its HA status.

  • HPA and KEDA for autoscaling (brick H05).
  • NATS JetStream for event triggers (brick C10).
  • PostgreSQL checkpoints and heartbeats for durable execution (bricks C02, C06 and C08).
  • Quota service and GPU accounting (bricks H01 and H04).
  • DatasheetAgents

    Isolated MCP runtimes per user and project

    The MCP registry and gateway decide who may use which server; the MCP runtime creates isolated instances on demand on the ToolHive Kubernetes Operator and destroys them after use. Every tool call still goes through policy, DLP and approval.

    2 min read
  • DatasheetSecurity

    Mandatory file scanning with ClamAV and YARA-X

    Every file sent to the AI is quarantined, scanned by ClamAV and YARA-X and then validated before Docling, OCR or RAG can read it. Fully local, fail closed, logged and highly available.

    2 min read
  • White paperGovernance

    Governing AI agents in production

    How Navin Enterprise AI keeps autonomous agents under control: OPA policies stacked from platform to tenant to project, approvals with a human in the loop, a kill switch available at any time and a governance registry as the single source of truth.

    25 min read

See these principles applied to your use cases

An architect presents the platform against your own constraints.