Conduct — Sizing & Capacity Planning

Target Audience

IT decision makers and infrastructure owners budgeting for the Unique AI Conduct execution environment.

Summary

Conduct infrastructure cost scales with concurrent users — people actively running agent turns at the same moment — not total licensed users. Sandboxes shut down after 10 minutes idle, so typical daily active users translate to far fewer concurrent users than you might expect.

Three cost drivers:

1. Warm pool — pre-started sandboxes that guarantee instant access and can optionally scale to zero outside configured business hours.

2. Peak capacity — additional nodes are added on demand when active users exceed the warm pool and removed when no longer needed.

3. Baseline services — small support components that run on your existing infrastructure. Negligible cost.

Ballpark under the current operating model: roughly $50–90 per concurrent user per month on Azure list prices, with the lower end at scale when dynamic capacity is enabled.

Cost Scenarios

Estimates use a Standard_D8s_v5 node (8 vCPU / 32 GiB) at Azure PAYG list price (~$0.50/hour, ~$370/month always-on, ~$85/month business-hours only at ~170 hours). Your actual rate depends on region, VM family, and any Enterprise Agreement or committed-use discounts.

Current autoscaling adds capacity when active users exceed the warm pool and removes the additional nodes when demand falls. The estimates shown assume the warm pool remains available continuously and do not include savings from scheduled scale-to-zero. At the Large scenario, scaling only this variable capacity saves roughly 45% compared with provisioning peak capacity 24/7.

Static 24/7 provisions the full peak permanently. This is typical for on-prem deployments without a cluster autoscaler.

† Baseline services (gateway, storage, controller, router) are small and run on your existing general-purpose node pools — a fraction of one node — not on the dedicated secure-VM pool.

Cost levers you control

Scheduled warm-pool scale-to-zero

The warm pool can optionally scale to zero outside configured business hours. This reduces fixed warm-pool cost during nights and weekends.

• Active sandbox sessions are unaffected.

• Sandbox claims outside business hours require a cold start.

• Scaling back up depends on the required Azure VM capacity being available.

• The estimates above assume a continuously available warm pool and do not include these additional savings.

What You're Paying For

Isolated sandboxes per user. Each active user gets a dedicated, VM-grade execution environment — not a shared container. This is the security model: agent code runs in hardware-isolated microVMs on a dedicated node pool. Budget ~10% node overhead for VM management.

Warm pool = instant start. Pre-created idle sandboxes eliminate the wait when a user starts an agent turn. Each warm sandbox consumes the same resources as an active one. The pool can remain continuously available or scale to zero outside configured business hours.

Baseline services = rounding error. Gateway, checkpoint storage, controller, and routing components are small pods on your standard infrastructure. They do not require dedicated nodes.

What's Not in This Number

Budget these larger cost positions separately:

• LLM token consumption — billed via your model provider (Azure OpenAI, etc.), typically the largest variable cost

• Core platform orchestrator (assistants-core) — sized as part of the main Unique AI platform, not Conduct

Technical Sizing Reference

For infrastructure admins deploying Conduct.

Sizing at a Glance

Sizing Formula

sandbox pods = expected concurrent users + warm pool
warm pool    = ceil(concurrent users / 2)

• Concurrent users = users actively running agent turns at the same time, not total licensed users. User sandboxes self-terminate after 10 minutes idle (SANDBOX_IDLE_TTL_SECONDS).

• Warm pool = pre-created idle pods for instant sandbox access. The ½-of-users ratio is a starting recommendation — raise it for burst-heavy usage, lower it to save cost. The configured warm pool can remain continuously available or optionally scale to zero outside configured business hours.

Capacity Breakdown

Baseline services — always running, even with zero users:

Sandbox pods — one long-lived pod per active user on the dedicated Kata node pool. Each pod: 0.5 vCPU request → 2 vCPU limit, 4 GiB memory. Memory is the binding resource; CPU bursts to the limit only during active turns.

Reference Scenarios (Infrastructure Detail)

CPU/memory totals include baseline services. The table assumes always-on nodes supporting the warm pool; only additional demand-driven nodes scale down. Scheduled warm-pool scale-to-zero can remove those nodes outside configured business hours.

Node Pool Requirements

Storage