What KDCube Is
KDCube is an open-source AI application framework with an integrated self-hosted production runtime. Builders develop against the framework: app contracts, SDKs, configuration, reusable components, and extension points. Their applications operate on the runtime: identity, ordered delivery, streaming, storage, isolation, budgets, scheduling, accounting, and failure handling. The wider platform combines both with app hosting and shared control surfaces.
You do not need to replace an existing agent or adopt every KDCube component. A LangGraph, CrewAI, Claude Agent SDK, or custom agent can keep its business logic and enter through one serving boundary. A new app can instead start with the ready chat and ReAct building blocks. Adopt one useful boundary first, then add others only where they help.
One running deployment is bound to one effective tenant/project and can host many apps and concurrent users. An app may expose any combination of backend operations, APIs, MCP, named services, Data Bus handlers, scheduled jobs, widgets, main views, websites, chat, and agents. None is universally required.
bundle_id, bundles.yaml, @bundle_entrypoint, or /bundles/....Every app can participate in two directions. surfaces.as_provider declares what it exposes to the platform and other callers. surfaces.as_consumer declares what the app and each of its agents may call, including Python tools, MCP servers, skills, and named-service namespaces. One app can be a provider, a consumer, both, or neither for a given surface family.
The object ecosystem lets apps expose domain objects through named-service namespaces, accept conversation or Data Bus events, and join an interactive scene with chat, canvas, memories, tasks, connections, or other surfaces. See Object Ecosystem & Ontologic Contracts.
System at a Glance
Key Terms
| Term | Description |
|---|---|
| Framework / runtime / platform | The framework is the programming model and contracts. The runtime executes and enforces them under concurrency, failure, security, and cost constraints. The platform combines both with shared services and control surfaces. |
| App | A self-describing KDCube application package registered internally with @bundle_entrypoint. It exposes only the surface families it actually implements. Technical identifiers still use bundle_id and bundles.yaml. |
| Provider / consumer surfaces | surfaces.as_provider describes what an app serves. surfaces.as_consumer describes what the app and its agents are allowed to call. |
| Named service | A self-describing domain realm behind a fixed grammar. One declaration serves two readers: agents use its schema; users understand, narrow, and consent through its service card. |
| Scene | Interactive host that composes chat, canvas, memory, task widgets, and other surfaces through context pins and object actions. |
| Conversation Event Bus / Data Bus | The Conversation Event Bus orders context for one user/conversation/agent lane. The Data Bus delivers app-owned domain mutations independently of chat. Outbound client streaming is a third, separate mechanism. |
| Block policy | Provider-owned rule for producing or rendering bounded timeline blocks from external objects and events. |
| Ingress | API gateway service: auth, SSE streaming, task enqueueing, rate limiting. Handles all inbound traffic before the app sees it. |
| Processor / Proc | Queue worker: executes apps, hosts the Operations REST API. Loads app singletons and calls execute_core() per turn. |
| Classical runtime | Process, tool, external-execution, and isolated-execution facilities under sdk/runtime. These services are not all agent-specific. |
| Agent Harness Runtime | The framework-neutral sdk/runtime/harness layer. Harness events resolve canonical object refs; harness workspace owns turn paths, files, materialization, and artifacts; harness timeline owns ordered blocks, event identity, persisted payloads, turn logs, and turn views. |
| Timeline | Shared harness contract for ordered conversation blocks and persisted turn views. It is not the Event Bus, communicator stream, or workspace; accepted lane events and rendered timeline blocks are distinct entities. |
| ReAct agent | KDCube's built-in agent implementation and one consumer of the shared harness. It adds ReAct rounds, semantic-channel protocol, governance, cache, tools, and presentation over shared event, workspace, and timeline contracts. |
| Connection Hub | Identity and delegation control surface for platform authorities, connected provider accounts, and credentials delegated by KDCube to hosted agents, external clients, or automations. |
| Existing agent integration | An existing agent keeps its framework and business logic behind a thin serving seam. Scaled integrations rebuild the agent graph per turn and reuse only durable connections; user state does not live in a process-local graph cache. |
| Tenant / Project | The effective scope of one running deployment. Shared backends remain possible through tenant/project schemas, namespaces, and key prefixes; many users share the deployment's workers under carried request identity. |