From Development to Production

You are the Platform Admin, standing in Production. Production serves your users. Every other environment is a workspace on its own namespace, sized as a share of production.

Half of production, one A100, Active, on its own hostname. Builders will work here. Nothing built in it reaches users until it is promoted.

Name, profile, size and GPUs. The platform provisions the namespace and reports when it is ready. We keep the Development environment that already exists.

Access to an environment is granted to a team, not to individuals. Open Users & Teams.

Click Teams.

Open Katonic-Builders: four members, and right now no environment at all.

Click Access: the platform components this team can use, and at the bottom, the environments it can reach.

Environments are off by default. Turn on Development. Production stays off: builders use what is live there, they do not build in it.

Save the grant. From this moment the team's builders have a Studio in Development.

Development now reads granted, and the platform confirmed it. That is step one of the gate: who may build where is an Admin's decision, and it is in the Audit Log.

You are now the Builder, in Studio, and the window title says where you stand: Katonic Pilot · Development. This Studio belongs to this environment only.

Production already serves one agent; Development has none. Whatever is built here stays here until it is promoted.

Click New agent.

Pick Answer & assist: one agent that answers questions from documents, using tools and knowledge.

Pick Search your docs: answers grounded in a knowledge base, with citations.

Templates prefill tools, knowledge and a prompt. For this walk, pick Blank.

Click Continue to build. Drafts stay private, and ship to a sandbox first; no production route until the gate says so.

We typed Outage assistant; the slug and the API path follow. Change the name if you like, the walkthrough keeps up.

Every agent is owned by a team: Katonic-Builders, the one the Admin granted this environment to. That is how the registry and the Control Room know who answers for it.

Open Behavior: the system prompt and the model tier.

Click Generate from Identity & template. Studio drafts a prompt from the name and the template; the model tier is routed through the AI Gateway, so prompts stay portable as models change.

Open Knowledge.

Attach Outage procedures, a knowledge base indexed in this environment. Each environment keeps its own knowledge; Production has a different library.

Click Publish, and watch where it is allowed to land.

The only target is Development. A builder cannot publish straight to Production; that needs a promotion and someone else's approval.

The team can try it in the Work Room of this environment. Nobody in Production can see it yet.

Click View agent.

Runs, quality, latency and spend will fill in as it is used. The eval suite already shows a pass rate; that score travels with the release request.

Click Promote to production.

The governance policy decides what happens next. Here Production needs approval, so the request goes to the queue and nothing changes in Production yet.

Here is the request: Development to Production, requested by Builder, evaluation 92%. Approve is disabled for the person who asked. Separation of duties is enforced by the platform, not by a policy on paper.

You are the Approver now. The same row, and this time Approve is live. Click it.

The version deploys to Production and the queue is clear. Development keeps its own copy, and the previous Production version is kept for rollback.

Back as the Builder, now in Production. The Work Room composer already addresses Outage assistant, live beside the agents that were here before.

We typed a question an operator would ask. Change it if you like, then go on.

Click Send.

The answer is grounded in the Production library, the counterpart of the knowledge base the Builder attached in Development. Each [n] marker opens the passage it came from, the Sources card names the document and page, and the badge records that the knowledge base was searched.

As the Platform Admin again, in the Audit Log: the Approver approved, the platform deployed, the Builder published and requested. Each line names who and when.

And here is the grant you made as the Admin at the beginning. One trail, from the first decision to the agent in Production. This is what an auditor reads.