KDCube Glossary

Canonical definitions of platform and agent-runtime terms. Use this when reading the docs, the API reference, or the SDK — every term here maps to something in the code. A few of them — marked coined here — are words we invented because the existing vocabulary didn't quite fit.

KDCube concepts

AI app a.k.a. mini-app: A small focused application built on AI primitives — typically an LLM, a few tools, and a real use case. The unit of work KDCube treats as the deployable thing. We use mini-app to emphasize the scope: specific use case, a few tools, one team, several access surfaces — the same logic exposed as chat, API, MCP, scheduled job, dashboard, etc. (small in use case, not in reach). Distinct from a framework (gives you a reasoning loop and stops there), an agent (the loop running inside the app), and a model (the LLM itself). The platform is built to host many of these on shared infrastructure; see Why KDCube and bundle (how an AI app is packaged for the runtime).
Technosystem Coined here: A self-contained technical environment that hosts everything one or more AI applications need to live, evolve, and serve users: agents, tools, surfaces (chat, API, MCP, dashboards, cron), runtime, storage, identity, governance, and economics. A technosystem is deployed on infrastructure you own and is where your agents live their entire lifecycle — from prototype to production, across customers and configurations. Distinct from a framework (which gives you a loop and leaves the rest to you), a platform in the SaaS sense (which hosts something for you, elsewhere), and a stack (a list of components, not an environment). We coined the word while building KDCube because the existing terms each carried baggage that misdescribed what we kept rebuilding underneath every customer. See Why KDCube and What is KDCube.
Surface: A user-visible or system-visible exposure point of a bundle: chat widget, embedded copilot, smart API, full UI, MCP endpoint, scheduled @cron job, real-time dashboard. A single bundle typically exposes several surfaces, all sharing the same backend logic, agents, tools, and storage. "Where does this AI feature live?" is answered with a surface; "what runs it?" is answered with a bundle on a runtime; "what hosts everything together?" is answered with a technosystem. We use the term throughout the docs because the existing words — endpoint (too HTTP-specific), integration (too generic), channel (overloaded) — each missed something.

Runtime & agent loop

ReAct loop: Reason, Act, Observe. The core decision cycle in which the agent generates a reasoning step, executes exactly one action (a tool call or final answer), observes the result, and iterates. The ReAct loop is what turns a language model from a text predictor into an agent. See ReAct v3.
Timeline-first architecture: The managed conversation path records tool calls, artifacts, plan updates, reasoning blocks, and final answers as ordered blocks in a conversation timeline (conv.timeline.v1). For that path, the timeline is the source of truth for in-turn context, history, and compaction.
Bundle: A hot-loadable unit of agent definition: Python code, tools, skills, prompts, widgets, and config. Bundles are versioned, can be rolled forward or back without restarting the platform, and carry their own entrypoint. See Application SDK.
Supervisor: The trusted process that mediates executor tool calls. In the reference split profile it runs outside the executor, receives tool invocations over a UID-verified Unix socket, resolves the callable on the trusted side, and returns results to the executor.
Executor: The process that runs generated code. In the reference split profile it is a separate, networkless, unprivileged executor with narrow mounts and no platform or provider credentials; external actions must cross a trusted mediation path. Local subprocess and legacy combined Docker provide weaker boundaries. Fargate uses a filtered child in one remote task/container and does not provide split Docker's separate-container mount boundary.
Generated-code execution profile (ISO runtime): The selected boundary for generated code. Split Docker is the reference separate-executor profile: networkless executor, dropped privileges, narrow mounts, and trusted-side tool mediation. Local subprocess, legacy combined Docker, and Fargate remote tasks have different documented guarantees.
Data Bus: The durable, bundle-scoped message path for state that is not a chat turn: collaborative document patches, domain-object updates, cross-widget coordination, background bundle messages. Scoped to tenant / project / bundle and an optional object, backed by Redis Streams, and processed by the bundle even when no chat turn is running and no browser is listening. A separate path from conversation ingress (turn-scoped, durable) and the comm relay (transient output fanout). See Communication System.
External event: A conversation-scoped fact or intent that arrives from a UI, transport, webhook, or system component and may be folded into a ReAct conversation. User prompts, attachments, followups, and steer controls are built-in external event types; external_events[] is the authored transport. Reactive external events wake the agent; non-reactive ones update lane state and are picked up on the next turn. See ReAct Agent.
Event source: The stable-identity model for inputs to a ReAct turn: event_source_id names a stable semantic source, event_id names a single occurrence. External events and tool results share the model, so the timeline can render, deduplicate, and recover them under one set of policies.
Pin Board a.k.a. canvas: The bundle canvas surface: a versioned, collaborative board that pins user text, user attachments, agent text cards, and file / memory / source references as canonical object refs. Pinned items are draggable and editable inline through a flyout drawer, resolved by a per-bundle object resolver registry. Chat conversations can be pinned and reopened. See the Application SDK canvas solution.
Scene composition: How a bundle assembles a host scene from reusable SDK components: iframe mounts by alias, a runtime CONFIG handshake, a component-to-component postMessage broker, and Data Bus wiring. A scene surface registry routes resolver object-opens to the right component.

Data & provenance

Source pool: A per-conversation registry of canonical source rows. Each source has a stable source ID (SID) that is referenced by citations and artifacts. The pool survives across turns so retrieval and provenance stay consistent within a conversation.
SID (source ID): A stable identifier assigned to a source row in the source pool. Citation tokens in generated text resolve to SIDs; produced artifacts record sources_used as a list of SIDs. Enables reviewers to reconstruct exactly which inputs influenced any response.
Citation token: An inline marker in generated text that resolves to a SID. At render time the UI replaces the token with a numbered reference linking back to the canonical source. The citation is preserved through compaction and replay.
Artifact: A typed, durable output produced inside a turn: a file, a plan snapshot, a code block, a rendered diagram. Artifacts are indexed in the timeline and carry their own provenance (tool, inputs, sources_used).
Knowledge space: A logical namespace (ks: URI) that resolves to file, database, or graph-backed knowledge without changing the ReAct protocol. Lets bundles declare semantic knowledge pools the agent can query directly.
memsearch react.memsearch: Conversational memory search exposed to the agent as react.memsearch. Retrieves across the source pool with hybrid retrieval — lexical and trigram retrievers fused with the semantic retriever via reciprocal rank fusion (RRF) — and can read across conversations using conv_<id>. path prefixes. Results are capped per source conversation and reduced to a signal-only envelope. Recovery-session working summaries are tagged and excluded.

Economics & admission

Budget reservation: The reserve-then-commit pattern used by integrated paid-call paths: budget is reserved before covered work, then committed with actual cost or released after failure or lower spend. It prevents TOCTOU overspend on those paths under concurrency; direct uninstrumented spending remains outside this control.
Tenant/project deployment scope (legacy anchor: tenant boundary): One running deployment binds one effective tenant/project and may serve many users and operator-approved apps. Platform services keep that scope in runtime context, database lookups, storage paths, budgets, and Redis/queue namespaces. Custom stores must define their own owner and minimum scope. Stronger hostile-environment isolation requires separate deployments or infrastructure.
Admission chain: The configured pre-execution sequence for managed conversation requests: session resolution, rate limit, backpressure, circuit breakers, economics reservation, and atomic enqueue. A request on that path proceeds only after its enabled checks admit it; other application surfaces declare and enforce their own guards.
Channeled streaming: The output protocol that splits a single agent response into discrete named channels (thinking, answer, followup, tool, etc.). Clients and auditors can subscribe to the channels relevant to their role; sensitive channels (thinking) can be role-filtered at the relay.
Economics enforcement engine: A reusable API that applies the full economics model — role → plan → funding lanes → reservation → settlement — to accountable flows that run model calls outside the chat entrypoint. EconomicsGuard verifies, reserves, and settles a flow; economic_preflight is a feasibility gate only. An EconomicsSubject names who pays. Covers off-turn task executions, memory semantic search, and the memory reconciler. See Platform Economics.

Security & governance

ToolStub: The executor-side proxy object that represents a tool. When the agent "calls" a tool, the ToolStub serializes the request over the Unix socket to the supervisor, which executes it and returns the result. The executor never sees the tool's network or filesystem access.
Decision log: Structured operational evidence of participating admission outcomes: budget, rate-limit, and throttling decisions with request context such as tenant, user, timestamp, and reason. It can pair with versioned turn snapshots for review; retention, immutability, and integrity remain operator policy.
Named secret: A credential referenced by logical name in bundle config; resolved at runtime in priority order: environment variable → settings store → secrets manager. Supports the Kubernetes *_FILE pattern for file-backed secrets and rotation without restart.
Session ownership validation: When a request carries a User-Session-ID header, the gateway verifies it belongs to the authenticated user. Mismatches are rejected with 401/403 before any processing — prevents request injection across user sessions.