Your app publishes a service. Discovery indexes it. An agent asks for it — and gets an error about a permission nobody has heard of. Nothing is broken: three of the four decisions that make a service usable have not been taken yet, and each belongs to someone else.
How KDCube apps choose among local operations, named services, Data Bus, jobs, conversation ingress, MCP, REST, and widgets.
A map of KDCube serving, Data Bus, communication, venv, provider, and isolated-execution runtimes — and the explicit contract at each crossing.
A hosted agent does not carry a session, restore a conversation, keep a file, or survive a worker restart on its own. Two different memories do that for it — one the platform owns, one the agent owns — and the line between them is the whole story.
An agent loop can choose a next action. It cannot, by itself, bind a user identity, serialize concurrent messages, preserve files, restore a conversation on another worker, enforce a grant, account for a model call, or isolate generated code. KDCube supplies that operating layer around the agent — without requiring the agent's reasoning core to become a K...
My agents act on users' Gmail and Slack every day - external agents like Claude Code included - and none has ever held a provider token. Every access is something the user granted, granular and on demand, and it takes two acts they control: connect the account, and permit the agent. Here is the whole machine, fence by fence.
KDCube architecture maps trusted apps, tenant and user scope, storage isolation, runtime fences, and split code execution.
How KDCube loads, reloads, predeploys authorized widget assets, and cuts over app generations without rewriting in-flight work.
How KDCube apps provide and consume API, MCP, named-service, connected-account, Telegram, UI, event, and job surfaces.
A map of KDCube app state: authorities, storage homes, scoped addresses, delivery lanes, public projections, and execution boundaries.