Skip to content

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 js fails 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
Tools and capabilities · RunAIAgents · RunAIAgents