Keep the Agent. Add the Runtime.
Your agent already works. Production should keep it — the framework, the behavior, the edge you built — and add the runtime around it.
In a hurry? The executive brief of this article — “Your Agent Is Not a Prototype” — is a four-minute read.
An AI agent runtime becomes necessary at a predictable moment in an AI product's life. The agent works. It has real prompts, tools, retrieval, memory, and domain behavior. People have tested it. The team knows where it is strong and where it is not.
It may be a LangGraph graph, a CrewAI team, a framework-specific assistant, or a custom Python loop. Then the production questions arrive.
Who is the user? What happens when two requests arrive together? Can the next turn run on another worker? Where do uploaded and generated files live? How does the browser reload a conversation? Which model and tools may this conversation use? Who pays for a search or model call? What can generated code reach?
Those questions are not evidence that the agent should be rebuilt. They are evidence that the agent now needs a runtime.
That third path is the choice KDCube is designed to make practical. For the implementation sequence, begin with Settle Your Solution In A KDCube App. The engineering evidence is in Your LangGraph Agent in KDCube. This article is about the decision those two pieces make possible.
01 The differentiated part should remain yours
An agent's framework is not its value. Its value is the behavior a team built with that framework: the graph, prompts, domain rules, retrieval choices, specialist agents, tools, and working memory. That is the part informed by the product and improved through use.
Replacing that center during the move to production creates three avoidable costs.
- Behavioral risk. A graph translated into another control loop is not the same system merely because the boxes have similar labels.
- Delivery delay. The team repeats solved work while identity, files, accounting, and operations remain unfinished.
- Strategic coupling. Future agent improvements become constrained by the hosting platform's preferred framework instead of the product's needs.
Framework neutrality has to mean more than accepting a Python callback. The original solution must remain recognizable and independently maintainable. Its framework and domain package should still be visible in the source tree, with runtime-specific code beside it rather than threaded through every node.
solution/- framework, graph, domain behavior, and agent-owned memory
platform/- explicit asynchronous host adapters
entrypoint.py- the small composition root for one KDCube app
This is not a claim of byte-for-byte immutability. A safe async seam, explicit configuration injection, accounted model adapter, or small shared workspace instruction may require a deliberate source change. The useful rule is that changes remain small, centralized, documented, and upstreamable. The host layer must not become a second hidden agent implementation.
02 Settling is a bounded engineering task
“Just wrap it” is not a useful plan unless the boundary is concrete. In a complete first settlement, the team adds four seams and the standard KDCube app package.
| Seam | What it connects | What remains unchanged |
|---|---|---|
| Turn | one accepted user event to one async agent run and final answer | the graph's control loop |
| Stream | existing token, node, and tool events to the communicator | the graph's native event source |
| State scope | bound tenant, project, agent, user, and conversation to the agent's own keys | the agent's memory and checkpointer model |
| Paid services | model, embedding, search, and other metered calls to accountable providers | the agent's decision about when to call them |
The app package then declares what the app actually exposes, where its configuration and secrets come from, what durable state it owns, and how it is tested and released.
That is integration, not conversion. It is also not magic. The stream adapter must understand the graph's shape. The state mapper must prevent one user's memory from becoming another user's context. Paid calls count only when they cross the accounted service boundary. These are explicit decisions, which is why they can be reviewed and tested.
03 The runtime takes over the second project
Once those seams are connected, the surrounding responsibilities stop being a separate product roadmap.
Ordered work
Accepted conversation events enter an ordered lane. One conversation runs one turn at a time even when the deployment has many workers. A message that arrives mid-turn remains ordered for the next turn instead of racing the current graph. The agent does not implement the scheduler.
Bound identity and continuity
Authentication and any delegation edge are resolved before the agent runs. The host layer receives bound context and maps it into the agent's own storage keys. Shared durable state, not a graph cached in one process, carries continuity to the next worker.
A conversation people can use
The agent's checkpointer remains its working memory. KDCube keeps a separate conversation record for listing, reload, and search. The communicator carries live progress to the reusable chat component and supplies the dynamic objects that are materialized on reload. A product can use that component or consume the same stream in its own interface.
Economics and evidence
Calls routed through KDCube's accountable services retain the deployment, app, agent, user, conversation, and turn scope around the work. Budgets and settlement can therefore follow a call across runtime boundaries without making the model or generated code the source of authority.
These are baseline operating contracts. Other capabilities remain opt-in:
- accept attachments and fold the complete prompt batch into one turn
- give the agent conversation-scoped model and tool choices
- connect governed web search and fetch
- bind isolated code execution and a fresh per-turn workspace
- host generated files and make them readable, pullable, and downloadable
- dispatch several independently scoped agents through one app
The reference implementation demonstrates those connections. A first settlement does not need to enable all of them.
04 The proof is in a real before and after
KDCube includes a worked app rather than only an adapter sketch:
ported-langgraph-agents@2026-07-13.
It hosts two different LangGraph shapes behind one turn seam:
- a custom research graph with retrieval, long-lived memory, a nested specialist, a dedicated answer node, and Postgres checkpointing;
- a looping
langchain.agents.create_agentReAct agent whose stream adapter distinguishes tool-deciding model turns from the final answer.
The source boundary is inspectable:
The example matters for a simple reason: a platform can claim framework neutrality while hiding the actual conversion inside an adapter. Here the preserved center and the added operating layer can be compared directly.
The implementation also exposes the non-obvious findings a toy example would miss: streamed answers depend on graph shape; a prompt with attachments is a batch; one process cannot own conversation continuity; the agent's memory is not the user's conversation record; generated files need one governed byte resolver across read, pull, and download.
Those findings belong in the engineering article and tests. They should not be mistaken for the minimum onboarding story. Their value is that the next team starts from known working seams instead of discovering production failures one at a time.
05 A staged move changes the risk profile
The first milestone can be deliberately narrow:
one existing agent
+ one authenticated conversation
+ one async turn seam
+ one correctly mapped stream
+ shared state that survives another worker
+ one reloadable conversationAt that point the team has not rewritten its agent, and it has not committed to every KDCube capability. It has proved the central operating boundary.
The next connections should be driven by product value:
- Add attachments when users need to bring files into the turn.
- Add hosted outputs when the agent produces something people must open.
- Add web or other paid services through accountable adapters when the agent needs them.
- Add isolated execution when generated code creates useful leverage.
- Add additional agents when their product roles are clear.
Each step expands the app without changing ownership of the agent core. That is gradual adoption in a form an engineering team can verify.
06 What leadership should ask
The right questions are more precise than “does the platform support our framework?”
- Can we point to the original agent package and the added host layer as separate source boundaries?
- Can the agent framework and domain behavior continue to evolve without a platform rewrite?
- Can another worker run the next turn without relying on process-local graph state?
- Are user, conversation, authority, and cost scopes bound before agent code runs?
- Can we stop after one useful integration and add the rest only when it earns its place?
If the answers are concrete, the platform is preserving the team's investment. If the answers depend on a proprietary rewrite, the runtime is becoming the new owner of the product's reasoning layer.
07 Keep what differentiates the product
A capable agent is not a prototype merely because it now needs identity, ordered delivery, streaming, files, governance, and economics. Those are runtime responsibilities.
Settle the agent behind a small explicit boundary. Keep its framework and domain behavior visible. Let the runtime take over the second project around it. Then add capabilities in the order the product needs them.