How to evaluate enterprise AI agent platforms

An enterprise AI agent platform should earn the right to act inside your company. A polished demo proves that a model can complete a prepared task. It says almost nothing about whether the platform can contain a compromised agent, explain an expensive mistake, recover a half-finished workflow, or let you leave without rebuilding every integration.

I evaluate these platforms as operating systems for delegated work, not as chat interfaces with extra buttons. Security sets the boundary, orchestration controls the work, observability supplies evidence, and exit criteria cap the long-term risk. If a candidate fails a hard gate in any one of those areas, a high total score should not rescue it.

Score the failure path, not the prepared demo

A useful evaluation starts with the failures your team must own after the vendor leaves the room. Ask each vendor to run the same production-shaped tasks, with the same tools, data classes, approval rules, and deliberate faults. Otherwise you compare demo engineering rather than platforms.

Write four or five workloads before you see a product. Each workload should have a clear trigger, allowed data, permitted actions, success condition, maximum cost, and owner. Include one read-only research task, one action that changes a business system, and one long-running task that must resume after interruption. Add a hostile or malformed input and a dependency timeout. Those cases expose the control plane faster than another hour of happy-path prompting.

A procurement team often asks whether an agent completed the task. That binary outcome hides most of the risk. Record whether it chose the permitted tool, requested approval at the correct boundary, passed only necessary data, stayed inside its budget, produced an intelligible trace, and left external systems consistent after failure. A result can be factually correct and operationally unacceptable.

Use hard gates before weighted scoring. A platform should fail the evaluation if it cannot enforce workload identity, restrict tool permissions, export audit evidence, or produce a credible exit plan. Weighted categories come later. This prevents an excellent user interface and a fast model from compensating for missing controls.

Do not let the vendor choose the operator. Your own engineer or analyst should configure at least one workflow from a blank project using ordinary documentation and support channels. Measure the hidden labor: policy setup, connector debugging, evaluation maintenance, incident review, and upgrades. The license is only one line in the cost model.

Security starts with delegated authority

The security question is not whether the model is safe. It is whether the platform limits what an unreliable decision maker can see and do. Models will misread instructions, accept poisoned context, and select the wrong tool. The platform has to make those errors containable.

Start with identity. Every agent run needs a workload identity distinct from the user who designed it and from the service account behind a connector. That identity should carry the tenant, environment, workflow version, and run identifier into authorization and audit records. Shared API keys destroy attribution and make revocation far too broad.

Then inspect authorization at the action level. A connector permission called CRM access is not enough. A research agent may read a limited set of accounts but must not export contacts or alter ownership. A support agent may draft a refund but cannot issue it above a threshold without approval. Ask the vendor to demonstrate the denied action, not just the configured policy. The denial should appear in the trace with the policy version and reason.

OWASP's guidance for applications built with large language models treats prompt injection and excessive agency as separate risks. That distinction matters. Filtering suspicious text does not reduce the authority already granted to an agent. Limit tools, parameters, data scope, transaction value, run time, and call count even when the input looks clean.

Secrets should be resolved at execution time and scoped to the smallest useful action. The model should never receive raw credentials in its context. Check how the platform rotates secrets, separates development from production, handles connector refresh tokens, and revokes access for a single workload without breaking unrelated agents.

Finally, test human approval as an authorization event. The prompt must show the exact action, target, material parameters, and relevant data change. An Approve button beside a vague summary creates approval theater. The system must bind the approval to that precise action so the agent cannot change parameters after the person accepts.

Orchestration must make retries boring

Good orchestration turns an agent's uncertain reasoning into controlled state transitions. The platform should separate planning, tool execution, approval, retry, compensation, and completion instead of burying the entire run in one opaque conversation.

Ask what happens when a workflow stops after it has changed one system but before it changes the next. A platform that simply reruns the prompt may duplicate a payment, reopen a ticket, or send the same message twice. You need durable state, idempotency keys for side effects, bounded retries, and compensation logic where reversal is possible. For irreversible actions, the workflow should pause for an operator rather than improvise.

Long-running agents need explicit lifecycle states. Pending, running, waiting for approval, waiting for dependency, retrying, completed, failed, cancelled, and compensating are a practical minimum for most systems. Names can differ, but operators must be able to distinguish a slow run from an abandoned one. Each transition needs a timestamp, cause, actor, and workflow version.

Concurrency controls deserve a live test. Run two agents against the same record and observe how the platform detects a stale read or conflicting update. Look for optimistic locking, queues, or application-level guards that fit your systems. A global one-run-at-a-time switch avoids conflict by killing throughput, while unlimited concurrency pushes consistency failures into downstream tools.

Versioning is part of orchestration. A run should remain attached to the prompt, policy, tool schema, model configuration, and workflow definition that started it. If a deployment changes mid-run, the platform must either pin the old version or migrate state through an explicit rule. Silent mixing creates incidents that nobody can reproduce.

Test cancellation too. The operator should stop future actions while preserving evidence about completed ones. Cancellation cannot retract an email or undo an approved transfer, so the interface must report residual effects plainly. A reliable platform makes partial completion visible instead of calling the whole run cancelled and moving on.

Observability must reconstruct a decision

Agent observability should answer who asked for what, what context the model received, why it selected an action, which policy allowed it, what the tool returned, and what the run cost. A transcript alone cannot answer those questions reliably.

Require structured events that join across the full path. OpenTelemetry gives teams a common model for traces, metrics, and logs, and its semantic conventions are the sensible starting point. Agent-specific fields still change across implementations, so keep your own stable business identifiers alongside vendor fields. At minimum, preserve the trace ID, run ID, workflow version, model configuration, tool name, policy decision, approval identity, token usage, latency, and outcome.

A normalized tool event can look like this:

{
  "trace_id": "01J...",
  "run_id": "refund-1842",
  "workflow_version": "7",
  "event": "tool.completed",
  "tool": "billing.issue_refund",
  "policy_decision": "allow_with_approval",
  "approval_id": "apr-992",
  "duration_ms": 842,
  "input_classification": ["customer", "financial"],
  "output_ref": "vault://runs/refund-1842/tool-3",
  "status": "success"
}

The event stores references to protected payloads instead of spraying sensitive content through logs. During the pilot, test redaction with realistic personal data, secrets, attachments, and tool errors. Confirm that authorized investigators can retrieve the original under a separate access policy and that routine dashboards cannot.

Observability also needs business outcomes. A run that ends without a technical error may still produce an unusable answer or leave a case unresolved. Join technical traces to a domain result such as accepted draft, reconciled invoice, resolved ticket, or human correction. That connection lets you find expensive success states that conventional uptime charts miss.

Export matters more than the built-in dashboard. Send raw events to a system your company controls, verify schema documentation, and replay a sample into your incident tooling. If evidence lives only inside the vendor interface, your incident response and migration plans both depend on the vendor staying available.

Evaluation measures safe behavior, not eloquence

An agent evaluation set should measure task quality, policy compliance, side effects, and recovery separately. One blended quality score makes a charming but unsafe agent look better than it is.

Build cases from real work after removing sensitive data. Each case needs an input, permitted evidence, expected outcome, forbidden actions, budget, and grading method. Some outputs can use deterministic checks, such as whether the correct record changed once. Open-ended analysis needs a rubric and periodic human review. Model-based graders can help with scale, but calibrate them against decisions made by people who understand the work.

NIST's AI Risk Management Framework separates governance, mapping, measurement, and management. I use that as a reminder that a benchmark is not a control program. A strong score on a static set does not tell you who accepts residual risk, how new failures enter the set, or when a degrading workflow gets suspended. Assign those decisions before launch.

Run adversarial cases that cross system boundaries. Put an instruction inside a retrieved document that asks the agent to ignore policy. Return a tool result containing a second instruction. Remove a permission midway through a run. Delay an approval until the underlying record changes. Feed the agent two customers with similar names. These are ordinary control tests, not attempts to prove that a model is evil.

Track correction burden alongside completion. Count how often a person rewrites an output, changes a selected action, supplies missing context, or repairs a downstream record. Automation that completes many runs while creating quiet cleanup work can look efficient in platform metrics and lose money in the operating budget.

Define release thresholds per workflow risk. A drafting assistant can tolerate a different error profile from an agent that changes access rights. Any forbidden action should trigger a failed gate, even when the rest of the evaluation passes. Average scores are useful for trend lines, never for excusing a severe control breach.

Governance needs owners and stop conditions

Governance works when named people can change, suspend, and retire an agent based on evidence. A committee charter and a policy library help, but neither controls a production run by itself. Put decision rights into the operating model and test them through the platform.

Every workflow needs a business owner who accepts the outcome, a technical owner who maintains the implementation, and a risk owner who sets the control conditions. Those roles may sit with two people in a small company, but the responsibilities cannot disappear. Record who can approve a release, widen a permission, change a model, accept an exception, and order an immediate stop.

Define stop conditions before launch. Examples include a forbidden action, repeated policy denials that suggest a bad loop, a sudden increase in human corrections, missing audit events, cost above the run budget, or an evaluation score below its release floor. Connect automatic conditions to a safe state where possible. A suspended agent should stop new side effects, preserve current evidence, and tell an operator which external changes already happened.

Model and prompt changes need the same discipline as application releases. Store the proposed version, evaluation results, reviewer, approval, rollout scope, and rollback target. Use a small initial cohort for changes that can alter actions. If the platform updates a managed model without offering version control, require notification and an evaluation run before the affected workflow returns to full volume.

Exception handling is where governance often collapses. A team grants broad access for a deadline, approves a weak trace export for a pilot, or disables an evaluation that produces false alarms. Each exception needs an owner, reason, compensating control, expiry date, and closure test. The platform should surface expired exceptions instead of letting temporary access become the normal configuration.

Create an incident path for agent behavior, not only infrastructure outages. The responder must be able to pause the workflow, revoke its identity, find all related runs, identify completed side effects, protect evidence, and notify the business owner. Practice that sequence with a seeded incident. If it requires a vendor ticket before your team can contain the agent, record the dependency as a control gap.

Retirement also needs an owner. Remove triggers, revoke credentials, close pending approvals, archive required evidence, delete unneeded data, and update downstream processes that expected the agent's output. An inactive workflow with live credentials still carries risk. The final retirement record should show that no scheduler, webhook, or user can start it again.

Governance evidence belongs in the same scorecard as technical controls. Score whether owners completed a release, exception, incident, and retirement exercise using the candidate platform. Written claims deserve less weight than actions your team has performed under realistic pressure.

Enterprise fit includes ownership and operating cost

Enterprise readiness depends on who can run the platform after deployment and what that operation costs. A feature list rarely exposes either answer. Map every recurring responsibility to your team, the vendor, or a named partner before signing.

Inspect deployment boundaries and data flow. Document where prompts, retrieved content, tool inputs, outputs, traces, evaluation data, and backups reside. Ask which subprocessors receive each class and how deletion propagates. Data residency claims need to cover operational telemetry and support copies, not only the main database.

Administrative separation matters in smaller companies too. The person who builds an agent should not silently grant it production authority and approve its sensitive actions. Test roles for workflow author, policy administrator, connector administrator, approver, operator, auditor, and billing owner. One person may hold several roles, but the platform should record which authority they used.

Calculate cost per accepted business result, not cost per model call. Include model tokens, platform fees, connector charges, storage, evaluation runs, human approvals, corrections, incident work, and the engineering time needed to maintain prompts and policies. Run the same workload at ordinary volume and at a burst level. Watch queue delay, rate-limit behavior, and fallback model pricing.

Support should be tested during the pilot. File a technical question with a trace ID and incomplete symptoms. See whether the vendor can inspect the right evidence without requesting unrestricted data access. Ask who responds to a production control failure, which channels exist, and how changes that affect behavior are announced. Contract language cannot compensate for a support process that has never handled an agent incident.

Also check internal skill requirements. If only one specialist understands the workflow language, policy engine, and tracing model, you have created a staffing dependency. Have a second engineer diagnose a seeded failure using the runbook. The time and missing permissions will tell you more than a training catalog.

Exit criteria belong in the first scorecard

You should define how to leave an AI agent platform before you decide how to enter it. Exit criteria turn vague portability promises into evidence that procurement, engineering, and finance can inspect.

List the assets you must recover: workflow definitions, prompts, tool schemas, policies, evaluation cases, run history, audit events, approvals, knowledge indexes, connector configuration, and cost records. For each asset, record the export format, API or batch method, frequency, owner, retention need, and replacement destination. Screenshots and vendor-specific reports do not count as portable data.

Separate model portability from platform portability. Changing a model endpoint may be easy while leaving the orchestration engine, policy semantics, identity system, evaluation history, and connectors fully proprietary. Vendors often demonstrate the first and imply the second. Ask your team to move one representative workflow to a small independent harness during the pilot. Measure what must be rewritten and which behavior cannot be reproduced.

Contract terms should support the technical plan. Check export access after termination notice, deletion timing, assistance rates, log retention, format documentation, and access to encryption keys where relevant. Establish who pays cloud egress and how long a full export takes at your expected volume. These are operating questions, not legal decoration.

Set trigger conditions as well as procedures. A material price change, loss of a required deployment region, repeated control failures, an unacceptable model restriction, or the end of a necessary connector may start a review. The trigger should identify a decision owner and a time box. Without triggers, an exit plan becomes a document that nobody invokes.

Run the export test before final approval and repeat it on a schedule. Import the data into a neutral store, verify record counts and relationships, and reconstruct one historical incident without the vendor dashboard. If the exercise fails, score the gap as current lock-in rather than future technical debt.

Use a weighted scorecard with nonnegotiable gates

A scorecard makes tradeoffs visible, but only if the team writes scoring anchors before vendor meetings. I use a 0 to 4 scale: 0 means absent, 1 means claimed or manual, 2 means partial and demonstrated, 3 means complete for the tested scope, and 4 means complete, exportable, and proven under failure.

This configuration is small enough to keep in version control and strict enough to stop score inflation:

scale:
  min: 0
  max: 4
gates:
  - workload_identity
  - action_level_authorization
  - immutable_audit_export
  - workflow_state_recovery
  - tested_exit_export
categories:
  security: 30
  orchestration: 20
  observability: 15
  evaluation_and_governance: 15
  enterprise_operations: 10
  portability_and_exit: 10
decision:
  minimum_weighted_score: 75
  minimum_category_score: 2
  gate_rule: every_gate_must_pass

The numbers are a starting policy, not a universal truth. Raise security or governance weight for agents with regulated data or material transaction authority. Keep each category weight explicit and total them to 100 so every late change has a visible tradeoff. Do not adjust weights after seeing which vendor benefits.

Each scored row needs an evidence reference and an owner. Acceptable evidence includes a recorded test, exported event sample, policy file, contract clause, architecture note, or incident exercise. A salesperson's yes belongs at score 1 until the team sees the control work. Add a short rationale describing the tested limitation, because a bare number becomes meaningless during review.

Require category floors as well as a total threshold. A platform with superb orchestration and weak observability can still reach a respectable average. The floor exposes that imbalance. Keep hard gates binary and few; if everything becomes a gate, the team will quietly waive them.

Finally, score the current internal alternative with the same method. Buying nothing has costs and risks, while building a thin control layer around direct model APIs may outperform a large platform for a narrow workload. The comparison stops the evaluation from assuming that one vendor must win.

A pilot must leave production-shaped evidence

The pilot should end when the team has enough evidence to make and defend a decision, not when a calendar expires. Limit the scope to a few representative workflows, but connect them to real identity, policy, observability, and incident processes in a controlled environment.

Start with written hypotheses. For example: an operator can reconstruct any side effect within thirty minutes; revoking a workload identity stops new tool calls; a failed two-system update resumes without duplicating the first change; and a full export can rebuild the evaluation history outside the platform. Replace the timing and scope with values your team can actually support.

Establish a baseline before the agent handles the workload. Measure the current completion time, queue delay, correction effort, escalation rate, infrastructure cost, and accepted output using the same definition you will apply to the pilot. Sample the work rather than trusting a team estimate. Without a baseline, a quick demonstration can claim time savings while shifting review and repair work to people outside the measured process. Keep the sampled cases and their grading notes so later platform updates face the same comparison rather than a revised story.

Use shadow mode when the workflow can support it. Let the agent propose decisions and tool calls while the existing process remains authoritative, then compare both paths at the level of individual cases. Shadowing exposes false confidence and missing context without creating external side effects. It cannot test approval binding, idempotency, or compensation, so follow it with controlled live actions. Record the point where you move between modes and the evidence that justified the added authority.

Assign an owner for platform configuration, security review, workflow quality, operations, finance, and the final decision. Vendors can assist, but your employees must execute the decisive tests. Keep a decision log when the team accepts a limitation or changes a test, including who approved the change and why.

Seed failures deliberately. Expire a credential, return malformed tool data, hit a rate limit, change a record while approval waits, cancel a run after one side effect, and deploy a new workflow version during another run. Capture traces, operator actions, recovery time, residual effects, and support interactions. Do not accept a verbal explanation when the platform cannot run the case.

The pilot package should contain the filled scorecard, raw evidence references, data-flow map, cost model, role map, risk exceptions, exit export, and a recommendation with conditions. A conditional approval may require a missing connector control or contract term before production. A rejection should preserve enough evidence to avoid repeating the same evaluation six months later.

For founders who lack the staff to design these tests while shipping product, a Team & AI Audit can turn the workloads, payroll constraints, and control gaps into a five-day decision package. The service costs $5,000 and comes with a stated guarantee of at least $50,000 per year in identified savings or the fee is waived.

A platform earns approval when your team can constrain it, operate it, investigate it, and replace it. Put one consequential workflow through the failure tests and export drill before negotiating a broad rollout. If the vendor will not support that evaluation, the refusal is evidence and the scorecard already has a place for it.