What is an AI employee?What is an AI employee?

An “AI employee” is usually an AI assistant or agent packaged around a role: sales development representative, customer-service officer, recruiter, analyst or operations coordinator. The label changes the comparison. Instead of comparing the product with a software subscription, the seller compares it with labour cost, availability or role capacity.

Underneath, the system still consists of models, instructions, context, tools and permissions. What makes the role claim meaningful is operational coverage: work arrives without a person pasting it into a chat; the system recognises the case; uses an approved source; takes or prepares the next action; retains state; follows up; and hands exceptions to an accountable person. OpenAI’s agent guide describes models, tools and instructions as the core design components, while Anthropic emphasises the difference between fixed workflows and models that direct their own tool use.^[1][2]

The word “employee” does not transfer legal accountability, create judgment or guarantee end-to-end reliability. It is better read as a proposed operating contract: “this system will own this bounded slice of work under these standing rules”. Your job is to inspect the boundary and the evidence.

An assistant contract begins when a person asks and usually ends when the person reviews the output. A delegation contract begins when work arrives and ends only when the workflow is completed, deliberately paused or handed over. The second contract needs state, ownership and recovery in ways the first may not.

Moving right should be an earned change in permission, not a feature toggle. Singapore’s agentic AI framework recommends bounding agents’ autonomy and access to tools and data, defining significant checkpoints for human approval, and keeping humans meaningfully accountable.^[4] Those controls are exactly what a role-shaped deployment should make inspectable.

Salary-like pricing can be defensible when the provider is taking responsibility for substantial integration and operation. It is not justified by model access alone. A credible proposal separates the work required to make a workflow dependable from usage charges that rise with volume.

Ask which costs are fixed, which vary by messages or model usage, and which third-party services remain your responsibility. A low headline price can hide staff time spent correcting, reconstructing handovers or maintaining facts. A high headline price can hide a simple chat layer behind role-based marketing. Compare the entire operating model.

Role-shaped automation fits work that is repetitive, observable and recoverable. Lead follow-up can work because each lead has a stage, owner, last action and next action. First-line enquiries can work because the answerable fact set and handover categories can be named. Screening can work when the rubric is explicit and a person retains the decision.

Poor fits share the opposite traits: the work changes every week, success is subjective, important context lives only in someone’s head, exceptions dominate, or a mistake would create an irreversible commitment. In those situations the system may still prepare useful work, but selling it as end-to-end ownership creates the wrong expectation.

• Strong candidate — frequent arrivals, stable inputs, explicit state, known sources, measurable completion and recoverable mistakes.
• Assistant-first candidate — useful drafts are possible, but a person still supplies judgment or unstated context.
• Do not delegate — the value is a human relationship, the decision carries non-transferable accountability, or plausible error would remain hidden.

A polished happy-path demonstration proves very little. Bring examples that are incomplete, contradictory, out of policy and dependent on a failed tool. Ask the system to show the source for a factual answer, refuse an unsupported commitment, recover from a CRM error, and hand a case to a person without making the customer repeat the story.

Then inspect the record. Can you reconstruct what the system read, proposed, did and handed over? Can an owner group corrections by cause—stale source, unclear rule, wrong tool, misunderstood intent or inappropriate autonomy? Anthropic’s guidance on agent evaluations stresses that multi-turn systems modify state and adapt after intermediate results, making them harder to assess than single responses.^[3] Evaluation must therefore cover the trajectory, not only the final sentence.

1. Step 01

   Show ordinary volume

   Run representative work, not a hand-picked prompt, and state the assumed throughput.

2. Step 02

   Break a dependency

   Remove a fact or fail a connected system and observe stopping, retry and handover behaviour.

3. Step 03

   Inspect the evidence

   Review sources, actions, approvals, corrections and the unresolved queue.

4. Step 04

   Demonstrate exit

   Export the facts, rules, workflow state and records in a usable form.

Humans remain responsible for setting the purpose, approving the boundary, maintaining important facts, dealing with unusual cases and reviewing whether the system still serves the business. Higher autonomy increases the importance of those responsibilities because fewer individual actions receive attention.

Keep commercial exceptions, refunds outside policy, hiring decisions, sensitive personnel matters, legal positions and relationship repair with people. An assistant can collect context, apply a rubric or prepare options; the accountable person should make and record the consequential decision.

If a workflow is still being understood, use the delegation tiers to begin with a draft-and-approve phase. If the rules are stable and the queue is visible, the Assistant Finder can indicate whether a package or custom integration is the more plausible starting point.