How an AI employee is built

Every build follows the same five stages, in the same order, regardless of which role or job it's built for: capturing the rules, connecting real systems, testing against real work, deploying with monitoring, and extending as the job changes.

You capture them by working through real, recent examples of the job with the person who does it, and asking why they made each decision, rather than asking them to describe the job in the abstract.

Almost nobody can list their own decision rules from a standing start. Ask a bookkeeper "what's your policy for chasing overdue invoices" and you'll get a rough answer that misses half of what they actually do. Ask instead "walk me through the last five overdue invoices you chased, and why you handled each one the way you did," and the real rules surface: this client always pays within a week of the second reminder, so a firmer first message isn't worth the relationship cost; that client's invoices are often disputed over a line item, so anything with unusual line items gets checked before a reminder goes out at all. Those specifics are the actual job. A generic "chase invoices over 30 days" rule misses them entirely.

This stage produces two things: a working set of rules the agent can follow for the normal cases, and, just as importantly, an explicit list of the cases that don't reduce to a rule, which become the triggers for escalation. See what stays human for how those triggers get defined. Getting this stage right matters more than any technical decision that follows, because an agent built on an incomplete or wrong picture of the job will confidently do the wrong thing, consistently, until someone notices.

Connecting an agent to your real systems means giving it credentials scoped as narrowly as the job requires: read access where it only needs to check something, write access only where it genuinely needs to act, and nothing beyond the specific tool or account the job touches.

This is where the technical and the trust questions meet directly, and it's worth being concrete about for a reader evaluating whether to hand over access at all. An agent built to triage a shared inbox needs access to that inbox, not to every mailbox in the organisation. An agent built to match bank transactions needs read access to the bank feed and write access to the relevant ledger in your accounting software, not admin rights across your whole Xero or QuickBooks account. Scoping access this tightly is standard practice, the same principle as giving a new hire a login with permissions matched to their actual role rather than a master password.

Where the tool supports it, access is granted through the platform's own permission system: an app-specific login, a scoped API token, a role with limited rights, rather than a shared admin credential. Where a system's own tooling doesn't support fine-grained scoping, that limitation gets flagged during mapping rather than worked around with broader access than the job needs. Every agent runs on infrastructure the client owns rather than a shared platform; see infrastructure you own for what that means for where credentials and data actually sit, and AI data protection in Ireland for the compliance angle specifically.

An agent is tested by running it against real past examples of the job (actual historical emails, actual past invoices, actual completed tasks) and checking both that it gets the routine cases right and that it correctly stops on the cases that should be escalated.

Testing against hypothetical scenarios is a weak substitute for this, because hypothetical cases tend to be the easy, obvious ones a person invents when trying to imagine what could go wrong. Real historical data contains the actual mess: the email with an ambiguous subject line, the invoice with a typo in the amount, the client whose situation genuinely doesn't map cleanly onto any rule written down so far. Running the agent against a substantial batch of real past cases and comparing its decisions against what actually happened, or what should have happened, surfaces gaps in the rules before they cost anything in production.

The escalation boundary gets tested as deliberately as the routine path. It isn't enough for the agent to handle normal cases correctly; it has to correctly recognise the cases it shouldn't handle alone, and hand those back rather than pushing through. A testing pass that only checks "did it do the routine task right" and never checks "did it correctly stop when it should have" hasn't actually validated the part of the system that keeps it safe to trust with real access.

Monitoring means someone actually reviewing what the agent has done and what it has escalated on a regular cadence, checking for drift in accuracy, and adjusting the rules when the pattern of escalations shows the boundary needs to move.

Concretely, this looks like a regular review of the agent's activity log: what tasks it completed, what it escalated and why, and any cases where its output needed correcting after the fact. A rising rate of a particular kind of escalation is a signal: either the rules need extending to cover a case that's become common, or the job itself has changed in a way the agent hasn't been told about yet. A corrected output is treated as data, not just a one-off fix: if the same kind of correction happens more than once, that's the rule that was missing, and it gets added.

This is different from "monitoring" in the sense of an uptime dashboard, though that matters too: the agent needs to actually be running, and a failure needs to be noticed quickly, not discovered days later when a task nobody realised had stopped happening finally gets missed. Both kinds of monitoring, is it running and is it still doing the job correctly, are part of what "running" an agent means on an ongoing basis, distinct from the one-off work of building it. How it works covers where this sits in the overall map, build, deploy, run sequence.

An agent gets extended the same way it was built in the first place: by mapping the new part of the job against real examples, adding rules and access as needed, and testing the extension against real cases before it goes live, rather than assuming the existing agent will generalise on its own.

Jobs change: a new supplier gets added, a tool gets replaced, a new category of client query starts appearing. When that happens, the temptation is to assume an agent that's already handling the core job will simply cope with the new piece. It usually won't, cleanly, because the new piece has its own rules that haven't been captured yet. Treating an extension as a small version of the original build (map the new case, capture the rules, test against real examples) keeps the agent's behaviour predictable rather than letting it quietly start guessing on unfamiliar territory.

This is also where a role's scope can grow deliberately over time. An agent built initially to handle inbox triage alone might, once that's proven reliable, be extended to draft replies, then eventually to send routine replies within tight limits, each stage built and tested as its own increment, not assumed from the start. The role catalogue describes the range of jobs this applies to across a business, from bookkeeping to first-line support to content production.

If you want to understand what building an agent for a specific job in your business would actually involve, the access it would need, the rules it would run on, send a brief describing the job and we'll walk you through it honestly. You can also email hello@replican.ie.