Building agents
Tools and capabilities
The tools an agent can call, how each is sandboxed or protected, and how approval gates work.
3 min read
An agent's capabilities come from the tools it can call. Each tool is sandboxed or protected in a way specific to what it does, and any tool that performs a consequential or destructive action can be placed behind a human approval gate.
code_execution
Agents can run code as part of a step, in one of two sandboxed runtimes depending on the language:
- JavaScript runs inside a QuickJS WASM isolate: no host filesystem, no network access, no process access. It's capped at 64MB of memory and a 5-second hard timeout, after which execution is forcibly interrupted.
- Python runs via Pyodide (CPython compiled to WASM) inside a worker thread. The JS FFI bridge is stripped out of that worker, so code that tries
import jsfails rather than reaching back into the host environment.
Both runtimes let an agent do real computation — parsing, transforming, calculating — without any risk of touching the underlying host.
api_call
Agents can make outbound HTTP calls to external services. These calls are protected against SSRF: connections are pinned to a pre-validated public IP address before the request is made, and private, loopback, link-local, and cloud-metadata addresses are blocked. This closes off DNS-rebinding attacks where a hostname resolves to something safe at validation time and something internal at request time.
knowledge_search
Agents can search a knowledge base you've uploaded. Results come back with citations pointing to the source material, so answers grounded in your documents can be traced back to where they came from.
connector_action
Agents can call out to a connected third-party service — a CRM, a messaging app, a ticketing system, and so on — through a connector you've set up. See connectors for how connectors are configured and authenticated.
mcp tools
Agents can call tools exposed by Model Context Protocol servers, giving them access to capabilities from any MCP-compatible integration without RunAIAgents needing to build a first-party connector for it.
Subagent delegation
An agent can delegate a sub-task to a specialized subagent rather than handling everything itself. This keeps individual agents focused and lets you compose more complex behavior out of smaller, purpose-built pieces.
The approval gate
Any tool call that's destructive or consequential — sending an email, executing a payment, deleting a record, and similar actions — can be placed behind an approval gate. When the agentic loop reaches a gated step, the run halts before executing it and asks a human to approve or reject the action. Nothing destructive happens silently: the agent proposes the action, a person decides, and only then does execution continue.
This matters because an agentic loop is, by design, choosing its own next steps. Approval gates are the control point that keeps a human in charge of anything that can't be undone, without slowing down the steps that carry no such risk.
How it fits together
During a run, the agentic loop picks which of these tools to call, validates the arguments against a schema before executing, and feeds validation errors back to the model rather than crashing. See guardrails for the additional layer of allow/deny lists, output redaction, and prompt-injection defenses that sit around all of this.
Still stuck? We're happy to help.
Contact support