KDCube capability map · August 2026 · sourced and dated
The complete KDCube capability map.
KDCube combines an application SDK, multi-user runtime, native and hosted agents, user-facing surfaces, governed connections, isolated execution, memory, economics, and operations. This page records that product contract without turning it into a score against unlike technologies.
KDCube capability map
What the product actually combines
This is the current KDCube contract, organized into five responsibility groups rather than ranked features. Scan the capability names first; each card then states what ships and the boundary that prevents over-reading the claim.
| Capability | Shipped KDCube contract | Important boundary |
|---|---|---|
| Application SDK and product surfaces 11 capabilities | ||
| Deployable app package and async lifecycle | A Git-managed, descriptor-backed app is the deployable unit; runtime configuration still uses the literal bundle identifier.↗ | App backend code is trusted deployment code and runs on the shared async proc event loop. |
| Provider surfaces | Reactive agent turns, REST operations, MCP endpoints, UI widgets, main views, jobs, cron, Data Bus handlers, and public content.↗ | Each surface declares intent, visibility, and authentication ownership independently. |
| Consumer surfaces | Descriptor-owned connections to MCP, tools, named services, event/job inputs, and scene components, with per-agent effective inventories.↗ | Registering a connection does not grant every agent every capability. |
| App transport map | A single SDK contract maps chat, Data Bus, background jobs, REST operations, widgets and static UI, communicator SSE/Socket.IO, public routes, and streamable-HTTP MCP to their runtime paths and authentication owners.↗ | Apps do not expose raw WebSocket/SSE or stdio/SSE MCP through proc; realtime output uses the platform communicator and supported route families. |
| Ready chat, multiple widgets, main views, scenes, and canvas | Apps can use the ready chat, independently build and serve multiple named widgets plus a main view, and compose them with chat and canvas in scenes.↗ | Each UI alias has its own enablement and build output; the host owns authenticated runtime configuration and routing. |
| Discoverable public-content lifecycle | An explicit app provider publishes, updates, and retracts canonical public pages with SEO, Open Graph, Twitter, JSON-LD, sitemap, and gone-state metadata.↗ | Public content is a governed app surface, not the widget shell or an inferred scan of app code. |
| App properties and deployment secrets | Code defaults and descriptor/admin properties merge into effective app props; secrets resolve through the configured secrets provider; on_apply_props is the public async hook.↗ |
Runtime YAML and Redis views are derived; the descriptor store is authoritative. |
| Per-user properties and secrets | Awaitable get/set/delete APIs store user properties in PostgreSQL and user secrets in the configured server-side provider.↗ | User state is not merged into deployment props or exported into app descriptor files. |
| Runtime-provided app storage and cache | Namespaced artifact storage and KV cache APIs let app code persist files and cached values without selecting local, EFS/shared-filesystem, or object-store implementations.↗ | The runtime owns deployment scoping and backend selection; apps must not invent storage roots or depend on local worker disks. |
| Explicit app and UI reload | Activate app code and configuration changes in the running proc without rebuilding the platform image; source UI builds are supervised and published atomically.↗ | Activation is explicit and Git-addressed; KDCube does not claim continuous mutable-branch polling. |
| Live settings and surface policy; explicit version switch | The production control plane edits effective properties, enables or disables individual API, MCP, widget, main-view, and cron surfaces, and changes roles, authentication, or CSRF policy at request time; it also selects and explicitly reloads a new app ref/version.↗ | Writes go through the descriptor authority; runtime YAML and Redis are derived views. Policy refresh and code-version activation are deliberately different paths. |
| Agents, harness, tools, and connections 9 capabilities | ||
| Built-in native agent | An event-aware native coding agent with multi-round tool use, live-event folding, governed streaming, subagents, and stable-prefix prompt-cache shaping.↗ | The native agent is one adapter over shared runtime contracts, not the owner of the conversation store or harness. |
| Descriptor and UI agent configuration | Deploy-time descriptors or the live Agent Forge configure models, versioned instruction sets and profiles, default tools and traits, skills, event sources, subagents, and administrator customization through one staged apply.↗ | Administrator configuration is the capability ceiling; conversation-scoped user choices can narrow it but cannot widen it. |
| Existing framework agents | Keep LangGraph, CrewAI, Claude Agent SDK, or a custom loop and add a thin async turn, streaming, state-scope, and accounted-service host layer.↗ | The framework keeps its graph, prompts, tools, and internal memory; KDCube owns the host boundary around it. |
| Hosted Claude Code runtime | A supported SDK runtime for Claude Code sessions, workspace continuity, MCP/tools, declared outputs, recording, and usage accounting.↗ | Claude Code has its own session substrate and tool configuration; it is not silently treated as the native agent. |
| Shared Agent Harness Runtime | Framework-neutral event/object resolution, persisted timeline and turn views, and per-turn workspace/reference/materialization contracts.↗ | The harness is not the Event Bus and is not a rename of the native agent or classical execution runtime. |
| Tools and skills | Schema-driven tools with runtime traits, fences, execution policy, and accounting context; reusable skills with imports and per-agent selection.↗ | Tool metadata is runtime-enforced; it is not prompt decoration. |
| MCP provider and consumer surfaces | Consume MCP through an app-scoped server registry plus explicit per-agent tool inventories; provide async app-native MCP with public, app-owned, or platform-managed authentication. Current discovery uses server/discover with legacy interoperability.↗ |
MCP direction, route family, and authentication owner are independent decisions. |
| Named services | Discoverable namespace and operation contracts for object realms, usable natively or through a generic MCP bridge.↗ | Named services are optional higher-level semantics, never a prerequisite for ordinary MCP. |
| Conversation-scoped agent capabilities | Administrator inventory defines the ceiling; a user can explicitly narrow tools, MCP, named-service operations, skills, subagents, model, and instruction profile per conversation.↗ | User selection cannot widen administrator configuration; concrete operation fences still decide each attempted call. |
| Users, conversations, files, and event delivery 10 capabilities | ||
| Multi-user deployment scope | One effective tenant/project deployment can serve many authenticated users and many operator-approved apps.↗ | Logical namespacing is not infrastructure isolation between mutually hostile app operators. |
| Ordered conversation turns and external events | Per-conversation ordered delivery owns messages, external events, followups, turn handoff, and agent execution wakeups.↗ | Run-to-completion adapters receive a fixed start-of-turn batch; the native agent can fold live mid-turn events. |
| Live browser delivery and semantic streams | REST plus SSE and Socket.IO, with separate thinking, progress, answer, followup, file, citation, and application-event semantics.↗ | Live relay is transient; reconnecting clients reconcile authoritative state. |
| Conversation recording, reload, and search | Framework-neutral conversation recording, reload, deletion, turn materialization, hybrid search, and role-aware jump targets.↗ | A smaller run-to-completion turn log is valid; importing a harness helper does not grant native-agent semantics. |
| Files, artifacts, citations, and feedback | Canonical conversation refs, out-of-band file delivery, artifacts and turn views, citations/source provenance, and structured reactions/feedback.↗ | A workspace artifact is not automatically a timeline block; signed links are not retyped through model output. |
| Distributed turn workspace | A sparse per-turn workspace with canonical conv:fi: refs, explicit read/pull/materialization, change detection, and hosted output artifacts.↗ |
Files arriving with a message are not silently pre-staged or read into model context. |
| Data Bus and Live Event Relay | Redis-stream-backed durable app messages with at-least-once handlers, plus transient session/project browser relay through SSE and Socket.IO.↗ | Data Bus publication does not create an agent turn; applications own deduplication and any bridge into conversation processing. |
| App-level outbound event firewall | An app-owned async policy can inspect user, event family, destination, and payload context before an outbound communication event reaches Redis publication.↗ | This firewall governs outbound app events only and is fail-open on policy errors; it is not an inbound network firewall. |
| Bounded event recording and sinks | Apps can copy selected post-firewall, privacy-filtered event families into bounded batches and configurable sinks across turns, APIs, MCP, reactive handlers, jobs, tools, and isolated execution.↗ | Recorded events omit raw prompts, answers, and tool arguments; this is reviewable operational evidence, not an immutable compliance audit. |
| Scheduled and durable background work | Descriptor-gated cron jobs plus queue-driven background and virtual-task work with durable lifecycle/progress records.↗ | Conversation turns, Data Bus handlers, background jobs, webhooks, and cron remain distinct delivery mechanisms. |
| Identity, delegated access, and execution governance 5 capabilities | ||
| Surface guards and bound runtime identity | Authenticated request context, surface visibility, app-owned or managed guards, delegated resources, grants, and operation-level tool fences.↗ | Authentication does not authorize every operation; route family does not determine authentication ownership. |
| Per-operation CSRF protection | Individual app operations can require descriptor-overridable, distributed single-use CSRF proofs that are consumed atomically across ingress replicas.↗ | CSRF is an additional browser request-integrity control; it does not replace authentication, authorization, or delegated grants. |
| Connection Hub and server-side credentials | Connected accounts, delegated-by and delegated-to access, platform authorities, authenticators, revocation, and consent under explicit storage boundaries.↗ | Provider tokens, delegated access tokens, and deployment secrets are different credential families with different stores. |
| Per-agent delegated access | Each agent is a delegated client with per-user, per-agent, per-resource grants, operation/account narrowing, demand-driven consent, and revocation.↗ | An agent grant never contains the user's upstream provider credential; both delegated-by and delegated-to consent may be required. |
| Profile-dependent generated-code isolation | Local subprocess, legacy combined Docker, and reference split Docker profiles; split uses separate supervisor/executor containers and trusted tool mediation.↗ | Local subprocess is development containment, not a security sandbox; only split provides the no-network/no-secret executor boundary. |
| Models, knowledge, memory, economics, and operations 11 capabilities | ||
| Hosted and local model routing | Role-model routing across integrated providers plus an operator-connected custom gateway for locally served models such as Ollama.↗ | KDCube routes to operator-supplied inference; it does not claim a platform-managed GPU serving fleet. |
| Knowledge and hybrid retrieval | Knowledge-base ingestion, semantic and hybrid retrieval, conversation retrieval, provider-owned objects, and source-aware results.↗ | Knowledge bases, conversation search, and durable user memory are separate state realms. |
| User-controlled durable-memory reconciliation | Durable user memories with evidence, search, operational maintenance, and explicit user reconciliation/edit/delete flows.↗ | This row is affirmative because the capability is user-controlled; it does not claim automatic turn-end reconciliation. |
| Stable-prefix prompt-cache governance | Stable system prefix, uncached turn announcements, selection-change policy, and explicit cold-turn cause/accounting for the native agent.↗ | This is a native-agent contract; hosted frameworks retain their own prompt/cache semantics. |
| Usage and cost accounting | Raw usage events and per-turn costs attributed across tenant/project, user, app, agent, conversation, turn, provider, model, and service.↗ | Only calls crossing an accounting-aware integration boundary are covered. |
| Usage analytics | Scheduled and on-demand aggregation into user, agent, app, provider/model, and OPEX views with indexed scale paths and CSV/dashboard consumers.↗ | This is usage/economics analytics, not a claim of a generic product-behavior analytics suite. |
| Verify, reserve, execute, settle economics | Pre-execution admission, scoped quotas/budgets, distributed reservation, actual-cost settlement, and funding/economics subject tracking.↗ | Integrated model, embedding, web-search, and participating custom/provider calls are covered; arbitrary outside spending is not. |
| Plans, prices, budgets, wallets, and payments | Economics descriptors seed plan quotas, price tables, and reservation policy; the live control plane manages plans, project budgets, wallets, internal and Stripe subscriptions, top-ups, refunds, cancellation, and reconciliation.↗ | Plan identity, user role, and funding source are separate; live database policy is authoritative after descriptor seeding. |
| Operational monitoring and telemetry | Gateway, queue, process, circuit-breaker, transport, connection-pool, latency, drain, health, and metrics signals plus communicator recording and reported metrics.↗ | The generic app telemetry stream/listener remains a proposal and is not claimed here as shipped. |
| Horizontal coordination and scaling mechanisms | Redis-backed coordination, queue/process metrics, shared locks, autoscaling signals, and graceful drain for operator-configured replicas and capacity.↗ | These are scaling mechanisms, not a claim of unlimited capacity or a vendor-managed control plane. |
| Open source and operator-run | MIT-licensed runtime and SDK, run in infrastructure selected and operated by the deployer.↗ | KDCube does not currently claim a generally available vendor-managed cloud service. |
Use the inventory, then compare within a product category
Choose the layer you actually need.
The comparison page groups frameworks, managed agent services, developer tooling, and deployment platforms before comparing their documented responsibilities.