Most AI agent projects fail at the vendor choice, long before anyone writes code.
People come to me already knowing what they want the software to do. What they cannot tell is which vendor can actually build it and which one can only sell it. The pitch decks look the same. The quotes sit 10x apart. Nothing on a vendor website tells you which one ships working software.
I have delivered 250+ projects since 2009, and I have watched this decision go wrong from the inside more than once. The pattern is consistent. The build rarely fails because the technology was too hard. It fails because nobody agreed on what "done" meant, or because the person who sold the project was not the person who wrote the code.
What follows is the checklist I would use if I were the one signing the invoice.
TL;DR
- An AI agent takes an action. A chatbot only replies. If a vendor uses the words interchangeably, that vendor has not built one.
- Ask five questions before you sign: what model runs it, who owns the code, what happens after launch, can I see it running, and what is the timeline with a reason attached.
- A live demo beats every slide deck. Any vendor building agents can show a small one running in the first or second conversation. A vendor who cannot is learning on your budget.
- Size is not skill. One specialist can outbuild a 200-person agency, because your result depends on the individual assigned to your work, not the logo on the contract.
- Read the portfolio for numbers, not logos. A case study with a measured before and after is evidence. A wall of customer badges is decoration.
- The cheapest quote is usually the most expensive project. Rewrites, slow replies, and time zone gaps cost more than the discount saved.
- If you are weighing one person against a firm, read AI automation consultant vs. agency. If you are still deciding what an agent should even do for you, start with AI agents for business owners.
Table of contents
- What an AI agent actually does for you
- Five questions to ask before you sign
- Warning signs that predict a failed build
- One specialist or a large firm
- How to read a portfolio when you are not technical
- What the work should cost
- FAQ
What an AI agent actually does for you
The outcome you are buying is work that finishes without you clicking through five screens to make it happen.
The term behind that outcome is an AI agent: a program that takes an action on your behalf instead of only answering a question. A chatbot reads your message and writes a reply. An agent reads an invoice, checks it against your records, flags the mismatch, and books the payment, with nobody pressing a button in between.
Anthropic, the company behind the Claude AI model, describes the pattern as a system that directs its own steps and picks which tool to call next, rather than following a fixed script written in advance. That distinction matters commercially. A fixed script is cheap and predictable. An agent that decides its own next step is more useful and harder to get right, which is exactly why vendor choice carries so much weight here.
Most agents need a way to reach your information: your calendar, your support tickets, your customer records. The open standard for that connection is called MCP, short for Model Context Protocol. The official MCP documentation compares it to a USB-C port. One standard connector instead of a custom cable for every device you own.
I built Instill on exactly that standard, an AI knowledge base reached through MCP. It runs with 30+ active users, 1,000+ saved skills, and 45+ projects powered. I built it partly to prove the pattern on a product that real people use daily, not on a demo that works once in a meeting.
None of this has to stay abstract for you. A vendor who understands the work should be able to sketch your specific loop on a napkin in the first meeting: what triggers the agent, what data it looks up, what it decides, and what it does. If a vendor cannot draw that loop for your case, that vendor has not thought about your build yet, whatever the deck says.
Five questions to ask before you sign
Five questions remove most of the risk from this decision. Ask all five in the first or second conversation, and ask for answers in writing.
1. What model or framework runs the agent, and why that one?
You are checking whether the choice was made or inherited. A vendor who tested options against your case can explain the trade-off in one minute: this model costs more per request but makes fewer mistakes on your document type, or this one runs faster and the accuracy difference does not matter for your use. A vendor who answers "it is the best one available" is telling you nobody compared anything.
2. Who owns the code after you pay the final invoice?
Get this in writing before the work starts, never after. Some vendors deliver software that only runs on infrastructure they control, which means the thing you paid for stops working the day the relationship ends. Everything I build is work made for hire. Once you pay, 100% of the code, design, and content is yours.
3. What happens after launch?
An agent is not a website that sits still once it goes live. Models get updated. Your data changes shape. Ask who fixes a break on a Saturday, how fast, and at what cost. A vendor with no answer here is selling you a launch, not a working system.
4. Can I see something running, not a slide deck?
OpenAI's agent documentation describes agents as software that plans, calls tools, and completes multi-step work on its own. That behavior either happens on screen or it does not. Any vendor who has built one can show you a small version working within a week of the first call. This single question filters out more bad vendors than the other four combined.
5. What is the realistic timeline, and what is the reason behind it?
You want a number attached to a reason, not a round number attached to nothing. When I delivered a HubSpot integration for one of Brazil's largest veterinary networks, it reached production in 4 weeks and processed 2M+ records with source-to-HubSpot sync under 50 seconds. Ask any vendor for a comparable figure from real delivered work. "Six to eight weeks, roughly" with nothing behind it is a guess wearing a suit.
A vendor who answers all five without hedging has built agents before, for somebody other than you. A vendor who answers none of them is asking you to fund their learning curve.
Warning signs that predict a failed build
Four signals predict a failed project more reliably than any reference call. Watch for them before money changes hands.
The scope stays vague past the first call. A vendor who cannot describe what finished looks like for your specific case will not know when to stop billing you either. Vagueness in the proposal becomes disputes in month three. Push for a written definition of done, with a list of what is included and, more usefully, what is excluded.
No working demonstration exists before the contract. AWS documents its agent service around a concrete loop: connect to your systems, retrieve information, run multi-step tasks. Those pieces are demonstrable at small scale. A vendor unwilling to show any of it running is asking you to take the entire build on faith.
The person who pitches is not the person who builds. This shows up most in large firms and offshore shops. A senior person with excellent English and 15 years of experience sells the project. A junior person you never met delivers it. Ask directly: will the person in this meeting write the code? Get the answer in writing.
No plan for safety, review, or failure. An agent that acts on your behalf can act wrongly. The NIST AI Risk Management Framework exists precisely because acting systems need controls that a chatbot does not. You do not need to read the framework. You do need a vendor who can tell you what the agent does when it is unsure, who reviews its actions, and how you shut it off in a hurry.
Two or more of these in the first conversation is your answer. Look at delivered work instead. My case studies carry real numbers on every entry, including the ones where the interesting part was the constraint rather than the technology.
One specialist or a large firm
This is the question I get asked most, usually phrased as a worry about risk. The honest answer is that both options carry risk, and they carry different kinds.
A large firm gives you process, contracts, and continuity. If someone leaves, someone else picks up the file. What you give up is directness. Your request travels through an account manager, into a ticket, into a queue, and eventually reaches a developer who has never spoken to you. Every layer costs money and adds a place for your intent to get lost. You are also rarely the biggest account in the room, which decides who gets attention when two projects collide.
A single specialist gives you the opposite trade. You talk to the person writing the code, every time. Nothing gets lost in translation because there is no translation. Decisions land in hours instead of weeks. The risk is concentration: one person can get sick, get busy, or disappear. You manage that risk with code ownership, written documentation, and a repository you control from day one, which you should demand from any vendor of any size.
I work alone by choice, and I take one customer at a time. That constraint is the product. It is why a decision reaches code the same day instead of next sprint, and why I can quote a fixed monthly price instead of billing you for coordination overhead. It also means I say no often, and new work joins a waitlist for the next quarterly slot.
There is no universally correct answer here. If you need 40 people building 12 systems at once, hire the firm. If you need one system built properly by someone who answers you directly, the layers are working against you. I unpack the full comparison in AI automation consultant vs. agency.
How to read a portfolio when you are not technical
You do not need to read code to judge a portfolio. You need to read for evidence, and evidence has a specific shape.
Look for a number with a before and an after. "Improved efficiency" means nothing. "Lead base grew 500% and the pipeline reached 250 new leads per day" is a claim someone can be held to. I built a custom CRM that turned Google Maps into a lead source with exactly those results, using Claude AI in production rather than in a prototype. Numbers like that either exist in a vendor's portfolio or they do not.
Look for constraints alongside the wins. A case study that mentions what was hard, what got cut, and what the trade-off was tells you the vendor was actually there. A case study that reads like a press release tells you a marketing person wrote it from a summary.
Check whether the work reached production. A pilot that impressed a room is not a system people use on Mondays. Ask how long the delivered work has been running and how many people touch it. This one question separates demonstrated capability from a portfolio of experiments.
Ignore the logo wall. A recognizable brand on a vendor site often means a subcontract on one small piece of something large, three years ago, by someone no longer at the company. It is the least informative element on any vendor website.
Ask to speak to a past customer directly. Not a written quote on the website. An actual conversation. A vendor with a healthy delivery record will arrange it. A vendor who deflects has told you something useful.
Platform vendors publish their own reference architectures, and reading one is a fast way to calibrate what is normal. Google Cloud's agent platform documentation lays out the standard pieces of an agent system in vendor-neutral terms. If a proposal you are holding contains none of those pieces, ask why.
What the work should cost
Price varies more by engagement model than by scope, which is why quotes for the same project can sit so far apart.
There are three shapes in this market. Fixed price puts the risk on the vendor and works when the scope is genuinely known in advance. Monthly retainer puts a ceiling on your spend and works when the work is ongoing or the scope will evolve, which describes most AI work honestly assessed. Hourly billing puts all the risk on you and rewards the vendor for taking longer, which is why I do not use it.
My AI Development service runs as a $3,999 per month retainer. It carries a 14-day money-back guarantee, full refund if you are not happy in the first 2 weeks, and you can cancel any time after that. If the work is a full product rather than an AI feature inside an existing one, Applications runs $4,999 per month for Standard and $6,999 per month for Pro. A first investor-ready version as a one-time fixed-price build is $7,999.
Those numbers are published rather than quoted per conversation, on purpose. A vendor whose price depends on how much budget you admit to having is pricing your wallet, not the work.
For sizing a budget before you talk to anyone, run the numbers yourself with the MVP cost calculator. It gives you a bounded estimate from a scope you define, which is a better starting position for any vendor conversation than an open question.
One warning on the low end. The cheapest quote in a stack of quotes usually becomes the most expensive project, because the discount gets repaid in rewrites, slow replies, and the eventual second vendor hired to finish the job. Price the total, not the invoice.
FAQ
What does an AI agent development company charge?
It depends far more on the engagement model than on the feature list. My AI Development retainer is $3,999 per month with a 14-day money-back guarantee. Full application builds run $4,999 per month for Standard or $6,999 per month for Pro. Treat any quote with no published anchor behind it as a negotiation position rather than a price.
How long does it take to build a working AI agent?
Scope decides this, not vendor size. The HubSpot integration I built for one of Brazil's largest veterinary networks reached production in 4 weeks while handling 2M+ records. Ask every vendor you speak to for a real number from real delivered work, and ask what made that project take exactly that long.
What is the difference between an AI agent and a chatbot?
A chatbot answers you and stops. An agent acts: it looks up data, decides a next step, and does something inside a connected system without a person clicking through each stage. The commercial difference is that a chatbot saves you reading time, while an agent removes work from your day entirely.
Can I hire one specialist instead of a firm?
Yes, and for a single well-defined system it is often the better trade. You talk directly to the person writing the code, which removes the layers where intent usually gets lost. Manage the concentration risk the same way you should with any vendor: own the code, own the repository, and require written documentation as a deliverable.
Do I need technical knowledge to work with an AI vendor?
No. A vendor worth hiring explains every technical term in plain words before you sign anything, including all the ones in this article. If you leave a meeting unsure what you just agreed to, that is a signal about the vendor rather than about you.
What happens if the vendor disappears halfway through?
This is why code ownership matters from the first invoice. Insist the repository lives in an account you control, insist documentation is a deliverable rather than a favor, and ask what a replacement developer would need to pick the work up. Any vendor who resists those three requests has answered a different question honestly.
Do I need Model Context Protocol to build an agent?
No, though it helps. MCP is an open standard that lets an agent reach your data and tools without custom wiring for every connection, which cuts both build time and long-term maintenance. I used it to build Instill, and I would use it again on most builds that touch more than two systems.
Next steps
You now have five questions, four warning signs, and a way to read a portfolio that does not require reading code. That is enough to walk into any vendor conversation and tell demonstrated capability from a confident pitch.
The next step is a conversation about your specific build rather than another article. Let's talk about what you want the agent to do, and I will tell you plainly whether it fits a short build, a monthly retainer, or neither.
Related reading: