Building Agents
An agent is a digital worker in Opal that works alongside people — in conversations, tasks, and flows.
Building and configuring agents — and the models, skills, connectors, tools, widgets, and guardrails they are assembled from — depends on your organization's plan, the role permissions you have been granted, and the permissions set on each individual resource. The access model is documented in one place: Access & Permissions.
Purpose
An agent is a digital worker in Opal: it takes part in conversations, executes and reviews tasks and flow steps, works from your organization's knowledge, and acts in the systems your team already uses.
What makes an agent more than a chat window is that it is assembled. A prompt defines its role. A model powers its reasoning. Skills, connectors, tools, and widgets give it capabilities. Guardrails set the boundaries it works within. Each of those pieces is built once and reused, so you are not rebuilding a good agent every time you need another one.
This subsection introduces the building blocks for creating and configuring agents. It is written for anyone arriving here for the first time — operations teams, agent builders, subject-matter experts, administrators, and team leads. No technical expertise is assumed; where a piece does need a developer's help, the page for that piece says so plainly.
This page is the map. It introduces each building block, says which page covers it, and tells you where to start.
In This Section
- Agents — What an agent is, the six steps that turn a blank configuration into a working digital worker, and how agents collaborate in threads, run tasks, and execute or review flow steps. Agents
- Models — The models catalog of language models from leading providers, how to compare them on capability, modality, and cost in Opal credits, and how a model config saves a model and its parameters as a reusable preset. Models
- Skills — Packaged expertise that tells an agent how to perform a kind of work: a primary skill document plus its reference documents, attached to agents, spaces, tasks, flows, and templates. Skills
- Connectors — Secure links to external systems built on the Model Context Protocol, where an administrator defines an MCP Server once and each person creates their own MCP Connection carrying their own permissions. Connectors
- Tools — Single callable actions created from reusable tool definitions, for calling a service over HTTP where no connector exists. Tools
- Widgets — Interactive interface elements an agent embeds in a thread message to present structured output and collect structured input, built from a component library or generated with AI Assist. Widgets
- Guardrails — Safeguards that check what reaches an agent and what it returns, using keyword, regex, or semantic detection, and redact, mask, hash, or block whatever they flag. Guardrails
Key Concepts
The agent is the whole; everything else is a part. An agent packages a prompt, a model, a set of capabilities, and its guardrails into one specialized worker. The other six pages in this subsection each go deep on one of those parts.
Each part answers a different question.
| Building block | The question it answers |
|---|---|
| Model | How well does the agent reason, what can it read, and what does each interaction cost? |
| Skill | How should this kind of work be done? |
| Connector | Which external systems can the agent reach and act in? |
| Tool | Which single, specific actions can the agent call? |
| Widget | How is the work presented to people, and how is input gathered back? |
| Guardrail | What content is allowed in, and what is allowed out? |
Nothing takes effect until it is attached. Skills, connectors, tools, widgets, and guardrails are all created in their own section of the platform and then attached where the work happens — to an agent, and in most cases to a space, a task, or a flow as well. Where every agent on a team needs the same capability, attaching it once at the space level beats repeating it on each agent.
Then the agent decides when to use it. You are equipping an agent, not scripting it. It judges when a skill applies, when a tool call is the right move, or when a widget is a better answer than a paragraph — and reaches for it as the work requires.
Specialize, then combine. A narrow, well-briefed agent tends to outperform a broad one, and specialized agents work well together — including the executor–reviewer pattern, where one agent does the work and another checks it before the output is accepted.
Reuse is the point. A model config, a skill, a tool definition, a widget, a guardrail — each is defined once and applied in many places, and templates carry a proven combination of them into every new agent, task, or flow created from it. See Templates.
Knowledge is not part of the agent's configuration. Add files and folders to a space, and the agents working there retrieve what they need as they work. See Managing Knowledge.
Short definitions of every term used here are in one place: Glossary.
Where to Start
Start with Agents. It shows the whole picture in one read — what an agent is, the order you assemble one in, and how it is put to work — and every other page in this subsection is detail underneath a step in it.
From there, go where your task takes you:
- To choose the intelligence behind an agent, or to standardize that choice for your team — Models.
- To capture your team's method so agents follow it every time — Skills.
- To let an agent work in the systems you already run — Connectors first, then Tools for actions no connector covers.
- To turn an agent's replies into something people can read at a glance and act on in place — Widgets.
- To keep agents inside your safety and compliance boundaries — Guardrails.
Reading the pages in order works well if agent building is new to you; each one also stands on its own if you have arrived with a specific job to do.
If your next question is where these agents actually do their work, read Getting Work Done, which covers spaces, threads, tasks, and flows.