Agents

An agent is a named, deployable unit: a system prompt (its instructions) plus the set of tools it is allowed to use. Agents are how you package a specific job so it can be run consistently from several places.

What an agent is made of

An agents row holds:

• a name,
• instructions (its system prompt),
• tool_ids - the tools it may call, and
• collection_ids - the collections it has access to.

The Agents page is the dashboard for creating and editing them. When selecting tools in the agent editor, you can use "Select all" or "Clear all" buttons to quickly manage the full toolset. Agents are visible across the workspace.

Running an agent

The same agent can run in three contexts:

• From chat. Opening /chat?agent=:id layers the agent's prompt onto the conversation and scopes the available tools to just the agent's tools.
• From a webhook. A webhook can target an agent, so an incoming payload is run through the agent's prompt and tools instead of a bare prompt. See Webhooks.
• On a schedule. A schedules row pairs an agent with an interval and an optional input. A scheduler edge function, ticked once a minute by pg_cron, runs due schedules. Each run uses the agent's own instructions; the optional input can add extra direction for that specific run. You manage schedules inside the agent editor.

Collections bound to an agent

When you bind collections to an agent, their contents — artifacts, files, to-dos, links, tables, and even other agents — are injected as primary context whenever the agent runs. This happens in all three contexts: chat, webhooks, and schedules. The user's manually picked collections (if any) are merged with the agent's bound collections.

This is how you give an agent a persistent knowledge set. For example, an agent that processes incoming tickets can be bound to a collection of templates and guidelines it should follow every time it runs.

Filing agents into collections

Agents can themselves be filed into collections just like artifacts, files, to-dos, links, and tables. You can organize related agents on the Agents page by multi-selecting them and clicking Add to collection, or add them one at a time from a collection's dashboard. This lets you keep specialized agents grouped by project, workflow, or purpose, making it easy to discover which agents are available and give the assistant a directory of capabilities.

Why scope tools per agent

Restricting an agent to specific tools is both a safety and a quality measure. A focused agent with three relevant tools behaves more predictably than one with access to everything. And when an agent runs from an untrusted trigger like a webhook, a tight toolset limits what a bad input could cause it to do.

The shared execution path

All three loops (chat, webhook, scheduler) execute built-in tools through one shared module, so a capability like "search the knowledge base" or "send email" behaves identically whether you are chatting live or an agent is running at 6am. That is what makes "the morning agent emails me a summary" reliable - it is the same machinery as chat, just triggered differently.

This also means agents can author content: create artifacts, organize them into collections, and add notes to your workspace knowledge base. A scheduled agent can, for example, fetch articles every morning and file them into a collection your team can chat with.