Engineering deep dives, industry perspective, implementation notes, and practical recipes.
Search covers titles, summaries, tags and full article text.
Bring your own agent — your graph, your framework, your control loop. KDCube hands it user events through the event bus: ordered and one turn at a time per conversation. A wake names one accepted occurrence; a run-to-completion adapter folds it and every other still-pending occurrence into one start snapshot. A live loop may fold new work while the turn r...
Paid paths that join KDCube's accounting boundary use one lifecycle: verify, reserve, run, and settle.
A KDCube tool can call your service as the user — not with a shared system key, not with a platform login token, and not with a secret copied into code. The user connects their account once through Connection Hub; after that, tools and named services resolve the user's provider token only when the requested claim is approved.
The app already has HTML, JavaScript, APIs, authentication, and a release. KDCube publishes its existing main view as a complete website without creating a second frontend artifact.
A tool schema tells an agent how to call a function. It does not tell the runtime whether that call reads, writes, or can safely begin before the model has finished generating the rest of its round. KDCube tool traits add that missing policy layer — metadata the runtime reads and enforces , not prompt advice.
One tool call charters a helper agent that runs as its own scheduled turn, streams into the same chat as a thread, and reports back onto the timeline it came from — with the admin shaping who may delegate to whom, the paying user deciding, and the runtime enforcing the same economic boundary as any turn .
The agent has been able to search your conversation history for a while — that is how it remembers what you decided in May. Today the same engine gets a human door: a search box in the chat sidebar. Same index, same ranking, same hard rule that you only ever see your own conversations — now with your hands on the controls.
The ReAct agent writes Python; the code posts a file to Slack, sends an email, saves a memory. That code runs in a sealed sandbox — yet the call reaches the real service, under the real user, with real consent checks. The trick is a relay: the request rides KDCube's durable message lane to the service's home process and the answer rides back.
A tool call leaves the process — a subprocess, a sandboxed container, a remote task. What must follow it is not the infrastructure but the situation: who is asking, which app is acting, what the call may touch. KDCube packs that situation into one JSON-safe room, ships it across the boundary, and rebuilds everything else from descriptors on the other side.
The complete hands-on authoring story: project one backend into coherent use-case realms, then declare nouns and refs, recursive capability discovery, exact guarded actions, complete data delivery, and the presentation layer — and the test that a realm now has two readers: an agent that works it from the schema, and a user who understands and controls it ...
Two ways into a running KDCube — a one-command clean bootstrap that stages a configured ecosystem, and a descriptor set that reproduces an environment as a reviewed artifact — and the one operating loop you live in afterwards.
Twenty-two real problems, stated the way practitioners state them — each answered with the concrete KDCube mechanism that solves it.