How Rightbrain works

Rightbrain has one top-level unit, the agent, and a small set of primitives you make available to it. Once you have that model, everything else, from a single API call to a scheduled production workflow, is the same shape.

An agent, and what you make available to it

An agent is a goal-directed reasoner on the model of your choice. It works with nothing attached — an instruction and a model are enough to run it. The leverage comes from making primitives available to it: at run time the agent decides which to use, picking a task for a specialized operation, drawing on a skill for how to approach a piece of work, reaching an external system through a connection.

• Tasks are structured AI functions the agent can call when it needs a specialized, reliable operation with typed output. One task tool can be the agent’s output formatter, terminating the run with structured output.
• Skills are reusable, versioned abilities the agent draws on to shape focused work. A skill can carry a capabilities contract that declares the connections it needs, and Rightbrain provisions those alongside it automatically.
• Connections give external reach, through native integrations (HubSpot, Salesforce, Slack, Google Sheets, Gmail) and MCP servers. Connections aren’t agent-only: a task can carry an integration or MCP tool and call the external service as part of its own run.
• Collections are the knowledge layer. An agent does not attach a collection directly; a task retrieves from a collection through its RAG configuration, and the agent calls that task.

Every primitive is created, managed, and versioned independently of the agents that use it. That separation is the point: improve a task and every agent following its active revision picks it up; roll a skill back without touching any agent; share one connection across a whole fleet.

Start with a task, promote to an agent

Not everything needs to be an agent. When the job is extremely well-defined and you need structured output reliably, a task alone is the right call — a task is, in effect, a deterministic agent: one thing, done very well, run after run. Each task also carries its own model — so an agent delegating to a task is one model handing a subtask to another, each chosen for its job. Promote to an agent when execution becomes conditional, multi-step, or conversational, and then decide whether that agent reaches outward through an integration or an MCP server. A task is one LLM call with a fixed shape; an agent may make several as it reasons, so reach for the agent only when the extra latency and cost buy you something.

A trigger starts a run

A run is a single execution of an agent (or a standalone task). Every run follows the same arc, whatever starts it.

Runs stream and get observed

Agent runs stream over Server-Sent Events, so your application sees the work as it happens rather than waiting for a single blocking response: each tool call and result arrives as an event, incremental text streams in, and a terminal event closes the run. The full event reference is in Run agents via API.

A run moves through the statuses running, waiting_for_human (paused for an approval), completed, and failed. Every run is recorded, so you can inspect it afterward in Logs and on the agent’s Observe page: telemetry, timing, credits, the trigger that started it, and the specific reason for any failure.

Predictable by design

Operational integrity means knowing what an agent will return and how it will get there.

• Typed outputs. Every task enforces a response schema, so you get the same shape on run one and run ten thousand, parseable by your systems with no drift.
• Execution order. An agent runs in one of two modes. In agentic mode the model decides which tools to call and when, for open-ended work. In sequential mode the steps run in a fixed order you define, with no improvisation, for pipelines that must be repeatable.

You also choose the model each task runs on, frontier or open-source, and can give it a fallback model that takes over mid-run if the primary fails.

Revisions let you change safely

Agents and tasks are both revisioned. Each revision is an immutable snapshot: for an agent, it captures the exact wiring of every tool; for a task, the prompt, model, and output schema. Exactly one revision is active at a time.

• Roll back by repointing the active revision to a previous one.
• A/B test a task by giving two revisions weighted shares of traffic.
• Pin or follow for task tools: an agent’s task tool can pin a specific task revision, or follow whatever revision the task itself has active.

Where to go next