Automations
An automation is the agent you already use in a conversation, started a different way. A schedule starts it at set times. An event in a connected app starts it when something happens there.
The agent keeps its instructions, skills, tools, and files. What changes is who sends the first message: the automation sends it, on every run.
A schedule can start a familiar job
Suppose the marketing launch agent prepares a campaign report with you every Monday. It reads the latest analytics, explains what changed, and posts a short summary to the team channel.
Once the report follows a stable pattern, you can schedule it for Monday morning. The automation sends the same message on each run, for example:
Summarize last week's Team Workspaces campaign. Compare results with the previous week, explain the two largest changes, and post the report to the launch channel.
An app event can start work when something changes
Some jobs should begin when something happens rather than at a set time.
The launch agent could start when a row is added to the launch tracker, or when a review issue gets a particular label. Agenta starts the run when the event arrives, so the agent does not need to check for changes on a timer.
The agent receives the message written in the automation, followed by the event's data: what the app sent about the change, such as the new row or the issue. The message tells the agent what to do with it. For example: "Draft the announcement for this new row in the launch tracker." An automation can also be set to send the message alone, without the event's data.
An unattended run needs a complete starting point
In a chat, the agent can ask what you meant by "the campaign," which date range to use, or where to put the result. An automation has no one to answer, so those choices have to be made before it runs.
Three places hold them:
- The agent's instructions hold the facts and rules that apply to all of its work.
- The automation's message describes this one recurring job: the task, where to find the information, and where to put the result.
- The agent's files and skills hold the reference material and the steps for tasks it repeats.
For the Monday report, the instructions describe the company and the audience, a reporting skill describes the analysis, and the automation's message names the campaign, the comparison period, and the channel.
The result needs a destination
In the playground, the answer appears in front of you. An automated run has no one watching, so it has to leave its result where your team will see it.
That destination might be a channel, an email, a document, a task, or a row in a sheet. Give the agent the tool for it and name the destination in the automation's message. Say in the message what the agent should do if it cannot deliver, for example "if posting fails, save the report to your files."
If later runs need the result, have the agent also save a copy in its files. Next Monday's report can then compare itself with this one.
An automation runs as whoever last saved it
Each run has the access of the user or API key that created the automation or last saved a change to it. When someone else saves a change, even a new name, the automation runs as them from then on. Pausing, resuming and deleting an automation do not change who it runs as. If that user leaves the project or loses the role, or the key is deleted, the next run is refused and the automation is paused. Its run history says why. To run it again, save it under an active user or API key, then resume it. Archiving the agent also pauses its automations, and unarchiving it does not start them again.
Every run is kept
Each run is recorded with the full conversation the agent had, so you can read what it did and why. A run that failed shows the error. You find them in the automation's run history.