Make it repeat
Most businesses run on routines: the report that goes out every Monday, the enquiry that wants answering the day it lands, the claim someone has to check before it is paid. Player One takes those off your hands, and you set each one up by asking for it in ordinary words.
Three things you could say
"Send me a summary of yesterday's orders every weekday at eight, on Telegram."
Player One sets up a scheduled task: one agent, one instruction, once a day. The summary arrives on Telegram at eight. The task itself is listed under Automations > Scheduled (/cron) with the time it will next run, and opening it shows every past run and how each one went. Say your timezone with the time, and name the channel you want it on: the web app will not buzz your phone, so a reminder has to go somewhere you actually look.
"Keep an eye on that supplier's price page and tell me when it changes."
Player One sets up a watcher. It sends you one message straight away to prove the alert works, then stays quiet until the price actually moves, and tells you once when it does. If you would rather it checked in loosely than on a strict clock, say so: ask it to keep half an eye on your inbox and it will look in periodically, interrupting you only when something has earned it.
"When an expense claim comes in, check it against our policy, draft the reply, and ask me before anything over five hundred pounds goes out."
That one is a flow, and it is the interesting one.
What a flow is
You describe the process in plain English, the way you would explain it to somebody new: what starts it, what normally happens, what to do about the exceptions, and where you want to be asked. Player One writes that description down with you, then compiles it into real software.
That last part is the whole point. Your description is not re-interpreted afresh every time a claim arrives. It becomes a program, so the hundredth claim is handled by the same steps in the same order under the same rules as the first. Where the process needs judgement rather than a rule, the program calls on an agent to make it. Where the process says a person decides, the run stops and waits for you, for ten minutes or for three days, and carries on from exactly where it paused when you reply.
Every run is kept. Automations > Flows (/manage/flows) lists your flows and their history, and opening a run gives you a live map of the process with the current step lit up, what went in, what came out, and a log of every decision, retry and question along the way. You can watch one happen or read one back a fortnight later, which is what makes a flow worth having for anything you may have to account for later.
Flows are early access. They work, and they are still being finished, so give a new one a few supervised runs before you trust it with something you cannot afford to have go wrong.
What sets one going
A flow can start when you press Run, on a schedule, when a message arrives on one of your channels, or when an outside system sends it an event. You can also run one on demand and hand it the details as you go: that is how the small reusable pieces get used, a pricing calculation or a validation step other processes call on.
Connecting an outside source happens in the conversation. Your agent tells you what to click in the other service rather than asking technical questions about it, waits while you fire one real test event so it can see the true shape of the data, and nothing goes live until you say yes. Connected sources are listed on the Providers tab of the Flows page, where a provider means an outside source a flow watches, not an AI provider. Starting a flow from another system's event needs your installation to have a public address and inbound webhooks switched on, so ask your assistant to check before you plan a month of work around one.
Nothing outside your installation can set something running by accident. Inbound endpoints are listed under Admin > Webhooks (/admin/webhooks), and the simplest kind turns a posted message straight into a message to you, with no agent involved at all.
Which one do you want
| What you want | Ask for |
|---|---|
| The same instruction on a clock, where the thinking is the value | A scheduled task |
| To be told when something changes, and left alone otherwise | A watcher |
| A process with an order to it, rules, approvals, or several people | A flow |
| One big piece of work, once, with a team on it | A job |
If you are not sure, describe the routine and let Player One choose. It will tell you which it picked and why, and it can move a routine up a level later: plenty of good flows began as a scheduled task that outgrew itself.
Two things worth knowing before you set a dozen running. A recurring task spends a little every time it fires, whether or not anybody reads the result, so pick the longest interval that still does the job: daily beats hourly, and every few minutes is almost never what you meant. And a repeating task that keeps failing does not switch itself off, so it pays to glance now and then at Automations > Active (/automations), one feed of everything running on your behalf, jobs and flows and scheduled tasks together, with whatever just finished or failed.
Where to go next
- Scheduled tasks and watchers, and flows, explained on their own terms.
- Schedule something and write your first flow, step by step.
- Set up a trigger, when something outside Player One should start the work.
- Three worked examples: inbox triage with your approval, a nightly check that opens a job and getting a group to agree on a date.