Enterprise AI agents: pick the first department, then write down what the agent may touch
An AI agent is software that takes actions in your systems. Every action is a permission you grant. This worksheet helps you pick the first department, write the permission sheet for one workflow, and test the agent on last month's work before it touches this month's.
What an AI agent is at work
An AI agent reads from your systems, decides the next step from written instructions, and takes an action. The action might be a drafted reply, an updated record, a routed ticket or a sent email.
That last part is what separates an agent from a chat assistant. An assistant answers a person, who then does the work. An agent does the work. So the useful questions are about permissions. What may it read? What may it change? Who sees what it did?
Most of the risk sits in those answers. Settle them first and the choice of model gets easier.
Pick the first department by the work
Start where the work is repetitive, where someone who does the job today can check the answer quickly, and where a mistake can be undone. Those three things matter more than which department is asking loudest.
A good first workflow has these traits:
- It happens many times a week, in roughly the same shape each time.
- The person doing it today can say whether an output is right in a minute or two.
- The systems it touches have an API or a reliable export.
- A wrong action can be reversed, or it waits for a person before it lands.
- One person owns the workflow and can make the call at the end.
This table shows common first workflows by department. It shows where agents usually start. Your own list will look different.
| Department | A typical first task | What the agent reads | What it writes | Where a person approves |
|---|---|---|---|---|
| Customer service | Classify and draft replies to incoming tickets | Ticket, order history, help articles | A draft reply and a category | Before any reply is sent |
| Finance, receivables | Prepare collection follow-ups for overdue invoices | Invoices, payments, past messages | A drafted reminder and a note on the account | Before anything goes to a customer |
| Finance, payables | Match supplier invoices to purchase orders | Invoices, purchase orders, receipts | A match or an exception flag | On every exception |
| HR | Answer policy questions from staff | The handbook and policy documents | An answer that cites the policy section | When the question is about one person's case |
| Sales operations | Update the CRM after calls and meetings | Notes, transcripts, the account record | Suggested field updates and a next step | Before fields change |
| Procurement | Compare supplier quotes against requirements | Quotes and the requirement sheet | A comparison table | Always. The agent never picks the supplier |
Notice the last column. In a first workflow, the agent prepares and a person decides. You can widen what it may do after it has a record.
The permission sheet
Write this down for the one workflow you chose, before anyone builds anything. It fits on a page. If a line is hard to fill in, that is where the project will get stuck.
| Line | What to write | Example: overdue invoice follow-ups |
|---|---|---|
| Reads | Every system and field it may see | Invoices, payments and the last three messages on the account |
| Writes | Every field or record it may create or change | A draft email and one note on the account |
| Sends | Who it may contact, and through which channel | Nobody directly. Drafts go to the collections queue |
| Never | Actions that are off limits | Changing an amount, issuing a credit, contacting a disputed account |
| Approval | Which actions wait for a person, and who that is | Every draft, reviewed by the receivables lead |
| Logs | What gets recorded for each action | Inputs used, draft produced, reviewer, sent or discarded |
| Off switch | Who can stop it, and how fast | The receivables lead, from the queue screen |
The "Never" line matters most. Agents get into trouble with access nobody meant to give them. A service account that can edit every record is easier to set up than one that can edit two fields, and that shortcut is where incidents come from.
Test it on last month's work
Before the agent touches live work, run it on a sample of work that is already finished. Take tickets, invoices or requests your team closed last month. Give the agent the same inputs your people had. Compare what it would have done with what they did.
Then read every disagreement. Some will be agent mistakes. Some will show that two people on your team do the same task differently, and that is worth knowing before you automate either version.
This replay gives you a baseline and a pass mark you can defend. Our pilot acceptance checklist covers the rest of what a pilot needs: an owner, rollback, support and a production decision.
Where agents go wrong
- It had write access it did not need. Start read-only plus drafts. Add write permissions one at a time, with a reason for each.
- Nobody owned the exceptions. The agent flags a case it cannot handle, and the flag sits in a queue no one checks. Name the person and the screen before launch.
- The instructions lived in a prompt nobody could read. When the rules are buried in a long prompt, nobody can review them or explain a decision. Keep the rules written down where the process owner can read and change them.
- It was judged on a demo set. A handful of clean examples says little about the messy cases. Use real closed work, including the ugly cases.
Build, buy or extend
Your helpdesk, CRM or ERP vendor may already offer an agent for the workflow you picked. Try that first. If it covers the workflow and the permissions are as narrow as your sheet requires, you are done.
A custom build makes sense when the workflow crosses systems that do not share an agent, when your rules are specific to how you work, or when you need to own the logic and the logs. Extending is the middle path: keep the vendor tool and connect the one step it does not cover.
How we approach it
David built and operates Bot for Kalshi. It turns a plain-language instruction into an explicit rule graph, with controlled, logged execution. Its engine, the Kalshi Bot Toolkit, is public and MIT-licensed. He built it for himself, and we say so plainly. It shows the discipline we bring to agent work: rules you can read, actions that are logged, and a person who can switch it off.
Using this with us, or without us
Fill in the permission sheet for one workflow. If it comes together easily, you may not need outside help. If it raises questions about access, integration or testing that you want a second pair of eyes on, send it to us and we will tell you what we would look at first.