DEV Community: DOS AI

We pinned our own domain to 127.0.0.1 and our SSRF guard ate two days of voice notes

DOS AI — Wed, 14 Oct 2026 21:45:12 +0000

I build DOS AI (dosai.pro), an AI assistant that answers a small business's customers in WhatsApp, Instagram and Telegram and keeps the leads in a built-in CRM. Customers in Kazakhstan send a lot of voice notes, so the bot transcribes them before it answers. For two days in October it could not hear any of them, and the cause was one line in /etc/hosts.

What changed

We had just moved the platform from a managed cloud to our own server. The hardening script that ran after the move added this line:

127.0.0.1 sb.dosai.pro dosai.pro

The intent was reasonable: the app calls its own storage and auth services hundreds of times a minute, and those calls should not depend on DNS being up. Pin the names to loopback, let the reverse proxy on the box route them by SNI, done.

What broke

The WhatsApp gateway stores every inbound voice note, photo and document in our own object storage and hands the pipeline a link like https://sb.dosai.pro/storage/v1/object/.... Before the pipeline downloads anything from a URL, an SSRF guard resolves the hostname and refuses private, loopback and link-local addresses. That guard exists because the bot also follows links customers paste into the chat, and "fetch whatever the user sent" is exactly how you end up reading your own metadata endpoint.

After the hosts change, sb.dosai.pro resolved to 127.0.0.1 on the server. The guard did what it was written to do: it saw a loopback address and dropped the download. No transcript, no image description, no player in the inbox. The assistant answered "I could not hear the voice note, could you type it?" to every customer who spoke instead of typing.

Over two days: 314 of 339 voice notes, 241 of 248 photos and 92 of 94 documents across 13 projects were lost this way. Nothing crashed. Nothing logged at error level, because a refused unsafe URL is a warning by design. The founder noticed it on his own ad leads.

Why it was not obvious

Three things lined up.

The hosts entry was made by one person as part of infrastructure work. The SSRF guard was written months earlier by another, for a different threat. Neither change was wrong on its own; the combination was.

The failure mode looked like a model problem. "The bot says it cannot hear voice notes" sends you to the transcription code and the prompt first, not to name resolution.

And the guard was correct from its own point of view. A hostname that resolves to loopback is a textbook DNS-rebinding pattern. It had no way to know that this particular name was ours.

The fix

We considered four options.

Remove the hosts entry. Simplest, but it brings back the DNS dependency the migration had just removed, and the next person hardening the box will add it again.
Allowlist by suffix: anything ending in .dosai.pro is fine. Ownership is not inherited by subdomains; a wildcard record or a forgotten CNAME would open the guard.
Skip the IP check for storage URLs only. Fixes this caller, and leaves the same trap for the next internal caller that fetches from our own name.
Teach the guard which public names are ours, by exact match, and ask that question after resolving and before the private-IP check.

We went with the fourth. The site host and the storage host come from the same environment variables the app already uses, so there is one source of truth and no second list to forget. The check is an exact hostname comparison, not a suffix. The connection is still pinned to the resolved address, so a request to our name goes to loopback as intended, and the proxy picks the certificate by SNI.

A hostname we do not own that resolves to loopback is still refused. Look-alike names (sb.dosai.pro.evil.com, dosai.pro-something) are still refused.

export function isOwnPublicHost(hostname: string): boolean {
  const h = hostname.toLowerCase();
  if (APP_HOST && h === APP_HOST) return true;
  return isOwnSupabaseHost(h); // exact match against the storage host from env
}

And in the guard, after DNS resolution:

if (isOwnPublicHost(hostname)) return { safe: true, resolvedIp: allIps[0] };
// ...private / loopback / link-local checks follow for everyone else

The regression test mocks the resolver to return 127.0.0.1 for our own host and asserts the URL is accepted, then does the same for a foreign host and asserts it is refused. On the old code two of the five cases fail, which is the point of the test: it had to go red before the fix, or it proves nothing.

What I took from it

A guard that judges by IP address needs to know your public names, because the answer to "where does our name resolve" is not a property of the name. It changes when you move hosting, add a hosts entry, put a proxy in front, or run in a container with its own resolver.

Security checks that fail closed are correct and quiet at the same time. If a refused download is a warning, the warning needs a counter and the counter needs an alert, otherwise you learn about it from a customer.

And when a bot starts saying "I could not hear that" to everyone at once, suspect the plumbing before the model. The model did not change that morning. The server did.

Measuring whether AI search names your product: six ways the measurement lied to me

DOS AI — Sun, 11 Oct 2026 23:34:01 +0000

I build DOS AI (dosai.pro), an AI assistant that answers a small business's customers in WhatsApp, Instagram and Telegram and keeps the leads in a built-in CRM. Search consoles show where a page ranks. Nobody shows you what an AI assistant says when a buyer asks it for a recommendation, so I wrote a script for that.

The script is under 300 lines. Getting it to tell the truth took longer than writing it. Here are the six places where it, or the things around it, gave me a wrong picture.

The setup

Thirty-five questions a buyer would type, in seven groups: choosing a service, a task to solve, price, agencies, our brand, Kazakh, English. Thirty-two of them do not contain our name. Each goes to a model with the web search tool switched on and an approximate location set to our city. For every answer the script records the text and the cited URLs, then counts where we appear and which sites the answer was built from.

A run costs about a dollar. I have four runs now: one in mid-September, two on October 10 and one on October 12.

1. An echo counted as a mention

The first version counted an answer as "they named us" if the text contained our name. One of the brand questions is "What is DOS AI?". The model answered that it could be AI software for MS-DOS or a denial-of-service attack. Our name was in the text, because the model repeated the question. The script scored it as a hit.

Two of three "hits" in that run were echoes. The rule now: for a question that contains our name, only a citation of our domain counts. The old ruler still prints as a second line, so earlier runs stay comparable.

2. A missing argument looked like a result

--limit takes a number. Without one it became NaN, slice(0, NaN) returned nothing, and the run finished with "named in 0 of 0". At a glance that reads as "nobody names us". A bad flag is now a launch error with exit code 2, and a run with zero answers exits with 1.

3. One run is not a number

On October 10 the script ran twice, four minutes apart. Same 35 questions, different answers. In the first run the model answered the brand question from memory. In the second it searched and found a different company with the same name on another domain, then quoted that company's prices as ours.

The score was the same both times, so the baseline holds. A difference of one answer between runs is noise, because the model decides for itself whether to search. I only treat a change as real when the unbranded count moves, or when three runs move the same way.

A third to a half of the answers involve no search at all: between 11 and 17 of 35, depending on the run. For those questions, nothing you publish this month matters. The answer comes from training data.

4. Published is not the same as visible

Between the last two runs we published eight articles on the site and several on outside platforms. The score did not move, and two days is too short for that. I checked each platform anyway, and the reasons turned out to be more specific than "wait".

One platform serves every article of a free account with x-robots-tag: noindex, and the links I checked there carry nofollow. Those articles do not exist for a search engine. Another keeps a new author's first article in a moderation queue with no public URL. I had counted both as "published".

The check is one request per article: read the response headers and the robots meta tag. I now do it before counting a publication as a publication.

5. The sitemap was not re-read

Search Console has an API. It told me Google last fetched our sitemap six days before the run, which is before any of the new pages existed. Of eight new articles Google knew five, found through links. Resubmitting the sitemap is one PUT request with a write scope on the same service account that reads the reports.

I had assumed that a sitemap with fresh dates gets picked up within a day. The last-download date is in the API response, and it takes one call to look.

6. The profile list had a dead link

Our home page carries a sameAs list in its structured data: the profiles that are also us. It exists to tie the name to the domain, which matters when another company shares the name. One of those profiles returned 404. A comment in the code said every address had been checked by a live probe, with the date. The check was real. It ran once, two months ago.

I wrote a checker that reads the list from the live page and fails on 404 or 410. Its first version reported five profiles, all alive except one. The page lists eleven. A dangling else had attached itself to the inner if, so the walker skipped most of the tree. I caught it only because I compared the count with the source.

A check that prints "all fine" for five items out of eleven is worse than no check. Print the count, and compare it with a number you got some other way.

What the measurement says now

By domain, the assistant finds us and describes the product correctly. By name alone, it finds the namesake. For the 32 questions without our name it does not mention us, and its answers to "which services exist" are assembled from roundup posts on other vendors' blogs.

So the problem sits outside our site. We have enough pages. What is missing is pages on other domains that say what DOS AI (dosai.pro) is. That is slower work than writing articles, and the script will show whether it pays off. The next run is in about two weeks.

What I would do first next time

Decide what counts as a hit before the first run, and test the counting rule on an answer where the model only repeats your question. Then check the things you believe are already true: that your publications are indexable, that the sitemap was fetched, that your own links open. Three of the six problems above were in that second group.

The product these numbers are about: dosai.pro. The page written for AI assistants, with the short description of what it is and what it is not, is at dosai.pro/llms.txt.

Instagram comment-to-DM automation: the limits you design around

DOS AI — Sat, 10 Oct 2026 19:04:07 +0000

"Comment PRICE and I will send you the list" looks like the simplest automation there is. A keyword, a direct message, done. I build DOS AI (dosai.pro), where businesses set up AI assistants for WhatsApp, Instagram and Telegram, and this feature ended up shaped almost entirely by what Instagram will not let you do.

Here are the limits and what we built around each.

You cannot write first, and a comment is the exception

A business cannot start a conversation in Instagram. Not by hand through a tool, not with a bot. The person starts it, with a direct message or with a comment.

So a comment is more valuable than it looks: it is permission to send one private reply. One. After that single message you are silent until the person answers.

In our dialog list such a conversation is marked "waiting for a message", and the reply box is closed. An open box that fails on send reads as a bug.

The practical rule for whoever writes the text: the first message must end with a question. "Here is our price list" ends the conversation. "Here are the prices, which day suits you?" starts one.

One private reply per comment, and it is short

The private reply is a single message of up to 1000 bytes. In Russian or Kazakh that is about 500 letters, since Cyrillic takes two bytes per letter. The limit is in bytes, not characters, which is easy to miss if you only test in English.

The public reply needs variants

Answering under the comment as well is good practice, but the same text under a hundred comments looks like spam to Instagram and can get the account limited. We require at least two variants for a public reply and rotate them.

Hourly ceilings, and a queue instead of a drop

We keep our own ceilings per project: 60 public replies and 200 direct messages an hour. When a post goes viral the rule keeps firing, and the replies above the ceiling wait.

A reply that cannot go now is never dropped. It stays in the feed marked "will go later" and is sent when the ceiling frees up, for as long as Instagram still accepts a reply to that comment, which is up to 7 days. A second comment by the same person does not queue a second reply.

The same queue covers the other reasons a send fails: a temporary error on Meta's side, or revoked access to the account.

The 24 hour window

Once the person writes to you, you may answer for 24 hours after their last message. The rule is the same for a bot, for a human operator in our dashboard and for any other third-party tool. After that the only way to reply is the Instagram app itself.

This is why Instagram is the one channel where our appointment reminders do not run: a reminder a day ahead cannot fit a 24 hour window that started at booking time.

Keyword matching

A keyword matches from the start of a word. A rule on "price" fires on "pricelist". A rule on "book" does not fire on "facebook". Plain substring matching would fire on that second case.

One event is handled by one rule, and keyword rules win over the AI rule.

Letting the model answer real questions

There is a rule that lets the assistant answer genuine questions under posts, such as "how do I book?", when the answer exists in the business's instructions or documents. It skips praise, emoji and spam, and it may not invent an answer.

Each checked comment costs the owner money, like any model call, so this rule has its own ceiling of 60 an hour and sits below the keyword rules.

The follower gate

Owners ask for "send it only to followers". It works: instead of the text the person gets a button, a follower gets the material, a non-follower gets a request to follow and a second button.

We describe the risk plainly in the guide. Instagram's anti-spam rules do not favour trading a follow for a reward, many accounts do it anyway, and after complaints reach can be cut. That is the owner's decision to make with the risk in front of them.

What generalises

Most of the code here handles "not now": one reply only, not after 24 hours, not above the ceiling, not the same text twice. If you build on a messaging platform, list its refusals first and design the states for them, including what the user sees while a message waits.

The owner-facing description is in our guide: rules and comments.

Appointment reminders in a chat bot: six rules we ended up with

DOS AI — Sat, 10 Oct 2026 19:03:30 +0000

I build DOS AI (dosai.pro), a platform where a small business sets up an AI assistant for WhatsApp, Instagram and Telegram. Booking is a core feature there, and the part that sounds trivial, "send a reminder before the visit", turned out to hold most of the rules.

None of this is about the model. The reminder texts are templates, not generated, and they cost the owner nothing. The work was deciding when not to send.

1. Night is a hard wall

Messages about a booking go out between 9:00 and 21:00 in the project's time zone. Two cases fall out of that:

A reminder that would land at night is sent the evening before, at 20:30. A 9:30 visit with a "two hours before" reminder gets it at 20:30 the previous day, not at 7:30.
A confirmation for a booking created at night goes out at 9:00. If the visit itself is before 10:00, the confirmation is skipped, because the reminder already covers it.

A confirmation arriving twenty minutes before the visit it confirms is noise.

2. Do not confirm what the customer already knows

A confirmation is for a person who has not heard from you yet. So it is not sent when:

the bot made the booking itself (it has just written "you are booked" in the same chat);
the chat was active in the last 30 minutes;
the business's own system says it sends confirmations on its side.

Reminders still go out in all three cases.

3. Never write first to a stranger on WhatsApp

A reminder is a message the business sends first, with no fresh message from the customer. WhatsApp blocks numbers that write to people who never wrote to them. So the rule is: we only message someone who has already written to this WhatsApp number, and we check that at send time, not at booking time. If the customer writes between the booking and the reminder, the reminder goes.

For everyone else the booking shows the reason in plain words, "the customer has never written to your WhatsApp number", and a button that opens WhatsApp on the owner's phone with the text prepared. A human sends it. That is slower, and it keeps the number alive.

4. Each channel has its own window

Instagram does not take part at all. You may answer there only within 24 hours of the customer's last message, so a reminder a day ahead cannot get through. Telegram does take part: a chat with a bot exists only if the customer started it.

It is tempting to hide this behind a "send reminder" abstraction. We show it instead, because the owner needs to know why a given customer got nothing.

5. A reschedule must find the same booking

Moving a booking moves its reminders. Cancelling removes them. The hard part is knowing that two events are the same booking.

When a booking lives in an external system, we ask for its booking id and match on that. Without an id we fall back to a rule: a repeat booking by the same customer in the same conversation within 2 hours is a reschedule, a later one is a new booking. It is a guess, and the guide says so.

6. Every message has a visible fate

Each reminder in the list carries one of five labels: scheduled (with the time already adjusted for the night rule), sent, not sent with a reason, not delivered, removed. "Not sent" always names the cause: no WhatsApp connected, subscription ended, reminders switched off, customer never wrote.

Without such a list, "the customer says they got no reminder" has no answer. With it, the answer is one line to read.

What I would do first next time

Write the "do not send" rules before the "send" code. Sending a templated message at a given time is an afternoon. Night hours, strangers, channel windows and reschedules are where the design time goes, and each of them is a case of a real person getting a message they should not have.

The owner-facing description of all this is in our guide: confirmations and reminders.

Choosing an AI chatbot for WhatsApp in 2026: six kinds of tools and ten questions to ask

DOS AI — Tue, 15 Sep 2026 08:34:46 +0000

Every small business owner who has ever missed a WhatsApp message at 11 pm eventually types "best AI chatbot for WhatsApp" into a search bar. The answers mix six very different kinds of product under one word, and the wrong pick costs months.

I build one of these products (DOS AI, an AI assistant for WhatsApp and Telegram with a built-in CRM), so treat my view with that in mind. Below is the map I wish owners had before they talked to any vendor, including us.

First, what changed in 2026

In October 2025 WhatsApp changed the terms of its Business Platform. From January 15, 2026 general-purpose AI assistants ("ask me anything" bots such as ChatGPT, Copilot or Perplexity) are no longer allowed on it. AI bots that serve a specific business (support, bookings, order status, selling that business's products) are still allowed.

In practice: your bot should talk about your business and politely decline everything else. That is also simply good configuration.

Start from the job, not the tool

"We lose customers because nobody answers fast enough." You need something that answers on its own, in free text. Canned replies will not do it.
"Leads get lost in sales reps' phones." You need a CRM with the chat inside. Humans can keep answering.
"The flow is repetitive: book, get a price, get a file." A button script is enough.
"We send promotions to our customer base." That is a separate job, and on WhatsApp it means the official API with approved templates.

Six kinds of tools

Kind	Examples	Who answers the customer	You pay for	Pick it when
WhatsApp Business app	the app itself	you, plus a greeting	nothing	few messages, you answer yourself
Flow builder	Manychat, SendPulse, Chatfuel	a button script	subscription, often per contact	uniform flow from ads
CRM connector	Wazzup, Chat2Desk, Kommo integrations	your reps	per channel	you have a sales team and a CRM
Official API provider	WATI, Twilio, 360dialog	whatever you build on top	provider plan plus Meta template fees	broadcasts, large companies
Agency, done for you	local studios	a bot built for you	build fee or monthly retainer	no time, budget available
Self-serve AI platform	DOS AI, Respond.io AI agents	an AI model on your data	subscription plus usage	the bot must answer on its own and you edit it yourself

A few notes that the table cannot hold:

Flow builders are predictable, which is their strength, and they break the moment a customer writes something the tree did not expect.
Connectors put chats into your CRM but do not answer. At night the customer still waits.
Official API numbers move off the regular phone app, and outbound template messages are billed by Meta. Replies within 24 hours of the customer's message are not.
AI platforms differ mostly in how they connect. Some run on the official API, DOS AI links your existing number by QR the way WhatsApp Web does. All of them share one honest weakness: a language model can be wrong, so anything involving money has to be checked by the system, not by a sentence in the prompt.

Ten questions to ask any vendor before paying

Who answers when the question is off-script: the bot in its own words, "sorry, I did not understand", or nobody?
Does it work on my current number, or do I need a new one or an API migration?
What makes the bill grow: contacts, channels, messages or AI usage? Price it on your monthly volume, not on the "from" tier.
Who edits answers, and how long does a price change take?
What does the bot do when it does not know? The right answer is "let me check" and a handover, not an invented price.
Does it understand voice notes, and in which languages?
Where do leads go: built-in CRM, your CRM, a spreadsheet, nowhere?
Can I test the bot on my own questions before connecting the real number?
How does payment work inside the chat, if at all?
What protects my number from being banned, and does the product send messages to strangers in bulk?

A one-evening test for any option

Take twenty real conversations from last week and write down every customer question, typos and voice notes included. Run them through the vendor's test chat. Count how many answers you would send to a customer without blushing. Fifteen out of twenty means the tool works and the rest is fixed with better instructions. Five out of twenty means no setting will save it.

Where DOS AI fits, honestly

Good fit: small and mid-sized businesses whose customers write to WhatsApp or Telegram and expect a fast answer, such as clinics, salons, driving schools and training centres, especially where customers switch between Russian and Kazakh or send voice notes. Pricing: Telegram is free, WhatsApp is $25 per number per month plus AI usage (a whole customer conversation usually costs 6 to 13 cents), 14 days free after connecting the number.

Not a fit: bulk broadcasting to thousands of people a day, a Meta-verified API number with approved templates, a strict button-only bot, or voice calls.

If you are choosing right now, the ten questions above matter more than any vendor's feature list, ours included.

A check that cannot fail is not a check

DOS AI — Sun, 16 Aug 2026 16:30:19 +0000

Two of my guardrails reported clean for weeks. Neither of them was capable of reporting anything else.

That is a different failure from a broken check. A broken check throws an error and you go fix it. These returned the exact output you get when everything is fine, so I read them as confirmation and moved on.

The grep that searched for a string nobody has ever written

We have a house rule against em dashes in published text. To enforce it on myself I grepped my own diffs:

grep -c $'—\|–' file.md

Zero. Every time. The rule looked healthy for months.

On macOS, BSD grep in basic mode treats \| as two literal characters instead of alternation. So that pattern searches for one literal five-character sequence, —\|–, which appears in no file I will ever write. It returns 0 for a file stuffed with em dashes and 0 for an empty file. Those two zeros look identical.

The version that works:

grep -c -e '—' -e '–' file.md

The interesting part is not the escaping rule. It is that I treated a zero as evidence without once asking what a non-zero would have required.

The analytics tag with nobody to send the hit

Most web analytics snippets have a "defer" or "manual pageview" mode. You turn it on when your app is a SPA, because you want to control when a view is counted instead of letting the loader fire on script execution.

Turning it on has a second effect that is easy to forget. The loader stops sending the initial pageview too. From that moment the counter reports only what your code explicitly sends.

If your code never sends anything, the outside view is indistinguishable from a working install:

the script loads, 200
the counter appears as "installed" in the vendor dashboard
no console errors
no failed requests, because a request that is never made cannot fail

You get an empty dashboard, and an empty dashboard has a much more likely explanation available: nobody visited. That explanation is wrong and it is very comfortable.

The 20-second probe, using Yandex Metrica as the example, works the same way for most vendors:

open any page with ?_ym_debug=1
console must print: PageView. Counter <id>.

If that line is missing, nothing is being counted, whatever the dashboard says.

The fix is two lines and the comment above them matters more than the code:

// The counter runs deferred because this is a SPA and route changes are
// not document loads. Deferred means the loader sends NOTHING on its own.
// If you ever remove `defer`, remove this call in the same commit, or every
// view is counted twice.
export function trackPageView(url: string, referer?: string) {
  window.ym(COUNTER_ID, "hit", url, referer ? { referer } : undefined);
}

Two settings that must agree, living in two files, with no error on either side when they disagree. That is the shape of the problem.

What both of these have in common

Neither check had a failing case I had ever observed.

I had never seen the grep print a number greater than zero. I had never seen the analytics dashboard show a number at all. In both cases the absence was the expected output of the healthy state, so it carried no information, and I kept banking it as good news.

Three habits came out of this, and they are cheap:

Feed the check something bad on purpose. Before trusting a linter, a grep, a hook, or an alert, hand it input that must trip it. If you cannot make it fail, you do not have a check. You have a constant.

Be suspicious of zero specifically. Zero errors, zero matches, zero events. Every one of those is also what a disconnected pipe returns. A pipeline that reports "3 problems found, 3 fixed" tells you it ran. A pipeline that reports nothing tells you nothing.

Verify at the far end, not at the near end. "The script returns 200" is a fact about your server. "The console prints PageView" is a fact about the thing you actually wanted. They are not the same fact, and only the second one is worth anything.

The pattern generalises past these two. Alerts wired to a metric nobody emits. Retry logic behind a condition that is never true. A test asserting a mock. In each case the system reports health, because reporting health is the only thing it can do.

I write about the ugly parts of running an assistant product on top of WhatsApp and Telegram at dosai.pro. The public API and MCP server are documented at dosai.pro/docs/guide/08-developers/80-public-api.

Automating a phone number you do not own: four invariants

DOS AI — Sun, 16 Aug 2026 11:04:42 +0000

If your product connects to WhatsApp through the linked-device protocol, your code operates a phone number that belongs to someone else. A small business owner scans a QR code and hands you their working line, the one printed on their van and saved in every customer's contacts.

The cost of a mistake is not a 500 in your dashboard. It is a ban, and a ban is not something you can refund. Only the messenger lifts it, on the owner's appeal, on their timeline.

What surprises most teams is that the anti-fraud system does not only read outgoing text. It watches how your protocol client behaves. A number can be flagged after two messages in a week if the client around it looks wrong.

Below are four invariants I now treat as non-negotiable for any system of this kind. None of them are about content.

1. Reaction is allowed, initiative is not

Replying to an incoming message is fine. Everything your process starts on its own is suspect.

Never let automation tear down a live session, request a fresh QR, wipe stored credentials, or scan the server for numbers on a schedule. Those actions belong to an explicit human click in your UI, and nowhere else.

The dangerous code is always well-intentioned. It reads like this:

// looks caring, behaves like an unstable client
if (Date.now() - lastInbound > SILENCE_THRESHOLD) {
  await restartSession(sessionId);
}

The intent is "the channel has been quiet, let me reconnect just in case". From the outside, a client that re-authenticates a healthy session three times in a morning is indistinguishable from a compromised or emulated one. Silence is usually just a quiet Tuesday.

If you need a liveness check, make it one auth-safe probe per silence episode with a long cooldown, and log the outcome. Anything that can loop must not touch authentication.

2. Any bulk lookup must converge

Sooner or later you will want to resolve identifiers: map contacts, check which numbers exist, backfill a table after a protocol change. That loop talks to the messenger about people who are not your users.

Three properties make it acceptable:

it remembers negative answers, not only successful ones
it has a ceiling per pass
it has a minimum interval between passes

Remembering only successes is the classic bug. Every pass re-asks about the same unresolvable numbers, the query count never drops, and the loop runs forever at full volume.

The convergence probe is arithmetic. Count the lookups per day and compare consecutive days. Falling is healthy. Flat means the loop is asking the same questions forever, and from the provider's side a permanent high-volume stream of questions about third-party numbers looks exactly like scraping a contact database. That is a category they ban for on its own, no matter how few messages you send.

// the fix is one table, not a rewrite
await recordLookupResult(number, result); // including "not found"
const pending = await pickPending({ limit: CEILING, olderThan: MIN_INTERVAL });

3. A process restart is not a reason to touch every session

Deploys are when fleets die together. The container comes up, the boot path iterates over stored sessions, and every number reconnects inside the same second.

Stagger it. A dozen seconds between reconnects plus jitter, and no automatic connection at all for sessions with no stored credentials, since those can only produce a QR request that nobody asked for.

for (const [i, session] of sessions.entries()) {
  if (!session.hasStoredAuth) continue;      // QR is a human decision
  await sleep(i * 12_000 + Math.random() * 4_000);
  void connect(session);
}

4. There are no silent touches

Every disconnect, reconnect and re-auth gets a row in a durable log with a parsed reason, and that log has to outlive the process that writes it.

This sounds like ordinary hygiene until the day you need it. When a number gets flagged, you have one question to answer: what did our client do in the hours before. If your telemetry lived in container stdout, the answer is a guess, and guesses are how teams end up blaming the messenger for their own restart loop.

Write the events to a table. Mount the raw log on a volume. Archive it on rebuild. It costs nothing and it is the difference between a post-mortem and a shrug.

The test to run on your own code

Take any automation you have that touches a session, and ask: if this misfires ten times in a row on a live customer number, what does the provider see?

Ten replies to ten incoming messages, fine. Ten re-authentications, ten QR requests, or ten thousand queries about strangers' numbers, not fine. That question catches the whole class, and it catches it before someone loses their business line rather than after.

I build DOS AI, where these rules are enforced by the platform rather than left to the integrator. Happy to compare notes in the comments if you run a fleet of your own.

Putting an MCP server in front of a real product: four things I got wrong first

DOS AI — Sun, 16 Aug 2026 11:04:31 +0000

If you ship an MCP server for a product that already has a REST API, the tempting move is to wire the tools straight into your service layer. Skip the network hop, call the function, return the object. I did the opposite, and after a full audit of the surface I am glad I did. Here are the four decisions that turned out to matter, three of which I only got right on the second pass.

I build a platform where an AI assistant answers customers in WhatsApp and Telegram, and the owner manages projects, conversations and leads from a dashboard. The MCP server exposes a slice of that to AI agents.

1. Every tool calls your own HTTP route, not your service layer

This looks like pure waste. You are inside the same process, you have the client, you could call listConversations(projectId) directly and save 20ms.

Do not.

Our API keys carry a read-only flag, and the gate that enforces it reads the request method from a header that middleware sets. An in-process call has no request, no header, and therefore no gate. The same is true for role checks, project scoping and rate limits: all of them live on the route. Bypassing the route means reimplementing four security controls in a second place, where they will drift.

// tool definition, simplified
{
  name: "list_conversations",
  method: "GET",
  path: (args) => `/api/projects/${args.project_id}/conversations`,
  project: (args) => args.project_id,
}

The tool layer becomes a projection: build a path, forward auth, shape the result. Nothing else. When we later added a new permission rank, no MCP code changed.

2. A 200 response is not a successful operation

Our send-message route returns HTTP 200 with { ok: false, error: "channel refused" } when the messaging provider rejects the payload. The route did its job, so 200 is correct.

The first version of the tool reported that as success. An agent told a human "message sent" about a message that never left the building. That is the worst class of bug in an agent product, because the agent is confident and the user has no reason to check.

So tools carry an explicit failure predicate:

{
  name: "send_message",
  failWhen: (body) => body?.ok === false,
  failMessage: (body) => `Channel refused the message: ${body?.error ?? "unknown"}`,
}

Rule of thumb: if your route can express failure inside a 200 body, your tool layer must know about it. HTTP status is a transport signal, not a business one.

3. Unwrap your envelope, or your confirmations arrive empty

Most of our routes answer with an envelope: { data: ... }, and a couple with { success: true, data: ... }. Human clients unwrap it without thinking. The tool projection did not.

The result was subtle. update_prompt returned { ok: true } and nothing else, because the interesting part sat one level deeper and got dropped. The agent had no way to confirm what it had written, so it either stayed vague or invented the detail.

const body = await res.json();
const payload = tool.unwrap ? unwrap(body) : body;

Test this per tool. A single shared unwrap is not enough if some routes wrap and some do not, which is exactly the state most real APIs are in.

4. Idempotency keys must be built from meaning only

Our send tool deduplicates repeated calls. The first key looked like this:

const key = `${conversationId}:${text}:${Math.floor(Date.now() / 60_000)}`;

The minute bucket felt harmless. It is not. Two identical calls that straddle a bucket boundary produce two different keys, so the duplicate goes through. The failure is rare, non-deterministic and impossible to reproduce on demand, which is another way of saying it will happen in front of a customer.

const key = `${conversationId}:${sha256(text)}`;

If time belongs in the key, it should come from the domain (a booking slot, a billing period), never from the clock at call time.

The thing I decided on purpose: no destructive tools

There is no delete-project tool, no payment tool, no remove-member tool. Not because they are hard, but because an agent that can read a customer message can be talked into acting on it, and the blast radius of a confused delete is not recoverable by an apology.

A test enumerates the registry and fails if a tool name matches a destructive verb. That test exists so that a future me, in a hurry, has to argue with a red build instead of quietly adding one.

What I would tell someone starting today

Treat the MCP layer as a thin, dumb projection of an API you already trust. Every piece of intelligence you put in it is a piece of intelligence that now exists twice.

Check the three failure modes above with a real agent, not with curl. Curl reads a raw JSON body and you fill in the meaning yourself. An agent reads what your tool returns and reports it to a human as fact, so an empty confirmation or a false success becomes a lie with your name on it.

The spec of what we expose is public if you want to compare notes: dosai.pro/llms.txt. Happy to go into the auth details in the comments.

Your prompt is not a security boundary

DOS AI — Sun, 16 Aug 2026 03:56:19 +0000

If your AI agent owns tools with side effects, one question decides whether it
is safe to ship: what happens when the model confidently calls a money tool on
invented grounds.

This is a writeup of one mechanism that closes that hole, and of where the
mechanism stops working. The context is assistants that talk to real customers
in messengers and can do irreversible things: confirm a payment, issue an
invoice, book a slot, notify the business owner.

Why an instruction in the prompt is not a control

A line like "only confirm payment after you received the receipt" executes
with a probability, not with a guarantee. That is not a quality problem with
the model. It follows from the training objective: be helpful, agree with the
person in front of you.

The conversation goes like this. The customer writes "I already paid, I will
send the receipt later, please confirm". There is no receipt. The model sees a
polite persistent human, sees an instruction that contradicts him, and over a
long context it picks cooperation. It answers "payment confirmed" and calls
the tool.

For tone of voice, probabilistic execution is fine. For money it is not.

One more hope worth killing early: the tool config field that looks like a
predicate. Most function schemas carry something like trigger_type, and
ai_decides literally means "the model decides". That field controls when the
tool is offered, never under which facts the tool is allowed to fire.

A precondition is a declarative fact about the conversation

The idea is small. A function carries a list of facts that the executor checks
against the database before dispatch. Not "the model believes a receipt
exists", but "there is an inbound attachment in this conversation".

Stored as JSONB next to the function:

[
  { "type": "client_sent_media", "within_messages": 10, "media_kinds": ["image", "document"] },
  { "type": "lead_field_filled", "field": "phone" }
]

The type list is deliberately short and covers nearly every real requirement:

type FunctionPrecondition =
  | { type: "client_sent_media"; within_messages?: number; media_kinds?: string[] }
  | { type: "lead_field_filled"; field: string }
  | { type: "function_called_before"; name: string }
  | { type: "min_client_messages"; count: number };

client_sent_media scans the last N messages written by the customer rather
than the last N rows of the thread. An owner who configures "the last 10
messages" means ten customer replies, not ten rows half of which the bot wrote
itself. The window is capped by a constant so that within_messages: 100000
in a config cannot turn the check into a table scan.

function_called_before reads the event log and requires an earlier
successful call in the same conversation. That is how you build chains like
"verify identity first, then modify the booking".

Three implementation properties that carry the whole design

The check lives in exactly one place. It sits in the tool executor, after
argument validation and strictly before dispatch to any handler. Put it inside
the handlers instead and you fix the class one handler at a time, which means
the next money-touching tool ships without a guard.

A block is returned to the model as a tool error with a reason. Not a
silent refusal:

Blocked: the customer must have sent a image/document attachment in their
last 10 messages. This did NOT happen. Do not tell the customer it did.
Ask the customer for what is missing, then call this function again.

The difference matters more than it looks. After a silent refusal the model
assumes the call went through and keeps lying to the customer. An error with a
cause produces self correction inside the same round: the bot goes and asks
for the receipt.

The requirement is appended to the tool description, so the model sees it
before spending a call:

HARD REQUIREMENT: this function is blocked and will refuse to run unless the
customer must have sent a image/document attachment in their last 10 messages.
Do not claim the action happened until the call actually succeeds.

Fail open, on purpose

When the check itself throws, the call goes through. It is not blocked.

} catch (err) {
  logger.error("Precondition check failed, letting the call through", { ... });
}

Here is the reasoning. A precondition defends against model hallucination, not
against an attacker. An attacker has no reach into this layer at all: he
speaks to the bot in words, while the facts come from our own database. So the
failure mode should be chosen by cost. Blocking every function for every
customer because Postgres blinked means breaking live conversations (no
invoice, no booking, no answer) over a hypothesis. The failure goes loudly
into the log, and the decision falls back to the prompt, exactly as it was
before the guard existed.

If this were access control the choice would be the opposite, fail closed. It
is not access control, and pretending otherwise would be worse than having no
guard.

What it does not solve

It does not replace authorization, idempotency or rate limits. It answers one
question: is there a fact in this conversation without which the action makes
no sense.

It does not rescue a badly specified function. If your only guard is
min_client_messages: 2, you moved the problem one message down the road.

It costs nothing where it is not used. A function with an empty precondition
list issues zero queries, the branch returns on an empty array. That property
is what keeps the guard alive past the second release: a check that slows down
every conversation for the sake of one money flow gets removed by whoever is
on call.

The takeaway

An LLM in production behaves like a capable intern. Most of its calls are
good, and nobody lets an intern sign the cheques. Boundaries belong in code,
get verified against data, and get logged in a way that survives a restart.
The prompt owns the quality of the conversation, and nothing beyond it.

All of the above runs in the platform I build, DOS AI: AI assistants for
WhatsApp and Telegram with a built in CRM, configured in plain text. If you
are building your own, our REST API, webhooks and MCP server are public, so
you can plug your agent in and look at the contract from the outside. The
machine readable spec sits at https://dosai.pro/llms.txt and the code samples
are on GitHub: https://github.com/adsytd1/dosai-api

Happy to go deeper on failure modes in the comments.