Sixty firms in this directory list generative AI as something they do. One hundred and thirty three list integration work. Twenty-two list both, and the distance between those three numbers is the reason so many generative AI projects look finished months before anyone can use them.
A generative AI integration agency sells the part nobody demonstrates. The model is the easy half now. Any competent team can stand up something that writes a passable draft, answers a question from a document, or summarises a call, and can have it running in front of an executive inside a fortnight. The hard half is everything that has to be true before that same system can be handed to four hundred employees who did not attend the demo, will not read the instructions, and will escalate to your support queue the first time it says something confidently wrong.
Sixty Firms, Twenty-Two Overlaps
Read those directory counts as a market signal rather than a statistic. Generative AI work and integration work are listed as separate specialities because, for most firms, they genuinely are. A studio that builds content pipelines employs writers, prompt engineers and designers. A firm that integrates systems employs people who have spent years with queues, identity providers, database migrations and the particular misery of a legacy API that returns a two hundred status code on failure. Those are different payrolls.
Twenty-two firms carry both labels, and some of those carry the second one aspirationally. The practical consequence for a buyer is that the agency which built an impressive proof of concept is frequently not the agency that can put it into production, and will rarely say so during the sales process. A generative AI integration agency is the second kind, and the word integration in its listing is doing real work. You can see how the two specialities are listed separately by opening the generative AI category and the AI integration category and comparing the firms that appear on each.
The Demo Ran on a Clean Export
Almost every generative AI pilot is built against a tidy sample. Somebody pulled a few thousand documents into a folder, removed the ones with formatting problems, and indexed what remained. The system that resulted answers questions well, because the questions were asked about documents chosen for being answerable.
Production has the other documents. It has the contract stored twice under slightly different names, the scanned fax from 2011, the spreadsheet where the real information lives in a comment on cell D14, and the policy document that was superseded last March by an email nobody indexed. It also has permissions: the sample folder had none, and the live system must not let a contractor in Ohio retrieve a salary review from a directory they were never meant to open.
Integration work is where those two realities get reconciled, and the reconciliation is most of the budget. The same pattern shows up across every delivery category on this site, which is why the question of what you are actually buying under the phrase custom AI matters before the first invoice rather than after it.
Four Failures That Arrive In Week Three
The failures are predictable enough to put in a table. Each one has a standard engineering answer, and a proposal that does not mention it has not been written by someone who has run one of these systems with real users on it.
| What breaks | What it looks like to a user | What the proposal should name |
|---|---|---|
| The provider is unavailable | A spinner, then a blank panel, during the vendor's incident and not yours | A cached response path, a retry policy with backoff, and a visible degraded state |
| The answer is confidently wrong | A customer is quoted the superseded policy and acts on it | Citations back to source documents, a confidence threshold, and a review queue with a named owner |
| Retrieval crosses a permission boundary | Nothing, until an audit or a complaint | Access control enforced at retrieval time against your identity provider, not filtered after the fact |
| The provider changes the model | Output quality shifts overnight with no deploy on your side | An evaluation set you own, run on a schedule, with a provider abstraction thin enough to swap |
The fourth row is the one buyers consistently underrate. A generative AI system has a dependency that changes without asking you, which is not true of the conventional software your procurement process was designed around. The NIST AI Risk Management Framework treats continuous measurement as a core function rather than an optional extra, and that is the right instinct: a system you cannot re-measure is a system you cannot maintain.
Who Owns The Evaluation Set
Ask this question in the first meeting and listen carefully to the shape of the answer.
An evaluation set is a collection of real inputs from your business paired with the output a knowledgeable person would accept. Two hundred of them is enough to be useful. It is the only instrument that tells you whether a prompt change, a new retrieval strategy or a provider update made your system better or worse, and it is the asset that takes the longest to build because somebody with domain knowledge has to sit down and write the acceptable answers.
It is also the asset most often left in a vendor's account. Model weights matter less than people expect, since providers deprecate and replace them anyway. The evaluation set is what survives, and a firm that keeps it is a firm you cannot leave without starting the measurement work from nothing. Get its ownership into the contract in plain words, along with where it is stored and in what format you can export it.
What The Proposal Has To Answer
Five things, and a proposal missing any of them is a proposal for a pilot rather than a system:
- The failure path. What a user sees when the provider is down, when retrieval returns nothing relevant, and when the model's confidence falls below the threshold. Three separate answers, not one.
- The permission model. Which identity system decides what a given user can retrieve, and whether that check happens before the documents reach the model or after the answer is generated. Only the first is defensible.
- The review queue. Who reads the flagged outputs, how often, and what they are empowered to change when a pattern appears. A queue with no named owner is a log file.
- The measurement plan. How the evaluation set is built, who writes the acceptable answers, how often it runs, and what happens when a score drops.
- The exit. What you hold if the engagement ends next month, and whether your own team can run and change it without the agency in the room.
Those five also work as a filter on firms. An agency that answers all five crisply has run this before. An agency that answers the first and treats the rest as phase two has run a demo before. A generative AI integration agency should clear all five without being prompted. Both are legitimate businesses and they cost different amounts, which is the distinction drawn at more length in our guide to what integration agencies actually deliver.
Briefing A Generative AI Integration Agency
The practical approach for most buyers is to stop looking for one firm that does everything and start being explicit about which half of the work is being bought. Three patterns hold up in practice:
- One firm, both halves. Workable when the firm genuinely employs both skill sets, which the twenty-two overlapping listings suggest is the minority. Verify by asking to speak to the engineer who ran the production deployment, not the one who built the pilot.
- A studio for the build, your own team for the integration. Sensible when you have platform engineers already. The studio needs a written interface contract, and your team needs to be in the room from week one rather than handed a repository at the end.
- An integration firm leading, with a specialist subcontracted. The pattern that fails least often on systems that must survive an audit, because the firm accountable for the outcome is the one that understands your stack.
Whichever pattern you choose, write the five answers above into the statement of work before money moves. Research published through MIT Sloan Management Review has consistently found that organisational and process factors, rather than model capability, separate the companies getting value from AI from the ones still piloting, and the five questions are process questions.
If you want to compare firms against your own brief rather than reading sales pages, describe your project on the matching page and the directory will rank the closest listings by the services each firm names and where it works. If you run an agency that does this work and your firm is not listed, add your listing, and name integration explicitly if you do it, because buyers are filtering on exactly that word.
Sources
- Listing counts for the generative AI and AI integration categories were read from this directory's own database on 5 October 2026, and the category totals can be checked against the directory.
- NIST AI Risk Management Framework, on continuous measurement and governance of deployed AI systems.
- OWASP Top 10 for Large Language Model Applications, on retrieval and permission-boundary risks.
- MIT Sloan Management Review, on the organisational factors that separate deployed AI from piloted AI.
- Stanford HAI AI Index, for background on adoption and model release cadence.
Related reading on this site: choosing between generative AI companies, what to buy across the AI service categories, and the first-time buyer's checklist.