Agents

What an agent is

An agent bundles a System Prompt (its role), a model, the tools and resources it is allowed to use (tables, workflows, interfaces, sub-agents, applications, files, skills), its limits, and the ways it can be started (chat, webhook, schedule, chat widget). Each time it is started it runs a tool-calling loop: read the request, pick a tool, run it, read the result, and repeat until it gives a final answer or hits one of its limits.

The model can be a regular API model or a CLI agent (Claude Code, Codex, Gemini CLI, or Mistral Vibe) that runs through a bridge. Which ones you can pick depends on what your administrator has set up; see Models & providers.

The Agents page

Open Agents in the sidebar. The page has six tabs:

Delegated tasks are not on this page: they live on the task board, under Board > Tasks. See Tasks & board.

Create an agent

You can ask the assistant in the chat to create an agent for you, or use the editor. The editor has three steps:

1. 1
   Basic Info

   Give the agent a name, a description, and a System Prompt that states its role.

2. 2
   Configuration

   Pick the Model Provider and Model Name, the tools and resources it may use, its skills, its Credit Budget, and its limits. Open Advanced mode for temperature, the per-turn loop guards, Generation, Mailbox, and context compaction.

3. 3
   Integration

   Optional ways to start and reach the agent: Reach me outside the app (a chat channel), Webhook, Schedule, and Chat Widget (embed a chat on your website).

How an agent is started

Model & reasoning effort

Model provider and model name are both optional. Leave them empty and the agent uses the platform default model. An unknown provider and model pair is replaced by the default and reported back as model_substituted, so saving does not fail on a model that was removed. Saving an agent on a CLI agent you are not allowed to use is refused.

Temperature goes from 0 to 2 (default 0.7): lower is more predictable, higher more creative.

Reasoning effort is an optional setting with six levels: minimal, low, medium, high, xhigh, max. It is a level, not a token budget. Only three consumers honor it: Claude Code, Codex, and the direct Anthropic API. Every other provider ignores it, and the editor hides it for them. Inherit (model default) leaves the choice to the model’s own default.

When several levels are set, a per-conversation choice wins over the agent’s value, which wins over the default an administrator set for the model.

Limits & timeouts

Four independent limits can stop a run. The editor shows the same defaults the platform applies.

Three more guards, under Advanced mode, stop a runaway agent:

A sub-agent started with executegets a timeout: the value the calling agent passes, otherwise the sub-agent's own execution timeout, otherwise 600 seconds. Whatever the source, it is kept between 10 and 7,200 seconds.

Tools & scope

Integration tools (the catalog of external APIs) are chosen with Available integration tools:

Resource Access is a separate choice. A new agent has no access to your workflows, tables, interfaces, sub-agents, or applications until you grant it, one family at a time: all of them, none, or a custom list. Web Search is the one capability that starts on.

Each family also has a read or write mode. write (the default) allows everything; read allows only reading actions, for example get, list, and query_rows on a table, or get, runs, get_run, and wait_run on a workflow. File Access and Long-term memory have their own read or write mode too.

Two capabilities are off until you turn them on, because they act on the outside world:

An agent that creates or edits another agent can only switch these on for it when it has them itself; otherwise it leaves them off and asks you to enable them.

Permissions: when an agent asks before acting

Some actions are sensitive: running a workflow or a catalog tool, calling a sub-agent, installing an application, sending or deleting an email, resolving a paused approval, putting a workflow live or taking it off, and giving an agent a schedule.

In the chat

In a chat with Orbi (the general assistant, no agent selected), a sensitive action shows a permission card, for example Run this action?, Send this email?, or Put this workflow live?. The action waits on the card: Authorize lets it run and the agent continues in place, Decline stops it. Tick Don't ask again in this conversation to stop being asked for that kind of action in this conversation. If you answer after the agent has stopped waiting, your answer starts its next turn.

A chat with a specific agent does not ask, unless that agent has Ask my permission before a sensitive action turned on (see below).

In runs nobody is watching

By default, an agent started by a schedule, a webhook, or a task runs its actions without asking. To make it ask, open the agent, go to Integration, turn on Reach me outside the app, and turn on Ask my permission before a sensitive action. From then on:

• The request is sent with approve and reject buttons (links to a confirmation page on Microsoft Teams) to the chat channel chosen as the agent’s Destination (the workspace default if you leave it empty). See Chat channels.
• If nobody answers in time, the run ends without doing the action. A later approval authorizes that exact action (same tool, same arguments) for the agent’s next run. It does not approve other actions of the same kind.
• The agent does not send the same request twice while one is waiting. Unanswered requests expire after 24 hours, and the agent may then ask again.
• With no working channel, nothing is sent, and the action is not done. The editor warns you: This agent asks permission before sensitive actions, but has no channel to ask on.

Turning Reach me outside the app off also turns off the permission setting: the agent’s questions are then answered by assumption, and sensitive actions in unattended runs are not done.

Questions the agent asks you

With the ask_user tool, an agent can put one to four multiple-choice questions to you (two to four options each). You can always type your own answer instead of picking one.

Long-term memory

Long-term memory holds durable facts that agents keep between conversations and runs: your preferences, corrections, project decisions, useful references. It is different from conversation history and from skills: a skill says how to do something, a memory says what is true here.

• Each entry has a Title, a one-line Summary, optional Details, and a Type (About the user, Feedback, Project, Reference).
• The summaries of active entries are added to every agent’s context in the workspace, on every run. The details are read only when an agent needs them. An entry marked Always in context (pinned) sends its full details every time, so keep that for rules that must never be missed.
• Memory belongs to the workspace: switch workspace and you see that workspace’s memory. An entry can also be private to one agent (One agent); other agents do not see it, but workspace members still do on the Memory tab.
• Agents save entries as they work. You can add, edit, or delete one on the Memory tab. Deactivate makes agents stop using an entry while keeping it; an agent saving the same fact again does not reactivate it.
• Set an agent’s Long-term memory to Recall only for an agent that should use the workspace facts without changing them.

Context compaction

Compaction replaces the oldest part of a long conversation with a summary so it keeps fitting in the model’s context window. Three settings under Advanced mode control it, and each can inherit the default:

Credit budgets

Credit Budget caps what an agent may spend. Empty means unlimited. Credits are the real metered cost of each model call (priced per model and per token), not a fixed amount per iteration.

An agent that is already over its budget is refused before it starts, on every way of starting it (schedule, webhook, widget, workflow node), and a refused scheduled run does not count toward the schedule’s maximum number of runs.

Budgets cascade. When agent A calls sub-agent B, B’s whole budget is reserved from A and from every agent above A. A parent with a budget of 100 can never let its whole tree spend more than 100. A child that needs 50 credits cannot start under a parent with only 30 free: it stops with BUDGET_EXHAUSTED, scope parent_reservation. When the child finishes, what it really spent is charged up the chain and the rest of the reservation is released.

Reset Mode decides when the count starts again. With Cumulative (the default) it never resets on its own; with Weekly it resets 7 days after the last reset; with Monthly it resets when the calendar month changes (in UTC). Reset Credits in the editor restarts it by hand at any time.

Task delegation

Agents can hand work to other agents, or to a shared backlog, as trackable tasks. You see and manage the same tasks on the task board (Tasks & board).

A task with no assignee goes to the backlog and is always pending. Only agents with Shared backlog participation on (off by default) and a way to wake up are offered backlog tasks and may claim them.

Every task follows the same lifecycle:

pending -> in_progress -> in_review -> completed | failed | cancelled

A finished or rejected task always goes through in_review. With a reviewer_agent_id, that agent reviews it. Without one, you are the reviewer, and the task waits in review until you act (that is expected, not stuck). After max_review_attempts rejections (1 to 20, default 3), the task fails; it is never approved automatically.

For recurring work, recurrence_create makes a cron template that creates a fresh task on each tick, without flooding missed ticks, managed with recurrence_list, recurrence_update, and recurrence_delete. A recurrence without a target agent posts to the backlog.

Guards: at most 5 assign calls per turn and a delegation depth of 5. Calls to sub-agents with execute are capped by Max per-resource / turn (5 by default). A sub-agent sees its last 20 messages by default, plus a list of the tasks in its inbox.

Skills

Skills are reusable instruction sets. An agent can have up to 10. Setting an agent’s skills from the chat replaces its whole list; use skill(action='assign') to add one without replacing the others. Skill access is write (default) or read (get, list, list_folders, help). See Skills.

Built-in tool modules

Besides catalog tools, an agent can use built-in tools, each described to it in one line of its system prompt. A module is present only when the agent has access to it.

When a tool call fails with a 401 or 403, the agent uses the credential tool (actions require, list, variables, set_variable). require shows you a card to connect or reconnect the service, with the missing scopes when the provider named them. set_variable writes a workflow variable that later steps read with {{$vars.name}}.

To wait for a workflow run, workflow(action='wait_run') blocks until the run finishes, for up to 120 seconds by default and 240 at most. On timeout it returns timed_out=true and the run keeps going; the agent calls it again.

Related AI nodes

Guardrail and Classify are AI nodes you place directly in a workflow.

See the Node reference for every parameter and output.

Metrics & inspection

Each agent keeps running totals: executions, tokens, tool calls, successes, failures, total duration, and the time of its last run. The Metrics tab charts them. In the Fleet tab, select an agent to open its recent executions, and select an execution to see its conversation and every tool call with its arguments and result. From the chat, task_get_execution with include_tool_calls=true returns the same tool calls, with secrets redacted.

Troubleshooting: why did my agent stop?

Every run ends with one of ten stop reasons, in three outcomes:

A Success or Partial stop leaves usable output; a Failure does not.

Other common problems

Related pages