1. Edge & access control

The edge is fully platform-owned for one practical reason: it's the part that has to be uniformly safe across every bundle on the runtime. A bundle that authored its own JWT path or its own ClamAV bypass would compromise the whole tenant. So the seam is high — the bundle starts after ingress has authenticated, scanned, and routed. See Communication for the full ingress shape and Deployment for the multi-tenant runtime.

2. Isolation & secrets

The isolation seam is the topic of an earlier post in this series: the executor runs without network or platform secrets, and a trusted supervisor mediates approved tool calls. From the bundle author's side, the contract is one function call. Everything beneath — split containers, supervisor RPC, network policy, syscall surface — is platform infrastructure. See also Security.

3. Economics, observability, governance

Economics is the most consequential shared seam on the platform. The bundle controls policy (a free tier gets 50 model calls/day; an enterprise tier gets per-project budgets per skill); the platform owns enforcement (atomic Redis-Lua reserve, ledger commit, hard reject). Bundles can't accidentally bypass quotas because the admission check sits outside their code path. Economics covers the full ledger model.

4. Storage, knowledge, retrieval

The storage seam is deliberately a layer: the bundle never picks an S3 bucket name or talks to pgvector directly, but it does name its own paths, pick its own KB sources, and decide what to write. Concepts introduces the artifact taxonomy that the platform's source pool, turn log, and citation system depend on. ReAct's conversation memory layers use the same artifact/provenance discipline; the standalone User Memory subsystem adds user-owned durable records on top when a bundle enables it.

5. Lifecycle & configuration

Hot-reload is the property that makes the whole bundle model practical: an admin pushes a new bundle version, the loader registers the new module, in-flight turns drain, new turns admit against the new code. The bundle doesn't write any of that. What the bundle does write is the two lifecycle hooks above — both of them small, both of them optional. See Configuration for the descriptor / prop / override flow.

6. Scheduling & background work

Off-turn work uses the same handoff pattern as the rest of the platform: span-aware cron, a Redis-locked scheduler, and a generic background job stream. Together they let a bundle declare a nightly KB re-index, a durable maintenance job, or an event-driven background workflow without standing up its own queue. User Memory reconciliation currently uses widget-submitted background work plus the bundle's single @on_job dispatcher; a bundle could also schedule similar maintenance with @cron.

7. Communication surfaces (REST / widgets / UI / MCP)

The same decorator-driven model surfaces REST, widgets, UIs, and MCP. The bundle author writes the handler and the widget source; the platform handles routing, role enforcement, static-asset serving, the chat-web-app integration, MCP transport negotiation, and source-folder builds. Public widget routes are only for loading the app shell; product data still goes through an authenticated bundle API. Integrations documents the surface in depth, and Communication covers the streaming contracts the chat surface uses.

8. Agent runtime, memory, tools, skills, streaming

The agent runtime is where the platform offers the most and the bundle can still replace the most. A ReAct bundle gets the layered conversation memory model, cache discipline (covered here), attention area (here), and channel-aware streaming (here). It also gets the KDCube skills subsystem, approved tool execution across runtimes, multimodal turn context, and live saturated widgets that behave like client-side components while being driven by model/tool events. A bundle that derives from the memory mixin can expose user-owned durable memories through the Memory widget, optional hotset projection into ReAct ANNOUNCE, and optional memory search/read/write tools. A bundle that needs a different loop overrides execute_core and drives its own LangGraph; storage, auth, economics, tools, skills, widgets, jobs, and observability still come from the platform.

9. The SDK contract at a glance

Across all eight sections above, the bundle author writes against a small, stable surface. Here are the decorators and lifecycle hooks. Every one of them is documented in the SDK reference; their full signatures live in kdcube_ai_app/infra/plugin/agentic_loader.py.

10. Two bundles, same seam

The same boundary supports both ends of the spectrum.

On one end: kdcube.copilot is a focused documentation-reader bundle. It prepares a ks: knowledge space, exposes curated docs/source paths, and lets ReAct answer product and architecture questions with precise references. The same bundle can now opt into economics, durable User Memory, and a Telegram WebApp with two sections — memory management and Telegram user administration — without owning a separate server.

On the other end: the reference versatile bundle is a larger example application. It builds its own LangGraph StateGraph, runs an MCP server with a header-token auth scheme, ships tools_descriptor.py and skills_descriptor.py, integrates Telegram delivery, registers widgets, exposes the shared User Memory widget, and demonstrates bundle-owned tools. The bundle author wrote application logic. The platform — the same platform — supplied ingress, auth, accounting, isolation, hot-reload, observability, the loader, and the SDK seams the bundle decorates against.

The handoff is clearest in two places. First, BaseEntrypoint.__init__ in chat/sdk/solutions/chatbot/entrypoint.py — the constructor shows the platform-injected runtime inputs (config, pg_pool, redis, comm_context, event_filter, ctx_client, continuation_source). The base class then initializes platform helpers such as logger, models_service, kv_cache, and effective bundle_props. The bundle decides what to do with that context.

Second, the loader: agentic_loader.py introspects the bundle's decorators and registers routes, schedules, MCP transports, and widget cards on the runtime. The bundle never registers a URL itself. One decorator line is the entire contract for "mount me here, with these roles, gated by this flag."

Where to go next

If you're sizing KDCube against your problem: Platform overview for the system shape, SDK reference for the decorator surface, Configuration for descriptors and props, Economics for the budget model, Security for the isolation story, and Deployment for the multi-tenant runtime.

If you're a coding agent: agents.json is the machine-readable manifest with the full decorator list and source paths; AGENTS.md is the human-readable companion. Parse one, read the other.