In AI integration, the model is the easy part
The model call is the small part. Most of the work is the plumbing around it.
Key takeaways
6 things that decide this
- 01In an AI integration the model call is the small part; most of the work is the plumbing around it.
- 02Queues absorb bursts so a spike in traffic never stalls the app your team works in.
- 03Keys and permissions live on the server, so the browser never holds a secret and every record knows whose it is.
- 04Stop rules decide when automation must go quiet: on a reply, a booking, an unsubscribe or a STOP.
- 05Every outside service has a deadline. If it fails on the day you need it, the feature fails, however good the model is.
- 06The trade-off: none of this shows up in a demo, so it is the first thing a rushed build skips.
Where do the hours actually go?
When you see an AI demo, you see the model. You type a question, it answers well, and the hard part looks done. That is why so many AI projects stall between the demo and the first real week of use.
Calling a model is a few lines of code. You send it text and a set of instructions, and it sends text back. What you are paying an integration team for is everything around that call. How does data get in? What happens when a hundred requests arrive at once? Where do the API keys live? When should the system stop talking to a customer? What happens when an outside service you rely on is down?
On Algoricum, a platform we built that texts and emails clinic leads until they book, the case study says it plainly: "The model is the easy part. What makes Algoricum work is the plumbing around it." The rest of this post walks through that plumbing, one piece at a time. If you want the shorter argument about where a model belongs in a workflow at all, read AI belongs inside the workflow. This post is about what you build around it.
Why do you need a queue?
Because traffic does not arrive evenly. An ad campaign takes off, a form gets shared, a partner sends a batch, and your system gets a burst of new work in minutes. If each new item calls a model and waits for the answer inside the request, your app slows to a crawl for everyone using it.
A queue fixes that. New work is written to a queue the moment it arrives, and the app moves on. Separate workers take items off the queue in batches and do the slow parts: the model call, the text message, the email. If the burst is big, the queue just gets longer for a while. Nobody's dashboard freezes.
On Algoricum, webhook spikes land in pgmq queues inside PostgreSQL. Dedicated workers drain them in batches for lead ingestion, SMS and email. Keeping the queue inside the same database means one less service to run and watch, and the queue gets the database's backups for free.
Where should the secrets and permissions live?
On the server, always. An AI feature usually needs keys for several outside services: the model provider, a payment processor, a messaging service. If any of those keys reach the browser, anyone who opens the developer tools can copy them and run up your bill or read your data.
On Algoricum, Stripe, Twilio, Mailgun, OpenAI and NexHealth calls all run in serverless functions. The browser asks the server to do something, and the server decides whether this user may do it before it touches a key.
Permissions get the same treatment. Roles and per-route permissions live in the database, and every record is keyed to a clinic workspace. That means a bug in the front end cannot show one clinic another clinic's leads, because the database itself refuses the read. When a model is involved this matters even more, because a model will happily summarize whatever data you hand it.
- 01API keys for the model and every outside service sit in server-side functions.
- 02Every request is checked against the user's role before it runs.
- 03Every record carries its owner, so the database enforces who sees what.
- 04The model only receives data the current user is allowed to see.
When should an AI system stop?
Before it embarrasses you. An automated sequence that keeps texting a patient after they replied, booked or asked to be left alone is worse than no automation at all. It is also, in many places, against the rules for automated messages.
Stop rules are plain logic, not model behaviour. On Algoricum, a nurture sequence halts on a reply, a booking or an unsubscribe. SMS STOP keywords and one-click email unsubscribe halt it too. A booking flips the lead to Booked and creates a task for staff. None of that depends on the model noticing. It is written into the workflow, so it works even when the model has a bad day.
Write your stop rules before you write your prompts. List every event that should end a sequence, and make each one a hard check the system runs before the next message goes out.
What happens when an outside service misses its day?
The feature fails, no matter how good the model is. Most AI integrations lean on outside services: a calendar, a CRM, a messaging provider, a payment processor. Each one has a moment when it must answer, and some of those moments have real deadlines.
Haployee shows this well. It reminds HR teams before employee birthdays and anniversaries, then sends a printed card or gift to the person's home. A reminder that lands on the birthday is already too late, because a posted card still has to travel. So every outside service the product leans on has to answer on the day the scheduler needs it.
That is why one team owns both the Google integrations and their maintenance on Haployee. Hashlogics holds that seat as tech lead. If a Google connection breaks, the fix goes to the team responsible for it, not into a gap between vendors. Webhooks fail the same quiet way, which we cover in webhooks break quietly.
Why does this work get skipped?
Because you cannot see it in a demo. A queue, a permission check and a stop rule all look like nothing when they work. A buyer comparing two proposals sees the same chatbot in both and picks the one that costs less, without knowing that one of them has no queue behind it.
The fix is to ask about the plumbing before you sign. Ask where the keys live. Ask what happens when a thousand leads arrive in an hour. Ask which events stop a sequence. Ask who fixes a broken connection on a Sunday. A team that has built this before answers quickly and specifically. Our API integration and AI development pages describe how we approach each one.
If you want us to look at your systems, start with a 45-minute call. If it is a fit, we write a fixed-fee Blueprint from your real systems, and its fee is credited in full against the build. Here is how we work.
Questions this raises
01What do AI integration services include?+
They include connecting a model to your real systems and everything around that call: getting data in, queues for bursts of traffic, keys and permissions kept on the server, rules for when automation stops, and monitoring of the outside services it depends on. The model call itself is a small part of the work.
02Why do AI integrations fail after the demo?+
Because a demo shows the model and hides the plumbing. Real traffic arrives in bursts, outside services go down, and customers reply or opt out. Without queues, stop rules and someone who owns each connection, the system breaks under ordinary use.
03How do you connect an AI agent to a CRM?+
Through the CRM's API, called from your server, never from the browser. The agent reads and writes only the records the current user may see, and every write goes through a queue so a burst cannot stall the CRM. Our answer page on connecting an AI agent to your CRM walks through the steps.
Related
- API integration →How we connect a product to the outside services it depends on.
- AI development →The service behind production AI features.
- Algoricum case study →Queues, server-side keys and stop rules in a live product.
- Webhooks break quietly →Why a missed event never throws an error.
- How to connect an AI agent to your CRM →The step-by-step version.
