Automating your processes: what repeats no longer has to be done
An incoming request to qualify, a report due every Monday, an alert to pass on. These tasks follow a rule, and a rule can be automated.
In short
An automation is a scenario you draw: a trigger, steps, effects. It reads your data, calls a language model when something has to be understood or written, decides according to conditions, then acts. Eight triggers and more than forty building blocks exist, and the scenario stops to ask for your approval wherever you require it.
Which processes are worth automating?
Some processes appear in no job description and still take hours each week. Sorting requests landing in a shared mailbox. Copying information from one tool to another. Preparing the same summary every Monday. Alerting the right person when a case changes state.
These processes share one trait: they follow a rule someone could state in a sentence. That is exactly what gets handed to a machine, and the surest way to save time without changing any of the tools already in place.
What is an automation here?
A scenario is drawn: a trigger, steps, effects.
The automation reads your data, calls a language model when something has to be understood or written, decides according to conditions, writes to the graph, sends a message. And it stops to ask for your approval wherever you require it.
That last point deserves emphasis. An automation acting alone on a sensitive matter is a risk. An approval step turns the scenario into a proposal: the machine prepares, a human signs off. This is also what the European AI regulation calls human oversight, and the point where a compliance requirement is settled inside the tool rather than in a procedure written alongside it.
What can trigger a run?
Eight triggers exist, and they cover most real situations.
| Trigger | What fires it | Typical case |
|---|---|---|
| Schedule | A time or a frequency | The Monday morning summary |
| Incoming email | A message in a watched mailbox | Qualifying inbound requests |
| Inbound call | Another system calls the platform | A business tool reports an event |
| File drop | A file lands in a watched folder | Processing a nightly export |
| Graph event | A piece of data changes | A contract reaches end of life |
| End of ingestion | A loading run finishes | Checking quality after an import |
| Predictive alert | A model flags a deviation | An anomaly on a customer account |
| Manual start | Somebody starts it | Whatever stays on demand |
What happens next
More than forty building blocks chain together in a scenario. The main ones:
Understand. Model call, classification into your own categories, structured extraction from free text, summary, translation.
Read and write. Reading from and writing to the graph, conditions, branching on a result.
Act. Sending an email, forwarding an original message with its attachments, a Slack or Teams message, an internal notification, an HTTP call to your systems, an outbound webhook, writing to Google Drive.
A concrete example beats a list. A request arrives in the sales mailbox. The scenario reads it, classifies it (pricing request, complaint, technical question), extracts the customer name, checks in the graph whether they already exist and whether they have an open incident, then routes it to the right team with that context. What used to take a few minutes per message, and required knowing the history, now happens unattended.
When a scenario is not enough, what do agents do?
A scenario follows a path decided in advance. Some requests have none.
An AI agent is an assistant restricted to a domain, with its own instructions and its own data scope. A user's question is routed automatically to the one able to answer it, without them picking from a list. When in doubt, generic handling takes over.
For processes calling on several skills in sequence, teams of agents are formed.
Credentials, declared once
An automation that sends an email or queries a business tool needs access. Declaring it inside each scenario guarantees that one changed password will silently break half of them.
A connection is therefore declared once, then referenced. Ten families are covered, among them databases, Google Drive, SharePoint, HubSpot, Notion, sending and receiving email, and HTTP services. A password that changes is fixed in one place.
Sharing is explicit: private, chosen people and roles, or the whole organisation for use only. And the permission is rechecked when the scenario runs, not only when it is saved. Revoking a share therefore genuinely stops the next run.
How do you know what is running?
An automation nobody watches becomes a source of surprises.
Runs are traced: what ran, what failed and why, failures grouped by cause. Logs are searchable. Tokens consumed are counted, per run and per period, which tells you what a scenario actually costs before you generalise it.
Events become messages on the channel each person chose, by email, live in the application, or by signed call to your own systems.
Where do you start when automating a process?
The right first process to automate is frequent, dull and low-risk. It serves to check the mechanics and earn the teams' confidence.
Sensitive scenarios come next, with an approval step, and are released gradually as results justify it.
An automation is worth what it knows about your company. The knowledge graph is what gives it that, and it is what separates this from a chain of calls between applications. If your data must not leave your network, scenarios also run on your own infrastructure.
Tell us about a task that comes round too often, and we will look at whether it can be drawn.