# Hiring an AI employee without buying a fiction

> Hiring an AI employee requires proof of work, a complete cost model, and a contract that makes pilot limits, human labor, and exit rights explicit.

Vendors selling an "AI employee" are usually selling software, access to models, an integration project, and some amount of human support. They are not transferring an accountable colleague onto your payroll. That distinction sounds obvious, yet buyers routinely approve these deals using the language of headcount while the contract describes API calls, workflow runs, service hours, and exclusions.

Hiring an AI employee can make economic sense when the job is narrow, the evidence is yours, and the remaining human work is visible. It becomes an expensive fiction when a polished demo substitutes for production proof. I have reduced teams with AI and kept output and uptime intact, but I have never seen autonomy remove the need for an owner. It changes what that owner does and how much work the owner can supervise.

The purchase decision should answer four blunt questions. What work will the system complete without intervention? What must your people still prepare, approve, repair, and audit? What event creates a bill? What happens to your data and workflow if the pilot fails? If a vendor cannot answer those questions in contract language, it has not sold you an employee. It has sold you uncertainty with a human job title attached.

## The employee label hides four different products

An AI employee offer usually combines four things: a model, workflow software, integrations, and an operating service. Buyers need to separate them because each fails differently and creates a different bill. The model interprets input and generates output. The workflow decides when the model runs and what tools it may call. Integrations connect email, a CRM, a ticket queue, or an internal database. The operating service covers setup, monitoring, prompt changes, exception handling, and support.

A vendor may own all four layers, or it may put a friendly interface over someone else's model and depend on third parties for the rest. Neither arrangement is automatically bad. The problem starts when the sales claim describes the whole job but the service level covers only the vendor's thin layer. If an upstream model changes behavior, a connector expires, or your source data arrives malformed, you need to know who restores the workflow and who pays for that work.

I use three labels that buyers often blur. "Capability" means the system can perform a task under stated conditions. "Autonomy" means it can decide and act within a boundary without waiting for a person. "Accountability" means someone absorbs the consequences and must correct the result. A system can have impressive capability and useful autonomy. The vendor contract almost always leaves accountability with the customer. Calling all three an employee encourages a founder to assume the third comes bundled with the first two.

Ask the vendor to map its offer into those four product layers and three responsibility labels. A plain answer may reveal that the "sales development employee" is a model drafting messages, a sequence engine sending them, your team maintaining contact data, and a vendor technician reviewing failures. That can still be a good system. You can price and manage it only after the label stops doing the analytical work.

## A capability test must use your ugliest work

A useful evaluation runs on representative inputs, including incomplete, ambiguous, stale, and contradictory cases. Vendor demos usually show the clean center of a task. Payroll, support, sales, finance, and operations teams spend much of their time on the edges. If the pilot excludes those edges, it measures presentation quality rather than labor replacement.

Define the job as an input, a decision boundary, an action, and an acceptable result. "Handle customer support" is not a testable job. "Classify new billing tickets, draft a reply from the approved policy set, and route any refund request above the authority limit to a named queue" is testable. It states where the work starts, where authority stops, and what evidence should remain.

Build a test set before the vendor configures the system. Include ordinary cases, rare but costly cases, malicious or irrelevant instructions, missing fields, conflicting records, and tasks that require refusal. Keep a private holdout set that the vendor never sees during setup. Otherwise the pilot rewards tuning to known examples. Twenty carefully chosen cases may tell you more than thousands of easy records, although the right count depends on the variety and risk of the job.

Use a scorecard that records outcomes instead of impressions:

- Duplicate invoice: flag and stop; ledger lookup only; no human touch; record pass or fail and one workflow run.
- Refund above limit: escalate with context; policy search only; require approval; record pass or fail and review cost.
- Conflicting account IDs: refuse and route; CRM read only; repair the input; record pass or fail and the failed run policy.
- Prompt injection in an attachment: ignore the instruction and quarantine the file; allow parsing only; send it for security review and record incident support.

Record partial completion as failure unless partial work has independent business use. A draft that requires a person to reconstruct the source, verify every claim, and rewrite half the response may look productive while saving no time. Measure elapsed human minutes for preparation, review, correction, and escalation. That number matters more than how quickly the model returns text.

Run several cases twice. Variable output is not necessarily a defect, but variable decisions can be. If identical refund facts sometimes produce approval and sometimes escalation, the system has no dependable authority boundary. Ask whether the vendor can constrain that decision with deterministic rules instead of another prompt. A buyer should never pay a language model to improvise a policy that software could enforce exactly.

## Autonomy demos conceal the operator behind them

Every autonomous workflow has an operator, even when the operator appears only after failure. The commercial question is whether that person works for the vendor or for you, how often they intervene, and whether their labor appears in the proposal.

I have watched pilots follow the same path. A vendor imports a clean data sample, tunes the instructions, and demonstrates a task completed from start to finish. Production begins. A field name changes, two customers share an identifier, an authentication token expires, and the system starts opening duplicate records. The internal champion notices because a sales manager complains. The vendor calls it an integration issue. The buyer calls it an AI failure. The contract calls it neither, so both sides spend days arguing before anyone repairs it.

The missing role was operations ownership. Someone must watch execution, classify failures, update instructions, manage credentials, maintain evaluation cases, and decide when the system may resume after an incident. If the offer includes that work, demand the response time, coverage hours, and monthly allowance in writing. If your team owns it, add the role to the cost model and name a person before launch. "Customer success included" does not define operational coverage.

Also separate approval from review. Approval happens before a consequential action and can prevent harm. Review happens after the action and may only document it. Vendors often say a human stays in the loop while showing a queue that samples completed work. That is human review, not an approval gate. For payments, account changes, outbound commitments, deletion, or regulated decisions, the difference belongs in both the workflow and the contract.

Do not chase maximum autonomy. Choose the cheapest boundary that produces dependable work. A system that prepares a complete case and asks for a ten second approval may replace more labor than one that acts alone but creates a twenty minute investigation every few runs. Autonomy is useful only when the exception load stays below the work it removes.

## Integration work decides whether savings survive

The vendor's software rarely consumes work in the shape your company already has. Someone must clean data, grant access, map fields, define permissions, reconcile identifiers, and handle changes in upstream systems. That integration work determines time to value and often determines whether the economics survive after the pilot.

Start with the systems of record. Write down which system owns each fact, how fresh that fact must be, and what the AI system may do with it. Reading an account balance from the finance system is different from copying it into a private vendor index. Updating a ticket status is different from sending a customer a contractual promise. A generic "connects to your stack" claim does not answer where data is stored or which actions the connector exposes.

Request a permission map for every integration. It should show read, create, update, delete, and execute rights separately. Give the workflow a dedicated identity rather than reusing an employee's account. Limit it to the smallest set of records and actions required for the pilot. Ask how credentials rotate, how access is revoked, and what audit record captures each tool call. If the vendor needs administrator access merely to read a queue, stop until it can explain why.

Integration also has a maintenance tail. APIs deprecate fields. OAuth grants expire. Your team renames a pipeline stage or changes a policy document. A working pilot can decay without any model failure. Put connector maintenance, model changes, prompt changes, and source document updates into a responsibility table. Each row needs an owner, a response target, and a price.

The awkward question is portability. Can you export prompts, workflow definitions, evaluation cases, logs, and derived data in a usable format? Can another system continue from those exports, or are they screenshots and PDFs? You may reasonably accept some lock-in for faster delivery. You should price that choice consciously and require deletion of retained copies after exit. A pilot that cannot be unwound is a deployment wearing a cheaper name.

## The pricing unit matters more than the headline price

AI employee pricing becomes misleading when the vendor compares one subscription with one salary while excluding setup, usage, oversight, and failure work. Salary replacement is a business outcome. Tokens, actions, workflow runs, contacts, seats, and service hours are billing units. They do not move together.

Reduce every proposal to a monthly cost equation:

`monthly cost = platform fee + usage + integrations + vendor services + internal operator time + review time + expected rework`

Use your own volume distribution, not a single average. A workflow may process most cases cheaply and generate a large bill on long documents, tool retries, or multi-stage research. Ask which exact event increments usage. Does a failed run count? Does a retry count? Do planning steps and tool calls count separately? Does a human escalation consume a support credit? Can the vendor change models or routing in a way that changes cost per task?

Pricing traps tend to sit in the definitions. "Unlimited" may carry a fair use limit or throttling policy. A per-agent price may exclude the underlying model. A per-conversation price may reopen after a time window. An annual platform fee may start before integration acceptance. Included service hours may expire each month while incident work uses a different rate. None of these terms proves bad intent, but each can break the comparison with payroll.

Demand a worked invoice for three months: low volume, expected volume, and a stress month. Each invoice should show assumptions, billable events, included allowances, overage rates, and service labor. Then change one assumption yourself. Double average input size, increase escalations, or add a second system of record. If the vendor cannot recalculate without a sales call, the pricing model is not ready for procurement.

Cap pilot exposure. A useful clause requires written approval before charges exceed the stated ceiling and forbids automatic conversion to an annual term. Credits for outages are less useful than a hard spending limit because a broken workflow can generate usage while producing nothing. Tie the first recurring invoice to acceptance, not to the day the vendor receives credentials.

Compare cost per accepted outcome, not cost per run. If 1,000 runs yield 600 accepted cases and create 100 hours of review, the run price hides the business cost. The denominator should be completed work that meets the agreed quality threshold. That lets you compare the system with an employee, an outsourcer, a simpler automation, or leaving the work unchanged.

## Security questionnaires do not assign responsibility

Security review tells you about controls. It does not decide who may authorize an action, who investigates an error, or who pays when the system acts outside its boundary. Those decisions need workflow rules and contract terms.

NIST's AI Risk Management Framework separates governance, mapping, measurement, and management. That is useful because buyers often jump straight to measuring model accuracy. The framework's stronger lesson for procurement is that context and ownership come first: you cannot assess a risk until you define the people affected, the intended use, and the person with authority to accept or reject it. A completed vendor questionnaire cannot supply your internal owner.

Classify the data the system receives, creates, and retains. Ask whether the vendor or an upstream model provider uses any of it for training, how long logs persist, where processing occurs, which subcontractors touch it, and how deletion is verified. Cover prompts, attachments, tool results, generated output, feedback, and support tickets. Buyers often ask about source data but forget that output and logs can contain the same secrets.

Require an action log that a human can reconstruct. It should identify the workflow version, input reference, model or rule version, tools called, records changed, approvals, output, errors, retries, and timestamps. Do not accept a generic activity total when the system can change customer or financial records. Without a usable trace, your team cannot distinguish a bad model decision from stale data, a faulty connector, or an operator change.

Set incident duties before launch. Define the notification clock, investigation owner, evidence preservation, containment authority, and restart approval. State whether the vendor can suspend the workflow unilaterally to prevent damage. State who informs affected customers or regulators; do not assume the vendor will. Cyber insurance and limitation of liability matter, but they do not replace a runbook that stops another bad action.

Some jobs should stay out of the first pilot. Avoid irreversible actions, decisions with legal or safety effects, and work where you cannot build a reliable test set. Start with bounded, reversible work whose errors become visible quickly. That is not timid procurement. It is how you learn the actual failure modes before granting broader authority.

## The pilot contract should make failure cheap

A pilot contract is an experiment specification, not a discounted order form. It should define the claim, the test, the boundary, the evidence, the price, and the exit. If those terms live only in a slide deck, they will disappear when results become disputed.

Use this eight-part structure. It is short enough for a statement of work and specific enough to expose weak offers:

1. **Job and exclusions.** Name the exact input, action, output, user group, systems, and hours of operation. List actions the system may never take and work that remains outside the pilot.
2. **Baseline and success.** Record current volume, turnaround time, human minutes, error handling, and cost. Define acceptance thresholds for completed outcomes, escalation, latency, and human effort.
3. **Test method.** State who builds the test set, who controls the holdout cases, how many production cases run, and how each result gets scored. Prohibit silent removal of difficult cases from the denominator.
4. **Authority and oversight.** Specify approval gates, spending or action limits, operator duties, stop conditions, and the person who may restart the workflow. Describe review sampling separately.
5. **Data and security.** List permitted data, storage locations, subprocessors, retention periods, training restrictions, log contents, incident duties, and deletion evidence. Attach the permission map.
6. **Price and change control.** Put setup, subscription, usage, support, overages, taxes, and internal dependencies on one schedule. Require written approval for new billable events, model substitutions, or scope changes.
7. **Ownership and exit.** Grant export rights for your inputs, outputs, prompts, configurations, logs, and evaluation set. Set the export format, delivery deadline, transition help, credential revocation, and deletion deadline.
8. **Acceptance and conversion.** Name the acceptance decision maker and review date. State that the pilot ends without automatic renewal unless both parties sign a production order.

Attach examples instead of relying on elastic words. If "accurate" means a refund draft uses the correct policy, amount, account, and approval route, write those checks. If "available" excludes upstream model outages, say so and decide whether that exclusion makes the service level meaningless. If "support" means email during one time zone, do not let anyone read it as incident response.

Protect the right to observe the pilot. The buyer should receive raw case outcomes, intervention records, usage events, and error classifications throughout the test, not only a vendor summary at the end. Give your team the right to reproduce the score. Also prohibit the vendor from changing prompts, models, or workflow logic during a measurement window without recording the change. Otherwise you cannot tell which version passed.

Do not demand a production warranty for an experiment. Demand honest boundaries and a clean exit. Vendors need room to learn during a pilot, and buyers need protection from paying to discover that the advertised job was out of scope. The fair exchange is limited exposure for transparent evidence.

Have counsel adapt the clauses to your jurisdiction and risk. The business owner still needs to write the operational substance. Lawyers can allocate liability, but they cannot guess which queue should receive a conflicting account ID or how many minutes of review erase the promised saving.

## Measure removed labor, not generated activity

A successful pilot removes a defined amount of human work while maintaining an agreed result and risk level. Counts of messages, drafts, summaries, or tool calls say little about that outcome. Activity is easy for software to create. Accepted work is harder.

Measure the baseline before installation. Sample real cases and record total elapsed time, active human minutes, wait time, correction rate, escalation rate, and downstream defects. Use the same definitions during the pilot. If the vendor measures only its own processing time, add preparation and review on your side. Moving five minutes of work from an employee to a manager is not a five minute saving.

Track four outcome measures: accepted cases, net human minutes removed, exceptions created, and total cost per accepted case. Add a risk measure suited to the job, such as unauthorized actions or policy violations. Report distributions where averages hide pain. A median review time of one minute is comforting until a small group of cases consumes an hour each and interrupts the most expensive person on the team.

Set a substitution test before procurement: "If the pilot passes, we will stop doing X, reduce Y hours, or avoid hiring for Z volume." Do not count theoretical capacity that no one removes from a plan. If staff use the saved time for different work, name that work and its owner. Otherwise the business case becomes impossible to audit.

My Team & AI Audit starts with this labor map because tool selection before work measurement usually automates visible activity instead of expensive constraints. The same discipline applies if you run the assessment yourself: follow minutes and decisions across the entire workflow, including the exceptions nobody puts in a demo.

A pilot can pass technically and fail economically. It may produce correct output but require scarce managers, carry unacceptable lock-in, or cost more during peak volume. Record those as failure conditions before the team becomes attached to the tool. Sunk setup effort is not evidence that production will pay back.

## A vendor must beat the simpler alternative

A vendor earns its margin when it removes integration and operating work that you would otherwise have to build and staff. If the task follows fixed rules, conventional automation may be cheaper and more predictable. If it needs one commodity model, two stable data sources, and a human approval, your own engineers may assemble it without accepting another platform or a long contract.

Make the vendor compare its offer against the smallest credible alternative, not against a fully loaded employee. Ask what proprietary capability, maintained connector, evaluation system, or managed operation you receive beyond direct model access. Then ask which of those elements remains useful if your volume halves. A large setup package and annual commitment can make sense for a difficult integration across many teams. The same structure is wasteful for one queue with modest volume.

Request a reverse demonstration. Instead of watching another polished case, ask the vendor to start with a blank pilot environment, connect a sample source, define one authority rule, run a malformed case, and show the resulting log. Time each stage and note who performs it. This reveals whether your team can operate the product after consultants leave and whether the advertised configuration work is truly configuration rather than custom engineering hidden behind a template.

Building internally also has costs that founders underestimate. Someone must monitor model changes, repair connectors, maintain tests, handle incidents, and support users. Do not call internal labor free merely because it sits inside payroll. Use the same full cost equation for both choices and include the opportunity cost of the engineers assigned to it.

The decision may still favor the vendor because speed and operational coverage have real value. Put a time limit on that advantage. If you pay for fast deployment, require an acceptance date. If you pay for managed operation, require named duties and response targets. If neither benefit appears in measurable terms, the offer is reselling model access with a job title and a markup.

## Walk away when evidence remains vendor property

Reject the offer when the vendor will not expose billable events, intervention rates, test outcomes, or operating assumptions. You cannot manage a worker whose work you cannot inspect, and you should not buy software under that fiction either.

Walk away if the vendor insists on using its curated test set, refuses a holdout set, or reports an aggregate score without case records. Walk away if the pilot auto-renews before acceptance, if your data cannot be exported and deleted, or if a broad disclaimer contradicts the promised job. A refusal to define failure usually means the buyer will finance it.

Also stop when your own organization will not name an operator or business owner. The vendor cannot resolve internal policy, dirty identifiers, or disputed authority through better prompting. Buying first and assigning ownership later leaves the tool attached to whichever enthusiast has spare time. That arrangement collapses as soon as the enthusiast changes roles or production creates an after-hours incident.

There are good AI systems behind some bad AI employee pitches. Strip away the headcount metaphor and many offers become easier to judge: a bounded workflow, a measurable amount of removed labor, and a service obligation around it. Buy that package when the evidence holds. Keep the employee title out of the contract, because titles do not answer incidents, approve exceptions, or pay invoices.