Ready to get started?
Deploy sovereign AI on your infrastructure - in weeks, not months.
Developers · Environments · Dev / Test / Prod
Dev, test, and prod - namespace-isolated, with their own quotas, budgets, and credentials. Eval gates block promotion when scores drop.
"We'll add staging later" stops being acceptable when the agent talks to your finance system.
Most teams ship agents to a single environment and call it good. The first incident reveals what's missing: no place to test changes against production-like data, no quality gate before users hit the bug, and no clean way to roll back when something regresses. Building isolation in retrospect is twice the work of having it from day one.
Builders test against prod data because there's no other option. The first time a fine-tuning experiment leaks into a customer conversation, the team scrambles to add isolation. By then the audit trail looks bad.
Quality gates are great in theory but most platforms make them a manual step. Promotion happens via a Slack message and a kubectl command. The eval ran yesterday. The threshold drift goes unnoticed for weeks.
Something regresses in prod. You need to revert. The previous version's config is in someone's git stash, the data ingestion ran on the new schema, and rolling back means coordinating four teams over Zoom. Mean-time-to-recover: hours.
This is what your operators see at /operations/org-environments. Three summary cards for dev/test/prod plus a full table with namespace, resources, LLM budget, status. Click 'Promote' on any agent and see the eval gate decide.
Dev / Test / Prod
Three-tier environment isolation. Each env is its own Kubernetes namespace with scoped data, GPU quota, and LLM budget.
| Environment | Namespace | Resource Profile | Resources | LLM Budget | Status | |
|---|---|---|---|---|---|---|
| DEVacme-dev | katonic-acme-dev | small | 8 CPU, 16Gi, 50Gi | $100/mo | ● ACTIVE | |
| TESTacme-test | katonic-acme-test | medium | 16 CPU, 32Gi, 200Gi | $500/mo | ● ACTIVE | |
| PRODacme-prod | katonic-acme-prod | large | 64 CPU, 128Gi, 2Ti | $5000/mo | ● ACTIVE |
/operations/org-environments renders this in your sandbox today. The promote modal opens from any agent's detail page in Studio when more than one environment exists.Most platforms gesture vaguely at "environments" without specifying which layers actually isolate. Here's the full list, by layer, with how the isolation works and what stays shared on purpose.
Every agent that reaches production walks this path. Steps 1-3 happen in Studio. Steps 4-6 are clicks. Step 7 is one click. Step 8 happens whether you look at it or not.
Builders create agents in dev. Best-effort GPU. Cheaper models. Sample/synthetic data. Iterate fast, fail cheap.
Click 'Promote' on the agent detail page. The promote modal shows source → target, eval gate status, and what gets copied (config) vs what doesn't (data).
Platform pulls the latest eval scores. If they pass the threshold for the target environment, promote proceeds. If not, the modal shows which evaluators failed.
Agent config, system prompt, tool bindings, guardrail profile, knowledge source bindings copy. Raw data, embeddings, and chat history stay in dev. Target runs its own ingestion.
QA runs the agent against production-like data. Test environment uses the same models as prod but with a smaller GPU quota and a $500/mo budget cap.
Same flow, higher threshold. Production environment gets guaranteed GPU, the real model tier, the production budget, and non-preemptible queue priority.
Something regresses? Click 'Rollback' on the agent detail page, pick a previous version. The active version pointer re-points. Hot reload, zero downtime.
Promote, rollback, env create, env delete - all write to the admin actions audit. Single timeline across environments. Full chain of custody from dev change to prod outcome.
How do environments map to Kubernetes?
Each environment is its own namespace under the org's pattern: katonic-{org}-{env}. The namespace gets a ResourceQuota matching the env's resource profile (small/medium/large), a NetworkPolicy that blocks env-to-env traffic, and a KAI Scheduler child queue under the org's parent queue with the env's GPU policy. Atomic delete: kubectl delete namespace removes everything.
Can I promote without an admin?
Dev → test, yes. Test → prod, no - that requires the org admin role. Builders see the Promote button on the agent detail page; the modal shows the eval gate status before the action. If your eval is below threshold, the button is disabled with the failing evaluators visible.
Where does the audit live?
Org-wide audit log with an env field on every entry. A single timeline across environments is what makes incident reconstruction possible. The audit log includes promote events (source env, target env, actor, timestamp), rollback events, env create/delete, and per-env config changes.
Can I cap dev spend separately?
Yes. Each environment gets its own monthly LLM budget in the AI Gateway. Default profiles: dev $100/mo, test $500/mo, prod $5,000+/mo. Budget exhaustion is configurable: block requests, degrade to cheaper tier, or alert-only. Budgets reset monthly and surface in the Operations Hub.
Fast to start. Painful to scale.
Test against prod. Pray. The first incident becomes the case study for why isolation should have been there from the start. Adding it later means migrating live data, changing namespaces, and renaming everything that hardcoded a path.
Three deployments. Three problems.
Set --set env=dev and deploy three copies. Each one is its own platform install with its own state, its own bills, its own upgrades. Promotion means manually exporting + importing. No eval gate, no shared audit.
Three envs. One platform. One promote.
Three first-class environments per org with namespace isolation, scoped data stores, KAI Scheduler queues, and per-env LLM budgets. Promote API copies config. Eval gates enforced. Rollback in one click. Org-wide audit.
Environments are the most important feature most platforms get wrong. Some skip them entirely. Some make them three full installs. Both options force the team to choose between "ship fast and pray" and "do the SRE work yourself." We picked: three environments per org from the first install, isolated by namespace, gated by eval, promotable by API. The team's first agent reaches production through a path that already includes the safety net the second one will need.
Sandbox access in 24 hours. Comes with dev, test, and prod environments preconfigured, a sample agent already promoted to test, and the eval gate threshold set so you can see a promote pass and a promote fail.
Then bring your own agent and run for real.