Agents and automations from first principles

Some of the work in any operation is routine: when this happens, do that. A deal is marked won, so a welcome email goes out. A work order is booked, so the customer gets a confirmation. Automations are how you hand that routine to the system, so it happens the moment it should instead of waiting on someone to remember. And when the response needs more than a fixed rule — a judgment call, a written reply, a decision about what to change — a step can hand off to an AI agent. This guide covers both: the fixed engine first, and where it turns agentic.

The mental model

An automation is a saved "when this, do that." It has two parts. A trigger is the "when" — the event that starts it. Steps are the "do that" — the sequence it runs in response. Build the pair once and the system runs it every time the trigger fires, the same way each time. That sameness is the point of an automation: it is dependable, not creative. Later we will see the one place that changes.

Triggers: the "when"

An automation waits for something to happen. Most triggers watch your data: an entry is created, a field changes, a status or a stage changes, an entry is archived. Others come from outside that: a scheduled time — run every morning, run at month end — an incoming webhook from another system, or an inbound email that opens or continues a conversation. You can also start one by hand, from a button or a call. Choosing the trigger is choosing the moment: "when a deal reaches Won," "every Monday at 9," "when a form posts to us."

Steps: the "do that"

Once triggered, an automation runs its steps. Some steps are actions that do concrete work: send an email, create or update a record, move an entry to a new stage, link two records, call an external service, or handle a conversation. Other steps shape the flow rather than do work: a condition that lets the run continue only when something is true, a loop that repeats over a set, a delay that waits before the next step. Strung together, these are the recipe the trigger sets off.

Conditions: doing something only sometimes

Rarely does every trigger deserve the same response. Conditions decide which steps run: send the reminder only if the invoice is unpaid, escalate only if the amount is over a threshold, skip the whole thing if a box is already checked. You compare a value — equals, contains, greater or less than, before or after a date, empty or not — and the run follows the outcome. One habit worth forming early: when a step is optional — "do this when the condition holds, otherwise carry on" — attach the condition to that step rather than splitting the flow into branches that later have to rejoin. Branches that must reconverge are the most common way to tie an automation in a knot.

When an automation becomes an agent

Everything so far is deterministic: the same trigger produces the same steps, every time. That is exactly what you want for a confirmation email or a stage change. But some responses cannot be written as a fixed rule — a reply that has to read the situation, a decision about which of several things to change, a judgment about what a record needs next. For those, a step can hand off to an AI agent: instead of following a scripted action, the step gives the AI the record and lets it reason and act — draft the tailored message, decide the update, choose the next move. This is the point where a fixed workflow becomes agentic. The trigger and the surrounding steps stay dependable; the one step that needs judgment gets it. It is the same kind of agent that can work your records through a direct connection — here it simply runs from inside an automation, set off by an event.

Try it before it is live

An automation acts on real data, so you want to see what it will do before it does it for real. A dry run walks the automation through without real side effects — no email actually sent, no record actually changed — so you can confirm the shape is right. Once it is live, you can inspect any run to see exactly what fired, which steps ran, and why one did or did not. Treat that as normal practice, especially for anything that sends mail or changes records in bulk.

A worked example

Take the repair shop and its Work Orders. A simple automation: when a work order moves to Done, send the customer a follow-up email, then, after a two-day delay, a request for a review. Fixed and dependable — the same two touches every time. Now the agentic version of the same idea: instead of one boilerplate email, an AI step reads the specific job — what was done, whether it ran long, whether the customer had asked anything — and drafts a follow-up that fits, which a person can send or which goes out on its own. Same trigger, same place in the flow; the difference is that one step now uses judgment. Swap the repair shop for a clinic or an agency and the pattern holds — only the trigger and the steps change.

Where to go deeper

Automations act on the collections and fields you have already built, so if that model is still forming, start with working with collections and fields, and for the picture underneath it all, understanding the Sonta data model. The step-by-step pages — creating an automation, the full list of triggers and steps, conditions, adding an AI step, common pitfalls, and inspecting a run — each have their own place in this section.