AI employees: Where the metaphor breaks

AI employees are software agents given a role, instructions and access to tools so they can carry out work that a person would otherwise do. You might assign one to prepare meeting notes, another to sort support requests and another to research suppliers. They can work through several steps without needing a fresh prompt for each one. But they are not employees in the ordinary sense. They cannot accept personal responsibility for a mistake, understand an obligation as a person does or be held accountable by a manager.

The employee comparison is useful because it gives owners and managers a familiar way to assign work. It becomes dangerous when familiar language encourages familiar assumptions. A job title sounds like competence. A completed assignment sounds like a job well done. Neither tells you what the agent actually checked, what authority it exercised or who must answer if something goes wrong.

Job titles help people describe work

Imagine a founder hiring a part-time operations assistant. The founder would explain the recurring jobs, provide examples of acceptable work and decide which matters the assistant could handle without asking. Nobody would start by drawing a diagram of every possible conversation the assistant might have.

That is a good reason to think of agents as employees while designing their assignments. A research analyst is easier to brief than a collection of search and document-processing functions. A support triager suggests a recognisable responsibility: read incoming requests, identify the issue and prepare a sensible next step. The title gives the human a starting point for writing instructions.

Delagents uses this idea in its agent roster and builder, with templates including a research analyst, support triager, bookkeeper and meeting-prep agent. The names describe intended work, not professional qualifications or permission to act without review.

There is a difference between saying 'You are our bookkeeper' and assigning 'Review these expense records, identify possible duplicates and prepare a list for review.' The first statement gives the agent an identity without a defined finish line. The second gives it a job whose output can be inspected.

A title is useful shorthand between people. The brief still needs to say what records count, what to do with missing information and what a finished deliverable should contain.

An agent has a role, not professional judgement

A person hired as a bookkeeper brings more than the ability to categorise expenses. They may have formal training, experience with awkward cases and an understanding that their reputation is attached to the work. If a transaction looks suspicious, their response can draw on professional obligations and knowledge of the business.

An AI agent can classify the same transaction and explain why it chose a category. It might even flag an unusual amount. But its explanation is generated from the information and instructions available to it. An apparently confident answer is not evidence that the agent has checked every relevant fact or recognised the consequences of being wrong.

Consider a supplier invoice with a familiar company name and new bank details. A human bookkeeper might recognise the supplier, remember a recent conversation and call a known contact before changing payment information. An agent may notice the mismatch if its instructions or tools give it a way to do so. Without those conditions, the same invoice can look entirely ordinary.

This is where the employee metaphor starts to hide important details. We assume a colleague has context acquired through experience. We assume they can recognise when something falls outside their expertise. Those assumptions cannot be carried over simply because an agent has a name, a role and a convincing explanation.

For an agent, judgement needs to be translated into observable requirements wherever possible: compare bank details against an approved record, identify conflicting information and stop before any payment is made. The person reviewing the result still has to decide whether the evidence is sufficient.

Delegated work is not delegated accountability

Suppose an outreach agent prepares an email to a prospective customer. It uses the correct product description, picks up a detail from the prospect's website and produces a polished message. The work appears complete. Then the recipient points out that the message makes a promise the company cannot keep.

Who owns that promise? The agent cannot attend the complaint meeting as a responsible party. It cannot personally accept a contractual obligation or repair a business relationship. The company that sent the message remains answerable for it.

A human employee can also make an unauthorised promise. The distinction is that employment comes with legal duties, management relationships and established ways to investigate conduct. An agent has none of those relationships in its own right. Its actions belong within a system operated by people.

This should change how owners assign authority. Preparing an email and sending an email are different tasks. Checking payment details and moving money are different tasks. Drafting a job advertisement and publishing it are different tasks. A team can delegate the preparation while keeping the consequential decision with a named person.

At Delagents, actions that have effects outside the workspace wait for human sign-off. The approval card shows the exact proposed action, the cost so far and a deadline. A person can approve, change or reject it. That arrangement does not make the agent accountable. It puts the decision in front of someone who can be.

The management comparison has limits

A manager might check a new hire's work closely during their first month, then grant wider discretion as trust develops. It is tempting to copy that pattern with agents: review the first few assignments, see that the answers look reasonable and gradually stop checking.

The problem is that an agent does not acquire workplace experience in the same way as a person. Successfully sorting fifty ordinary requests does not establish that it will recognise the next request as a legal threat or a privacy complaint. A change in available tools, instructions or source material can alter what it does. A good run of familiar cases says little about an unfamiliar one.

We find it more useful to separate authority from apparent competence. An agent may be allowed to prepare thousands of low-risk drafts while never being allowed to issue a refund on its own. That is not a punishment for poor performance. It is a boundary based on the effect of the action.

The same distinction matters for budgets. A human employee has a salary, agreed hours and a manager who can question unexpected spending. An agent consumes resources through the work it performs. Repeated searches, failed attempts and extra tool calls can create cost without producing a better deliverable. A delegation needs its own spending limit rather than an assumption that the agent will know when enough work has been done.

Nor does an agent need the same access as the person who briefs it. A recruiting screener may need candidate documents but have no reason to alter payroll records. An inbox triager may need to read messages and prepare replies without the authority to contact every sender. Permissions should follow the assignment, not the seniority implied by the job title.

Design the role around what can be checked

There is a useful test for any proposed AI employee role: can another person inspect the work and tell whether it met the assignment? If the answer depends entirely on trusting the agent's explanation, the job is too loosely defined.

A research agent asked to 'find the best supplier' has room to hide uncertainty behind a ranking. Ask it instead to compare suppliers against an agreed specification, record the evidence for each claim and list what could not be verified. A human can then review the trade-offs and select a supplier.

A support agent asked to 'keep customers happy' has an equally vague mandate. Give it categories of incoming issues, an approved source of policy information and a clear rule for when a response needs review. Its deliverable can be a proposed reply with the relevant ticket details and the reason for its classification.

These are management decisions expressed as product design. What can the agent read? What may it prepare? What is it forbidden to change? What evidence should appear beside its recommendation? Where does the assignment stop? An audit trail helps a person reconstruct what happened, but it cannot replace a well-defined boundary in the first place.

A useful roster should therefore tell an owner more than which jobs have been given names. Each role needs a narrow purpose, appropriate tools, a recognisable output and a clear account of the decisions that remain human.

Write one job description without pretending to hire

Choose one task your team repeats, preferably one that ends in a document or a recommendation rather than an irreversible action. Meeting preparation is a good candidate. The agent can gather an agenda, organise supplied background material, identify unanswered questions and prepare a briefing for the meeting owner.

Write the assignment as you would for a new colleague, then remove every instruction that depends on assumed human judgement. Replace 'use your discretion' with a decision rule. Replace 'contact anyone you need' with an explicit limit on external communication. Replace 'do a thorough job' with a list of evidence the finished briefing must contain.

Before handing over the task, identify one person who will check the deliverable and decide what happens next. Give that person a short checklist: Are the facts supported by the supplied material? Are unknowns marked? Does any proposed action need permission? Has the work stayed within its scope?

Run one assignment with those boundaries written down. When the briefing arrives, review the evidence rather than the confidence of its prose. If something is wrong, revise the brief or the permitted scope before repeating the task. You will have designed a working AI role without having to pretend that the software is a member of staff.