AI Agent Infrastructure: The Runtime Around Your Framework

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.

the agent loop answers:  what should the agent do next?
the runtime answers:     how does this operate safely for real users?

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.

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.

FRAMEWORK
  SDK · contracts · configuration · components · extension points
                           |
                           | declarations become enforced behavior
                           v
RUNTIME
  ingress · scheduling · isolation · storage · streaming · accounting
                           |
                           | shared operating services
                           v
PLATFORM
  apps · identity · integrations · user settings · hosting · control surfaces

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.

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. The runtime owns ingress, routing, authentication, 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. Live events can fold into a running turn, while retained events become future context. 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 both 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.

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 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; credentials do not move into generated code.

Local subprocess, Docker, split supervisor/executor, and distributed execution profiles serve different deployment needs through one contract with different isolation strengths. 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 isolated tenant/project environment locally or on shared cloud infrastructure.

One running KDCube environment belongs to one tenant/project. It can serve many users and many apps inside that boundary. Separate tenant/project environments provide the larger isolation unit and keep unrelated tenants in separate application processes.

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.

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.

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.

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:

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

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 minimal user turn, attachments, hosted files, and answer, while replaying dynamic objects emitted through the communicator for listing and reload.

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.

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.

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:

• Runtime composition: bind existing handlers, agents, tools, jobs, or provider services.
• Surface declarations: expose only the APIs, conversations, MCP, named-service, Data Bus, scheduled, or UI surfaces that really exist.
• Configuration and secrets: declare safe defaults separately from secret references and deployment values.
• Interface and storage contracts: document machine-callable surfaces and who owns durable state.
• 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.

Start with one useful boundary

The shortest path begins with the product already running today:

• Pick one routine infrastructure responsibility consuming product time.
• Wrap the existing implementation at the nearest KDCube surface.
• Keep the framework, UI, tools, and storage that still serve the product.
• 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

• What You Can Do With KDCube
• How To Integrate With KDCube Apps
• Quick Start: Local KDCube
• How To Write A KDCube App
• Serve Chat From Your App
• External Events Journey And Handling
• Tenant, Project, User, Authority, And Execution Boundaries
• Cross-Runtime Context
• Isolated Execution Runtime
• Economics Enforcement Engine
• Connection Hub
• Named Services
• Application-Hosted Websites
• Port Your Solution To A KDCube App
• Hosted Agent Conversation
• Ported LangGraph Agents Reference App
• Your LangGraph Agent In KDCube