Application Data in KDCube: Where State Lives and How It Moves
A map of KDCube app state: authorities, storage homes, scoped addresses, delivery lanes, public projections, and execution boundaries.
Deep dives from building an event-first, multi-user AI platform.
Search covers titles, summaries, tags and full article text.
A map of KDCube app state: authorities, storage homes, scoped addresses, delivery lanes, public projections, and execution boundaries.
How KDCube separates platform, app, and user properties and secrets, then resolves live configuration through async SDK contracts.
A KDCube ReAct turn is a state machine that runs the model, watches what it generates as it streams, decides in real time what may reach the user, and — when something goes wrong — tells the model exactly what happened before asking it to continue.
How KDCube governs MCP in both directions: per-agent consumer inventories, app-native provider surfaces, delegated authority, dual-era wire support, named services, and economics around paid work.
How KDCube apps move state: the durable Data Bus for inbound changes, the live relay streaming to watchers, and the scene bridge into embedded widgets.
No magic token table: handles, secrets, metadata, edges, and sessions each live where their lifecycle fits. The storage model is the design.
What you actually write for a KDCube app: four starting points, the runtime services around each, and the point where the work stays yours.
A working agent is product IP, not migration debt. Preserve its LangGraph core and add a bounded async host layer for ordered turns, streaming, user-bound state, and reload.
In KDCube's reference split-Docker profile, generated code runs in a separate networkless executor while approved tools act through a trusted supervisor.
Every integration wants to act as someone, somewhere. One broker keeps identities, claims, grants, and secrets distinct across three directions of trust.