KDCube
← Our Journal
Entry № 12 — 10 July 2026 · Journal

The ReAct Agent's Code Can Use Your Services

named services data bus isolated runtime consent same identity end to end

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.

Code the ReAct agent generates 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 + typed selector; no bearer secret crosses relay: publish + wait actor + access_id required Data Bus (Redis Streams) durable, per-bundle lane messages: actor + access_id results: recorded answer dlq: failed messages consumer groups, retries, redelivery on silent consumers Host proc provider bundle's bus worker resolves current card and active catalog admits + binds actor, account_scope for invocation 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 caller facts end to end; current authority is resolved at the target for this invocation.
One request, there and back: sandbox → durable lane → the service's home → recorded answer.

The round trip

  • Same caller facts end to end; current authority at the target. The message carries the trusted actor plus a typed, nonsecret delegated-card selector, including the exact access_id. The target runtime validates that selector, resolves the current durable card and active catalog from Connection Hub, and runs admission there. Authority is not serialized as a frozen projection. Requests without a trusted actor and selector are refused.
  • One decision per invocation. The target binds actor and selected account_scope for the provider invocation and restores the previous context on success, error, or cancellation. A streaming result keeps that one admission for its complete consumption; chunks are neither reauthorized nor rebound.
  • 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.
  • The relay is generic; ownership is explicit. The always-running services app ships the handler for its own providers, so mail, Slack, and conversations work out of the box. Another owner app first publishes its provider through its app registry, then adds the same relay handler to make that provider callable from isolated runtimes. Discovery selects only the app's explicitly published current providers.

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.

Since then, a second consent stands in front of that one: the AGENT itself must hold the user's grant for the namespace it calls. Every agent — external MCP client or an agent hosted in a KDCube app — is a delegated client the user grants per agent (kdcube-agent:<app>:<agent>), revocable per resource in Connection Hub's Delegated by KDCube tab. A missing agent grant raises its own one-click consent card at the attempt, before the provider's account claim is even asked — and it stays that precise past the first grant: a call into a namespace outside the granted set asks with exactly the missing claims, and the approval advances the agent's current delegated card. Two independent consents remain. Editing or revoking either changes the next invocation; work already admitted may complete.

Related documentation

KDCube Journal · Entry № 12 · 10.07.2026