The object model

Everything in Controller AI is built from a small set of objects. This page is the map; each object links to the page that owns it.

The three building blocks

Object	What it is	When to use it
Agent	A conversational operator with instructions, knowledge files, and attached tools.	The request is flexible; the allowed actions need guardrails.
Integration action	One ready operation from a connected app, attached directly to an agent.	A single existing app operation completes the capability.
Workflow	A no-code process: triggers, flows, nodes, typed data, versions, execution history.	The capability needs steps, transformations, branching, loops, durable data, triggers, or a reusable typed contract.

Agents decide when things happen; actions and workflows define what is allowed to happen. An agent can hold both kinds of tool. A workflow can also exist standalone with no agent — triggered, scheduled, or called via the API.

Inside a workflow

Workflow
├── Flows            function-like units: typed inputs → node graph → optional typed output
│   └── Nodes        one executable step each, connected by edges
├── Triggers         entry points that start a flow on an outside event
├── Data types       custom schemas used across the workflow
├── Data store       records of those types (separate dev and live stores)
└── Versions         the editable development version + published live releases

Flows are the unit of execution and reuse. A flow declares typed inputs, contains a directed graph of nodes, and can return typed values with a Return response node. Use multiple flows when logic should be reused, called by an agent, run per-item over a list, or tested separately.

Nodes are single steps. Broad families:

• Flow control — If/Else, Router, Join paths, Wait, Set value, Return response, and the Run flow family (call a flow, run one per list item, run from a trigger).
• AI — structured-output calls to AI providers.
• HTTP — direct API requests.
• Data — create, query, update (single or batch), and delete records in the workflow’s data store.
• File — create runtime files.
• Agent — operate on agent conversations and files from inside a workflow.
• Integration nodes — thousands of catalog operations for connected apps, searched by app and action.

Edges express dependency: the downstream node waits for the upstream node’s result. The graph is acyclic — repetition is expressed by running a flow per list item, not by looping edges back.

Triggers connect outside events to flows. Three natives (Webhook, Scheduled, Email) plus app-event triggers from the integration catalog — new row in a sheet, new lead in a CRM, new message in a channel. A trigger is two things composed: an event source and its mapping into a flow. See Triggers.

Data types and records give workflows durable, schema-validated state. The type (custom.lead) describes a shape; a record (dataRecord.custom.lead) is a stored row with identity. The distinction has teeth — see Type system.

Inside an agent

Agent
├── Draft            the one mutable copy you edit and test
├── Published versions  immutable snapshots; Live runs the latest
├── Tools            integration actions + workflow tools, each with an approval policy
├── Knowledge files  reference documents frozen into each published version
└── Conversations    Test (uses draft) or Live (uses latest version), each with its own files

An agent’s tools carry per-tool policy: whether a call needs human approval (requiresConfirmation), and for workflow tools, which release to follow (latest or pinned). Knowledge files belong to the agent and freeze at publish; conversation files belong to one conversation. See Building an agent.

Two version rails

Workflows and agents each have a development/production split, and they compose — an agent Test conversation runs attached workflows’ development heads, a Live conversation runs their live releases. The rails, what runs where, and what bypasses the publish gate: Versions and rails.

Ownership and sharing

Everything above belongs to your account within an organization. Agents can be published and shared to the organization — teammates always get the latest published version, never the draft, and usage draws from the organization’s shared pool. Workflows and connections stay owner-scoped; a shared agent’s integration actions run on the owner’s connections. See Sharing with your organization.