Featured article
KDCube is a platform plus a contract. The newest post walks the bundle/platform seam section by section — for each capability, who owns it, what the bundle decides, and where in the platform the handoff lives.
Short answer: the platform absorbs the parts that have to be uniform across every bundle — ingress, JWT validation, multi-tenancy, atomic budgets, isolated execution, hot-reload, observability. The bundle decides application-specific behavior through decorators, lifecycle hooks, configuration, and its own code.
Platform absorbs
Ingress & auth, multi-tenancy, atomic budgets, isolated code execution, hot-reload, observability, storage backends, ReAct v3 memory layers, User Memory infrastructure, LLM router.
Bundle decides
Agent prompts, tools, skills, role gates, role models, quota policies, REST & MCP surfaces, scheduled/background jobs, custom UIs, and whether to opt into User Memory.
Same seam, two ends
kdcube.copilot focuses on docs and knowledge reading; versatile is a larger reference app. They ride the same runtime seam.
Editorial direction
The point of these posts is not to advertise complexity for its own sake. The point is to explain
why the system ended up with some apparently unusual choices once the requirements became:
multi-user, multi-tenant, streaming, auditable, isolated, and cluster-friendly.
The blog should feel technical, opinionated, and grounded in the actual runtime rather than generic
“AI architecture” slogans. The first two posts set the tone:
one on event-first orchestration, one on the fixed attention board, and one on how the runtime shapes the cache instead of leaving it to chance.