How to Choose an AI Employee Platform: A 12-Point Evaluation Framework

§ 01The 12-Point AI Employee Platform Scorecard

The weights below are an illustrative starting point for a knowledge-work role that reads internal information, creates deliverables, and takes some external actions. They are not an industry standard.

Move weight toward permissions, audit, and data controls for higher-risk roles. Move it toward tool reach and output breadth for production-heavy roles. Move it toward triggers, task state, and handovers for operational queues.

The central rule is simple:

Score the platform you can prove, not the product the vendor can describe.

§ 02What Should You Define Before Comparing AI Employee Platforms?

Define the job before the software.

An AI employee platform is only valuable in relation to a bounded responsibility. “Help with marketing” is not a testable responsibility. “Every Monday, assemble the approved channel data, produce the weekly acquisition review in the standard format, identify material changes, and route budget recommendations to the growth lead” is.

If the role itself is still unclear, use the AI employee hiring process to turn the workload into a role contract before opening a vendor spreadsheet.

Write a one-page role card

The platform must support this operating contract. It does not earn credit for an impressive capability the role does not use.

Build a representative test pack

Use 10-20 examples drawn from real work, sanitized where required. Include:

• ordinary tasks;
• incomplete inputs;
• ambiguous requests;
• conflicting sources;
• a denied action;
• a tool or API failure;
• a duplicate trigger;
• a stale instruction;
• a high-risk action that must escalate; and
• a task that should be stopped rather than completed.

The test pack prevents a vendor from choosing only favorable examples.

Separate must-pass gates from scored preferences

Some requirements are not tradeable.

Reject or pause a vendor that fails a gate. Do not let a 90 in model quality erase a zero in approval enforcement.

§ 03How Should You Score Vendor Evidence?

Every score needs both a number and a receipt.

Use this six-level evidence scale:

Documentation can prove that a control exists. It cannot prove that your configuration works under your conditions.

Calculate the weighted score

For each criterion:

weighted points = criterion weight × evidence score ÷ 5

Then add the 12 weighted results.

Suppose one platform receives these evidence scores:

A 68.6 is not automatically good or bad. Your policy decides.

An illustrative decision policy might be:

• 80-100: shortlist if every gate passes;
• 65-79.9: continue only through a bounded evidence plan;
• below 65: do not advance for this role; and
• any failed gate: do not deploy, regardless of total.

Publish the weights, scores, evidence links, evaluator, and date. Otherwise the spreadsheet becomes a record of preference disguised as analysis.

§ 04Can the Platform Represent a Persistent Role?

Criterion 1 asks whether the product can hold a standing responsibility - not merely produce a strong response.

If your use case is one-off analysis, a capable assistant may be enough. The AI employee definition becomes relevant when work needs a durable role, continuity, initiative, action, and accountability.

What to evaluate

Look for configurable objects or behaviors covering:

• role purpose;
• goals and boundaries;
• supervisor;
• recurring responsibilities;
• identity or communication channel;
• schedule or availability;
• open tasks;
• role-specific instructions;
• context carried between work sessions;
• performance expectations; and
• retirement or reassignment.

The platform does not need to copy a human HR system. It does need a durable place for the role’s obligations to live.

Ask for a restart test

Start a multi-step task. Interrupt it. End the session. Resume later from a different interface or scheduled run.

The system should recover:

• what outcome it owes;
• what has already happened;
• which source is authoritative;
• what remains blocked;
• what action is next;
• which approval is still valid; and
• when the task should stop.

Conversation history alone is weak evidence. It may preserve words without preserving an explicit operating state.

Score role ownership, not anthropomorphic presentation

A friendly identity can help collaboration. It is not evidence of operational persistence.

§ 05Can the Platform Start the Right Work Without Creating Duplicate or Unbounded Work?

Criterion 2 covers triggers and demand control.

An AI employee may wake on a schedule, event, email, message, queue item, webhook, threshold, or direct request. The important question is not whether a trigger exists. It is whether the trigger starts the right work exactly as intended.

Evaluate trigger coverage

Demand control is part of reliability

Ask whether the system supports:

• deduplication;
• idempotency;
• rate limits;
• concurrency limits;
• retry caps;
• backoff;
• budget caps;
• quiet hours;
• priority rules;
• stale-event handling;
• cancellation; and
• a dead-letter or exception path.

“Runs 24/7” is a capacity claim. It is not a control design.

Run a duplicate-trigger test

Send the same event twice. Delay a prerequisite. Then deliver the prerequisite after the original task has expired.

A credible platform should not:

• send two customer messages;
• create two records;
• continue an obsolete task;
• retry indefinitely; or
• hide which event produced which action.

Score the vendor on the behavior you observe and the controls you can configure.

§ 06Is Context and Memory Useful, Correctable, and Governed?

Criterion 3 covers what the AI employee knows across work sessions.

Persistent memory can reduce repeated prompting. It can also preserve a false fact, stale policy, confidential detail, or malicious instruction. The buying question is not “Does it have memory?” It is “Can we govern what becomes memory, where it applies, when it expires, and how it is corrected?”

The full design problem is covered in the guide to AI employee memory. At platform-selection stage, test the minimum controls directly.

Distinguish five context layers

A single undifferentiated “memory” box makes conflicts difficult to resolve.

Test correction, conflict, and expiry

Give the platform an old policy, then provide a newer authoritative version. Ask it to perform a task where the two conflict.

The system should:

• prefer the defined authoritative source;
• expose the conflict;
• avoid silently blending incompatible rules;
• show which source affected the decision;
• let an authorized user correct or remove the bad record; and
• prevent one customer or role’s context from leaking into another.

Ask what memory is not

Vendors often combine the following objects under one label:

• chat history;
• retrieved documents;
• vector search;
• generated summaries;
• saved preferences;
• task state; and
• long-term learned records.

Ask which layer stores each object, who can see it, how long it remains, whether it is used for model training, and what deletion actually removes. A memory feature without a lifecycle is a future incident queue.

§ 07Can the Platform Perform the Role’s Real Actions?

Criterion 4 covers tools and action capability.

A platform that can draft a perfect update but cannot read the approved data, write to the task system, or send through the governed channel may still leave the human as workflow operator.

List the role’s required actions before evaluating connectors.

Build an action inventory

“Connects to the CRM” earns no credit if the role needs an unsupported object or write operation.

Evaluate four action modes

1. API or native connector: structured, often easier to scope and validate.
2. Browser or computer use: broad reach, but interface changes and session state matter.
3. Code execution: flexible, but sandboxing, secrets, dependencies, and output validation matter.
4. Artifact generation: documents, spreadsheets, presentations, code, media, or dashboards.

One mode is not universally superior. Score the mode against the specific task, evidence needs, and failure exposure.

Test the last mile

Ask the vendor to complete the full chain:

1. identify the correct source;
2. retrieve the correct record;
3. transform or reason over it;
4. create the required artifact;
5. place it in the correct destination;
6. update task state;
7. request approval if needed; and
8. return evidence.

Many demos stop at step 4. Operational value often depends on steps 5-8.

§ 08Can You Restrict Authority at the Action Level?

Criterion 5 receives the highest sample weight because tools turn model errors into business actions.

A connected account is not a permission model. “The agent can use Gmail” does not tell you whether it can read, draft, send, delete, change settings, contact any recipient, or act only inside an approved thread.

Use the detailed AI employee permissions and approvals framework to design the role. During vendor selection, require the platform to implement that design.

Ask for an action envelope

The platform should enforce the boundary. A prompt that says “please do not” is an instruction, not an authorization control.

Test denial and revocation

Run three cases:

1. ask the role to perform an explicitly denied action;
2. revoke a connector or permission while a task is open; and
3. alter the target or parameters after an approval is granted.

Expected behavior:

• the denied action does not execute;
• revocation takes effect predictably;
• the task moves to a visible blocked state;
• the approval applies only to the exact reviewed action;
• replay or parameter substitution is rejected; and
• the event appears in the audit record.

OpenAI’s agent guide recommends pairing guardrails with authentication, authorization, access controls, and normal software security measures. It also identifies high-risk or irreversible actions and repeated failure as reasons for human intervention.

OWASP’s AI Agent Security Cheat Sheet similarly recommends least-privilege tools, explicit approval for high-impact actions, action previews, audit trails, interruption, and separate validation of irreversible execution.

Score the enforced path

Do not award points for controls the vendor says it can custom-build later.

§ 09Can Work Pause, Resume, Transfer, and End Cleanly?

Criterion 6 covers task state and handovers.

Long-running work does not move directly from started to done. It waits for data, approval, a reply, a scheduled follow-up, another role, or a changed condition.

Require explicit task states

A useful minimum is:

• queued;
• in progress;
• waiting on external event;
• waiting on human;
• blocked;
• completed;
• failed;
• canceled; and
• reopened.

The exact labels can differ. The state transitions should not be hidden inside prose.

Inspect the handover object

A handover should carry:

• original outcome;
• work completed;
• evidence created;
• decisions made;
• source versions used;
• actions taken;
• permissions consumed;
• unresolved questions;
• current status;
• next action;
• next owner; and
• deadline or wake condition.

“Here is what I did” is a summary. “Here is the accepted state from which the next actor can continue” is a handover.

Test three interruptions

1. Session interruption: stop midway and resume later.
2. Human dependency: require approval, then approve with a modification.
3. Role transfer: move the task to another agent or a person.

The platform should not repeat completed actions, lose the modified approval, or declare success before the postcondition is true.

Define completion as a postcondition

For a weekly report, document generated may be insufficient. Completion might require:

• correct reporting period;
• all required sources present;
• calculations reconciled;
• report stored in the approved folder;
• owner notified;
• evidence attached; and
• no unresolved critical exception.

Task state is how a platform turns impressive outputs into dependable operations.

§ 10Can You Reconstruct What Happened?

Criterion 7 covers observability and audit evidence.

An AI employee can make decisions across many tool calls and work sessions. A supervisor needs more than a final answer and a token total.

Require three evidence layers

A polished natural-language recap can help humans scan. It should not be the only record.

Ask for correlation and export

You should be able to connect:

trigger → run → source → decision → approval → tool action → result → task state

Test whether the platform can:

• search by task, customer, role, action, and time;
• correlate a tool action to the triggering event;
• distinguish proposed from executed action;
• show retries and partial failures;
• preserve approval evidence;
• export records;
• restrict log access;
• redact sensitive fields; and
• apply a retention policy.

Test a failed run, not just a successful one

Disable a tool after a run has been configured to use it. Then ask:

• Did the run retry?
• How many times?
• Did any partial action succeed?
• Was the task status correct?
• Did the user receive the right escalation?
• Can an evaluator reconstruct the sequence without asking the agent to remember it?

NIST’s AI Risk Management Framework Core treats documentation, ongoing monitoring, production behavior, incident response, recovery, override, and change management as lifecycle concerns - not an end-of-project checklist.

§ 11Can the Platform Measure Role Performance and Regression?

Criterion 8 separates activity from accepted work.

Runs, prompts, tokens, messages, and documents are operational telemetry. They do not show whether the role produced useful outcomes.

Define an accepted outcome

For each task type, specify:

• required fields;
• quality rubric;
• source requirements;
• allowed actions;
• approval state;
• completion evidence;
• exception rule; and
• reviewer.

Then measure:

Require a regression set

The platform, model, tools, prompts, policies, and source data will change. Keep a versioned test set containing ordinary cases, known failures, and abuse cases.

Run it:

• before deployment;
• after a model or prompt change;
• after a connector or permission change;
• after a memory or retrieval change;
• after an incident; and
• on a regular schedule.

OpenAI’s practical guide advises teams to establish a performance baseline with evaluations before optimizing model cost and latency. NIST likewise calls for documented test sets and performance evidence under conditions similar to deployment.

Separate model evaluation from role evaluation

A reasoning benchmark can show that an engine performs well on a defined set of research tasks. It does not prove:

• correct account access;
• reliable event handling;
• action authorization;
• governed memory;
• handover quality;
• recovery from your tool failures;
• accepted business outcomes; or
• predictable unit economics.

Credit a benchmark only inside the criterion it actually measures. Then run the role test.

§ 12Does the Platform Support the Team You Need?

Criterion 9 covers delegation and multi-role coordination.

Do not buy a multi-agent architecture because the diagram looks organizational. A second role is useful only when specialization, independent verification, access separation, or workload routing improves the outcome enough to justify more coordination.

Anthropic’s guidance on building effective agents recommends adding complexity only when it demonstrably improves results. It also notes that autonomy can increase cost and compound errors.

Compare three coordination patterns

Use the general-purpose versus specialized AI agent architecture guide to score task variance, context, tool choice, permission separation, evaluation, coordination, and accepted-system-outcome cost before awarding points for team features.

Test delegation as a contract

When one role delegates to another, inspect:

• task identity;
• requested outcome;
• relevant context;
• data and tool boundary;
• deadline;
• acceptance rubric;
• authority;
• evidence returned;
• failure path; and
• final accountable owner.

A message between agents is not a governed handover.

Check blast-radius control

Multi-agent systems can multiply access and error propagation. Ask whether:

• roles have separate permissions;
• one role can grant authority to another;
• shared memory is scoped;
• inter-agent messages are attributable;
• a compromised task can spread;
• recursion and delegation depth are capped; and
• the whole team can be paused centrally.

If the intended role works as one bounded agent, team features should have a low weight. Buy the simplest architecture that proves the outcome.

If the first role later exposes a stable reason to add workers or a manager, design the operating model before expanding the org chart. The AI organization framework covers ownership, interfaces, shared state, escalation, supervision, controls, and coordination economics.

§ 13Is the Model Capability Relevant to the Whole Job?

Criterion 10 covers the reasoning and production engine under the employee scaffolding.

Model quality matters. A persistent role built on weak reasoning will persistently produce weak work. But “uses the latest models” is not an evaluation result.

Map capabilities to role stages

A general-purpose platform may be valuable when one role needs research, spreadsheets, documents, code, images, or dashboards in the same workflow. A specialized platform may outperform it when one narrow task benefits from proprietary data, dedicated interfaces, and deeply tuned workflows.

Ask how models are selected

Evaluate:

• fixed versus configurable model;
• routing by task or risk;
• fallback behavior;
• latency and cost tradeoffs;
• context limits;
• supported modalities;
• model-change notification;
• regression testing after upgrades;
• provider and regional constraints; and
• whether model choice changes data terms.

Use benchmark evidence precisely

For every benchmark, record:

• task set;
• sample size;
• date;
• judge;
• metric;
• tested product or model;
• configuration;
• public reproducibility;
• relationship to your workflow; and
• what the benchmark does not measure.

“Ranked first in research” supports a research-capability claim when the result is current and reproducible. It does not support “best AI employee platform” without action, governance, reliability, and economic evidence.

§ 14Can You Forecast Total Cost per Accepted Outcome?

Criterion 11 covers pricing and total cost.

Plan price is only one term. Seats, credits, tasks, model tokens, runtime, tool calls, storage, concurrency, and successful outcomes can all be billing units.

Use the full AI employee cost framework when building a business case. During vendor selection, normalize every candidate against the same workload.

Calculate the complete operating cost

monthly operating cost = subscription + usage + integration + supervision + correction + monitoring + failure exposure

Then:

cost per accepted outcome = monthly operating cost ÷ accepted outcomes

Illustrative example:

Platform A has the lower vendor bill. Platform B has the lower cost per accepted result.

The numbers are illustrative, not market benchmarks.

Run a fixed-workload pricing test

Give each vendor the same:

• 20 ordinary tasks;
• five hard tasks;
• three failure cases;
• output quality requirement;
• review standard;
• tool set;
• concurrency;
• context volume; and
• time window.

Record billed units, failed attempts, retries, reviewer time, and accepted outcomes.

Ask about the edges

Verify:

• minimum commitment;
• included usage;
• overage;
• credit expiry;
• premium model multipliers;
• tool or connector fees;
• storage;
• background or scheduled-run charges;
• failed-run charges;
• retry charges;
• support tier;
• implementation services;
• cancellation;
• data export; and
• price-change notice.

Pricing pages change. Check the vendor’s live terms on the decision date. CellCog, for example, currently publishes credit-based pricing and explains that more complex operations use more credits; a buyer should still measure credits against a representative role workload.

§ 15Does the Data and Security Posture Fit the Deployment?

Criterion 12 covers the complete information path, not only the base model.

An AI employee may receive data from email, documents, databases, browser sessions, connected apps, human prompts, long-term memory, logs, and other agents. Map all of it.

Build a data-flow record

Evaluate the whole supply chain

Ask about:

• hosting provider;
• model providers;
• connector or integration brokers;
• email, voice, or messaging providers;
• analytics and error monitoring;
• support tooling;
• data residency;
• encryption;
• identity and access;
• tenant isolation;
• backups;
• vulnerability management;
• incident response; and
• contractual commitments.

Certifications can provide useful third-party evidence. They do not replace your workflow-specific review.

Test portability and exit

Before purchase, ask the vendor to show how you export:

• role instructions;
• task history;
• memory or learned records;
• generated artifacts;
• evaluation sets and results;
• audit evidence;
• connector configuration; and
• usage and cost data.

Then ask what is deleted after termination and on what timeline.

A system can be easy to start and difficult to leave. Portability belongs in selection, not offboarding.

§ 16Which Type of AI Employee Platform Fits the Role?

The category contains different product shapes. Compare the shape before comparing logos.

If the shortlist mixes a managed platform with an internal architecture, run the build-versus-buy AI employee lifecycle comparison before assigning a platform score. It prevents a prototype estimate from being compared with a subscription that already includes parts of the runtime, connector, memory, and operating layer.

Choose an assistant-first product when

• work is irregular;
• the user benefits from constant collaboration;
• the output is advisory;
• a person naturally owns follow-through; and
• standing access would add more risk than value.

Choose a workflow builder when

• the sequence is known;
• rules can be expressed deterministically;
• inputs and outputs are structured;
• exceptions are limited; and
• predictability matters more than open-ended judgment.

Choose a specialized platform when

• one high-volume role drives the business case;
• domain data or workflow depth matters;
• the product has evidence on your exact channel and outcome; and
• specialization offsets vendor concentration.

Choose a general-purpose AI employee platform when

• the role crosses applications and artifact types;
• work is recurring but not fully deterministic;
• persistent task state and follow-through matter;
• one role may later coordinate with others; and
• the buyer wants to configure jobs rather than build agent infrastructure.

Choose an internal build when

• the workflow is a durable competitive advantage;
• data or execution constraints cannot be met by a vendor;
• the engineering team can own evaluation, observability, security, and upgrades;
• time to first value is less important; and
• the three-year ownership cost is justified.

Platform shape narrows the field. The 12-point scorecard chooses within it.

§ 17What Should You Ask a Vendor to Prove in the Demo?

A demo should be a controlled evidence session, not a product tour.

This is a shortlist test - not the complete pilot design.

Send the vendor the same six cases

1. Normal case: complete the ordinary workflow.
2. Missing-input case: identify the missing prerequisite and stop correctly.
3. Conflicting-source case: apply the defined source hierarchy.
4. Denied-action case: refuse an action outside the role’s authority.
5. Tool-failure case: contain partial work, cap retries, and escalate.
6. High-risk case: preview the exact action and route approval.

Watch the operator, not only the output

Ask the vendor to show:

• role configuration;
• trigger setup;
• memory source and correction;
• tool permission;
• approval policy;
• task state;
• run evidence;
• failure record;
• cost or usage record; and
• export.

If the vendor hides setup behind a services team, price and score that dependency.

Capture proof in a decision log

A later procurement process may ask dozens of legal, technical, and commercial questions. Use the 50-question AI employee platform RFP after this shortlist test to request architecture, configuration, logs, tests, assurance, pricing, and contract evidence without turning the first demo into a generic security questionnaire.

Once mandatory proof gaps are closed, use the AI employee pilot decision framework to freeze the baseline, representative sample, staged authority, KPI thresholds, budget, and go/revise/switch/stop rules before scored work begins.

§ 18What Are the Red Flags When Choosing an AI Employee Platform?

Most red flags are evidence problems, not missing buzzwords.

Beware the feature-parity trap

Two vendors may both list memory, tools, approvals, and schedules. They can still differ dramatically in:

• granularity;
• defaults;
• configuration burden;
• evidence;
• failure behavior;
• scale;
• operator usability; and
• contractual commitment.

Score the operating behavior.

Beware the demo-quality trap

A good result can come from:

• vendor-selected data;
• hidden preparation;
• expert prompt engineering;
• a manually repaired run;
• broad permissions;
• unlimited retries; or
• an expensive model configuration.

Ask to reproduce the result in your environment with visible settings and billing.

Beware the average-score trap

A platform with excellent output breadth and low price can still be wrong for a role if it cannot:

• enforce the approval boundary;
• recover from a partial action;
• prevent cross-account context leakage;
• meet retention policy; or
• show what it changed.

Gates protect the buyer from averaging away existential risk.

§ 19How Does CellCog Map to the 12-Point Framework?

CellCog positions itself as a general-purpose AI employee platform. Its current public materials provide evidence for several scorecard areas, but a buyer should still run the same role-specific proof required of every vendor.

The assessment below reflects public pages reviewed in July 2026. Product behavior, terms, and documentation can change.

What the public product material establishes

CellCog’s AI Employees page describes an employee with goals, permissions, an inbox, task board, persistent memory, shifts, event-based wake conditions, KPI dashboards, tools, approvals, and handovers. These are relevant category signals. They are not a substitute for your configured denial, failure, and outcome tests.

How to interpret the benchmark

CellCog’s benchmark page reported in July 2026 that CellCog Max ranked first on the public DeepResearch Bench leaderboard, with a 55.78 overall score under the stated judge and methodology.

That is relevant evidence for research capability. It does not by itself establish:

• reliable scheduling;
• correct connector use;
• permission enforcement;
• handovers;
• audit completeness;
• role-level acceptance;
• security fit; or
• cost per accepted outcome.

Score it under model capability, verify the public leaderboard, and then test the role.

How to interpret the privacy material

CellCog’s current privacy policy describes AI employee configuration, mailbox content, memory and work artifacts, connected-account actions, service providers, US-based hosting, encryption, retention, and access, correction, deletion, and portability rights.

That transparency helps a buyer map the data flow. A procurement team should still verify how the policy and contract apply to its plan, users, data classes, regions, deletion requirements, authentication model, and assurance needs.

The fairest CellCog shortlist test

Configure one real role. Then require CellCog to:

1. wake from a normal trigger;
2. retrieve the correct context;
3. complete a multi-modal work product if the role needs one;
4. attempt and refuse a denied action;
5. request an exact approval for a high-risk action;
6. survive a connector failure;
7. hand over an unfinished task;
8. show the evidence chain;
9. report role KPI and usage; and
10. export the records the buyer needs.

If the role passes its gates and score threshold, move CellCog into the named-vendor comparison. If it does not, the framework should say so.

§ 20How Do You Make the Final Platform Decision?

Use a three-part decision rule:

advance = all gates pass AND weighted score clears threshold AND open risks have an accepted treatment

First, compare evidence quality

Do not compare one vendor’s pilot score with another vendor’s marketing score as if both numbers mean the same thing.

Your final table should include:

These are illustrative results.

Second, inspect the score shape

Two vendors with 82 points may create different decisions.

• One may be balanced across every criterion.
• One may dominate model capability and tools but trail on evidence and control.
• One may fit the first role but not the likely second role.
• One may require more implementation work but create stronger long-term ownership.

Review the individual criteria, not just the total.

Third, write a reversible decision

A good decision memo states:

• selected role;
• selected platform and shape;
• rejected alternatives;
• gates and evidence;
• score and weights;
• known limitations;
• allowed deployment boundary;
• supervisor;
• review date;
• expansion conditions;
• pause conditions; and
• exit path.

The first purchase should authorize a bounded role, not declare a universal platform winner.

§ 21A Copyable AI Employee Platform Evaluation Template

Use this structure for each vendor:

Role and decision context

• Role:
• Recurring outcome:
• Supervisor:
• Systems:
• Allowed actions:
• Prohibited actions:
• Approval boundary:
• Acceptance rubric:
• Monthly volume:
• Risk level:

Non-compensating gates

• High-risk actions require enforceable approval.
• Access can be revoked centrally and promptly.
• Runs can be interrupted; retries and spend are bounded.
• Actions, approvals, and task state are reconstructable.
• Data processing, retention, deletion, and contract fit policy.

Weighted score

Decision

• Gates:
• Weighted score:
• Cost per accepted outcome:
• Evidence gaps:
• Risk treatments:
• Decision:
• Decision owner:
• Valid until:

§ 22AI Employee Platform Selection Checklist

Role readiness

• One recurring outcome is defined.
• Inputs and authoritative sources are named.
• Required and prohibited actions are listed.
• The supervisor and escalation path are explicit.
• Acceptance evidence and stop conditions are written.
• A representative test pack exists.

Evidence design

• Every vendor receives the same cases.
• Evidence scores use one 0-5 definition.
• Weights total 100 and reflect role risk.
• Gate failures cannot be averaged away.
• Scores include a link or artifact.
• Evidence dates and evaluators are recorded.

Operating capability

• The role resumes after interruption.
• Duplicate triggers do not duplicate actions.
• Memory can be inspected, corrected, and scoped.
• Required tools support exact operations.
• Denied actions are technically blocked.
• Approvals bind to the reviewed action.
• Connector revocation changes behavior.
• Task states cover waiting, failure, cancellation, and reopen.
• Handovers preserve obligations and evidence.

Reliability and measurement

• Runs correlate triggers, decisions, approvals, actions, and results.
• Failed and partial runs are visible.
• Logs are searchable and exportable.
• Accepted outcomes are defined.
• Review and correction time are counted.
• Regression tests cover ordinary, edge, and abuse cases.
• Model or configuration changes trigger reevaluation.

Economics and governance

• Pricing is normalized against one workload.
• Failed runs, retries, background work, and review are included.
• Cost per accepted outcome is calculated.
• Data flow and subprocessors are mapped.
• Retention, deletion, and training use are understood.
• Identity, access, incident, and recovery controls fit the role.
• Role data and evidence can be exported.
• Expansion, pause, and exit conditions are documented.

§ 23The Short Version

Choose an AI employee platform in this order:

1. define one role;
2. write the action and risk boundary;
3. create a representative test pack;
4. set non-compensating gates;
5. assign role-specific weights to the 12 criteria;
6. score evidence from claim to production-like proof;
7. compare platform shapes;
8. normalize total cost per accepted outcome;
9. document limitations and risk treatments; and
10. authorize only a bounded first deployment.

The point is not to find the vendor with the most AI. It is to find the operating system that can own the right work, prove what happened, and return control when the boundary is reached.

If CellCog fits your winning platform shape, inspect its AI Employee operating layer and score it with the template above. Then compare it with the relevant alternatives on the AI employee platform comparison page.