Editorial illustration based on a server-room photograph at NOIRLab headquarters in Tucson, Arizona. Photo: NOIRLab/NSF/AURA/T. Slovinský, CC BY 4.0. Cropped and branded by TECHi. Original photograph
Before hiring an AI agent development partner, ask the team to demonstrate three things: a task completed against agreed acceptance criteria, an action correctly blocked by permissions, and a failed operation recovered without duplicating its effects. Those demonstrations reveal more about production readiness than a polished conversation with a chatbot.
An agent that retrieves information and changes business records carries responsibilities beyond generating a plausible answer. Your development partner needs to understand the surrounding software, the people accountable for its decisions, and the cost of correcting mistakes. The evaluation should therefore begin with a bounded workflow and a measurable business outcome.
Key Takeaways
- Measure accepted workAn illustrative $1,000 operating budget divided by 850 accepted tasks is about $1.18 per accepted task, including review.
- Test control boundariesAsk the partner to demonstrate permission denials, interrupted operations, and human handoffs.
- Plan the handoverInclude evaluation ownership, deployment instructions, and ongoing support in the agreement.
Make the cost of an accepted outcome visible
Consider a hypothetical monthly pilot that attempts 1,000 tasks and produces 850 accepted results. Suppose model and tool usage costs $240, infrastructure costs $160, and human review costs $600. The operating total is $1,000, or approximately $1.18 per accepted task: $1,000 divided by 850.
Looking only at model and tool spending would suggest $0.24 per attempted task. That figure uses a different denominator and omits two substantial expenses. The example is an illustrative calculation, not a vendor quote or measured benchmark. It also excludes development fees, taxes, and downstream remediation. Its purpose is to show why proposals should report costs and acceptance rates together.
Ask each shortlisted partner to build a comparable estimate using your expected workload. Include unsuccessful attempts, retries, escalation, and review time. Compare the result with your existing process at an equivalent quality level. An apparently inexpensive system may offer little value if employees must repeatedly repair its output.
Choose a partner who can justify the architecture
A credible team should explain why your workflow needs an agent and where conventional software remains the better choice. A fixed approval process may suit a predefined workflow. A task that requires selecting tools in response to changing information may justify more model-directed behavior.
In its discussion of building effective agents, Anthropic distinguishes predefined workflows from systems in which models direct their own processes and tool use. It recommends starting with simpler approaches and weighing added complexity against cost and latency. That distinction gives buyers a useful question: which decisions actually need model judgment?
Look for an architecture diagram that identifies those decisions, the tools available at each step, and the conditions that stop execution. A multi-agent design may be appropriate when distinct roles improve a measured outcome. Ask the partner to demonstrate that benefit against a simpler baseline before accepting the extra coordination and maintenance burden.
Turn service descriptions into verifiable commitments
Service pages can help build a shortlist, but the proposal must translate broad capabilities into deliverables. LITSLINK describes discovery, integration, evaluation, deployment, and monitoring on its AI Agent Development Services page. These are the provider’s descriptions of its offering; they do not establish how a particular implementation will perform.
Apply the same scrutiny to every candidate. Request an example of an evaluation report, a redacted operational incident review, and a walkthrough of how permissions are enforced. Where confidentiality prevents sharing client work, ask for a demonstration using synthetic records. You should still be able to inspect the engineering approach without accessing another customer’s information.
The statement of work should identify the target workflow, supported integrations, acceptance criteria, exclusions, and named deliverables. If the proposal promises monitoring, specify which metrics appear, who receives alerts, and what response is included. If it promises ownership, identify the code, configuration, datasets, and documentation covered by that term.
Inspect data access before expanding autonomy
For every connected system, establish what the agent may read, what it may change, and whose authority it uses. Authorization should be enforced by application code and the connected service. A sentence in a prompt telling the model to respect permissions is insufficient as an access boundary.
OWASP’s prompt injection recommendations explains how instructions embedded in external content can influence model behavior. Its mitigations include restricted privileges and human approval for sensitive operations. Retrieval and fine-tuning do not, by themselves, eliminate this class of vulnerability.
Ask the partner to demonstrate a malicious instruction inside a retrieved document and show what prevents an unauthorized action. Inspect the resulting tool request and the permission decision. For consequential changes, an approval screen should show the exact action and affected record. An approval for one operation should not silently authorize a different operation later.
Data handling deserves the same specificity. Document where inputs, retrieved content, logs, and backups are stored; which providers receive them; and how retention and deletion work. Request supporting evidence for the controls relevant to your environment rather than relying on a general assurance that the solution is secure.
Evaluate failures as deliberately as successes
Build the acceptance set from realistic tasks, including incomplete requests, conflicting records, unavailable tools, and questions the system cannot answer. Keep some cases separate from development examples so the final assessment is less vulnerable to tuning around familiar inputs. Have the business owner agree on the scoring criteria before results are collected.
Inspect intermediate actions as well as final responses. A correct summary does not excuse reading a restricted record, and a convincing completion message does not prove a database update occurred. Require evidence from the connected system for actions the agent reports as completed.
| Scenario | What the partner should demonstrate |
|---|---|
| A user requests a restricted record | Access is denied without leaking the record through responses or logs available to that user. |
| A write succeeds but its response times out | The system checks the operation’s state and avoids creating a duplicate effect. |
| A required source is unavailable | The agent identifies the limitation and follows an agreed retry, stop, or escalation path. |
| An approved action changes before execution | The system rejects the changed action or requests a new approval. |
| A model or prompt is updated | The evaluation suite runs again and the release can be rolled back if acceptance criteria fail. |
These are proposed acceptance scenarios, not a certification or a universal release threshold. Set targets according to the consequences of failure. A drafting assistant and an agent permitted to modify customer accounts require different limits and escalation rules.
Ask how the system recovers from interrupted work
A timeout leaves an important question: did the operation fail, or did its confirmation fail to arrive? Retrying blindly can duplicate a message, booking, or record change. Amazon’s Builders’ Library explains how idempotent APIs make retries safer by allowing repeated requests without additional side effects.
Your partner should show how this principle applies to each integration. Where an external service lacks suitable support, the design needs an alternative such as checking operation state or escalating uncertain outcomes. Also ask where progress is saved, how interrupted tasks resume, and which errors require a person rather than another automatic attempt.
Set explicit bounds on execution time, tool calls, and spending. A useful recovery policy explains when the system stops trying. During a pilot, observe those limits under slow responses and service failures instead of checking only the normal path.
Make ownership and support part of acceptance
NIST’s AI Risk Management Framework provides a voluntary basis for considering trustworthiness across AI design, development, use, and evaluation. In a procurement discussion, that lifecycle perspective helps keep responsibility from ending at the launch date.
Agree on who owns operational alerts, permission reviews, model updates, and recurring evaluations. The handover should cover source access, deployment instructions, integration credentials under your control, evaluation cases, and an incident runbook. Identify third-party licenses and proprietary components separately so ownership promises match what you can actually maintain or move.
Begin with a limited rollout, review the results with the people responsible for the workflow, and expand permissions only when the evidence supports it. A development partner earns trust by making outcomes, limitations, and recovery procedures inspectable. That gives your business a practical basis for deciding when an agent is ready to carry real operational responsibility.
Comments