How Automation Works
This page follows one automation from the moment a user asks for it to the moment they read the result. The example is the KG-2041 check that Kirana Group's operations lead set up in Atlas. Along the way it explains the statuses you will meet.
Before you start
- Read the Automate Tasks overview for the big picture and who does what.
1. A user asks
Automations are created in conversation: in the web chat, in a voice call, or on WhatsApp. The user just describes what they want. In Atlas's public chat, signed in, the operations lead typed:
"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."
Other requests Atlas users might make:
"Every Monday at 8, list the capex requests still waiting for approval."
"Every Monday at 8, email me last week's summary of the projects that slipped."
"Tomorrow at 9, remind me to submit the KG-F12 form for the Surabaya site."
The agent works out the trigger, condition, task and action from those words. It does not create anything yet.
2. The agent shows its interpretation
Before anything is saved, the agent shows an automation preview for the user to check: the Name, Trigger, the next three runs, the Condition, Task, Skills if any, Action, and notes from the policy. For WhatsApp, the recipient number is written out in international format, such as +62 812…; for email, the address, or a note that the user's own account address will be used. Anything ambiguous can be corrected here.
For the KG-2041 request, Atlas showed the name "KG-2041 delay / on-hold check", the trigger "Every weekday (Monday to Friday) at 07:30 (Asia/Jakarta)", and the next runs on Mon 5, Tue 6 and Wed 7 Oct 2026.
The user confirms with a plain "yes", and only then is the automation created. The pending preview expires after 30 minutes. See Create an Automation.
3. It is scheduled
Qlar stores the automation and schedules only its next run, not a timer per automation. After a run, it calculates the following one and schedules that. Editing, pausing or deleting an automation cancels what was scheduled, and a run that arrives for an automation that has since changed is discarded rather than executed.
Runs may begin up to a minute or so after the scheduled time. Qlar spreads automations that share a popular time (like 07:30 or 08:00) so they do not all start in the same second. When many are due at once they queue and run in order, so a busy moment can delay a run further.
4. The run
When a run is due, Qlar checks that the automation is still active and still allowed by the policy. Then it runs one turn of your agent in a new conversation, as the user who created it:
- If the automation has a condition, the agent first reads the current data with its own tools and reports the values. Atlas calls its Projects API for KG-2041 and reports the
project_status. Qlar evaluates the rules itself. If the condition is not met (for example, KG-2041 is "On track"), the run stops here: no conversation, no message. - Otherwise the agent carries out the task: here, a short summary of the status, progress, budget and current approval stage.
- Qlar then performs the actions: a new conversation, a WhatsApp message, an email, or any combination of them.
During a run the agent has no way to escalate to a human, and it does not write to the person's memory. Skills the user selected when creating the automation are attached to the run.
5. The result
| Action | What the user gets |
|---|---|
| Create conversation | A new conversation appears in their list, marked unread and marked as written by an automation, and a notification appears on the bell. They can open it and keep chatting like any other conversation. The agent knows which automation produced it. |
| Send WhatsApp message | The result is sent to the number in the automation. |
| Send email | The result is emailed to the address in the automation, from the agent's own {agent}-automation@qlar.ai address under the agent's name, with a link to the user's Automations page. Tables are kept; charts are left for Qlar. |
For the KG-2041 check, the new conversation starts with an answer such as "Delayed — approval is at Regional Director; next approver: CFO. Progress: 62%. Budget spent: US$1.48M of US$2.5M." The operations lead can reply in that conversation, for example "Who do I chase for the CFO sign-off?".
Conversations from runs that failed, whose condition was not met, or that only send a WhatsApp message or email never appear in the user's list.
Statuses
An automation is always in one of five statuses:
| Status | Shown to users as | Meaning |
|---|---|---|
| Active | Active | Running on its schedule. |
| Paused | Paused | Stopped for now. Paused by the user, by a contributor, because the user has more active automations than the policy now allows, or because the agent moved to another organization. |
| Disabled | Turned off | Switched off by a contributor. The user cannot resume or edit it, but can still delete it. |
| Error | Stopped | Stopped automatically, after three failed runs in a row or because the policy or the user's access no longer allows it. |
| Completed | Finished | It has no future runs: a one-time automation that ran, or one that reached its end date or maximum number of runs. Removed after 7 days. |
Every status carries a reason, shown on the automation in both the CMS Monitor and the user's Automations page. See Troubleshooting Runs for the full list.
Run outcomes
Each run is recorded in the automation's history:
| Outcome | Meaning |
|---|---|
| Succeeded | The task ran and the actions were performed. |
| Condition not met | The condition was checked and did not hold, so nothing was done. This is normal, not a failure. On a day when KG-2041 is on track, this is what you see. |
| Failed | The run could not finish. Temporary failures are retried according to the policy; three failures in a row stop the automation. |
| Skipped | The run was not attempted, for example because the policy is off or a daily limit was reached. |
| Timed out | The run took longer than the policy's run timeout. |
| Interrupted | The run was cut off before it finished. |
What is remembered, and for how long
| Data | Kept |
|---|---|
| The automation | As long as it has future runs. Finished ones are removed after 7 days; paused, stopped or turned-off ones nobody has touched for 90 days are cleaned up; a user deleting one removes it at once. |
| Run history | For the policy's History Retention (default 30 days). Records when it ran and how it ended, never the answer itself, which lives in the user's conversation. |
| Notifications | 30 days. |
If the organization uses Privacy Mode, the content of every automation is encrypted. A WhatsApp message or email still carries the full result, because that is what the user asked for. See Monitor and Govern.
Check the result
You understand the life of an automation if you can answer these for the KG-2041 check:
- Which tool does Atlas use to check the condition? (Its Projects API,
get_project_status.) - What happens on a morning when KG-2041 is on track? (The run ends as Condition not met. No conversation, no notification.)
- Where does the summary appear when the project is delayed? (In a new conversation in the operations lead's chat list, with a notification on the bell.)
Next steps
- Next in the journey: Set Up the Automation Policy, to switch Automation on and choose its limits.
- Troubleshooting Runs: what each status and run outcome means when something goes wrong.