Invocations
Choose where a named agent shows up and what can start its work: time, channels, systems, or another agent.
Once a named agent has a job, choose where it should show up like a coworker. It might prepare the report every Monday, answer the team in Slack, receive work by email, or take a specialist handoff from another agent.
An invocation is any way that agent's work starts besides you opening a thread and asking. The invocation supplies the trigger; the named agent brings its identity, instructions, model, tools, and knowledge. The work still happens in a thread.
Invocations are available to named agents
Save the agent first, then add the places and events that may start its work. Each invocation belongs to that agent and uses its configuration. A temporary thread without a named agent cannot have schedules, channels, endpoints, or requests from other agents attached to it.
Four ways a run starts
You start it
A thread. This is where every job begins its life: you watch the agent work, correct it, and refine the process before trusting anything to run alone.
Time starts it
The work starts it
A request in Slack, an email in the inbox, an event from your systems. The work arrives where it already happens, and the run starts there.
Another agent starts it
A named agent hands specialist work to another agent, which runs in its own thread and returns the result to the caller.
What every invocation shares
The subpages cover each doorway in detail. Four rules hold across all of them, and knowing them makes every subpage easier to read.
The thread is the record. Every run lands in one. The invocation decides whether each run gets a fresh thread or accumulates in a continuing one, and that choice shapes what the agent remembers between runs.
Trust is granted per doorway. A run started by outside content begins with less: schedules default to read-only, email addresses take sender allowlists, webhooks want their secret. You loosen each doorway on its own terms, and loosening one never loosens another.
Delivery is not access. Sending a result to Slack never grants the agent Slack write access. Reporting and permission are separate systems everywhere, which is why a read-only run can still deliver its report.
Every invocation has an owner. Runs execute with the context of whoever configured the invocation, and count against their usage. If the owner leaves the workspace, the invocation pauses rather than run as a ghost.
Which invocation fits the job
Schedules
"Every Monday at 7, the report should exist."
Live Mode
"Tell me when something changes."
Slack
"The team should reach it where they already talk."
Telegram
"I want it on my phone."
"People should be able to forward things to it."
Webhooks
"Our systems should trigger it automatically."
MCP server
"My IDE or another AI tool should call it."
Other agents
"Another named agent should hand it specialist work."
Start attended, then automate
The invocations aren't a menu to fill out on day one. Most agents earn them in order:
Shape the job in a thread
Run the work interactively until the output is right more often than not. This is where you find out what the agent needs: sources, format, the standard.
Put it on one trigger
Once the job is stable, give it the one invocation that matches how the work arrives: a schedule if it's calendar-shaped, Slack if the team asks for it, a webhook if a system produces it.
Widen trust as it earns it
Start read-only, watch the runs, then loosen the write level or the sender list once you've seen it succeed enough to trust.
FAQs
Run, stop, and fork a thread
A run is the agent working through your request. It keeps going after you leave, ends when the work is done or when you stop it, and can be forked from any point without losing the original.
Schedules
Put an agent on a recurrence: define the work, control its threads and write access, deliver the result, and review every run.