KDCube
← Our Journal

Agent-generated code executes in an isolated runtime: the code itself in a no-network executor, platform tools beside it in a supervising sidecar. That sidecar knows who is asking (the portable context room travels with every execution) and which app serves the namespace — but the live in-process caller that a direct agent call uses exists only in the host server. The relay closes that last hop.

ONE REQUEST, THERE AND BACK Isolated runtime agent code + tool sidecar object_action(send) policy and discovery pass; no live caller in this process relay: publish + wait identity refused if unbound Data Bus (Redis Streams) durable, per-bundle lane messages: request + actor results: recorded answer dlq: failed messages consumer groups, retries, redelivery on silent consumers Host proc provider bundle's bus worker binds the message actor as the request identity provider runs: consent, claims, connected accounts answers once per message id publish claim result answer The lane delivers at least once; the handler's recorded response makes the effect exactly once — a redelivered "send" returns the first send's result. Same identity end to end: the provider authorizes the relayed call exactly as a direct one.
One request, there and back: sandbox → durable lane → the service's home → recorded answer.

The round trip

  • Same identity end to end. The message carries the requesting user — id, roles, permissions, authority — copied from the restored context. The worker binds it before the provider runs, so consent claims and connected accounts resolve for the real user. A runtime with no bound identity is refused outright; nothing anonymous is relayed.
  • Exactly-once effect on an at-least-once lane. The lane redelivers when a process dies between doing the work and acknowledging it. The relay handler records its response per message id and answers redeliveries from the record — a re-delivered "send" returns the first send's result instead of a second email.
  • One handler makes a service reachable. The always-running services app ships it, so mail, Slack, and conversations work out of the box; any app serving its own namespace joins with three lines.

The use case that proves it: consent from inside code

The user asks the agent to post a diagram to Slack, and the agent decides to do it in code. The Slack file-upload approval hasn't been given yet.

CONSENT FROM INSIDE CODE Run 1 — code calls Slack upload_file(channel, file_path) relay carries it to the provider; no slack:files:write approval yet fails honestly: consent error + hub link The person decides the same consent card a direct call raises appears in chat one approval in Connection Hub: Upload Slack files — approved Run 2 — same code upload_file(channel, file_path) provider finds the approval, shares into the direct conversation file lands in Slack Consent stays a human decision at a human surface. Code never bypasses it — and never buries it: the failure carries the exact fix, and the approval unlocks every future run, generated code included.
The code fails honestly; the person gets a real consent card; the same code works after approval.

First run: the generated code calls upload_file; the relay carries it to the Slack provider; the provider finds no slack:files:write approval for this user — and answers with the same structured consent error a direct call gets, including the Connection Hub link. The code fails honestly, the agent reports it, and the consent card reaches the person in chat. They approve once. Next run — same code, same call — the provider finds the approval and the file lands in Slack.

Consent stays a human decision at a human surface; code never bypasses it and never buries it.