Mental Model

#Purpose

Opal has a lot of parts — spaces, threads, tasks, flows, agents, models, skills, connectors, tools, widgets, guardrails, knowledge, templates, the Marketplace, your organization. Learned one at a time, they can feel like a long feature list. They are not. They are the pieces of one operating model, and each one exists because of its relationship to the others.

This page draws those relationships. It does not re-explain what each concept is — Opal at a Glance tours them, and the pages in this section document each one in full. What this page adds is the shape they form together: which pieces contain which, what depends on what, where the work enters and where it comes out, and what surrounds all of it.

That is worth ten minutes because it changes how you use the platform. Opal is an agentic operations platform: it coordinates people, agents, knowledge, systems, and processes toward shared objectives instead of adding one more assistant to one more person's screen. Once the model is in your head, you stop asking "which feature do I use?" and start asking "where does this piece of work belong?" — which is a much easier question, and usually has one obvious answer.

It is written for readers who have finished Getting Started. No administrative knowledge is assumed, and nothing here requires you to be able to configure the platform yourself.

#In This Section

The Core Concepts section is grouped into six subsections, and each one covers a different part of the model described on this page:

• Getting Work Done — Spaces as the environment work happens in, and threads, tasks, and flows as the three ways it gets done inside them. Getting Work Done
• Managing Knowledge — Opal's centralized knowledge base, and how the same reviewed content grounds both people's decisions and agents' work. Managing Knowledge
• Building Agents — Agents as digital workers, and the building blocks each one is assembled from: models, skills, connectors, tools, widgets, and guardrails. Building Agents
• Templates — Reusable, pre-configured starting points for creating agents, tasks, and flows, so a proven setup becomes the standard. Templates
• Marketplace — How resources built in one organization are published, discovered, and adopted by another, for a price or for free. Marketplace
• Organization — Your company's single tenant on Opal: its members, teams, roles, security, billing, credits, org-wide configuration, and governance. Organization

#Key Concepts

The model in one sentence. Inside your organization, a space brings people, agents, knowledge, and capabilities together; work is then carried out in that space as a thread, a task, or a flow; templates and the Marketplace mean you rarely start from nothing; and governance keeps all of it permissioned, versioned, and traceable.

Five layers, and what each one contributes. Opal's concepts group into five layers. Four of them stack; the fifth runs through all of them.

Read the first four downwards and you get the assembly order: equip the workers, gather the material, put both in a space, then run the work. Read governance across them and you get the reason a digital workforce can be trusted at all.

Everything happens inside one organization. Your organization is a single tenant on Opal — the top-level container holding its members, teams, roles, resources, and organization-wide settings. Nothing on this page sits outside it. That is why organization-level decisions have such long reach: a role, a verified email domain, a resource tag, or a credit balance applies to everyone and everything inside the boundary.

The space is where the pieces meet. A space is the operational environment where people and agents come together to do work, bringing the agents, knowledge, capabilities, and work of a team, project, or initiative into one organized context. It is the join in the model: agents are put to work by being added into a space; knowledge becomes usable by agents when files and folders are added to a space; skills, connectors, tools, widgets, and guardrails added at the space level are available to every agent and every piece of work in it; and people take part at the permission level they hold there — Manage, Access, or View. Configure something once at this level and it carries through consistently, instead of being set up again on each agent.

People and agents are the only things that act. Everything else in the model is context or constraint. An agent is a digital worker assembled from a prompt, a model, capabilities, and guardrails; it collaborates in threads, executes or reviews tasks, and executes or reviews flow steps, working from the instructions given for that assignment. People do the same work in the places where judgment belongs — directing a thread, being the assignee on a flow step, or reviewing an agent's output before it is accepted. This is the human-and-digital workforce in practice: people keep leadership, judgment, and governance; agents add capacity for analysis, coordination, and execution.

Capabilities are attached; knowledge is reached. These two look similar and behave differently, and mixing them up is the most common way the model goes wrong in someone's head. Skills, connectors, tools, widgets, and guardrails are attached — created once in their own section, then attached where the work happens: to an agent, and in most cases to a space, a task, or a flow as well. Nothing takes effect until it is. Knowledge is not attached to an agent at all: you add files and folders to a space, and the agents working there retrieve what they need as grounding context while the work happens. Skills supply the method; knowledge supplies the material.

The three ways of working differ only in who is steering. A thread is directed by you, live, in conversation. A task is started by its trigger — manual, recurring, scheduled, or an incoming webhook from another system — and run by its agent without you in the room. A flow is directed by the process itself: sequential steps, each with an assignee and instructions, and optional review wherever the work needs checking. What does not change between them is the context: all three run inside a space, are carried out by its agents, and draw on its knowledge and capabilities.

Oversight is layered, and sized to the work. No single control carries the whole load. Guardrails check what reaches an agent and what it returns. Reviewers — an agent, a person, or both — check the output of a task or any step in a flow before it is accepted. The Run Log records every execution of a task or flow, so work that ran without you watching is still work you can trace. Version history and activity logs record what changed in a resource and who changed it, with the organization-wide view in the audit log. Whether a given action is available to you at all is decided by three gates — your organization's plan, your role permissions, and your permissions on the individual resource. The model itself is documented once, on Access & Permissions.

Proven work becomes a starting point. This is what makes the model compound rather than repeat. A configuration that works can be captured as an agent, task, or flow template, with {{ placeholders }} marking the details that change from one use to the next — so the next person starts from a blueprint and fills in a few guided fields. Anything created from a template stays linked to it and never changes underneath you: when the template improves, each owner chooses when to sync. Beyond your organization, the Marketplace extends the same idea outwards, so a resource proven in one organization can be adopted by another instead of rebuilt.

Each run can leave the model better than it found it. The loop closes in three places. Tasks and flows can use Continuous Learning to capture lessons from successful runs. A flow run that meets changed requirements can be reset and re-run with the new context, and Opal reworks only the steps the change affects. And agents can create and edit knowledge documents themselves, under the same review and publishing controls as anyone else — so the material the next run is grounded in is more current than the material this one started with.

One piece of work, all the way through. Abstract models are easy to nod along to and hard to use. Here is a single real piece of work — a customer success team's quarterly renewal reviews — moving through every layer.

1. The organization sets the boundary. Before any of this, an administrator has set the company up on Opal: members invited, teams created to mirror departments, roles assigned so each team has the access its work calls for, security aligned with company standards, and credits funded so usage does not stall. Nothing the team does later steps outside that boundary.
2. Someone builds the worker. An agent builder creates an Account Analyst agent: a prompt describing how to assess an account, a model config suited to the work, a connector to the team's CRM so it can pull live account data, a skill capturing the team's renewal-assessment method, and an output guardrail that masks sensitive customer data before anything is returned.
3. The team builds the material. In Knowledge, the team uploads its renewal criteria playbook, digitizes a set of scanned contracts into markdown with OCR, and transcribes a recorded customer discovery call. Each document is edited in a draft and published as a version, so the agent and the team are working from reviewed content rather than someone's latest local copy.
4. A space brings them together. The team creates a Renewals space. In go the Account Analyst agent, the knowledge folder, and — at the space level — the CRM connector and the masking guardrail, so every agent and every piece of work in the space inherits the same integration and the same safeguard. People are invited at the permission level their role calls for: leads with Manage, specialists with Access, stakeholders with View.
5. The work happens in three shapes. The lead opens a thread to think the quarter through, adding two agents and tagging them in the order she wants them to answer. She sets up a recurring task that has the Account Analyst compile account health summaries every Monday, with a second agent as reviewer and herself as user reviewer, so she only looks when something needs her. And she builds a flow for the review itself: steps assigned to agents to gather data and draft recommendations, a step assigned to the account owner to approve the recommendation before it goes to the customer, and flow-level context stating the objective so every step works toward the same outcome.
6. Something changes mid-run. Pricing is revised halfway through the quarter. Rather than rebuilding, she resets the current flow run and re-runs it with the new pricing as additional context. Opal reviews the work already completed at each step and reworks only the steps the change affects, skipping the ones it does not.
7. The trail is already there. Nobody has to assemble an audit afterwards. The Run Log holds every execution of the task and the flow, the guardrail has masked customer data on the way out, each knowledge document carries its version history and activity log, and organization-wide activity is in the audit log.
8. The second quarter costs a fraction of the first. The flow is saved as a flow template, with placeholders for the region and the customer segment. Two other teams create their own flows from it and fill in their own values. When the template improves, each team syncs when it suits them. Because the skill behind it turned out to be broadly useful, the organization could also list it on the Marketplace for other organizations to adopt.
9. And the model is better than it was. Continuous Learning has captured what the successful runs taught. The Account Analyst has drafted an updated version of the renewal playbook, which a team member reviewed and published. Next quarter starts from better material, a proven blueprint, and a process that has already absorbed one change without breaking.

That is the whole operating model, and it is the same shape whatever the work is. Substitute a marketing launch, a hiring process, or a monthly compliance check, and the pieces line up in the same order — which is exactly why learning it once pays off across everything you do next.

Short definitions of every term used here are in one place: Glossary.

#Where to Start

Start with Getting Work Done. Spaces, threads, tasks, and flows are the layer you touch first and use most, and everything else in the model exists to serve work that runs there.

From there, follow the assembly order the model implies, or jump to whichever layer your role sits in:

• To ground the work in your organization's own information — Managing Knowledge.
• To build and equip the agents that do the work — Building Agents.
• To stop rebuilding what already works — Templates, then Marketplace for what other organizations have already built.
• To set up, secure, fund, and govern the whole environment — Organization.

For the full contents of this section, see Core Concepts. If a term on this page is unfamiliar, look it up in the Glossary.