Why Specification Matters More for AI Agents Than for Standard Software
The Eight Things You Must Define Before Briefing a Partner
1. The Agent's Primary Function
2. Autonomy Level and Human-in-the-Loop Requirements
3. Data Sources and Integration Points
4. The Failure Mode Taxonomy
5. Evaluation Criteria and Success Metrics
6. Model and Infrastructure Constraints
7. Security and Access Control Requirements
8. Maintenance, Monitoring, and Ownership Model
What to Look for in a Partner's Response to Your Brief
The Difference Between a Prototype and a Production Agent
How AI Agents Interact with Legacy Systems
Putting the Specification Together
Frequently Asked Questions
Most custom AI agent development projects stall not because the technology fails, but because the brief was incomplete before anyone wrote a line of code. The partner builds what they were told to build. The founder wanted something different. Neither party is lying — they were working from different assumptions.
This is a specification guide for founders and technical leaders who are close to engaging a development partner for an AI agent. It covers what you need to define, what questions to ask, and where vague answers will cost you later.
Why Specification Matters More for AI Agents Than for Standard Software
A conventional web application has predictable inputs and outputs. You define the screens, the data model, the user flows. Scope creep is annoying but containable.
AI agents are different. They make decisions. They call external systems. They can be configured to operate autonomously across multi-step workflows or constrained to a narrow advisory function. The difference between those two configurations is not a line of code — it is a design philosophy that shapes the entire architecture.
If you do not specify the decision boundary before the build starts, your partner will make that call for you. Sometimes they get it right. Often they do not, because they do not know your risk tolerance, your compliance environment, or what your users will actually trust.
Get the specification right first. The build follows from that.
The Eight Things You Must Define Before Briefing a Partner
1. The Agent's Primary Function
This sounds obvious. It is not. "An AI agent that handles customer support" could mean a retrieval-augmented FAQ bot, a triage agent that routes tickets to humans, a fully autonomous resolution agent that queries your CRM and closes tickets without human review, or an escalation layer that monitors sentiment and flags at-risk accounts.
Each of those is a different product. Each carries different infrastructure requirements, different risk profiles, and different levels of complexity.
Write one sentence that describes what the agent does, who it does it for, and what outcome it produces. If you cannot write that sentence, the specification is not ready.
2. Autonomy Level and Human-in-the-Loop Requirements
This is the single most consequential design decision in any AI agent build, and it is almost always underspecified.
Define where human review is required. Is the agent advisory only — it recommends, a human confirms? Is it semi-autonomous — it acts, but a human can override within a window? Is it fully autonomous — it acts and the action is final?
Each level carries a different error cost. A fully autonomous agent that sends the wrong email to 10,000 customers is a different problem from an advisory agent that suggests the wrong email and a human catches it before sending.
For regulated industries — financial services, healthcare, legal — the autonomy question is not just a product decision. It is a compliance requirement. Specify it explicitly and document the reasoning.
3. Data Sources and Integration Points
Your agent needs data to act on. Before briefing a partner, map every system the agent will need to read from or write to — your CRM, your database, third-party APIs, internal tools, and any document stores the agent will retrieve from.
For each integration, answer three questions: Does an API exist? What are the rate limits and access controls? Who owns the authentication credentials?
Partners who are serious about production delivery will ask these questions in the first meeting. If they do not, that is a signal. Our practical guide to AI agent integration covers this in more depth — the integration layer is where agent builds most commonly break down, and almost always because data access questions were deferred rather than answered upfront.
4. The Failure Mode Taxonomy
What should the agent do when it does not know the answer? What should it do when an external API is unavailable? What should it do when a user input is ambiguous, hostile, or out of scope?
These are not edge cases. They are the conditions under which most agents are actually used. Real users test boundaries. Real systems have downtime. Real data has gaps.
Define at minimum three failure modes before you brief a partner:
Uncertainty handling: Does the agent say "I do not know" and escalate, or does it attempt an answer with a confidence qualifier?
System failure handling: Does the agent fail gracefully with a user-facing message, or does it retry silently?
Out-of-scope handling: Does the agent redirect, refuse, or attempt to answer anyway?
A partner who does not ask about failure modes during scoping is building an agent for the happy path. That agent will embarrass you in production.
5. Evaluation Criteria and Success Metrics
How will you know the agent is working? That question needs a specific answer before the build starts, not after.
Vague success criteria — "it should be helpful" or "it should save time" — make objective evaluation impossible. They also make it harder for your partner to make sound architectural decisions, because they do not know what they are optimising for.
Define quantitative metrics where possible: resolution rate, escalation rate, response latency, user satisfaction score, task completion rate. Define the baseline you are measuring against. Define the threshold at which the agent is considered production-ready.
If you are building an agent to accelerate an internal workflow, measure that workflow before the agent exists. That baseline is the only honest comparison point you will have.
6. Model and Infrastructure Constraints
Your partner will make model selection decisions during the build. If you have constraints — on cost, on data residency, on which models are approved for use in your environment — those constraints must be in the brief.
Common constraints that founders forget to specify:
Data residency: If your users are in the EU, does the model need to process data within EU infrastructure?
Model approval: Some enterprise clients and regulated businesses maintain approved model lists. Claude, GPT-4, Llama — not all are interchangeable from a compliance perspective.
Cost per query: At scale, model inference costs are not trivial. A cost ceiling per interaction shapes which model and which retrieval architecture your partner will choose.
Latency requirements: A customer-facing agent that takes eight seconds to respond is a different product from one that responds in under two. Latency targets affect architecture.
Specify these constraints before the build. Retrofitting them later is expensive.
7. Security and Access Control Requirements
Who can use the agent? What data can it access on behalf of which users? Can it take actions that modify records, send communications, or trigger financial transactions?
These questions define the agent's permission model. A well-scoped agent has explicit boundaries on what it can read, what it can write, and who it can act on behalf of. An underspecified agent has implicit permissions that expand over time as new use cases are added — and that is how security incidents happen.
Define the permission model in the brief. Your partner should be able to describe how the agent authenticates, how it handles user-level access control, and how its actions are logged and auditable.
If the agent will operate in a multi-tenant environment — where different users or organisations have different data access — specify that explicitly. Multi-tenancy in AI agents is an architectural decision, not a feature you add later.
8. Maintenance, Monitoring, and Ownership Model
A production AI agent is not a static artefact. Models update. Prompts drift. Data sources change. User behaviour evolves. The agent you ship on day one is not the agent you will be running six months later.
Before you sign a contract, answer these questions:
Who owns the prompt engineering and configuration after handover?
Who monitors the agent's outputs in production?
What is the process for updating the agent when the underlying model changes?
What observability tooling will be in place — logging, tracing, alerting?
Is the partner providing ongoing support, or is this a build-and-hand-off engagement?
The answers determine whether you are buying a product or buying a dependency. Both are legitimate. But they carry different costs and different risks, and you need to know which one you are buying before you sign.
What to Look for in a Partner's Response to Your Brief
A serious partner will push back on your specification. That is not a red flag — it is the right behaviour.
If a partner accepts your brief without challenge and returns a proposal within 24 hours, be cautious. The questions in this article are not easy to answer quickly. A partner who has not asked about your failure modes, your data residency requirements, or your success metrics has not thought carefully about your build.
The questions that distinguish experienced partners from inexperienced ones:
"What does the agent do when it encounters a query it cannot answer confidently?"
"What systems will the agent need to write to, not just read from?"
"What is your current baseline for the workflow this agent is replacing or augmenting?"
"Who will own prompt iteration after we hand over?"
These are not trick questions. They are the questions that determine whether the build will work in production.
It is also worth understanding how your partner has handled AI agent builds that went wrong. Not whether they have had failures — every serious engineering firm has — but how they diagnosed the problem and what they changed. That answer tells you more about their process than any portfolio piece.
The Difference Between a Prototype and a Production Agent
This distinction matters more than most founders realise. A prototype demonstrates that an AI agent can perform a task in a controlled environment. A production agent performs that task reliably, at scale, under adversarial conditions, with monitoring in place and a clear path to update it when something changes.
The gap between those two things is where most AI agent projects fail. The prototype works in the demo. The production agent handles edge cases, integrates with real systems under real load, and has someone responsible for it when it misbehaves at 2am.
When evaluating a partner, ask directly: "Have you deployed this type of agent into a live production environment, or are you describing a prototype?" The answer should be specific. When AI development is not the right call is worth reading before that conversation — it is a useful frame for separating genuine production readiness from well-presented proof-of-concept work.
We have been building production AI agents with Claude integration since 2024 — not pilots, not demos, but agents running in live client products. One delivered a 57-page analysis in three hours. That kind of output requires the full specification discipline described in this article before a line of code is written.
How AI Agents Interact with Legacy Systems
One specification area that is consistently underestimated is the integration between a new AI agent and an existing codebase or data infrastructure. Most scale-ups do not have clean, well-documented APIs across their entire stack. They have a mix of systems built at different times, by different teams, with different data models.
An agent that needs to retrieve data from three different internal systems — each with its own authentication model, each with its own data format — is a significantly more complex build than one querying a single clean API. Our analysis of AI agents working with legacy code covers the specific challenges this creates and how to approach them systematically.
If your data infrastructure is fragmented, say so in the brief. A partner who understands legacy integration will scope the work differently from one who assumes clean APIs throughout.
Putting the Specification Together
The specification document does not need to be long. It needs to be complete. A one-page brief that answers all eight questions in this article is more valuable than a ten-page document that answers six of them.
Structure it this way:
Primary function (one sentence)
Autonomy level and human-in-the-loop requirements
Data sources and integration points (list every system)
Failure mode taxonomy (three scenarios minimum)
Success metrics and baseline
Model and infrastructure constraints
Security and access control model
Post-launch ownership and maintenance plan
Send that document to every partner you are evaluating. The quality of their response will tell you more than any sales call.
If you cannot yet answer all eight questions, that is useful information too. It means the specification work is still ahead of you — and engaging a partner before that work is done will produce a build that solves the wrong problem.
We work with scale-ups at exactly this stage, helping founders define what they are actually building before the engineering work starts. If you want to talk through your AI agent specification before you brief a partner, start at wireapps.co.uk.
Frequently Asked Questions
What is custom AI agent development?
Custom AI agent development is the process of building an AI system designed to perform a specific set of tasks autonomously or semi-autonomously within your product or workflow. Unlike off-the-shelf AI tools, a custom agent is built to your data sources, your permission model, your failure handling requirements, and your success criteria. The output is a production system, not a configured SaaS product.
How long does it take to build a production AI agent?
Timeline depends heavily on the complexity of the integration layer, the autonomy level, and the quality of the specification going in. A well-specified agent with clean API access to its data sources can reach production in six to ten weeks. An agent that requires legacy system integration, complex permission modelling, or multi-tenant architecture will take longer. Underspecified builds almost always run over, regardless of the partner.
What should I include in an AI agent development brief?
At minimum: the agent's primary function in one sentence, the autonomy level and where human review is required, every system the agent will read from or write to, three failure mode scenarios, quantitative success metrics with a baseline, model and infrastructure constraints, the security and access control model, and who will own the agent after handover. A brief that answers all of those questions gives a partner everything they need to scope the work accurately.
How do I evaluate whether an AI agent partner has genuine production experience?
Ask for specific examples of agents they have deployed into live production environments — not demos or prototypes. Ask about failure modes they have encountered and how they handled them. Ask about their observability and monitoring approach. Ask who is responsible for the agent when something goes wrong at 2am. Vague answers to specific questions are a reliable signal of prototype-level experience.
What is the difference between an AI agent and a chatbot?
A chatbot generates responses to user inputs, typically within a single conversational context. An AI agent can take actions — querying external systems, writing to databases, triggering workflows, making multi-step decisions — based on its inputs and its defined objectives. The distinction matters for specification because agents have a much larger failure surface and require explicit permission modelling, whereas chatbots are primarily a content and retrieval problem.
What models are typically used in custom AI agent development?
The most common production models in 2026 are Claude (Anthropic), GPT-4 and its successors (OpenAI), and Llama-based open-source models for on-premise or data-residency-constrained deployments. Model selection should be driven by your latency requirements, cost per query at scale, data residency constraints, and any approved model lists in your compliance environment. A good partner will recommend a model based on your specific constraints — not default to whatever they know best.
Do I need a technical co-founder or CTO to commission an AI agent build?
No, but you do need someone who can make the eight specification decisions described in this article. Those decisions are business decisions as much as technical ones — autonomy level, failure handling, success metrics, and ownership model are all things a non-technical founder can define with the right framework. Where technical leadership adds value is in translating those decisions into architecture and holding a partner accountable to them during the build.
Share
