Integrations
Think of the RAS as a socket adapter: it does not care which appliance is plugged in, as long as the connection shape is compatible.
Re in Act is runtime-agnostic. The RAS works with any tool action layer — as long as it can expose reason() and optionally act().
That matters because Re in Act is not tied to one vendor or one orchestration stack. The core idea is to strengthen the action phase, whatever runtime happens to host it.
For optional interfaces layered on top of the core runtime contract, see Re in Act Extensions.
LLM APIs
One useful reference design here is Anthropic's Programmatic tool calling. In that model, Claude writes code inside a code-execution container, calls tools from the running program, pauses on tool_use, resumes when the host returns tool_result, and keeps intermediate processing out of the model's top-level context window until the final output is ready.
That is close to the Re in Act intuition: loops, filtering, branching, and local tool coordination should happen inside the action space, not through repeated outer-loop model turns.
Re in Act is broader than that specific product feature. The spec does not require Anthropic-managed code execution or Anthropic's response protocol. reason() can be backed by any LLM API that supports structured output and fresh local inference calls, while act() can be wired to MCP tools, custom functions, or runtime-native actions.
Recommended models for reason() calls: lightweight, fast models. reason() is an atomic local decision step, not a full top-level reasoning pass — it does not need frontier-scale capability.
Bash / CLI
The Bash RAS runs reason and act as CLI commands in PATH. This makes it easy to integrate with any shell environment, CI pipeline, or existing scripting workflow:
cat input.json | reason --prompt "Summarize:" --prompt - --structure '{"summary": ""}' | jq -r '.data.summary'
No SDK or language runtime required.
Code Runtimes
The Code RAS runs inside a sandboxed Python or Node.js process. Integration points:
| Runtime | How reason() / act() are provided |
|---|---|
| Python | Injected as async functions into the script scope |
| TypeScript | Injected as async functions into the module scope |
| Bash | Registered as CLI commands in PATH |
The runtime executes the delegated program and returns a single final observation to the outer loop. This is the integration-level expression of the same idea used throughout the docs: keep local work local, and only return what matters.
Sandboxing For Bash And Code
Sandboxing is a common operational requirement for both Bash RAS and Code RAS in production. The issue is not the surface syntax. The issue is that the RAS executes real actions against real environments.
Two supported strategies:
-
Cloud Sandbox — the RAS runs in a managed cloud environment. Providers purpose-built for agent code execution:
- E2B — cloud sandboxes with Python/JS SDKs, popular for AI agent use cases
- Deno Sandbox — instant Linux microVMs with TypeScript + Python SDKs, built-in prompt injection protection
- Modal — serverless container execution, commonly used with LangChain agents
- Daytona — dev environment sandboxes for agents
- Sprites — agent-focused sandbox runtime
-
Client-side Sandbox — the RAS runs locally or in a self-hosted environment (Docker, WASM, Cloudflare Workers).
The sandboxing strategy does not affect the reason() / act() interface contract.
MCP (Model Context Protocol)
MCP is the recommended integration layer for tool discovery and execution. The RAS can act as an MCP Server or consume tools exposed by an MCP host.
Using MCP tools via act()
Any MCP tool can be called through act():
# List available tools
tools = await act("__manual__", {})
# Call a specific MCP tool
result = await act("websearch", {"query": "Re in Act spec"})
MCP Sampling for reason()
reason() can be implemented via MCP Sampling — the RAS acts as an MCP Server and requests LLM completion from the MCP client. This offloads model invocation to the host application, with no direct API key required inside the RAS.
RAS (MCP Server) → sampling/createMessage → MCP Client → LLM
See the one-agent reference implementation for a working MCP Sampling integration.
ACP (Agent Client Protocol)
For agent()-style delegated execution, ACP is a recommended integration layer. For the Re in Act contract itself, see Agent Interface Extension.
- Get started: Agent Client Protocol — Agents
- Useful when you want to connect multiple agent runtimes behind one integration shape
- Common targets include Claude Code, Codex, and OpenCode
In practical terms:
- use MCP for tools inside the RAS
- use ACP for agent runtimes
These are complementary layers, not competing standards.