AI Agent Infrastructure: The Runtime Around Your Framework

---

In a hurry? The executive brief of this article — “The Second Project” — is a four-minute read.

AI agent infrastructure is everything a product needs around the agent loop: identity, concurrent requests, files, credentials, streaming clients, background events, paid calls, and generated code. Agent frameworks answer how the agent should reason. The infrastructure question begins where that answer ends.

Agent frameworks are useful. They help a team describe a graph, coordinate specialists, call tools, preserve agent state, or build a reasoning loop. A custom loop can be useful for exactly the same reason: it captures how your agent should work.

KDCube starts at the next boundary. Once users, concurrent requests, files, credentials, streaming clients, background events, paid calls, and generated code surround that loop, the product needs a runtime that can operate them together.

Your framework stays. Bring LangGraph, CrewAI, the Claude Agent SDK, another library, or your own Python. Keep your existing UI and business services. Start with one useful boundary, then adopt more where it removes routine infrastructure from your product roadmap.

01 Start with what you already have

A KDCube integration can be thin.

• An existing agent can become the implementation behind one app operation.
• A backend can remain behind REST or a webhook.
• A product can keep its own UI and consume a KDCube conversation stream.
• An external agent can enter through a grant-protected MCP or REST surface.
• A team that wants less frontend work can use the ready multi-user chat widget.
• One expensive or risky tool can move into isolated execution while everything else stays where it is.

These are independent starting points. Chat, ReAct, Scene, Canvas, MCP, APIs, jobs, and integrations can each be adopted on their own. An app can be backend-only or expose one API. It can also host several agents and several UI surfaces, with UI remaining optional. A deployment can run one focused app or a fleet of independently configured apps.

your product today
  |
  +-- existing website --------> keep it; use APIs or conversation streams
  +-- existing agent ----------> host it behind an app surface
  +-- existing tools ----------> register them as governed callable tools
  +-- existing integrations ---> resolve credentials through the runtime
  +-- existing storage --------> keep it, or adopt app storage selectively
  |
  `-- choose the first boundary that saves work now

That first boundary can remain the only one. Composability supports gradual adoption.

02 Framework, runtime, and platform

The word framework is familiar because it describes what builders develop against: programming models, SDKs, contracts, configuration, reusable components, and extension points.

The runtime is the active machinery. It executes and enforces those contracts under concurrency, failure, security, and cost constraints. It authenticates an operator, schedules work, delivers ordered events, isolates generated code, accounts for paid calls, stores state, and reports failures.

The platform is the continuity between the two, plus the shared services that make independently authored apps work together.

KDCube was built runtime-first: production responsibilities came first, and a framework emerged as those responsibilities were generalized into reusable app contracts. Builders develop against the framework. Their apps operate on the runtime. KDCube provides both.

03 What the runtime takes off the product roadmap

A tool call is only the center of the product journey. The useful question is how much routine infrastructure the team must build and keep operating around that call.

1. Serve the product through the surface it needs

One KDCube app can expose any honest combination of:

• authenticated REST operations and public webhooks
• streamed multi-user conversations over SSE or Socket.IO
• MCP resources for external agent clients
• scheduled jobs and cron routines
• app-domain events through the Data Bus
• widgets, complete main views, and application-hosted websites
• one or several agents behind those surfaces

The app author declares each surface, including whether it is public, platform-authenticated, or protected by delegated grants. The runtime owns ingress, routing, declared guard enforcement, enabled-state checks, and the transport lifecycle. Business code receives normalized request and user context instead of rebuilding those seams for every endpoint.

For conversation work, accepted messages and events enter an ordered lane. A processor wake schedules the app; the lane defines event order. Native ReAct may fold eligible arrivals into its live turn. A foreign run-to-completion adapter instead takes the whole still-pending lane once at start, then watches read-only: ordinary arrivals wait for handoff, while runtime-specific control can cancel a LangGraph stream or reach hosted Claude Code at its next tool boundary. Streaming is therefore a durable conversation contract that extends beyond a loop printing tokens to a socket.

2. Keep conversations, files, and delivery honest

A useful assistant handles more than text. Users upload files, agents produce reports, tools return artifacts, web and knowledge sources become citations, and events arrive while work is in progress.

KDCube provides conversation storage, timelines, attachments, hosted files, artifact references, provenance, followups, steering, and streaming delivery. File delivery is verified. For each declared external file, the runtime hosts the file, emits the file event, and reports a delivery failure when hosting fails.

Products operating outside a chat turn can use signed download URLs and single-use upload slots. File bytes stay out of model messages and ordinary tool payloads.

The team can use these services with its own UI. It can also embed the configurable chat component and receive the full conversation, streaming, files, context, and connection experience immediately.

3. Establish identity and connect in three directions

AI products operate across several identities:

• the signed-in platform user;
• a channel actor, such as a verified Telegram user;
• an external provider account, such as Gmail, Slack, or a custom OAuth/OIDC service;
• an external operator, such as a script, CI job, or agent client;
• the app and agent currently handling the request.

KDCube keeps these relationships explicit. Three are Connection Hub trust directions - the app as platform authority, delegated to KDCube, and delegated by KDCube; a channel-identity edge additionally links a verified channel actor to a platform user.

PLATFORM AUTHORITY
the app hosts login and provides a platform authority realm
  -> an accepted upstream proof becomes a KDCube platform session

DELEGATED TO KDCUBE
user connects Gmail / Slack / custom OAuth-OIDC account
  -> KDCube may use selected provider claims for that user

DELEGATED BY KDCUBE
user approves an external script or agent client
  -> external operator may use selected KDCube resources and operations

LINKED CHANNEL IDENTITY
verified Telegram actor + approved connection edge
  -> requests may resolve to the linked platform identity when required

The shared service behind this is Connection Hub. Provider tokens remain in the server-side user-secret lifecycle. Tool code requests a connected account with specific claims; the runtime resolves the current user's credential or returns a structured consent/reconnect action.

For incoming automation, bearer credentials are handles for server-side grant records. Managed REST and MCP guards resolve resource-scoped grants and selected operations before product code runs. The external operator remains a delegated actor, preserving who acted and on whose authority.

4. Bound code and side effects

Model-generated code is useful precisely because its behavior is discovered at runtime. KDCube applies the isolation profile selected by the operator. The reference split-Docker profile gives that code narrower network, process-environment, secret, and filesystem authority than trusted application code.

The agent and generated program are requesters, not sources of authority. The runtime binds tenant, project, actor, user, authority, and grants independently of model output. A logical ref or path proposed by the model is treated as an untrusted locator. Trusted runtime code resolves it inside that already-bound scope and materializes only an authorized result into the execution workspace; an out-of-scope request contributes no bytes. The executor receives that workspace, not a shared storage root or a selector that can change the user.

KDCube's isolated execution model separates a trusted supervisor from an untrusted executor:

trusted supervisor
  - restores approved runtime context
  - resolves inputs under the bound identity
  - mediates tools and artifact exchange
  - may reach configured platform services
             |
             | narrow brokered protocol
             v
isolated executor
  - runs generated code
  - network disabled in split isolation
  - minimal safe environment
  - reaches external services only through approved tools

Approved tool calls cross a separate authenticated bridge. Their trusted implementations run in the supervisor under the carried request identity, grants, and provider claims. In split isolation, provider credentials and the platform secret store are not present in the executor container.

Local subprocess, legacy combined Docker, split Docker, and remote execution serve different deployment needs through one contract. Local mode is development-time crash containment and inherits host environment and network. Combined Docker filters the generated-code child but shares one container/mount trust zone. Split Docker is the production reference for untrusted generated code. Execution policy can be chosen per surface or tool instead of treating the entire application as equally trusted.

This execution boundary is reusable rather than tied to one agent loop. KDCube ReAct uses it through its logical workspace tools, and the LangGraph reference app attaches the same isolated workspace and execution service as a normal LangChain tool.

This boundary also lets tools carry runtime meaning. Tool traits can describe ordered multi-action strategy and, for supported detached calls, execution scheduling and replay behavior. The model proposes work; runtime policy still decides when a validated call may begin and whether a retry has already been consumed.

5. Track and enforce economics

An AI product spends money in many places: model calls, embeddings, web search, external APIs, rendering, and custom metered services. Logging those costs after the fact is useful. Deciding before a call runs whether the user may spend them is a different responsibility.

KDCube uses one enforcement lifecycle across chat, REST operations, jobs, and search:

verify -> reserve -> run -> settle actual usage

Usage can be attributed to the platform user, app, conversation, turn, flow, provider, and model. Subagent spend can roll up to the delegating work. A turn's cost is computed as the sum of the spendings inside it.

Built-in tracking covers model, embedding, and web-search work. Custom services can use the same accounting contract. The result is one operational answer to “may this run, what did it spend, and who funds it?” rather than a different budget implementation in every product surface.

6. Deploy, configure, update, and operate

App source can come from Git. Descriptors select app sources and declare non-secret configuration; secret descriptors contain references and placeholders. Runtime properties, user settings, storage, and credentials have separate ownership because they have different lifecycles.

The local and cloud paths use the same app contract. Builders can:

• initialize and start a local runtime from descriptors
• apply updated app configuration
• reload app code and configuration independently of platform image builds
• move the platform runtime to another release when platform code changes
• inspect app status and health
• scale serving and processing workers around shared queues, catalogs, and deployment storage
• run one tenant/project-scoped deployment locally or on shared cloud infrastructure

One running KDCube deployment is bound to one effective tenant/project. It can serve many users and many trusted apps inside that scope. Backing services may be dedicated or shared through tenant/project namespaces. Use separate deployments, accounts, networks, or backing services when unrelated tenants require an infrastructure-level boundary.

7. Compose a complete product experience

Teams can bring every frontend of their own. They can also start from reusable KDCube product surfaces:

• a configurable assistant widget for an existing site
• a ready multi-user chat experience with streaming, files, tools, skills, models, and per-conversation user choices
• a ready ReAct agent with a conversation-owned workspace, web and knowledge tools, governed file operations, and isolated code execution
• Scene as a host for independently authored surfaces
• Canvas and Pinboard for visual working context
• user memories and domain services
• app-hosted websites and multiple frontend widgets
• subagents for parallel, chartered assignments
• named services that expose domain objects through one stable grammar

Each agent is configured separately. Administrators grant its inventory of models, tools, skills, MCP servers, named-service operations, and helper agents. Users may narrow that inventory for a conversation. Tool and code-execution policies remain runtime-enforced rather than prompt suggestions.

Named services are especially useful when a product has many domains. Instead of teaching a model dozens of near-duplicate tool shapes, each domain describes its own objects behind a common grammar:

about · capabilities · schema · list · search
get · action · upsert · host_file · delete

Memories, tasks, conversations, mail, Slack, and custom business realms can use that grammar. Internal agents, generated code, and delegated external agents can reach the same service under their respective identity and grants.

04 A product request is more than a Python call

Consider a user asking an assistant to inspect an uploaded spreadsheet, search the web, and post a summary to Slack.

browser / host product
  |
  | authenticated message + attachment
  v
conversation ingress
  |
  | ordered accepted events
  v
app + selected agent
  |
  +-- read hosted file
  +-- run generated analysis in isolated execution
  +-- call accounted web search
  +-- request Slack connected-account claims
  +-- post through the server-resolved user credential
  |
  v
streamed answer + delivered files + stored conversation
  |
  `-- usage, actor, grants, artifacts, and failures remain attributable

The agent framework still decides how to reason about the task. KDCube operates the surrounding product journey: admission, identity, ordered delivery, file materialization, trusted tool access, consent, isolation, streaming, storage, and accounting.

05 How much does a builder need to do?

The answer depends on the first problem being removed. KDCube supports several depths of adoption.

The runtime has ready implementations for teams that want speed, but its seams remain explicit for teams that bring their own. Use the conversation store or keep domain data elsewhere. Embed the chat component or render the stream natively. Use the built-in ReAct agent or host another loop. Adopt one app and one API, or compose a fleet.

06 What a real LangGraph integration required

We tested this framing by integrating two existing LangGraph agents into one KDCube reference app: a hand-built research graph and a langchain.agents.create_agent agent. LangGraph remained the decision runtime. The vendored nodes, prompts, LangChain tools, graph semantics, and Postgres checkpointer continued to do their original jobs. The graph instance did not become process state: execute_core builds it for one bound turn, runs it, and discards it. Only the checkpointer connection is reused.

The integration used three explicit adapters:

1. A BaseChatModel bridge routed the graph's model calls through KDCube's configured and accounted model service.
2. A stream adapter translated LangGraph astream_events into ordered KDCube conversation events for the browser.
3. A turn I/O map converted the KDCube message, identity, conversation, and attachment context into each graph's input and returned its final answer.

The surrounding foreign-runtime seam folds every still-pending lane occurrence into that turn in sequence order and keeps only its own scheduled reservation fresh while the graph runs. The reference app advertises steer, not live follow-up: cancellation happens at an await point, and before the next model request the adapter repairs every checkpointed tool call that never received a tools-node result.

KDCube turn --------> turn I/O map --------> existing LangGraph graph
                                               |
                     accounted model <--------+-- model bridge
                                               |
KDCube client stream <--- stream adapter <----+-- astream_events

That seam is small and real. Most of it was mechanical. Message conversion, graph-node-specific stream mapping, and coherent user/file ownership needed careful tests because a naive adapter could appear to work while losing a tool result, a stream event, or a file's owner.

The scaled-serving rule is more important than an adapter detail. A later turn may land on another worker or machine, and many users may execute concurrently inside the same deployment. No conversation can therefore depend on a graph cached in one process. Agent memory and checkpoints live in shared storage; the reference app uses one tenant/project schema, app-prefixed tables, and agent_id row/key scope rather than per-agent schemas.

KDCube then supplied the surrounding services selected for the app: authenticated and ordered turn delivery, SSE/Socket.IO client transport, a framework-neutral conversation record, a reusable chat UI, conversation-scoped model and tool choices, isolated code execution, file hosting, economics accounting, and a Telegram webhook. LangGraph's checkpointer remained the agent's memory. KDCube's separate conversation record stores the accepted user-input batch before either completion or a terminal error: every text submission, context event, and hosted attachment occurrence retains its batch identity. It then stores hosted files and the answer while replaying dynamic objects emitted through the communicator for listing and reload. Visible model-round text remains its own timeline evidence instead of being concatenated into the final answer.

The first useful community milestone: bring one graph and its tools, connect the three adapters, and see it answer through one authenticated, streamed, accounted KDCube conversation. The reference app now ships in the default install and contains these adapter patterns, so the next integration starts from tested working seams rather than rediscovering them.

07 How KDCube fits beside agent frameworks and managed platforms

The products in this space solve different layers. The comparison below maps those categories and the layer each one emphasizes. Individual offerings, deployment modes, and plans change; follow the linked official sources when making a current product decision.

Examples of the neighboring categories include LangGraph, LangSmith Deployment, CrewAI, and the Claude developer platform. LangGraph is an open-source framework. LangSmith is a commercial platform with cloud, hybrid, and enterprise self-hosted modes. KDCube's framework and runtime are MIT-licensed and self-hosted. These projects remain useful in their respective layers; this is an operating-model distinction, not a claim that one category replaces another. KDCube's role is the integrated operating layer around the agent and the rest of the application.

08 What the builder actually authors

A KDCube app is a self-describing package, but it can remain small. The builder authors only the parts the app provides:

1. Runtime composition: bind existing handlers, agents, tools, jobs, or provider services.
2. Surface declarations: expose only the APIs, conversations, MCP, named-service, Data Bus, scheduled, or UI surfaces that really exist.
3. Configuration and secrets: declare safe defaults separately from secret references and deployment values.
4. Interface and storage contracts: document machine-callable surfaces and who owns durable state.
5. Tests and release metadata: keep runtime decorators, configuration, interfaces, docs, tests, and release history synchronized.

The platform supplies the common runtime contracts. The app remains the home of the product behavior. This is why one app can be a tiny integration adapter, another can own a domain service, and another can host a full workspace while each remains independently configured and deployable.

09 Start with one useful boundary

The shortest path begins with the product already running today:

1. Pick one routine infrastructure responsibility consuming product time.
2. Wrap the existing implementation at the nearest KDCube surface.
3. Keep the framework, UI, tools, and storage that still serve the product.
4. Add another runtime service only when it earns its place.

Start with one webhook, one streamed conversation, one ready chat widget, one isolated code tool, one connected provider account, or one delegated MCP resource. Deploy it from Git. Configure and update it independently. Let the runtime handle that boundary while the team stays focused on what is unique in the product.

Bring the agent. Keep the product. Use KDCube for the parts that should become routine.

· Read more