AI agents for business: roles, permissions and guardrails
An AI agent for business is software that takes one defined job, reads the business data it is allowed to read, works out what to do and produces the result, with a person approving anything that matters. It is not a chatbot and not a fixed rule. It is a worker with a role, permissions and a record.
- One job per agent
- Draft first, approve always
- Every action on record
Proof
- 80,000+
- venues on Purple, in 90 countries
- 500 million
- logins across the Purple network a year
- 2 million
- people onboarded every day
- 1,000+
- connectors
Purple runs WiFi and guest data for brands such as McDonald's, JPMorgan, Whitbread, Premier Inn, SoFi Stadium, Pizza Express, Stonegate.
What is an AI agent for business?
An AI agent is a worker with one defined role. It reads the data it is permitted to read, decides which steps reach its goal, drafts the result and, where you allow it, acts. Every step is logged. That separates it from a chatbot, a rule or a workflow.
Most of the confusion about agents comes from using one word for five different things. A chatbot answers a question and forgets you. An automation rule fires when one condition is met. A workflow runs the same steps in the same order every time. An internal app gives a person a screen to enter and see information. An agent sits in the gap none of those cover: a job where the steps change depending on what the data says, and someone still has to read several sources to reach the answer.
Take the Monday report for a 40-site restaurant group. A rule cannot write it, because what matters changes every week: one site is down on lunch covers, another is over on labor, a third has a private booking that explains an odd Saturday. A person can write it, but only after exporting from the till, the bookings system, the schedule and the footfall feed. An agent does the reading and the first draft, and the area manager spends ten minutes checking and editing instead of three hours compiling.
| Tool | What starts it | What it decides | Best used for | Where it falls short |
|---|---|---|---|---|
| Chatbot | A person asks a question | How to phrase an answer | Answering questions from a fixed body of knowledge | Changes nothing in your systems and forgets the context |
| Automation rule | One event or condition | Nothing: it follows the rule | Single, always-the-same reactions, such as an alert at a threshold | Breaks when the situation does not fit the rule |
| Workflow | A schedule or a trigger | Nothing: it follows the steps | Repeatable multi-step processes across systems | Cannot cope with variation until a person adds a branch |
| AI agent | A schedule, a trigger or a request | Which steps to take and in what order, inside its permissions | Jobs that need several sources read and a judgment on what matters | Needs guardrails, a named owner and a record to be trusted |
| Internal app | A person opens it | Nothing: a person decides | Entering, tracking and approving structured information | Does not read across systems unless something feeds it |
The same business uses all five. The skill is matching the job to the tool, which the rest of this guide helps you do.
One defined job
Prepare each site's Monday report
Then: Read permitted data
Read permitted data
Tills, bookings, schedule, WiFi footfall
Then: Work out what changed
Work out what changed
Against each site's usual week
Then: Draft the output
Draft the output
One page per site
Then: A person approves
A person approves
Edits, then signs off
Then: Run goes on record; Send back: Draft the output
Run goes on record
What ran, when, which data
Why do multi-site operators need agents now?
Because the data to answer most operating questions already exists, in systems that do not talk to each other, and the people who need the answers spend their week stitching it together. An agent does the stitching and the first draft, so managers spend their time deciding.
The cost is easy to see once you do the arithmetic on your own estate. If a site manager spends three hours a week assembling the numbers for one report, a 40-site group spends 120 hours a week on compilation that produces no decision. Over a 48-week working year that is 5,760 hours. The decisions only start once the report exists.
Most multi-site businesses already hold the inputs. The till knows what sold. The bookings system knows what is coming. The schedule knows who is paid to be there. The WiFi network knows how many people walked in and how long they stayed. Purple runs that last source for 80,000+ venues in 90 countries, and it is the one source that tells you who actually came through the door. The gap is not data. It is the labor of joining it, repeated every week at every site.
- 3 hours
- a week on one report at each siteThe example used throughout this guide
- 120 hours
- a week across 40 sites on compilation
- 5,760
- hours a year, over a 48-week working year
The same shape repeats across the business. Facilities want to know which sites are overdue on checks. Finance wants supplier invoices matched to deliveries. Operations wants the site that has fallen behind its usual week flagged on Tuesday, not discovered at month end. Each of these jobs reads several sources, applies judgment and produces a short output for a person. That is the job description of an agent.
How does an agent work on the systems you already run?
The agent connects to your systems with read access, does its work on that data and hands a draft to a person. Reading does not change your source systems. Nothing is written back until a permitted action is approved, and every step lands in a record you can open.
Purple Build connects your business systems through 1,000+ connectors: tills and point of sale, bookings, CRM and marketing tools, email, calendar and documents, plus Purple WiFi footfall, visits and dwell time. You describe the agent's job in plain English, the way you would brief a new colleague, and Purple Build creates it on the data you have connected. If you want it different, you say what to change.
The design choice that matters is where the agent sits. It does not replace your systems and it does not live inside one of them. It sits across them, with read access to the sources its role needs and nothing else. That is why one agent can compare a site's till takings with its footfall and its schedule, which no single system can do alone.
Brief the job
In plain English
Then: Request the data
Request the data
Permitted sources only
read: Sources answer
Sources answer
Read only
data: Draft the report
Draft the report
One per site
Then: Review and approve
Review and approve
Then: Log the run
Log the run
What, when, which data
Which jobs should an agent do first?
Start with jobs that read several sources, repeat on a rhythm, produce a short output and have a named person who reads it. Reports, alerts and drafts are the safest first jobs. Anything that changes pay, money or a customer's record comes later, with approval on every run.
A good first job has four properties. It repeats, so you get many runs to learn from. It reads more than one source, so the agent is doing work a rule cannot. It produces something a person reads before anything happens, so a mistake costs a correction rather than an incident. And somebody owns the output and will tell you when it is wrong.
The table below lists eight jobs multi-site teams give agents first, with the data each reads, who approves it and how much it can hurt if it is wrong. The risk column is the one to read before you choose.
Where the steps are fixed, multi-site workflow automation is the simpler tool. An agent can only act on data it can read, which is the job of connecting your business data, and steps where a person enters or approves data usually want an internal business app.
| Job | Reads | Produces | Approved by | Risk if wrong |
|---|---|---|---|---|
| Monday site report | Tills, bookings, schedule, footfall | A one-page summary per site | Area manager | Low: a draft a person reads |
| Site behind its usual week | Tills, footfall | An alert with the likely cause | Operations lead | Low: an alert, no action |
| Schedule suggestion | Bookings, footfall, availability | A proposed schedule per site | Site manager | Medium: affects people's hours |
| Ordering prompt | Item sales, stock counts | A suggested order | Site manager | Medium: money, reversible before sending |
| No-show follow-up list | Bookings | Bookings at risk of a no-show | Host or reception | Low: a list, no action |
| Invoice check | Invoices, delivery notes | Mismatches flagged | Finance | Medium: money, nothing paid by the agent |
| Overdue checks | Opening and closing checklists | An overdue list by site | Facilities lead | Low: a reminder |
| Board pack draft | Every connected source | A draft pack with sources | Finance director | Medium: reputational, reviewed first |
Examples of jobs teams give agents, not a limit on what Purple Build creates. The same pattern applies to any job that reads several sources and ends in a short output.
Notice what is missing from the list: nothing that pays someone, hires or fires, or messages a customer without a person reading it first. Those jobs are possible, and some belong in an agent's remit eventually, but they belong at the end of a record that shows the agent behaves, not at the start of the pilot.
How do you set permissions and guardrails for an agent?
Treat the agent like a new member of staff with its own identity. Give it the least access its job needs, in five layers: identity, data scope, action scope, limits and record. Start at draft only, and widen one layer at a time as the record earns it.
The mistake that causes most agent incidents is borrowing a person's login. The agent then inherits everything that person can see and do, and nobody can tell afterwards which actions were the agent's. Give the agent its own identity instead, with a role that names exactly what it may do.
The principle behind the five layers is least privilege: grant the minimum access the job needs, and no more. It is the same principle your IT team applies to staff accounts and service accounts, and it is the most effective control against two of the risks OWASP's guidance on large language model applications names: prompt injection and excessive agency. An agent that can only read three named sources and only draft cannot be talked into emptying a database, however clever the input it reads.
1. Identity
The agent has its own role. It never uses a person's login.
2. Data scope
Only the sources and fields its job needs, and only what the person may see.
3. Action scope
Read, draft or write. Writing needs approval until the record is clean.
4. Limits
Caps on volume, value and frequency, so one bad run stays small.
5. Record
Every read, draft and action logged: what ran, when, which data.
| Level | The agent may | Example | Sign-off |
|---|---|---|---|
| 0. Read | Read named sources and answer questions | Which sites are behind this week? | None needed; access is the control |
| 1. Draft | Produce output only a person sees | Each site's Monday report | Reader checks it |
| 2. Act with approval | Write to a system after a person approves | Send the approved schedule to the team | Approver on every run |
| 3. Act within limits | Write alone inside caps, and report | Send a reminder to up to 20 managers | Owner reviews the record weekly |
| 4. Act freely | Write without caps | Not recommended for money, pay or customer records | Do not grant |
Purple Build agents start at level 1 and draft for your approval rather than acting alone.
Agent guardrail checklist
0 of 9 done
When should a person approve what an agent does?
Always, when the action touches money, a person's pay or hours, or a customer's record, and whenever it cannot be undone in one step. Let an agent act alone only where the action is reversible, capped and visible. Use the decision tree below to place a specific action.
Human-in-the-loop is not a single switch. It is a decision you make per action, on two questions: how bad is it if this is wrong, and how easily can it be undone? Where both answers are comfortable, approval slows the business for no benefit. Where either is not, approval is the cheapest insurance you can buy.
The rule of thumb that holds up in practice is to approve the first month of any new action regardless of how safe it looks, then relax approval only for the actions whose record is clean. The record is what makes relaxing safe: you are looking at weeks of what the agent actually did, not trusting a description of what it should do.
Does this agent action need a person to approve it?
Question 1
Does the action touch money, a person's pay or hours, or a customer's record?
Examples: paying an invoice, changing a schedule, updating a customer's details.
See every path as a list
- Does the action touch money, a person's pay or hours, or a customer's record? Yes (go to: A person approves every run.); No (go to: Does the output leave the business, to a customer, supplier or regulator?)
- Does the output leave the business, to a customer, supplier or regulator? Yes (go to: Is the wording fixed in advance, as a template a person has approved?); No (go to: Can the action be undone in one step?)
- Is the wording fixed in advance, as a template a person has approved? Yes (go to: Approve the template once, then let it run within caps.); No (go to: A person approves every run.)
- Can the action be undone in one step? Yes (go to: Let it act, and review the record daily at first.); No (go to: Approve each run for the first month, then reassess.)
- Answer: A person approves every run. The agent drafts the change and a named owner approves it before anything is written. Review the record weekly.
- Answer: Approve the template once, then let it run within caps. Cap the volume and frequency, and review the record weekly for the first month.
- Answer: Let it act, and review the record daily at first. Reversible and internal: the worst case is a correction. Move to weekly review once the record is clean.
- Answer: Approve each run for the first month, then reassess. Hard to undo means a clean record has to come first. Reassess once you have four clean weeks.
How do you stop an agent being tricked by what it reads?
Treat everything the agent reads from outside your business as untrusted, and keep its permissions narrow enough that a trick cannot do damage. Prompt injection hides instructions in content, such as an email or a web page. Least privilege, approval on risky actions and a full record are the defence.
Prompt injection is the best-known way to attack an agent: someone hides instructions in a document, an email or a web page, and an agent that reads it follows them as if they came from you. OWASP lists it first among the risks to large language model applications. No filter removes the risk completely, so the defence is structural rather than clever.
Three structural controls do most of the work. First, narrow data scope: an agent that reads three named internal sources has little untrusted input to be fooled by. Second, narrow action scope: if the agent can only draft, a hidden instruction can at worst produce a bad draft that a person then reads. Third, the record: if something odd does happen, the log shows what the agent read and what it did, so you find it in minutes rather than weeks.
Keep agents that read outside content, such as inbound email, separate from agents that can write to your systems. The combination, an agent that both reads untrusted content and can act, is the one to avoid.
How do you measure the time an agent saves?
Count hours returned net of the time spent reviewing, not the hours the agent worked. Track four numbers each week: runs, approval rate, edits per run and escalations. Use the calculator for the hours, and the metrics table for whether the agent is improving or drifting.
The number that matters is net hours returned, because review time is real. An agent that drafts a three-hour report in a minute but needs thirty minutes of checking has returned two and a half hours, not three. Teams that skip the review line overstate the saving and then lose trust in the whole program when the first complaint arrives.
The second set of numbers tells you whether the agent is getting better. A rising approval rate and falling edits per run mean the role is well defined. A rising escalation rate means the agent is meeting cases its role does not cover, which is a signal to tighten the brief, not to give it more access.
Agent time-saved calculator
Enter your own numbers. The result is net of review time.
- Hours the agent takes over each week
- 96.0 hours
- Review time each week
- 10.0 hours
- Net hours returned each week
- 86.0 hours
- Net hours returned a year
- 4,128 hours
Worked example. At the defaults, 40 sites each spending 3 hours a week on the report, with the agent drafting 80 percent of it and 15 minutes of review per site, the agent takes over 96.0 hours a week, review costs 10.0 hours, and the net return is 86.0 hours a week, or 4,128 hours over a 48-week year.
How the numbers are built
- Hours per site are what the work takes today, not what you hope it will take.
- Review time is per site, per week, and includes edits.
- The calculation counts hours only. Multiply by your own loaded hourly cost to value them.
- It ignores faster decisions and fewer errors, which are real but harder to measure.
| Metric | How to read it | Healthy sign | If it moves the wrong way |
|---|---|---|---|
| Runs and failures | Did it run when it should, and finish? | Every scheduled run completes | Check the connection to the source that failed |
| Approval rate | Share of outputs approved without a rewrite | Rising over the first month | Tighten the role description |
| Edits per run | How much a person changes | Falling | Find the repeated edit and add it to the brief |
| Escalations | Cases the agent hands to a person | Stable, and for good reasons | Rising means the role is meeting cases it does not cover |
| Net hours returned | Hours taken over minus review hours | Matches the calculator | If it is lower, check review time first |
How do you start with a 30-day agent pilot?
Pick one job with a named owner, write its role in a paragraph, connect only the sources it needs, set it to draft only and run it alongside the manual way for two weeks. Compare line by line, record the numbers, then widen, tighten or stop.
A 30-day pilot, in eight steps
Pick one job with a clear owner and a rhythm
Choose a recurring output such as the Monday site report, where one person reads the result and can tell you when it is wrong.
Check: You can name the person who reads the output and the day they read it.
Write the role in one paragraph
State what the agent reads, what it produces, how often, and what it must never do. If the paragraph needs a second page, the job is two jobs.
Check: A colleague can read the paragraph and predict the output.
Connect only the sources it needs
Name the systems and the fields. Leave everything else out, including data that would be convenient. Narrow scope is the cheapest control you have.
Check: Every connected source appears in the role paragraph.
Set it to draft only, with an approver and a backup
The agent produces; a person approves. Name a backup so a holiday does not stall the pilot.
Check: Nothing can be written to a system without an approval.
Run it alongside the manual way for two weeks
Keep producing the report by hand at three to five sites while the agent produces it for the same sites. Compare the two line by line.
Check: Differences are logged, with a cause for each.
Record the numbers
Track runs, approval rate, edits per run, escalations and review time. Put the net hours returned next to what the calculator predicted.
Check: You have two weeks of figures for every metric.
Decide: widen, tighten or stop
Widen to more sites if approval is high and edits are low. Tighten the role if edits repeat. Stop if the job turned out not to suit an agent, and note why.
Check: The decision and its reason are written down.
Add the second agent only after four clean weeks
A second job on the same sources is cheap. A second job on new sources is a new pilot.
Check: The first agent's record is clean for four weeks running.
What does UK GDPR mean for an agent working on business data?
If the data includes personal data about customers or staff, UK GDPR applies to the agent as it does to any other processing. The principles that matter most are data minimisation, purpose limitation and the limits on solely automated decisions. Narrow data scope and approval on people-affecting actions satisfy most of them in practice.
The UK GDPR does not have a separate regime for agents. It regulates how personal data is processed, whoever or whatever does the processing. Three principles shape how you set an agent up.
Data minimisation, in Article 5(1)(c), means processing only the personal data that is adequate and necessary for the purpose. A tight data scope, where the agent reads the fields its job needs and nothing else, is that principle applied. Purpose limitation means the data collected for one purpose is not quietly reused for another, so an agent drafting a staffing report should not be given customer contact details collected for marketing.
Article 22 limits decisions based solely on automated processing that have legal or similarly significant effects on a person. This is why approval on any action that affects a person's pay, hours or a customer's record is more than good practice. The agent drafts, a person decides. Where processing is likely to be high risk, Article 35 requires a data protection impact assessment before you start, and it is worth running one for any agent that touches staff data.
The Information Commissioner's Office publishes guidance on AI and data protection that walks through each of these. Your data protection officer, or whoever holds that role, should see the agent's role paragraph and its data scope before the pilot starts.
When should you not use an agent?
Do not use an agent when the steps never change, when a person has to make the call, or when a mistake cannot be undone. Use a workflow for fixed steps, an internal app for entering and approving information, and a person for judgment about people.
Agent, workflow, app or person: which fits the job
AI agent
Fits when
- The job reads several sources and the answer changes week to week.
- The output is a draft or recommendation a person reviews.
- Compiling the answer is the slow part, not deciding it.
Not when
- The steps are identical every time.
- The action cannot be undone and nobody reviews it.
Workflow
Fits when
- The steps are fixed and repeatable, such as copying a booking into a schedule.
- A trigger or a schedule starts it, and the path never needs judgment.
Not when
- Exceptions are common and each needs a different handling.
Internal app
Fits when
- People need to enter, track or approve structured information.
- You want one screen that every site uses the same way.
Not when
- The job is reading across systems, with nothing for a person to enter.
A person
Fits when
- The decision turns on relationships, discipline, pay or care.
- The conversation matters more than the output.
Not when
- The work is compiling, matching or summarising.
Most businesses end up with all four. Start with the job that costs the most time and ends in a short output a person can check, and give that one to an agent.
The options side by side
| Route | Purple Build | A chat assistant bolted on | A custom build | A general automation tool |
|---|---|---|---|---|
| Works on your connected business data | Yes, through 1,000+ connectors, Purple WiFi included | Only what you paste in or export | Yes, once a developer connects each source | Yes, step by step, per connection |
| Who builds the agent | The person who runs the job, from a description | Nobody: it answers questions | A developer, from a specification | A technical user, from a flowchart |
| Permissions respected from the source | Yes: people see only the data they are allowed to see | Not applicable | Only if the developer builds it | Per connection, set by hand |
| Every action visible | Yes: each run is on record | No | Only if the developer builds logging | Run history, with detail that varies by tool |
| Time to the first agent | A description, then your review | Immediate, but changes nothing | Weeks to months in a queue | Days, plus upkeep as sources change |
Purple Build runs on the same credits as Purple Engage, with a free tier.
AI agents for business
All guides in this pillar
Each guide takes one question in this pillar all the way down, with the diagrams, tables and worked examples to act on it.
Foundations
When to use an agent, when not to, and how to measure the time it saves.
Control and safety
Guardrails, permissions, audit logs, approvals and monitoring for agents that touch business data.
Use cases
Agents for retail, restaurants and hotels, and a 30-day pilot plan.
AI agents for business
The terms, defined
- AI agent
- Software given one defined job that reads permitted data, decides the steps to reach its goal and produces a result, with a record of what it did.
- Guardrail
- A limit that keeps an agent inside its role: its identity, data scope, action scope, caps and approval rules.
- Least privilege
- Granting an identity the minimum access its job needs and nothing more.
- Human in the loop
- A person reviews and approves an agent's output or action before it takes effect.
- Prompt injection
- Instructions hidden in content an agent reads, such as an email or web page, that try to make it act against its role.
- Excessive agency
- An agent holding more permission or autonomy than its job needs, so a mistake or trick has a larger effect.
- Run record
- The log of one agent run: what it read, what it produced and what happened next.
- Escalation
- A case the agent hands to a person because it falls outside its role.
- Data minimisation
- Processing only the personal data adequate and necessary for the purpose, a principle of UK GDPR Article 5(1)(c).
- Net hours returned
- Hours of work an agent takes over, minus the hours people spend reviewing its output.
FAQ
Questions operators ask
What is an AI agent for business?
An AI agent for business is software with one defined job. It reads the business data it is permitted to read, works out the steps to reach its goal, drafts the result and, where you allow it, acts. A person approves anything that matters, and every step is logged. It differs from a chatbot because it works on your systems.
How is an AI agent different from a chatbot or an automation?
A chatbot answers questions and changes nothing in your systems. An automation or workflow follows fixed steps and cannot cope with variation. An agent decides which steps to take inside its permissions, so it suits jobs where several sources must be read and the answer changes each time, such as a weekly report across 40 sites.
Can an AI agent act without human approval?
It can, inside limits you set. Purple Build agents start by drafting for your approval. You can let an agent act alone only for actions that are reversible, capped and visible in the record. Anything touching money, a person's pay or hours, or a customer's record should keep a person approving every run.
What data can an agent see?
Only the sources and fields its role needs, and only data the person it works for is allowed to see. In Purple Build you connect the systems the agent needs, such as tills, bookings, schedule and Purple WiFi footfall, and leave everything else out. Narrow scope is the first guardrail and the cheapest.
How do I stop an agent being fooled by hidden instructions?
Treat all outside content as untrusted and keep permissions narrow. Prompt injection hides instructions in emails, documents or web pages. An agent that can only read named internal sources and only draft cannot do serious damage if tricked. Keep agents that read inbound content separate from agents that can write to your systems.
How do I calculate the return on an AI agent?
Take the hours the work takes today, multiply by the share the agent drafts, then subtract review time. At 40 sites spending 3 hours each, with 80 percent drafted and 15 minutes of review per site, the net return is 86 hours a week. Track approval rate and edits per run to see whether it improves.
Does an AI agent on business data fall under UK GDPR?
Yes, wherever the data includes personal data about customers or staff. Data minimisation means reading only the fields the job needs, and Article 22 limits solely automated decisions with significant effects on a person, so keep a person approving anything affecting pay, hours or customer records. Run an impact assessment for agents touching staff data.
How long does an agent pilot take?
Thirty days is enough for one job: a week to write the role and connect the sources, two weeks running alongside the manual way, and a week to compare the results and decide whether to widen, tighten or stop. Add a second agent only after four clean weeks on the first.
Do I need a developer to build an agent in Purple Build?
No. The person who runs the job describes it in plain English and Purple Build creates the agent on the data you have connected. To change it, you say what to change. Your IT and data team keeps control of what connects and who sees what, so the guardrails stay with the people who own them.
What does Purple Build cost?
Purple Build runs on the same credits as Purple Engage, so one balance covers both, and there is a free tier to start on. You do not need any other Purple product to use it. Waitlist members get early access first, with the systems they name connected first.
Where to go next
Sources and standards
- OWASP Top 10 for Large Language Model Applications
- NIST AI Risk Management Framework
- ICO: guidance on AI and data protection
- UK GDPR, Article 5: principles relating to processing
Reviewed on 9 October 2026.
Run your whole business from one place
Name your systems, tell us your first build, and they are connected first when early access opens. Or talk it through with the Purple team today.
- Join the waitlistLeave your details and you are first in for early access.
- Tell us what to connectTell us which systems you want to connect and what you would build first, and we connect yours first.
- Get early access firstWaitlist members get early access before anyone else, with a free tier to start on.
Early access
Get your systems connected first
Two questions: which systems you run, and what you would build first. That is all it takes.