Buying principleThe valuable deliverable is not an autonomous demo. It is a controlled operating system for one real workflow.
An AI agent development agency should challenge the use case first
An agent is justified when the path cannot be fully prescribed, the system must inspect changing information, and the result can be checked. If the steps are stable, ordinary software is usually easier to test and cheaper to run.
Consider an accounts team handling invoice exceptions. A fixed workflow can extract fields, check totals and route known error codes. An agent may help when it must inspect a contract, compare a purchase order, ask for missing context and choose the next tool.
Anthropic distinguishes workflows with predefined code paths from agents that direct their own process and tool use. Its practical advice is to add agentic complexity only when simpler solutions fall short.
Ask a prospective agency to show the simplest non-agent design first. If every problem requires autonomy, the proposal is selling a category, not solving your workflow.
Scope one workflow with a visible finish
The brief needs a trigger, available evidence, allowed actions, stopping conditions and a definition of done. “Handle customer support” contains too many journeys and consequences to be a useful first scope.
A bounded first version could investigate a delivery complaint, draft a reply and recommend one of three approved remedies. A person still approves the remedy. The finish is visible: the case contains the evidence, proposed action and reason.
Write this contract before implementation in an AI product requirements document. Include normal cases, ambiguous cases, forbidden actions and the person who decides when evidence conflicts.
The agency should also name where the agent stops. Maximum turns, time, spend, tool errors and missing data all need explicit exits. “Keep trying” is not resilience. It is how a small support ticket becomes an expensive ghost story.
Set tool permissions by consequence, not convenience
Tool access should become more restrictive as consequences increase. Reading an order, drafting a refund and issuing a refund are different permissions even if they appear behind one API.
OpenAI's agent safety guidance recommends tool approvals, structured fields between steps, guardrails and trace evaluations. Anthropic describes a similar control pattern: people can allow a read while requiring approval before an action such as sending an invitation.
For the delivery complaint example, the agent can read the order and carrier status automatically. It can draft a response. It should request approval before crediting money, changing an address or contacting a third party.
A proposal should list each tool, the data it exposes, the operations it permits, the approval rule and the audit record. A generic statement that “a human stays in the loop” is too vague to test.
| Permission level | Example | Control | Evidence to retain |
|---|---|---|---|
| Read | Open an order record | Allowed fields and purpose | Data source and timestamp |
| Draft | Prepare a customer reply | No external side effect | Inputs, draft and cited evidence |
| Approve | Recommend a refund | Named person confirms | Recommendation and approval identity |
| Execute | Issue the refund | Amount limit and idempotency key | Tool result and resulting state |
Evaluate the path, not only the final answer
A correct final sentence can hide a dangerous route. Acceptance tests must inspect which records the agent read, which tools it selected, which approvals it requested and whether it stopped when evidence was insufficient.
Build a test set from representative work, awkward edge cases and deliberate attacks. Include duplicated requests, stale records, conflicting policies, a tool timeout, hostile text inside a document and a user asking the system to exceed its authority.
The NIST AI Risk Management Framework organizes risk work around governing, mapping, measuring and managing. Its Generative AI Profile applies that structure to generative systems. In procurement terms, require named risks, test evidence, monitoring and an owner rather than a single accuracy percentage.
Run the same cases after prompt, model, tool or policy changes. An AI product audit can examine the live traces later, but the evaluation harness should exist before launch.
Design recovery before increasing autonomy
Production agents need a reliable way to resume, retry safely or hand work back to a person. A browser refresh or provider failure should not repeat a consequential action.
For a refund workflow, the execution request needs an idempotency key so the same operation cannot create a second payment. The agent state should record what was attempted, what the tool confirmed and what remains unresolved.
A useful trace lets an operator answer four questions: what did the agent believe, what did it do, what changed outside the system, and what can safely happen next? Logs that show only model text are not enough.
Ask the agency to demonstrate one failed tool call, one interrupted run and one manual takeover. A happy-path video proves the interface exists. Recovery proves somebody thought about the business.
Buy ownership and handover, not framework dependence
The finished system should belong to the product team operationally, not only contractually. Your team needs the source, prompts, tool schemas, evaluation cases, deployment configuration, runbook and access map.
Request a dependency register that separates open standards, vendor services and agency-owned components. Frameworks can speed up a prototype, but hidden abstractions make later debugging and migration harder.
A good handover includes a live incident exercise. Give the operator a session with a failed action and ask them to find the trace, stop the agent, correct the state and resume or close the case.
Compare this discipline with the broader criteria in choosing an AI product development partner. Agent work adds a sharper burden because external side effects must remain understandable and reversible.
AI agent development agency checklist before you sign
- Name one workflow, trigger, owner and verifiable finish.
- Ask why a fixed workflow is insufficient.
- List every data source and tool operation.
- Separate read, draft, approve and execute permissions.
- Define spending, time, turn and action limits.
- Test ambiguity, duplication, hostile input and tool failure.
- Require traces, idempotency, manual takeover and recovery.
- Own the prompts, schemas, evals, runbook and deployment access.
- Use an AI proof of concept to retire one named risk, not to imitate production.
If one workflow is ready for this level of scrutiny, send Seuil the workflow, tools and actions involved. That is enough to decide whether you need an agent, a deterministic workflow or a smaller experiment first.