What an AI agent actually is here
An agent is software that reads something arriving in your business, decides what it means, and then acts in your systems through their APIs. The language model supplies the judgment. The connectors, the rules and the audit trail are the engineering, and that is most of the work.
That distinction matters because the word gets used for three different things. A chatbot answers questions on a website. A workflow automation moves fields between apps on fixed rules and stops when the input does not match. An agent does neither: it handles the messy input, decides, acts, and escalates to a person when it is not confident.
- Reads: a phone call, an email, a PDF, a form, or an event in your CRM
- Decides: against your rules, your price list, your history and what the system already knows
- Acts: creates the record, sends the message, files the document, updates the other system
- Escalates: hands a person the decision when confidence is low, with everything it saw
The development process, step by step
Every agent we build follows the same five stages. We publish it because the thing that kills these projects is not the model, it is a vague scope and no definition of done.
- Map. One to two weeks watching the actual work. Who touches it, which systems it crosses, how often, and what the exceptions look like. Output is a written map of the workflow and a ranked list of what an agent could take.
- Scope. We pick one job and write down exactly what the agent will do, what it will never do, which systems it touches, what permissions it needs, and what done looks like. You approve that before anything is built.
- Build. Two to six weeks depending on the connectors. The agent, the integrations, the approval flow, the logging and the test suite. You see it running on real data before it touches anything live.
- Test. It runs alongside the human doing the job. Every action it would have taken is recorded and compared. We tune until the exception rate is boring.
- Hand over and run. It goes live with an approval step and a kill switch. We host it, monitor it, and read the logs. You get a monthly report in plain English.
Two agents we have built, with the systems named
Abstract descriptions of agents are useless for judging whether one can do your job. Here are two real shapes, with the actual software involved.
- The phone agent. A call arrives on a Twilio number after hours. The agent answers as the business, holds a real conversation, handles interruptions and background noise, reads details back to confirm them, and decides whether this is an emergency. It then writes a summary card into Slack with the recording attached, pushes the contact into the CRM, and texts an on-call person when the call matched an escalation rule. Runs on the OpenAI Realtime API for low-latency speech.
- The finance agent. A deal flips to Closed-Won in Salesforce. The agent pulls the account, contacts and line items, validates the deal against margin and vendor rules, then creates a purchase order and a customer invoice in QuickBooks Online. It waits for the QuickBooks to BILL sync, confirms the synced invoice matches on customer, total and open status, generates the payment link, and drafts the customer email. A human clicks approve in Slack before anything reaches the customer.
Which job should be your first agent
The wrong first project is how these efforts die. A team spends four months on the most interesting problem, it half works, nobody trusts it, and the budget for the second one never appears. The interesting problem is rarely the right one to start with.
Four tests, and a candidate should pass all four.
- It happens on a schedule you can name. Every day, every order, every closed deal. If it happens twice a month, the agent will never earn its keep and nobody will notice when it breaks.
- The input arrives somewhere predictable. An inbox, a phone line, a folder, a webhook, a status change in the CRM. If a human has to go and fetch the input first, automate the fetching before you automate the judgment.
- The rules fit on a page. Not simple, but writeable. If two experienced people in your company would disagree about the right answer, an agent will not settle it either.
- A mistake is cheap to catch. There is a natural point where a person can look before anything reaches a customer or the ledger. That check is what makes the first agent safe enough to trust.
Where agent projects fail
We have built enough of these to know the failure modes, and none of them are about the model being insufficiently clever.
The most common is scope that never closed. If the written scope says the agent handles invoices, everyone imagines a different agent, and the build never converges. That is why our scope stage names what the agent will never do as explicitly as what it will.
The second is silent breakage. A no-code automation stops firing, and nobody notices for three weeks because it fails quietly. Anything we run has monitoring on the outcome, not just on whether the code ran, and a person on our side gets paged.
The third is the unattended leap. An agent goes live with approvals, works well for a fortnight, and someone switches the approvals off across the board. Loosen one action at a time, on the evidence of its own exception rate, and keep the financial and customer-facing ones supervised the longest.
The fourth is turnover of the person who understood it. If your one technical person built it in their spare time and then leaves, you own something nobody can change. That is the argument for a run fee: not that you cannot maintain it, but that maintaining it should not depend on one person staying.
The stack, stated plainly
Most agencies will not tell you what is under the hood. Here it is, because you are going to ask anyway and because it affects your data.
We use hosted frontier models through their business APIs, chosen per job: a real-time speech model where latency decides whether a call feels human, a strong reasoning model where the agent has to weigh rules against a messy document. We do not train models on your data, and the business terms of these APIs do not use your data for training either.
Your data stays in your systems. The agent reads and writes through each product's own API using scoped credentials you issue and can revoke in one click. There is no copy of your database sitting in our infrastructure, and every action the agent takes is logged with what it saw and why it acted.
What it costs and how we quote
Three fixed fees, no hourly meter. A meter pays us to be slow, and it makes the bill impossible to predict.
Discovery is a fixed price agreed on the first call, covering the mapping stage. The build is a fixed project price for one agent, quoted after scope so the number does not move. Running it is a flat monthly fee per agent that covers hosting, monitoring, model updates and a person on our side who owns the outcome. You can cancel the run fee and keep the code.
What moves the build price is the number of systems the agent touches and whether it has to speak. Connectors are the work; the model is the cheap part. A voice agent costs more than a text one because latency and interruption handling have to be right or the caller hangs up.
How long it takes
Discovery is one to two weeks. A first agent on one or two systems is typically two to six weeks after scope is signed off. Voice agents sit at the longer end, document-reading agents in the middle, and an agent that watches one system and posts to another can be quicker.
The approval period after go-live is not a delay, it is the product. Expect a few weeks where a person checks every action, then a gradual loosening as the exception rate falls. Anyone promising an unattended agent in week one is selling you a demo.
What you own at the end
You own the code, the prompts, the connectors and the documentation. If you stop working with us you keep all of it, and we will spend a session handing it to whoever takes over.
You also keep the credentials, because they were always yours. We never hold the only key to a system you depend on.
Choosing an AI agent development company
Most firms on this page build for enterprises. That is not a criticism, it is a different job: a bank's agent has a compliance team, a data warehouse and a year. A 30-person distributor has QuickBooks, a shared inbox and a person who is drowning.
If you are the second one, the questions worth asking any AI agent development company are narrow.
- What did you build last month, and can I see it running?
- Who operates it after handover, and what happens at 2 a.m. when an API changes?
- What is the first job you would automate for us, and why that one?
- What does it cost to run, not just to build?
- What do I own if we stop working together?