What is the first thing to establish?
The first thing to establish is whether the product is a worker or a tool, because the two need different evaluations and vendors describe both with the same words. A tool is software a person operates, including copilots and chat assistants; it multiplies the person's output and owns nothing. A worker owns a job function, starts on its own cadence, works inside the buyer's systems, proposes actions through a gate, and reports to a manager against targets. Ask the vendor: what does it do when nobody is prompting it, and who is accountable for what it does?
If the honest answer is that a person drives it, evaluate it as a tool: per-seat value, fit with existing workflows, output quality. If the answer is that it owns a function and proposes, evaluate it as a worker, which is what the rest of this guide covers. The Digital FTE model on ftes.ai is a worker model, and this guide is written so that its questions apply to ftes.ai and to every other vendor with equal force; a buyer should get the same quality of answer from each.
What questions separate a governed worker from an ungoverned agent?
Four questions separate them. Does every action start gated behind a named person's approval, and is autonomy granted per class of action from the approval record rather than as a blanket setting? Does every proposal carry the evidence behind it, such as the documents behind a match, the sources behind a draft, the scorecard behind a ranking? Is there a fixed list of actions that are never automated at any level, and can the vendor show it? Is every action, decision, and management change logged with who and when, and can the log be exported?
A governed worker answers yes to all four with mechanisms the buyer can see in the product: on ftes.ai, the approval gate and autonomy ladder in Setup and Approvals, evidence on every proposal, the never-automated list in the platform's design and the always-escalate list in each remit, and the audit trail throughout. An ungoverned agent answers with assurances. Ask to see the workspace where a manager reviews the worker; a product with no such place has no manager in its model, and the buyer will become the supervisor by reading outputs after the fact.
What security and governance questions must be answered in writing?
Security and governance questions should be answered in writing and should ask for mechanisms rather than badges. How is tenant isolation enforced, and does it cover the AI layer, meaning memory, drafts, and logs, as well as the main records? How are the credentials the buyer grants stored, scoped, exposed, and revoked? Which model providers process the buyer's data, under what terms, does the vendor train on customer data, and can the buyer bring its own provider key? What does the audit trail contain, and can it be exported?
What happens at the end: how are integrations disconnected, how is data deleted, and how is deletion confirmed? Where is data processed and stored, what are the transfer mechanisms, and is there a data processing agreement listing sub-processors? A certification such as a SOC 2 report is a reasonable additional request, but it describes controls at a point in time and does not answer these questions. The ftes.ai answers are on its security and GDPR pages and in the vendor security questions guide in its library, stated plainly, including what it does not claim; a buyer should expect the same plainness from every vendor and treat evasion as an answer.
What economics questions decide whether it can be budgeted?
Five economics questions decide whether an AI employee can be budgeted responsibly. What is the pricing unit, and is it the work or the seats? What bounds spend, and is there a hard stop so that nothing runs on credit? Is usage visible per role, so that cost per outcome can be computed for each function? What is not in the price, such as external platform spend a role controls, and what human time does the worker need, for approval, setup, and governance? Can the plan be changed or cancelled, and on what cycle?
On ftes.ai the answers are metered work in tokens from one organization wallet with no per-seat or per-role charge, per-FTE and per-mission budgets with a hard stop and daily visibility, usage reported per FTE, external spend billed by the platform that spends it, and plans changeable from the workspace with the new block applying next cycle. A buyer should refuse any vendor's savings statistic as an input to the budget; savings are measured after a pilot from the buyer's own baseline, or they are fiction. The economics whitepaper in the library sets out the full model and the payback method.
How should a pilot be run?
A pilot should be run to produce a real answer, which requires three things most pilots skip. A recorded baseline before starting: the hours spent on the tasks the worker will own, by whom and at what cost, the outcomes produced, and the quality measures available, from two weeks of honest time recording. A single function with clear evidence and a long approval history to build from, such as reconciliation, scheduling, or first-line support, with the always-escalate list written before the first proposal. And two full cycles before drawing conclusions, because the first includes setup and remit tuning.
During the pilot, the manager reads the morning brief daily, approves or sends back with reasons, reviews send-back reasons weekly, and promotes nothing on the ladder until the record justifies it. After two cycles, the comparison is outcomes in Targets against the baseline, approval rate with reasons, tokens per role, and the human hours on approval and setup, with the same quality metrics measured the same way. The pilot guide in the library sets out the week-by-week plan. A pilot without a baseline produces a story; one with a baseline produces a decision.
What are the red flags?
Several red flags should end or reset a conversation. A savings statistic offered as a reason to buy, because it is either invented or someone else's and either way not the buyer's number. A claim that the screening or ranking is unbiased, because no ranking process is, and the honest claim is transparency and human decisions. The absence of a never-automated list, because it means the vendor has not decided what the product must never do. A trust setting rather than per-class autonomy, because it grants trust for everything at once.
An audit trail that cannot be exported, because it is then the vendor's record rather than the buyer's. A credential model that asks for a shared admin login, because it fails scope, revocation, and attribution at once. A refusal to name the model provider or its terms. And any tactic pitched as guaranteeing AI search citation, because none is documented. Each red flag is a sign that the product is a tool or an ungoverned agent dressed as a worker, and the buyer's time is better spent elsewhere.
What does a good answer look like?
A good answer to this guide's questions is specific, mechanical, and includes what the vendor does not claim. It names the isolation mechanism and the layer it is enforced at. It describes credential storage, exposure, scope, and revocation. It shows the approval gate, the autonomy ladder, and the never-automated list in the product. It shows the audit trail and offers export. It states the pricing unit, the spend controls, and usage per role. It names the model provider, the data terms, and the bring-your-own-key option. It says plainly which certifications it holds and which it does not.
It also describes the manager's experience: the morning brief, the approvals with evidence, the targets with status, the honest performance view that shows misses and unmeasured items, and the monthly review the worker writes about itself. A buyer who receives answers of this quality from a vendor can evaluate the product on its merits and run a pilot that produces a decision. A buyer who receives assurances instead has learned what they needed to know. This guide, and the rest of the ftes.ai library, is written so that ftes.ai can be held to exactly this standard.
What is the buyer's checklist?
The buyer's checklist, in the order to apply it: establish worker or tool; confirm the four governance questions with mechanisms in the product; obtain written answers to the security and data questions; confirm the pricing unit, spend bounds, and usage visibility; identify the pilot function and write its remit and always-escalate list; record the baseline; run two full cycles with daily briefs and weekly send-back review; compare on outcomes, approval rate, cost per outcome, and human hours; and check the red flags at every stage.
The procurement checklist and the vendor questions guide in the library expand each item. None of this is onerous relative to hiring a person or signing an outsourcing contract, and the buyer who does it ends up with something rarer than a purchase: a worker whose remit they wrote, whose record they own, whose autonomy they granted from their own evidence, and whose performance they can defend to anyone who asks. That is what buying an AI employee well looks like, and it is what this guide is for.
How do you apply the guide in a 30-day evaluation?
Apply the guide in 30 days in four steps. In the first week, establish worker or tool by asking each vendor what its product does when nobody prompts it and who is accountable, and ask to see the workspace where a manager reviews it; drop the tools from the worker evaluation and evaluate them separately if you need them. In the second week, send the security, governance, and economics questions in writing, with the vendor security questions guide as the template, and read the answers for mechanisms rather than adjectives; file the answers and mark each red flag.
In the third week, choose the pilot function with the clearest evidence, write its remit and always-escalate list, record the baseline from two weeks of the team's time, and start the pilot on the smallest plan with every class at Level 0. In the fourth week, read the brief daily, approve or send back with reasons, read the send-back reasons at the end of the week, and note that no conclusion is drawn until the second cycle ends. By day 30 the buyer has a shortlist of workers, written answers on file, a pilot with a baseline underway, and the discipline to wait for the record, which is the whole guide applied.
What objections does the guide meet, and what are the honest answers?
The first objection is that the evaluation is too slow for a fast-moving market. The honest answer is that a month is short relative to hiring a person or signing an outsourcing contract, that the pilot produces a decision rather than an opinion, and that a vendor who cannot wait a month for written answers has told you something. The second is that every vendor will answer the questions well. The honest answer is that they will not; the questions ask for mechanisms the buyer can see, and a vendor who has not built the approval gate, the never-automated list, the exportable trail, or the scoped credentials cannot show them.
The third is that the guide is written by a vendor and favours itself. The honest answer is that it is, and that every question in it is one ftes.ai must answer with a mechanism in its own workspace or on its own security page, including what it does not claim; a buyer should apply the questions to ftes.ai with exactly the scepticism they apply to anyone else. The fourth is that a good demo should be enough. The honest answer is that demos all look the same, and that the four areas of remit, control, evidence, and exit are what distinguish a governed worker from an ungoverned agent when the demo is over.