Somewhere isolated to run
Workloads are created, run and retired inside isolated per-tenant environments. One customer's run does not see another's database, secrets or memory.
Production
Production ready AI agents
A demo is a model and a loop. Production ready AI agents also have an identity, their own credentials, memory, a policy that can refuse, and a record of what they did.
What production ready AI agents actually require
A demo needs a model and a loop. Production ready AI agents need a place to run that survives a restart, an identity per user, credentials that never cross users, memory that stays affordable, a policy that can refuse, and a record that holds up later. Skip any one of those and the failure shows up as a support ticket, a leaked key, or an action nobody can explain.
Kodeus is that list, already running. You describe the outcome you want operated. Kodeus drafts the application, assembles a model, suggests the tool servers it needs and scaffolds the skills, then runs it. The same spec runs on your laptop, in your VPC, on Kodeus Cloud, or fully airgapped. Nothing about the agent changes when you move it. Only the boundary around it changes.
That is a different job from a framework. A framework helps you compose prompts and tools, then leaves the runtime to you. Production ready AI agents are what you have once the runtime, the identity and the policy are no longer a side project. If you are comparing composition libraries first, start with LangGraph vs CrewAI, then come back to what has to surround either one.
The checks that separate a demo from a product
Treat this as a list you can walk with a security reviewer. Each line is something the runtime does, not a paragraph in a prompt.
An identity on the request
Every request carries an identity derived from a verified credential. The trace answers who, not only what.
Credentials that stay with the user
AES-256-GCM per user, with rotation and revocation. A shared environment variable is how a prototype becomes an incident.
Memory with a boundary
Session and per-user memory, isolated by tenant. You are not designing a schema and a compaction job before the first user.
Policy that can say no
Guardrails evaluate the turn and can monitor, redact, block, escalate or abort. A blocked call never reaches the tool. See AI agent governance for how that is configured.
A record you can query
Tool calls, results, refusals and timing are structured events. AI agent observability is how you debug, audit and improve without reading chat logs.
How a production ready AI agent gets built
You can create the agent in the Console or author it as a kodeus.yaml spec with the SDK. Model, tools, skills, memory, policy and limits live in that file. Policy is declared, not buried in a prompt. The SDK validates the spec, scaffolds skills and launches the runtime locally. The local runtime uses the same policy engine you will have in production, so a surprise later is not a different rule set.
Tools attach over MCP. Choosing them is its own decision: a wide server with a shared key looks convenient and fails the moment a second user arrives. The notes on the best MCP servers are the criteria we use before connecting one. Deployment itself, including VPC and airgapped, is the subject of how to deploy AI agents in production.
The SDK and demo app are in private preview. Early access is the way onto the runtime. Bring one workflow. We will show the tools, the identity model and the approval boundary, and we will say if it does not fit.
What you should not expect
Kodeus does not host an agent you already finished in another framework. If the sentence you want is "we will run your LangGraph app," this is the wrong product. The supported sentence is: describe the outcome, and Kodeus builds it and runs it.
Production ready AI agents are also not a claim that nothing can go wrong. Models still choose badly. The difference is that a bad choice hits a policy, a person, or a trace, instead of a tool with a shared key and no record. Warren runs on this runtime on live markets. The same core is what an enterprise deployment uses inside a perimeter you control.
Bring one workflow
We will walk through the tools, the identity model and the approval boundary.
Frequently asked questions
What makes an AI agent production ready?
A production ready AI agent has an isolated place to run, an identity for each user, credentials that never cross users, memory that stays in scope, policy that can refuse, and a trace of what it did. A working demo has the model and the loop. Production is the rest of that list.
Is Kodeus a place to host an agent I already built?
No. Kodeus drafts the application from what you describe, then runs it. You are not porting a finished agent across. You describe the outcome, and the same spec runs locally, in your cloud, on Kodeus Cloud, or airgapped.
Can I start without a production environment?
Yes. The local runtime uses the same policy engine as production. When you deploy, the agent does not change. Only where it runs changes.
What do I still own?
The outcome, the tools you allow, the approval boundary, and the data. Specs, artifacts, memory and traces are written to a database you run. You own the data and the infrastructure.
How do tools get attached?
Tools attach over MCP. Adding a capability is a connection, not a new integration project. See the guide to choosing MCP servers for what to look for before you connect one.
How do I know it is safe to let it act?
Policy sits in the runtime, not in the prompt. Risky actions can wait for a person. Refusals and approvals land in the trace, so you can show what happened instead of reconstructing it.
Where else is this covered?
This page is the overview. Deployment steps are in the guide on how to deploy AI agents in production. Enterprise controls, including VPC and airgapped runs, are on the enterprise page.
Is the SDK public?
Not yet. The SDK and demo app are in private preview. Early access is how teams start.