AI Agent Development: How to Choose and Work With a Specialist Agency

AI agent development has moved from research demo to production workload in under two years. Anthropic's Claude, OpenAI's Assistants and Responses APIs, and open-source frameworks like LangGraph and CrewAI have made it feasible to ship agents that take real actions - drafting emails, updating CRMs, reconciling invoices, triaging tickets - inside operational systems. The gap between a proof-of-concept notebook and a production agent that runs unattended is still large, though, and that gap is where a specialist agency earns its fee.

This guide is for operations, engineering, and innovation leaders evaluating whether to hire an AI agent development agency, what to expect from one, and how to tell a competent partner from a rebadged prompt-engineering shop. It covers stack choices, pricing models, governance requirements under UK GDPR, and the specific questions to ask before signing a statement of work.

What an AI agent development agency actually builds

An AI agent is a system where a language model decides what to do next based on a goal, calls tools or APIs to act, observes the result, and iterates until the task is complete or it hands off to a human. That is different from a chatbot that answers questions, and different from a linear workflow automation that follows a fixed script. Agents branch, retry, and reason about intermediate state.

In practice, an agency building agents for a mid-market client is doing five things at once:

• Task decomposition: breaking a fuzzy business goal ("handle inbound supplier queries end to end") into discrete steps an agent can plan against.
• Tool design: writing the functions the agent can call - CRM lookups, database writes, email sends, ticket creation - with strict schemas and permission boundaries.
• Retrieval: connecting the agent to the client's knowledge base (contracts, product docs, historical tickets) via RAG, usually with hybrid search over Postgres + pgvector, Weaviate, or a managed option like Pinecone.
• Guardrails and evaluation: refusal patterns, output validation, hallucination detection, and a test harness that runs on every deploy so the agent does not silently degrade.
• Human-in-the-loop: UI or Slack surfaces where humans approve high-risk actions, correct mistakes, and generate the training data that improves the system over time.

A generalist dev shop can usually deliver items one and two. A specialist agency delivers all five, and treats items four and five as the actual product. Anthropic's own guidance on building effective agents is worth reading before any procurement conversation - it clarifies when you need an agent at all versus a simpler workflow.

When you need an agent (and when you do not)

Most tasks that look like agent problems are actually workflow automation problems. If the steps are fixed, the branching logic is knowable at design time, and the tools return deterministic results, you want an n8n or Zapier flow with an LLM node inside it, not an autonomous agent. It will be cheaper, faster to build, easier to debug, and more reliable in production.

You need an agent when:

• The number of possible paths through the task is too large to enumerate. Customer support triage across a broad product surface is a good example - the agent needs to decide what to look up based on what the customer said.
• The task involves reasoning over unstructured inputs (emails, PDFs, meeting transcripts) where a fixed extraction schema will not cover the long tail.
• You want the system to improve as tools change without rewiring the workflow each time - an agent with well-described tools adapts; a hard-coded flow does not.

A good agency will talk you out of an agent build when a workflow suffices. If your shortlist all pitch you agents regardless of use case, that is a signal to widen the shortlist. The industry has enough proof-of-concept graveyards already - Gartner's 2024 forecast that 30% of generative AI projects will be abandoned after proof-of-concept by end of 2025 is largely a story of teams building agents where a simpler system would have shipped.

The stack: what a competent agency will use in 2026

There is no single correct stack, but there is a recognisable one. When you evaluate an agency, you should hear specific opinions on each of these layers, not brand-name-dropping.

Models

Claude Sonnet and Opus for the reasoning core when tool use and instruction-following matter, GPT-4o or o-series for OpenAI-native shops, Gemini 2.5 Pro for long-context work, and open-weights models (Llama 3.3, Qwen 2.5, DeepSeek) via a self-hosted or Bedrock deployment when data residency or cost per token dominates. A good agency runs cost and quality benchmarks per workload, not a blanket vendor preference.

Orchestration

LangGraph for stateful, branching agents where you need explicit control over the graph. CrewAI or AutoGen for multi-agent setups. The OpenAI Agents SDK or Anthropic's tool-use API directly when the graph is simple and framework overhead is not worth it. Watch for agencies that force LangGraph into every project - it is powerful but overkill for single-agent workloads.

Retrieval

Postgres with pgvector is the sensible default for most mid-market builds. It puts your embeddings next to your relational data, avoids a second system to operate, and scales into millions of vectors comfortably. Move to Weaviate, Qdrant, or Pinecone when hybrid search complexity or scale genuinely demands it. Hybrid retrieval (BM25 + dense) matters more than the vector store choice.

Observability

LangSmith, LangFuse, or Arize for trace-level debugging. Without this, you cannot tell why an agent made a decision, cannot reproduce failures, and cannot iterate. If an agency does not mention observability in the first scoping call, they have not run agents in production.

Deployment

FastAPI or Next.js API routes for the agent server. Temporal or Inngest when you need durable execution across long-running tasks. Docker on ECS, Fly.io, or Railway for hosting; Bedrock or Azure OpenAI when the client requires cloud-native compliance boundaries. The choice depends on the client's existing infrastructure, not the agency's preference.

Pricing, timelines, and engagement models

Agency pricing for agent work in the UK mid-market falls into a recognisable range as of 2026. The Productive 2024 agency benchmark and BCG's 2024 GenAI value report both point to build engagements clustering in three tiers:

• Discovery and prototype: £15k-£40k, four to six weeks. Ends with a working prototype against real data, a costed roadmap, and a go/no-go decision. This is the right first engagement for most buyers.
• Production build: £60k-£200k, three to five months. Full agent system with evaluation harness, monitoring, human-in-the-loop UI, and initial rollout to a defined user group.
• Ongoing operation: £5k-£25k per month retainer, covering model updates, prompt iteration, new tool integrations, incident response, and quarterly evaluation refreshes.

Beware fixed-price full-build quotes without a prior discovery phase. Agent projects have irreducible uncertainty in weeks one to four - what the model can actually do on your data, where the failure modes are, what tools you actually need. Agencies that skip discovery usually pad the fixed price to cover the risk, or discover the problems mid-build and burn the relationship.

Time-and-materials with a capped budget and weekly demos is the honest structure. Fixed price is fine for discovery and for well-scoped follow-on modules once the system exists.

Governance, data protection, and UK-specific requirements

Any agent that reads or writes customer data is a data processing activity under UK GDPR. The Information Commissioner's Office has published specific guidance on AI and data protection which any competent agency should be able to walk you through without reaching for the deck.

The practical checklist for an agent build in a UK mid-market context:

• Lawful basis and DPIA: agent systems that process personal data at scale, or that automate decisions with significant effects on individuals, need a Data Protection Impact Assessment. Your agency should either run this or work alongside your DPO to complete it before build.
• Data residency: if you cannot send data to US-hosted models, plan for Azure OpenAI in UK South, Bedrock in eu-west-2, or a self-hosted open-weights model. This decision changes the stack materially and needs to be made in discovery.
• Sub-processor transparency: the agent will call model APIs, vector stores, and observability platforms, each of which becomes a sub-processor. Your DPA schedule needs updating; the agency should provide the list.
• Retention and training opt-out: confirm the model provider does not train on your data. Anthropic, OpenAI enterprise, and Bedrock all offer this contractually; consumer-tier APIs sometimes do not.
• Automated decision-making rights: under Article 22 of UK GDPR, individuals have rights when decisions are fully automated. If the agent makes decisions without human review, you need a route for individuals to contest them.
• Auditability: every agent action should be logged with the prompt, the model response, the tools called, and the outcome. This is both good engineering and a regulatory requirement in regulated sectors.

For financial services clients, the FCA and PRA have signalled that existing model risk management expectations (SS1/23) apply to AI systems. For healthcare, MHRA guidance on software as a medical device may bite depending on use case. A generalist agency will not know this; ask specifically.

How to evaluate a shortlist

Most shortlists in this market contain three types of agency: former dev shops that added AI to the deck, former strategy consultancies that hired engineers, and specialists built around agent work from day one. All three can deliver good work, but the questions that separate them are the same.

Ask each shortlisted agency to walk you through a production agent they have shipped, in detail: what the goal was, what tools the agent could call, how they handled failure modes, what the evaluation harness looked like, how they monitor it now, and what has changed since launch. If they cannot show you this - under NDA if needed - they have not shipped one.

Ask about their evaluation methodology. "We test it manually" is not an answer. You want to hear about golden datasets, LLM-as-judge with human calibration, regression tests that run on every prompt or model change, and a defined process for when the eval score drops.

Ask what they will not build. An agency that will build anything you ask for is selling capacity, not judgement. The good ones turn away projects where an agent is the wrong tool, where the data is not ready, or where the governance is not in place.

Ask who runs it after launch. Agent systems degrade if left alone - models get deprecated, prompts drift as the underlying model updates, tools change their APIs. If the agency hands over a repo and disappears, you are inheriting an operations problem you may not be staffed for. Retainer or clear handover-to-internal-team is the choice; both are fine, but pick deliberately.

Common failure patterns to avoid

Three patterns account for most of the agent projects we see abandoned within twelve months.

Building the agent before the workflow exists. If the human process is undocumented, inconsistent, or contested internally, an agent will amplify the mess. Map and stabilise the workflow first, then automate the parts that are stable.

Underinvesting in evaluation. Teams spend 80% of the budget on the initial build and 5% on evaluation, then have no way to tell if the system is getting better or worse. Aim for closer to 60/25 build-to-eval, with the remaining 15% on monitoring and UI.

Treating the agent as a product launch, not an operations capability. Agents need someone whose job includes tending them - reviewing traces, updating prompts, adding tools as the business evolves. Without that owner, the agent silently degrades until users stop trusting it and route around it.

FAQs

How is an AI agent development agency different from a general AI consultancy?

A general AI consultancy typically ends its engagement with a strategy document, a shortlist of vendors, or a proof-of-concept notebook. An agent development agency builds, deploys, and operates production systems. The distinction matters because roughly 70% of the work in an agent project happens after the first working prototype - evaluation harnesses, monitoring, human-in-the-loop UI, prompt iteration as models update, and integration with existing systems. Consultancies that do not staff engineers who have shipped agents in production tend to underestimate this phase, which is where most abandoned projects die.

How long does it take to build a production AI agent?

For a well-scoped single-agent system with three to six tools and a defined user group, expect four to six weeks for discovery and prototype, then twelve to twenty weeks for production build and initial rollout. Multi-agent systems, agents that touch regulated data, or agents integrated with legacy systems (AS/400, on-premise ERPs) run longer, often six to nine months to steady state. The variable is rarely the model work; it is the integration, the evaluation harness, and the change management with the humans who will work alongside the agent.

What does an AI agent actually cost to run in production?

Running costs split into model API spend, infrastructure, and human operations. Model costs for a mid-market agent handling 1,000-10,000 tasks per day typically run £500-£5,000 per month with Claude Sonnet or GPT-4o class models, dropping significantly if you self-host open-weights models. Infrastructure (hosting, vector store, observability) adds £200-£1,500 per month. The larger and often overlooked cost is human operation - one part-time engineer or ops person spending 4-8 hours per week reviewing traces, updating prompts, and handling edge cases.

Should we build in-house or hire an agency?

If you have two or more engineers with production LLM experience already, and agent work will be a permanent capability, build in-house. If this is your first agent, your engineering team is fully loaded, or you need something in production within three months, an agency accelerates the learning curve substantially. A common pattern is agency-led build with knowledge transfer through paired working, then an internal team takes over operations at six to nine months. This gets you to production faster without creating permanent vendor dependency.

How do we protect against vendor lock-in with an agent build?

Insist on model-agnostic architecture from day one. The agent orchestration layer should treat models as swappable - Anthropic today, OpenAI or an open-weights model tomorrow, with a config change rather than a rewrite. LangChain, LangGraph, and LiteLLM all support this pattern. Keep prompts, tool definitions, and evaluation datasets in your repository, not the agency's. Contractually, require source code delivery, documentation of all prompts and evaluation criteria, and a defined handover process. Avoid agencies that host the agent on their own infrastructure without a migration path.

What are the UK GDPR risks specific to agent systems?

Agents create three GDPR risks that static systems do not. First, autonomous decision-making can trigger Article 22 rights if the agent takes actions with significant effects on individuals without human review. Second, the agent's tool calls create data flows to sub-processors (model providers, vector stores) that need to be documented in your Article 30 register and DPA schedules. Third, prompts often contain personal data that gets logged for debugging, creating a retention question. The ICO's AI and data protection guidance covers each of these; a DPIA is usually required before production launch.

How do we measure whether an AI agent is actually working?

Three layers of measurement. Task-level: does the agent complete the task correctly, measured against a golden dataset of representative cases, refreshed quarterly. Business-level: has the metric the agent was built to move (time to resolution, cost per ticket, conversion rate) actually moved, measured against a control group where possible. Operational: uptime, latency, cost per task, and rate of human intervention. Agencies that only report on the first layer are hiding from the second. A quarterly business review that reconciles all three is the right cadence for most mid-market deployments.

Can AI agents integrate with our existing systems (Salesforce, SAP, legacy databases)?

Yes, and this is often where the real engineering work sits. Modern SaaS platforms (Salesforce, HubSpot, NetSuite) expose APIs the agent can call as tools with well-defined schemas. Legacy systems (SAP on-premise, AS/400, custom ERPs) usually need an integration layer - REST or GraphQL wrappers, sometimes a message queue - built alongside the agent. Budget 30-50% of the build cost for integration work when legacy systems are involved. A capable agency scopes this in discovery rather than discovering it in week eight.

Getting started

The first decision is not which agency, but whether an agent is the right tool for the problem you have. Map the workflow, be honest about how much of it is genuinely non-deterministic, and be willing to accept that a well-built workflow automation may serve you better than an agent for now. If the answer is genuinely agent-shaped, run a four-to-six-week discovery with a specialist before committing to a full build.

AI Advisory works with UK mid-market teams on exactly this scoping question, and builds the agent systems that come out the other side. If you want a conversation about whether your use case is agent-shaped and what a sensible first engagement looks like, get in touch.

Further reading

Sources referenced for context not directly cited in the body:

Ready to put this into production? book a discovery call.

• Claude 3.5 Sonnet