Automate Tasks
Automation lets the people who use your agent ask it to do a piece of work later, on its own, without opening the conversation again. Kirana Group's operations lead tells Atlas: "Every weekday at 7:30, check the status of project KG-2041 and give me a short summary, but only if it is delayed or on hold." From then on Atlas does exactly that, every weekday morning, in the background.
Nobody has to learn cron expressions, queues or workflow builders. The conversation is the interface; Automation is the persistent execution.
The model in one line
Every automation follows the same four steps:
Trigger → Condition → Task → Action
| Step | Answers | Example from Atlas |
|---|---|---|
| Trigger | When is it evaluated? | Every weekday (Monday to Friday) at 07:30 (Asia/Jakarta) |
| Condition | Should it carry on? (optional) | Project KG-2041's status contains "delayed" or "on hold" |
| Task | What work does the agent do? | Check KG-2041 and summarize its status, progress, budget and current approval stage |
| Action | What happens with the result? | Create a new conversation in Qlar and notify the user |
The task runs in your agent's own context, with its configuration, skills, and data access. It never has more permission than the person who created the automation already has. In the example, Atlas reads the project status with the same get_project_status API it uses in normal chat (see Connect Your API).
Who does what
Two groups of people are involved, in two different places:
| Who | Where | What they do |
|---|---|---|
| Users of your agent | The chat itself, and the Automations page in QA-Web (open the chat sidebar with ☰, then Automations) | Create automations by talking to the agent, then view, edit, pause, resume, run now, view history of, and delete their own. |
| You, the agent's Owner or Contributor | The Automations group in the CMS sidebar | Decide whether users may automate anything and within which limits (Policy), and watch or govern what they created (Monitor). |
You govern; you do not write your users' automations for them. What an automation does stays with the person who asked for it. For Atlas, the operations lead creates her own KG-2041 check, and the Atlas team in the CMS only sets the policy and watches the Monitor.
Where it lives in the CMS
Open your agent's sidebar. Between Channels and Simulation there is an Automations group with two pages:
| Page | What it is for | Guide |
|---|---|---|
| Policy | The master switch and every limit: what users may automate, how many, how often, and what they may do with their own automations. Off by default. | Set Up the Automation Policy |
| Monitor | A governance view of every automation users created on this agent, with run history and pause / resume / disable / delete. | Monitor and Govern |
In this section
| Guide | What you will learn |
|---|---|
| How Automation Works | The life of an automation: creation, scheduling, a run, the result, and the statuses in between. |
| Set Up the Automation Policy | Switching Automation on for Atlas and choosing the limits. |
| Create an Automation | What your users say, what the agent shows back, and how to confirm. Includes schedules, conditions and actions. |
| Manage Your Automations | The user's own view: the Automations page, notifications, and the controls on each automation. |
| Monitor and Govern | The CMS Monitor, contributor permissions, and how Privacy Mode changes what you can see. |
| Troubleshooting Runs | Why a run was skipped or failed, or why an automation stopped, and what to do about it. |
Before you start
- Your agent is live and people use it. Automation is a Stage 4 feature: finish Preview and Publish Changes and Manage Who Can Use and Build first.
- Users must be signed in. An automation belongs to a person, so it can only be created and managed by someone who is logged in. Visitors, the CMS preview, group chats and agent-to-agent calls never get Automation.
- It is off until you switch it on. Until you enable it on the Policy page, the agent does not offer Automation and nobody sees an Automations entry in the chat.
- The agent needs a tool for the data. An automation can only check what the agent can already read in a normal chat. Atlas can check KG-2041 because it has the Projects API.
- Every run spends credit. A run is a real turn of your agent, billed like any other conversation. The Policy page has limits to keep this predictable.
Next steps
- Next in the journey: How Automation Works, to follow the KG-2041 check from request to result.
- Set Up the Automation Policy: switch Automation on for this agent.
- Remember Each User: the previous step in Stage 4.