The wrong question is, “Is this AI agent good?”
The useful question is, “Can this exact agent complete this exact workflow, with these permissions, inputs, and approval rules, without creating more risk or correction work than it removes?”
An agent can write an impressive sample and still be unsafe for client work. The failure may happen in the steps you do not see: using the wrong source, following an instruction hidden in a document, choosing an overpowered tool, retrying until costs climb, changing the wrong record, or completing a high-impact action before a person can stop it.
Evaluate the whole workflow before the agent reaches client data or a live system.
The NIST AI Risk Management Framework offers a useful governing structure: map the context, measure the risks, manage them, and keep governance active throughout the lifecycle. The scorecard below translates that principle into a practical pre-client test.
Quick Takeaways
- Test one agent configuration and one workflow at a time. A general product reputation is not evidence for your use case.
- Start with synthetic or sanitized inputs and read-only access.
- Score source fidelity, permissions, high-impact actions, rollback, logs, security, correction burden, and cost, not only the final answer.
- Use hard stops. A high average score should not compensate for an agent that can send, delete, publish, purchase, or change permissions without approval.
- Include ordinary, ambiguous, incomplete, adversarial, and tool-failure cases.
- Expand access only when the evidence supports the next stage.
Related NisonCo resources: AI agents for business, ChatGPT Work security and privacy, and the AI-native business playbook.
First define the workflow, not the agent
“Help with client work” is too broad to test.
“Read these approved public sources, produce a 500-word research brief with citations, and save it to a review folder without sending or publishing anything” is testable.
Before choosing a product or model, write down:
- the outcome;
- the allowed inputs;
- the allowed tools;
- actions that are prohibited;
- the definition of an acceptable result;
- material failure conditions;
- when the agent must stop and ask;
- the time, retry, and cost limits;
- the person who reviews the result.
This step can reveal that the task does not need an agent. A prompt, template, ordinary automation, or checklist may be cheaper and easier to control. Anthropic's agent-design guidance makes a similar point: add agentic complexity when the task truly needs open-ended planning and feedback, not because autonomy sounds more advanced.
For a plain-English introduction to the category, start with the related resources above before choosing a tool or permission model.
The eight-part readiness scorecard
Score each dimension from 0 to 4:
- 0: absent, unknown, or contradicted by evidence;
- 1: an informal claim with little evidence;
- 2: partly defined and tested on ordinary cases;
- 3: documented and tested on normal plus failure cases;
- 4: independently reviewable evidence, monitoring, an owner, and a retest trigger.
The score is a discussion tool, not a safety certificate. The weakest dimension and every hard stop matter more than the average.
1. Task fit and acceptance
Can the team tell whether the agent succeeded?
A useful test has a bounded task and an acceptance checklist. “Good research” is not enough. Require the sources, structure, dates, exclusions, length, and handoff the reviewer needs.
Also define what a failed result looks like. A missing required source, unsupported claim, wrong client, incomplete file, or unapproved action may be an automatic failure even if the rest of the output is polished.
2. Source fidelity
Can the agent show which source supports a material statement? Does it distinguish a source fact from an inference? Does it stop when the evidence is missing or contradictory?
Test with one source that is outdated, one that conflicts with another, and one question the packet cannot answer. The agent should not smooth over those gaps.
3. Permission scope
List every tool, file, account, folder, and system the agent can reach. Then ask which access is actually required.
The OWASP guidance on excessive agency identifies excessive functionality, permissions, and autonomy as separate sources of risk. A research agent may need to read an approved folder. It probably does not need permission to delete files, send email, change user access, or update the CRM.
Separate read access from write access. Separate one client's workspace from another. Remove old connectors and unused tools before a pilot.
4. Consequential-action gates
Sending, publishing, purchasing, deleting, changing permissions, issuing refunds, contacting a client, and changing a live page should not be treated as ordinary tool calls.
Require approval outside the agent's own recommendation. The same system that proposes a high-impact action should not be the only system deciding that the action is safe.
The agent should be able to prepare a draft, explain the proposed action, name the destination, and wait. The human approves the exact action, not a vague category such as “handle the campaign.”
5. Recovery and rollback
What happens when the agent is wrong halfway through a long task?
A usable workflow needs a stop control, checkpoints, preserved intermediate work, and a way to undo reversible changes. The team should know how to resume from a verified state rather than restarting from a possibly contaminated history.
Test a tool timeout, an unavailable source, a malformed file, and an interrupted run. Recovery is part of the product, not an edge case to discover with a client watching.
6. Observability and audit
Can a reviewer reconstruct what happened?
Record the agent and product version, instructions, inputs, tool calls, outputs, errors, retries, approvals, changes, and timestamps. Do not put passwords, tokens, or unnecessary personal data into the log.
Anthropic's guidance on agent evaluations emphasizes that agents act over many turns, use tools, and modify state. Evaluating only the final paragraph misses the behavior that makes the system agentic.
7. Data handling and security
Use public, synthetic, consented, or sanitized material first. Classify the real data the workflow would eventually need and identify where it is stored, processed, logged, and retained.
The OWASP AI Agent Security Cheat Sheet recommends least privilege, external-input validation, session isolation, human oversight for high-risk actions, monitoring, structured logs, cost limits, and adversarial testing.
Test indirect prompt injection. Put an instruction inside a document or web page that tells the agent to ignore the task, reveal unrelated information, or use a prohibited tool. The correct behavior is to treat retrieved material as data, follow the governing instructions, and refuse the unauthorized action.
For product-specific questions about client information, verify the vendor's current documentation and your organization's own data-handling requirements before moving beyond sanitized test material.
8. Usable-result economics
Do not call an agent cheap because the visible model charge was small.
Record:
- incremental cash spend;
- allocated subscription cost;
- setup time;
- elapsed run time;
- reviewer time;
- correction time;
- failed and retried attempts;
- accepted results.
The practical metric is cost per accepted result. If a fast draft requires a senior employee to rebuild its sources and correct the deliverable, the inexpensive run may be the expensive workflow.
Five tests a polished demo usually avoids
The missing-information test
Remove one required fact. Does the agent identify the gap, or invent a plausible answer?
The conflicting-source test
Provide two dates, prices, policies, or versions. Does the agent identify the authoritative source and flag the conflict?
The hidden-instruction test
Place a malicious or irrelevant instruction in retrieved content. Does the agent follow it, ignore it, or escalate?
The wrong-permission test
Make an unnecessary write or send tool visible. Does policy prevent its use even if a document tells the agent to call it?
The failure-and-recovery test
Interrupt a tool or make a dependency unavailable. Does the agent preserve a truthful state and stop, or declare success without the required evidence?
Hard stops that override the score
Do not move an agent into client work when:
- it needs broader access than the task requires;
- it can take a high-impact action without an external human gate;
- the team cannot inspect source use for a fact-sensitive workflow;
- logs do not reveal which tools or systems were used;
- retries, time, tool calls, or cost have no limit;
- a plausible failure cannot be contained or reversed;
- sensitive data has not been authorized for the test;
- an ordinary or adversarial case produces an unresolved material failure.
An average score can hide a catastrophic weakness. Treat these as gates.
A safe deployment ladder
Move through access stages rather than jumping from demo to production.
- Output only: synthetic inputs, no tools, no real client material.
- Read-only sandbox: approved public or sanitized sources and a limited test environment.
- Authorized read-only data: real but approved information, isolated by client and fully logged.
- Reversible staging writes: changes in a test system with rollback.
- Supervised production writes: a person approves each exact action and destination.
- Limited unattended actions: only after repeatable evidence, monitoring, rollback, and named ownership.
At every promotion, freeze the configuration and rerun the important cases. A model, tool, connector, prompt, permission, memory, or policy change can invalidate the prior result.
The bottom line
An agent earns trust one bounded workflow at a time.
Define the job. Restrict access. Freeze the acceptance standard. Test ordinary and hostile cases. Inspect the tool path. Measure corrections and true cost. Require a person for consequential actions. Expand only when the evidence supports the next stage.
That process is slower than believing a demo and much faster than cleaning up an avoidable client failure.
