Skip to main content
Most plays in a Motion are agents: AI workers with a goal written like a runbook, a scoped set of tools, and explicit rules about which actions need a human’s OK. This page covers where reusable agents live, how they move from one Motion into the shared catalog, and how their autonomy actually works.

​
The Agent Templates catalog

Agents in the sidebar (/home/agents) is your org’s library of reusable agent capabilities — the place to find the right agent to drop into a Motion slot, or to clone as a starting point. It is a library, not an audit view: what’s running on which account lives on the account and in the Inbox, not here.
The catalog is visible to org admins only.
The catalog holds two populations — agents built by Thread (ready-made templates) and agents built by your org. You can group the list by what each agent does (the default) or by lifecycle phase, and filter by source, by which integrations an agent touches, by tags, and by how it wakes (on a schedule vs on a signal). Views you use often can be saved. Every agent presents the same compact contract, on its card and in full in its detail view:

​
Save, publish, promote

When you create an agent from inside a Motion (the ”+ Create a new agent” tile in a stage slot), you choose its scope at save time:
  • Save to this motion — the agent lives in this Motion only and stays out of the catalog. Right for one-off, motion-specific work.
  • Save and publish — the agent is also added to Agent Templates, so you can reuse it across Motions.
As the editor puts it: Save to this motion keeps this agent here only. Save and publish also adds it to Agent Templates so you can reuse it across motions. A motion-scoped agent isn’t stuck. Open it from its slot in the Motion editor and Promote it to the catalog whenever it proves itself. Promotion only changes visibility — the Motion’s binding to the agent is untouched, and everything already running keeps running. Agents generated by Build your Motion start motion-scoped too, and follow the same promote path. Agents created from the catalog’s own front door are published to the catalog directly.

​
Per-action autonomy

Autonomy in Thread is per action — there are no autonomy tiers or blanket modes. Every state-changing action an agent can take (send an email, create a calendar event, write to a connected system) has its own switch in the agent’s Approvals section:
  • Needs approval — the agent pauses before this action and waits for a human decision.
  • Autonomous — the action runs without an approval pause. Thread’s safety checks still apply.
“Set all autonomous” / “Set all approval” bulk buttons cover the common cases; read-only actions never need approval. For a custom agent, the switches apply to that agent in every Motion; for a Thread-built template, you can override the approvals per Motion. Some Thread templates lock certain gates by design — fork the template to a custom agent to change those. You’ll see the same distinction in the Inbox, on every agent-produced item:
  • Needs your OK — a pending approval. Review the draft (edits included — what you approve is what sends) and decide in place.
  • Already sent — the agent acted autonomously; the row is the record of what went out.
Autonomy switches only ever govern the pause-for-approval step. Thread’s runtime safety layer — grounding checks, injection defense, and sandboxing during rehearsal — applies to every action at every setting. And an agent asking to pull a human in is never itself gated: escalation to a human is always allowed.

​
Approvals from outside Thread

Sometimes the right approver doesn’t work in Thread — an AE, an executive sponsor, a teammate who lives in Slack. An agent can route a specific upcoming approval to them: it names a kind of recipient (the account’s assigned CSM, the assigned AE, or a named member of your org — never an arbitrary address; Thread resolves the actual person server-side), and when the approval materializes, that person receives a tokenized, no-login /approve link by email or as a Slack DM. The link is protected by a one-time code and scoped to that single decision. See External approvals for how recipients experience it and how pending items are tracked.

​
What agents produce

Agents don’t just message — they create real artifacts:
  • Documents — agents write real Markdown documents, including directly into Google Docs on the assigned owner’s Drive, and generate branded documents and decks through Studio.
  • Emails — drafted (and, where approved autonomous, sent) through the same template, prompt-slot, and audit machinery described in Email plays.
  • Calendar events, CRM updates, Slack posts — via your connected integrations, each gated by its own approval switch.
Everything an agent produces is attributable: the artifact, the run that made it, and the approval (or the autonomous-action record) that let it happen.