Custom AI Agent Development Services
AI agent development is building software that plans a task, calls your tools and APIs to carry it out, then checks its own work, instead of waiting for a human prompt at every step. InApps designs, builds and runs those agents. An evaluation suite before launch, guardrails and human approval wherever being wrong is expensive, and monitoring you can actually read afterwards.
Trusted by engineering teams across 15+ countries - from startups to Fortune 500.
Most agent projects die between the demo and the first real user
Six failure modes we hear on almost every first call. The demo is never the hard part.
The prototype works on ten hand-picked examples. Nobody knows what it does on the other ten thousand.
There is no eval suite, so "better" is a matter of opinion and every prompt change is a coin flip.
Legal asks what happens when it is confidently wrong in front of a customer. The project stops there.
Token cost was modelled on the demo. At real volume the agent costs more than the person it replaced.
The integrations were the easy slide. They are half the build, and the legacy ones have no sandbox.
The model provider ships a new version. Nothing in the pipeline tells you whether quality moved.
What AI agent development services actually cover
Is a chatbot answering questions it should be acting on?
An agent decides and acts. A chatbot replies
An AI agent takes a goal, breaks it into steps, calls tools and APIs to execute them, reads what came back, and decides what to do next. A chatbot generates a reply and stops. That difference is the whole engineering problem: the moment software is allowed to act, you need to know what it does when it is wrong.
So the build is not the prompt. It is the tool layer, the memory, the evaluation suite that scores every change against real cases, the guardrails that stop an action the business cannot afford, and the monitoring that tells you quality moved before a customer does. InApps builds all of it, then keeps running it.
Single-purpose agents
One job, done properly, with two or three tools behind it.
- Document intake and data extraction
- Ticket triage and routing
- Research and enrichment
- Report and summary generation
- Scheduled back-office runs
- Internal knowledge answering
Multi-agent systems
Several agents with different jobs, and something deciding between them.
- Orchestrator and worker patterns
- Specialist agents per domain
- Handoff and escalation rules
- Shared memory and state
- Conflict and deadlock handling
- Per-agent cost and latency budgets
Tool and system integration
The half of the estimate everyone underprices.
- CRM, ERP and ticketing systems
- Internal APIs and databases
- Legacy interfaces with no sandbox
- Identity, permissions and audit trail
Evaluation and operation
The part that decides whether the agent is still trustworthy in month six.
- Eval suite built from your real cases
- Regression scoring on every change
- Model upgrade testing before you switch
- Token cost and latency monitoring
- Drift and quality alerting
- Support against a response time agreed in writing
Agent, chatbot, or plain automation
An agent is the most expensive of the three and the right answer least often. This is when it is worth it.
| Criterion | AI agent | Chatbot or copilot | Rules or RPA |
|---|---|---|---|
| What it does | Decides the steps, then takes them | Answers, drafts, suggests | Repeats a fixed sequence |
| Handles a case nobody foresaw | Usually. That is the point | Answers, but a human still acts | No. It breaks |
| When the input format changes | Adapts | Adapts | Breaks silently, often for weeks |
| Predictability | Bounded by guardrails and evals, never absolute | A human reviews every output | Total. It does exactly one thing |
| Cost per run | Highest, and it scales with volume | Moderate | Near zero after the build |
| Build effort | Weeks, and the evals are most of it | Days to weeks | Days, if the process is stable |
| What ongoing work looks like | Re-scoring on every model and prompt change | Content and prompt upkeep | Repair whenever a screen or field moves |
| Pick it when | The work needs judgement and the inputs are messy | A person should stay in the loop | The process is stable and fully specified |
Where an agent has actually paid for itself
Grouped by function, with the precondition that decides whether it works. If the third column is not true for you, the agent will not hold.
| Function | What the agent does | Only works if |
|---|---|---|
| Customer support | Triages, answers from your docs, opens and updates tickets | Your documentation is current. An agent inherits its source's errors |
| Back office | Reads invoices and forms, extracts fields, posts to the system of record | Someone will review the low-confidence cases rather than trusting all of them |
| Sales and CRM | Enriches leads, drafts follow-ups, keeps records clean | The CRM has write permissions you are willing to grant |
| Engineering | Triages bug reports, drafts fixes, reviews routine pull requests | Tests are good enough to catch a wrong fix before a human does |
| Internal knowledge | Answers policy and process questions with the source cited | There is one authoritative source, not four with different answers |
| Compliance and risk | Flags exceptions, drafts reports, assembles an audit trail | A human signs off. An agent proposes; it does not certify |
| Logistics and operations | Reconciles orders, chases exceptions, updates partners | Partner systems expose an API. Email scraping is not an integration |
What happens when the agent is wrong
It will be wrong. Any vendor who tells you otherwise has not run one at volume. Four layers, each one firing at a different moment, and all four exist before go-live rather than after the first incident.
Before launch: the eval suite
We build a scored test set from your real cases, including the awkward ones, and every prompt, model or tool change is re-scored against it. That is what turns "this feels better" into a number. Without it you cannot tell an improvement from a regression, and neither can we.
At runtime: guardrails
Hard limits the agent cannot argue its way past. Allowed tools and allowed arguments, spend and rate caps, output validation against a schema, and refusal paths for anything outside scope. A guardrail is code, not an instruction in a prompt.
At the risky step: a human
Any action that spends money, contacts a customer or changes a record of consequence goes to a person first, with the agent's reasoning attached so the review takes seconds. You decide where that line sits, and you can move it once the eval scores earn it.
After launch: monitoring
Every run is traced end to end, so you can open a bad outcome and see the plan, the tool calls and the responses. Quality, cost and latency are alerted on. Rollback is a version switch, not a redeploy, and it is tested before go-live rather than during the incident.
From use case to an agent running in production
Discovery and scoping
Which task, on what data, and what it costs today. This is also where we say no.
Prototype and eval
A working agent on your real data, and the scoreboard that says whether it is good enough.
Hardening
Everything that turns a prototype into something legal will sign.
Deploy and operate
Live, watched, and still being tuned. This is the longest stage by a distance.
Models, frameworks and infrastructure we build on
Model-agnostic by design. Providers change their pricing and their quality on their own schedule, and you should be able to move without a rewrite.
Models
OpenAI, Claude and Gemini, plus open-weight models where data cannot leave your infrastructure. Routing is a config change, so a provider price rise or a quality drop is not a project.
Frameworks
LangChain and LangGraph for orchestration, CrewAI and AutoGen for multi-agent patterns, Pinecone and pgvector for retrieval. We pick per project and we will tell you when none of them is needed.
Infrastructure
AWS, Azure and Google Cloud, in your account rather than ours. Containerised, traced end to end, with the same CI and rollback discipline as any other production service.
Agents are only useful if they can reach the systems the work already lives in. These are the integrations we have built and run most often.
What actually moves the price of an AI agent
We do not publish a rate card for agent work, because the build is rarely the biggest number. Running it at volume usually is. These are the five things that decide it, in the order they tend to matter.
| Cost driver | Cheaper when | Expensive when |
|---|---|---|
| Volume of runs | Hundreds a month, or a smaller model handles most of them | Millions a month. Token spend then dwarfs the build, every month, forever |
| Number of tools | Two or three systems with modern documented APIs | A dozen systems, or one legacy interface with no sandbox to test against |
| Cost of being wrong | A person catches it in the next screen and nothing was spent | Money moved or a customer saw it. Evals and approval steps get much heavier |
| State of your data | One current, authoritative source the agent can read | Four sources that disagree. Cleaning them is a project before the agent starts |
| Regulatory load | Internal tool, no personal data, no external reporting | Personal or financial data, audit trail requirements, residency constraints |
How to evaluate an AI agent development company
Four questions, in the order that disqualifies fastest. Ask us the same four. This category is full of demo-ware, and these are the questions demo-ware cannot answer.
How do you measure whether it works?
The answer has to involve a scored test set built from real cases. If it is "we test it thoroughly" or a benchmark score, there is no way to tell an improvement from a regression, and every future change is guesswork you are paying for.
What stops it doing something expensive?
Ask specifically whether the limits are code or prompt instructions. Prompt instructions are advisory; models ignore them under pressure. You want allow-lists, spend caps, schema validation and an approval step, all enforced outside the model.
What does it cost to run at our real volume?
Not the build. The monthly bill at production traffic, with the model they are proposing. A vendor who has operated agents has this modelled. One who has not will quote the build and discover the rest with you.
What do we own, and can we leave?
Ask whether the prompts, the eval suite and the orchestration code are yours, or sit inside the vendor's platform. Ask whether it runs in your cloud account. An agent locked in someone else's platform is a subscription, not an asset.
Proof, not promises
We have been shipping production software for a decade. The agents are new; the delivery discipline behind them is not.
Worth the call, or worth an early no
An agent is the wrong answer more often than this industry admits. Here is where we say so, on the first call rather than in month three.
This works well if
- The task needs judgement on messy input, and a rule engine has already failed at it.
- People are doing it today, so you have real cases to build an eval suite from.
- The systems it must touch have APIs, and you can grant scoped access to them.
- You can name the number that should move, and you already measure it.
This is not a fit if
- The process is stable and fully specified. A script is cheaper, faster and will not surprise you.
- The answer has to be right every single time with no human in the loop. No agent clears that bar today, and we will not claim ours does.
- The underlying data is contradictory. Fix that first, or the agent confidently repeats the contradiction.
- What you actually need is engineers on your own roadmap. That is staff augmentation, and it costs less.
Ask the people who stayed
Every quote below is from a verified review. None of them were written by us.
“Clear expectations, rules that actually hold, delivered on time. And the people are genuinely easy to work with, not just professionally, but as humans.”
Where your data goes, and who owns what is built
Agents read more of your business than most software does. These are the four answers legal asks for, in the order they ask them.
Your data does not train anyone's model
We run model providers on enterprise terms with training opt-out and zero retention, and we name which provider sees what before you sign. Where that is still not acceptable, the agent runs an open-weight model inside your own infrastructure and nothing leaves it.
IP is yours from the first commit
The orchestration code, the prompts, the tool definitions and the eval suite are all assigned to you under the engagement agreement. No milestone gates the transfer. Nothing sits inside an InApps platform you would have to keep paying for, and it runs in your cloud account.
ISO/IEC 27001:2022 certified
A certified information security management system audited against the 2022 revision, not a self-attestation. It covers the office, the devices and the network, and carries the access control, logging and incident response the standard requires.
GDPR for EU and UK work
Personal data is handled to GDPR requirements, with data processing terms agreed before onboarding. Agents get scoped credentials limited to what the task needs, every tool call is logged, and residency is agreed per engagement rather than assumed.
Answered without the hedging
Still deciding?
Send us the task and roughly how often it runs. We will tell you honestly whether an agent is the right shape for it, including when a script would do the job for a fraction of the cost.
Book a Discovery CallWhat is AI agent development?
How is an AI agent different from a chatbot?
How much does AI agent development cost?
How long does it take to build an AI agent?
Do we need to provide training data?
What happens when the agent makes a mistake?
Can you integrate with our existing systems?
Who owns the agent, the prompts and the eval suite?
Do you offer post-launch support?
Is our data used to train models?
Tell us the task, not the technology
No pitch, no obligation. Describe the job, roughly how often it runs, and which systems it touches. You get a feasibility answer, a scoped use case and both cost numbers, the build and the monthly run. If a script would do it cheaper, we will say that instead.