Agents are the AI nobody talks to. They run on a schedule, look at your data, and do something when they find what they were told to look for.
The assistant answers when asked. An agent notices when nobody did.
What an agent is made of
Four parts, and they are worth understanding separately because most bad agents are bad in exactly one of them.
A schedule. Every hour, daily at six, daily at nine, weekdays at six, or weekly on Monday morning.
A scope. What it looks at.
Conditions. What counts as worth acting on: equals, does not equal, greater than, less than, or simply not empty.
An action. Create a task, send a notification, update a record, or draft an email.
The seven built in
You do not have to invent one. These exist, and they are the patterns worth stealing from.
Deal Reviver finds deals going quiet, including ones with a missing party or pipeline, and files a follow-up for the owner.
Cash Watchdog watches invoices past due and partial payments going stale, drafts the chase, and flags the aging total.
Meeting Follow-ups reads the action items out of recent meetings and files each one as a task, so nothing dies in the notes.
Reply Chaser spots inbound conversations waiting on a human past the agreed time and nudges whoever owns the thread.
Data Janitor sweeps weekly for deals with no company, contact or pipeline, and files a fix-list so the rot never accumulates.
Leave Cover sees approved leave starting soon and flags what needs covering before the person is out.
Support Triage categorises and prioritises incoming tickets every half hour.
Look at that list before building anything. Between them they cover the most common failure in any business system, which is not a missing feature but something nobody noticed.
Start with tasks, not emails
The single most useful rule here.
Your first agent should create tasks and nothing else. A task appears in somebody's list, they read it, and they judge whether the agent was right. If it was wrong, one person was mildly inconvenienced.
An agent that drafts an email is one step from something reaching a customer. Right eventually, and wrong as the thing you learn on.
An agent that updates records changes your data on a schedule based on rules you wrote in ten minutes. Only after you have watched it run for a fortnight and agreed with every decision.
Schedule it for when somebody will look
An agent that files work at three in the morning files it into a list nobody opens until nine.
Weekdays at six is the good default for anything a person acts on. It is ready when they arrive and it does not run at the weekend, when the follow-ups it creates will sit for two days looking urgent.
Every hour is right for very little. Most business conditions do not change hourly, and an agent running twenty-four times a day to find the same three things produces noise and consumes credits for nothing.
Making the conditions tight
A loose agent is worse than no agent, and the failure is specific: it produces a lot of output, people stop reading it, and then it produces something important and nobody notices.
Start narrower than feels right. An agent that finds three real things a week is trusted. One that finds forty maybes is ignored by the second week and switched off by the fourth.
Watch what it produces before widening. The first run tells you more about your conditions than any amount of thinking about them.
Watching them
Every run is recorded: what it looked at, what it found, what it did.
Read the first few runs properly. An agent doing the wrong thing quietly for a month is the actual risk here, and it is entirely preventable by looking twice in the first week.
Check on the ones that find nothing. An agent reporting nothing for three weeks is either a business in good shape or a condition that never matches. Those look identical from the outside and are worth telling apart.
When an agent is wrong
It will be, and the question is what happens next.
A wrong task is cheap. Somebody reads it, disagrees, closes it. That is the system working, and it is why the first agent should only file tasks.
Wrong repeatedly is a condition problem, not a model problem. Read the runs, find what matched that should not have, and tighten. Rewriting the instruction rarely helps when the scope was wrong.
Right but unwelcome is worse than wrong. An agent that correctly identifies forty things a week nobody has time to act on trains people to ignore it, and then the one that mattered is ignored too. If the output is real and nobody acts on it, the answer is usually a narrower agent rather than a reminder to the team.
Switch it off rather than tolerating it. An agent everybody has learned to skip is worse than none, because it occupies the space where a good one would go.
Agents and automations
Both do things without being asked, and they are different tools.
Automations react. Something happens, a rule fires, an action follows. Deterministic, immediate, and the right answer whenever the rule can be written down.
Agents look. On a schedule, at a body of data, applying judgement to what they find.
If you can state the rule exactly, use an automation. It is cheaper, faster and easier to reason about. Use an agent when the thing you are looking for needs a read rather than a match.
Before you build your own
Three questions worth answering honestly first.
Who acts on this? Name the person. Output nobody owns is output nobody reads.
What happens if it is wrong? If the honest answer is "somebody deletes a task", proceed. If it is "a customer gets an email", start with tasks.
Would a report do? If somebody could look at a list once a week, a saved view is simpler, cheaper and easier to trust than an agent.
What they inherit and what they do not
They take their voice from Persona and guardrails, so a drafted email sounds like everything else.
They do not get their own permissions. An agent works within the access it was given, and cannot reach data a person in that position could not.
Did this answer your question?
No, ask a person