The ReAct Agent's Code Can Use Your Services
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.
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.
- 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.
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.
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 merges into the agent's record.
Two raw consents, two revocations, either one stops the tool.