Roles for AI agents: who builds, who checks

What shipped

This is a practical role split for Irish SME teams that want to build simple AI agents without turning every manager into a developer.

The point is not to create a new bureaucracy. It is to stop a common problem: one keen person builds a helpful agent, the team starts using it, and nobody is quite sure who owns the instructions, checks the answers, fixes the source material or decides when it is good enough to use.

For a small business, that confusion can kill a good idea. It can also create risk if an agent starts drafting customer replies, summarising supplier emails or helping staff make decisions without a clear human review step.

A workable split is:

1. Users: the people who will use the agent in their daily work.
2. Builders: trained non-technical staff who can assemble and test the agent.
3. Reviewers: named people who check the agent output before it is used operationally.
4. Owners: the manager responsible for the process, rules and sign-off.
5. Custodians: the person or small group that keeps source documents, prompts and permissions tidy.

That is enough for most early agents. It gives staff permission to build, while making it clear that the output is decision support, reviewed by a person before operational use.

This is the kind of structure covered in Artellis agent-building training, especially for teams using Microsoft Copilot Studio, Google AI Studio and similar tools.

Who should care

This matters if your team already has people experimenting with AI, but you are not yet comfortable letting those experiments near real work.

It is especially relevant for operations, sales, customer service, finance and administration teams. These are the teams with repeat questions, messy hand-offs and lots of small decisions hidden in email, spreadsheets and shared folders.

The usual blocker is not lack of imagination. People can see plenty of possible agents: one to answer internal policy questions, one to qualify enquiries, one to summarise inbound supplier messages, one to draft first replies, one to prepare a job handover.

The blocker is confidence. Managers ask sensible questions:

Who is allowed to build this?

Who checks whether the answer is right?

What happens when the policy changes?

Could this send the wrong thing to a customer?

Are we creating work for IT later?

Those questions should be answered before training starts. If the role split is clear, non-technical staff can learn agent building as a controlled business skill, not as a shadow IT project.

Richard recently completed a cross-departmental Copilot Studio workshop for a large organisation. One lesson applies just as much to smaller Irish firms: people learn faster when they can see where their responsibility starts and stops. A user does not have to become the owner. A builder does not have to become the final approver. A reviewer does not have to understand every setting in the tool.

For background on how Artellis approaches practical AI adoption, see the wider Artellis insights library.

A worked example

Take a service business that receives project enquiries by email. The enquiries vary in quality. Some include dates, budgets and locations. Others are vague. A manager wants an agent to help staff triage the inbox and prepare a short qualification note.

Without roles, the work can get messy. A sales administrator might build a quick agent. A colleague might rely on it. A manager might later discover that it treats missing budget information as low priority, even though some of the best jobs arrive without a stated budget.

With roles, the training exercise becomes safer and more useful.

The users are the sales and operations staff who read the enquiries. They describe the real workflow, the common cases and the awkward exceptions.

The builder is a trained team member who creates the agent. They connect the approved source material, write the instructions and test the agent against sample enquiries.

The reviewer is a named manager or senior staff member. Their step is called the Human Review Gate. Before any triage note is used to prioritise work, a person checks the suggested category, the extracted details and the draft follow-up.

The owner is the manager responsible for enquiry handling. They decide what good looks like, what the agent is allowed to do and what must stay with a person.

The custodian keeps the approved qualifying questions, service descriptions and pricing notes up to date. If the business changes how it handles a type of enquiry, the custodian updates the material and triggers a retest.

In training, the team might build a first version of the agent that does three things:

1. Summarises the enquiry in plain English.
2. Extracts key details such as location, date, service type and missing information.
3. Drafts a short internal recommendation for the reviewer.

It does not automatically reply to the customer. It does not reject enquiries. It does not update the CRM without approval. It supports a decision, then a person reviews, tests and approves the next step.

That keeps the first agent simple enough for a non-technical team to understand and maintain.

Where I'd start

Start with a one-page role map before anyone opens an agent-building tool.

Pick one workflow where the team already knows the pain. Good candidates are enquiry qualification, internal policy questions, meeting follow-ups, document triage or routine drafting. Avoid anything where a wrong answer could immediately affect safety, legal rights, payroll or a customer commitment without review.

Write down five names or roles:

Who will use it?

Who will build the first version?

Who will review outputs before use?

Who owns the business process?

Who keeps the source material current?

Then agree the Human Review Gate. This should be visible and specific. For example: no customer email is sent until the service manager reviews the draft, or no enquiry status is changed until the sales lead confirms the recommendation.

Next, train the builders on a real but limited use case. Do not begin with a company-wide agent. Begin with one process, one team and one clear decision point. The aim is to learn the pattern: define the task, ground the agent in approved material, test it with real examples, record the limits and put a person in the approval loop.

Finally, decide how the team will retire or revise agents. If nobody owns that step, old instructions and stale documents will undermine trust.

The clear takeaway is this: non-technical teams can build useful AI agents, but only when the roles are simple, named and taught from the start.

If you want to explore this for your own team, book a 20-minute call about agent-building training and bring one workflow you would like staff to improve.