DEV Community: Dialog Brain

How to stop your AI chatbot making up answers

Dialog Brain — Tue, 27 Oct 2026 08:30:00 +0000

A chatbot makes up answers when a customer asks something nobody taught it, and however carefully you teach an AI agent about your business, customers will ask it something you never wrote down. What matters is what happens next: whether it guesses, or tells you, and whether you find out once, or never.

Every agent meets a question it was never taught

You wrote down your prices, your hours, your delivery zones. Then on day two someone asks whether you deliver on Sundays, whether they can bring a dog, whether you take card payments over the phone. None of it is in the instructions, because nobody thinks of everything in advance.

An agent in that position can do one of two things. It can guess, and a confident wrong answer about a price or an opening time is worse than no answer. Or it can say it will check with the team. The second is right, but on its own it leaves you nothing: the same question arrives next week, and the week after, and you only notice when a customer complains.

Turning “I don’t know” into a list you can act on

DialogBrain closes that loop. When the agent cannot find the answer in your knowledge base, it is told not to guess but to answer the customer the way your instructions say, and it also notes the question for you.

Those notes go into one list in your workspace. Customers ask the same thing in many ways, “how much is shipping?”, “is delivery free?”, “what does it cost to deliver to my area?”, so questions that mean the same thing are gathered into one row with a count beside it. The row asked forty times sits at the top; the one-off question sits at the bottom. You see at a glance which missing answer costs you the most replies.

Questions that only look alike are kept apart. “When do you open?” and “when do you close?” use nearly the same words and need different answers, so they stay separate rows.

Answer once, in your own words

Opening a row shows how customers actually phrased it and links to each conversation. You write a short title and the answer, and save it. From that moment it is part of your knowledge base: the next customer who asks, in whatever words and whichever language, gets your answer from the agent.

Nothing is sent to the people who already asked, the answer is for everyone after them. And the title is yours, not a copy of a customer’s message, so a name, a phone number or anything else someone typed never ends up in the material your agent reads.

If a question keeps coming back after you answered it, the list says so: the answer is there, but the agent did not connect it to the way people ask. Rewording the question, and the answer, if needed, in the customers’ own words usually fixes it.

The agent now finds your documents in a busy inbox

While building this we found a second reason agents sometimes said “I don’t know”: the answer was in a document the owner had uploaded, and the agent still did not see it.

When an agent looks something up, it searches your documents and your past conversations together. In a workspace with years of chats, those conversations are thousands of short messages, and many of them sound a little like any question, “are you open today?”, “what time?”. They crowded the one handbook page with the real answer out of the search before it was ever weighed.

Now documents and conversations are searched separately, and your documents are always given room in what the agent reads. The handbook page is found again, and so is every answer you add from the list of unanswered questions.

What it takes from you

About five minutes a week. Open the list, answer the two or three rows at the top, hide the ones that are not about your business. After a few weeks the list is short and your agent answers most of what customers ask on its own.

Questions and answers

Why does my AI chatbot say “I don’t know” when the answer is in my documents?

Often because years of short chat messages crowded your documents out of its search, so the page with the answer was never read. DialogBrain now searches documents and conversations separately and always gives your documents room, so that page is found again.

Will the AI agent make up an answer it does not know?

It is instructed not to: when your knowledge base has no answer, it notes the question for you and replies the way your instructions say. But it can only fall back well if you tell it how, add one line to its instructions, for example: “If you don’t know, say a colleague will reply shortly.”

Do I have to answer every question?

No. Answer the ones at the top of the list, they cover most of what customers ask. Hide the ones that are not about your business, and they stop coming back.

Does the customer who asked get my answer?

Not automatically. The answer goes into your knowledge base for everyone who asks after that. If someone is still waiting, the list links to their conversation so you can reply yourself.

Does it work in other languages?

Yes. Questions asked in different languages about the same thing are grouped together, and the agent answers each customer in the language they wrote in.

Originally published at dialogbrain.com.

Giving an AI agent its own IP address

Dialog Brain — Sun, 25 Oct 2026 12:00:00 +0000

An agent that logs into sites on your behalf arrives from a datacenter, and the sites can tell. You can now hand it your own WireGuard, OpenVPN or residential proxy, for the whole workspace, or for one identity at a time.

The problem is the address, not the agent

An AI agent that works in a browser does everything a person does, opens a site, signs in, clicks, reads, replies. What it cannot do by itself is arrive from a plausible place. It arrives from a cloud provider’s address range, which any consumer site can look up in a public database, and which no ordinary customer of that site has ever used.

That single fact produces most of the friction people blame on automation being "detected". Extra verification on login. A sign-in that works from your laptop and fails from the agent. Two accounts that should have nothing to do with each other treated as one, because both were reached from the same address.

None of that is about how convincingly the agent behaves. It is about where it came from, and it is fixed in one place rather than by making the agent act more human.

Bring your own exit

A workspace can now leave the network in one of three ways: directly, through a residential proxy you supply, or through a VPN profile you upload, WireGuard or OpenVPN, whichever your provider gives you.

You paste the provider’s config as-is. It is encrypted with a key scoped to your workspace, and no endpoint returns it, the form is empty when you reopen it because there is genuinely nothing to show, including to you.

Configs are checked against an allowlist rather than trusted. WireGuard’s PostUp and PreUp, and their OpenVPN equivalents, run shell commands on the machine that loads them; a config carrying one is refused, naming the directive it tripped on. That is a deliberate refusal of a real capability, not a parser limitation.

[Interface]
PrivateKey = <from your provider>
Address    = 10.66.66.2/32
DNS        = 1.1.1.1
MTU        = 1280

[Peer]
PublicKey  = <from your provider>
AllowedIPs = 0.0.0.0/0
Endpoint   = frankfurt.example-vpn.com:51820

# Paste the file as your provider shipped it.
# PostUp / PreUp lines are refused, not run: they
# execute shell, and nothing here needs them.

One exit per account, not one per company

The interesting setting is not the workspace default, it is the override on a single browser identity. Each identity can take its own VPN profile, so the account you keep in Frankfurt is reached from Frankfurt and the one in Amsterdam from Amsterdam, while everything else goes direct.

That is the difference between "our company uses a VPN" and "these two accounts have never shared an address". For anyone running more than one presence on the same platform, the second is the only version that means anything.

The resolution order is short, and its middle step is the one people get wrong: an identity with no setting inherits the workspace default. It does not mean direct.

the identity's own setting
  ↓  (unset, which means inherit, never "direct")
the workspace default
  ↓  (unset)
direct

# At every step, if the chosen exit cannot be produced,
# the request FAILS. It never quietly falls back to ours.

It covers the API calls too

A browser session is the visible half. The other half is every outbound call your workspace makes to a third-party API: OAuth token exchange and refresh, connection tests, API-spec discovery, the MCP transport an assistant speaks over, and the tool calls themselves.

Those requests reach the same provider the browser session does. Leaving them on a datacenter address would both expose the address you are paying to hide and break any provider that ties a session to the IP that created it, the token minted from one place, used from another.

One boundary is worth stating plainly, because it is the opposite of what people assume: an integration bound to a browser identity for its cookies still takes its network path from the workspace default. Cookies from the identity, IP from the workspace.

It fails closed

If the chosen exit cannot be produced, the tunnel will not come up, the proxy is switched off, the selected profile was deleted, the request fails. There is no quiet fallback to our address.

This is the part worth insisting on. A silent fallback is the worst possible behaviour: it puts the datacenter address on the wire for exactly the workspace that is paying not to be there, at exactly the moment nobody is watching, and you find out from the other end, from the account that got flagged.

So a broken exit is loud. The card says so while collapsed, the status pill in the header turns red at any screen width, and a test that has never run reads as unproven rather than green. Green means a live test went out through that exact tunnel and came back with an address.

What a tunnel costs you

Nothing while idle. A tunnel is started when something needs it and shut down after about fifteen minutes of quiet, so there is no permanent connection to pay for and no stale tunnel left holding a route. The first request after a gap waits for the tunnel to come up, measured at about four seconds.

A word on free VPNs, since it is the first thing people try: they work for confirming the feature does what it says, and they are a poor production exit. Every user shares one address, so the sites you care about have already rate-limited it, and you do not get to choose a country. A dedicated exit exists precisely to not be shared.

Questions and answers

Does this hide that an AI agent is doing the work?

No, and it is not meant to. It changes where the traffic comes from, not what the agent does or discloses. What it removes is a mismatch that has nothing to do with the work: a real account, operated on your behalf, arriving from an address no customer would ever use.

WireGuard or OpenVPN?

Both work; paste whichever your provider gives you. WireGuard connects faster and its config is a dozen lines, which is why most providers now lead with it.

Can I use a different country per account?

Yes, that is what the per-identity override is for. Upload one profile per exit, then point each browser identity at the one it should use. A workspace holds up to five profiles.

What happens to my running browser sessions when I switch?

They are rebuilt against the new exit rather than kept on the old one, the exit is part of what makes a pooled session reusable, so changing it retires the session instead of leaving it running on the address you just stopped using. Allow about a minute: the resolver caches the answer for that long, so a session already in flight can finish on the old exit before the new one takes over.

Who can change it?

Only a workspace owner. Members see the current state; the public viewer tier sees none of it. Changing where an entire workspace appears from is not a setting to leave open to everyone who can read the inbox.

Originally published at dialogbrain.com.

respond.io vs SleekFlow vs Wati: what each one charges for, and where each one stops

Dialog Brain — Fri, 23 Oct 2026 08:59:07 +0000

Most comparisons of WhatsApp inbox tools list features in a grid and stop there. The grid hides the part that decides the bill: what each product counts. One counts seats and active contacts, one counts channels, one sells the AI agent as an add-on. This post walks through respond.io, SleekFlow and Wati on the questions that usually come up when a small team picks one, using their public pricing and help pages as of October 2026.

Disclosure: I work on DialogBrain, which competes with all three. I'll say where each of them fits better than we do.

What you pay for

respond.io is built around tiers: Starter $99, Growth $199, Advanced $349 a month ($79, $159 and $279 billed yearly). Each tier comes with a set number of users and monthly active contacts, and WhatsApp fees are on top. The trial is 7 days.

SleekFlow prices by region. On its ASEAN page, Pro is US$99 a month with 3 seats, 1,000 active contacts and 3 channels; Premium is US$299 with 10 seats and 10 channels; an extra seat is US$30. The WhatsApp Business Platform adds US$10 a month per number plus conversation rates. Also a 7-day trial.

Wati has Growth, Pro and Business. Growth has 3 users and no way to add more; Pro and Business have 5, with extra seats at $24 and $69 a month. Message fees follow Wati's rate card.

The thing to check before you compare prices: which limit will you hit first? A team of two with heavy inbound traffic hits active contact limits. A shop selling on WhatsApp, Instagram, Telegram and a website chat hits a 3-channel cap. A team of four on Wati Growth hits the seat limit, because Growth has none to add.

The AI agent: included or an upgrade?

This is where the three differ most.

respond.io: AI Agents start on Growth. Starter has none.
SleekFlow: AI agents from Pro; AI agents that call your integrations from Premium.
Wati: the agent is called Astra. Not on Growth, a separately priced add-on on Pro, included on Business.

If the reason you are shopping is "we want an AI agent to answer the first message at 3 a.m.", the entry plan of each of these will not do it, and the real starting price is one tier up.

WhatsApp: API only

All three are built on the official WhatsApp Business Platform (the API). That is the right route for template broadcasts and click-to-WhatsApp ads.

respond.io: bots created through BotFather only. Its help center says a Telegram Business account cannot be added.
SleekFlow: one bot, created through BotFather.
Wati: Telegram is not among its channels.

If your customers write to a person on Telegram (common in Eastern Europe, the Middle East and parts of Asia), none of the three connects that account. A bot is a different contact with no history.

Calls

respond.io lists calls, AI voice calls and call transcripts on its pricing page.
SleekFlow lists VoIP calls and local number hosting as not available at the moment.
Wati supports WhatsApp Business Calling, answered by Astra and handed to the team.

API and automation

respond.io: developer API and Zapier or Make from Growth; webhooks and HTTP requests in workflows from Advanced.
SleekFlow: webhooks and HTTP requests in flows from Premium; Shopify, HubSpot and Salesforce integrations depending on the plan.
Wati: no webhooks on Growth, limited on Pro, extensive on Business.

Where each one fits

respond.io fits large teams that run on broadcasts and deep workflow automation.
SleekFlow fits commerce teams in Asia that want Shopify and CRM integrations and click-to-chat ads out of the box.
Wati fits a team whose whole business is WhatsApp marketing: click-to-WhatsApp ads, broadcasts and a Shopify store.

Where DialogBrain is different

Since I work on it, here is the short version, and you can check it against the tables linked below.

Priced per connected channel: $20 a month per channel, $5 per extra teammate (the owner's seat is free), AI usage paid as used. No tiers, so nothing is held back for a higher plan. 14 days free, no card.
The AI agent is on every account and every channel, answering from your website and files and handing the chat to a person when it is unsure.
WhatsApp either way: link the number you already use by QR, with its chats and groups, or connect a Business API number. Both can sit side by side.
Telegram as your own account, with real chats, groups and calls, or as a bot.
The same agent answers calls on Twilio or Telnyx numbers, Telegram and WhatsApp, and joins Google Meet or Microsoft Teams to write the transcript.
REST API, webhooks and a hosted MCP server on every account.

Side-by-side tables with the sources:

If what you need is an agent on the phone line rather than the chat, there is a separate page on the AI phone agent, and for a support desk across channels, the AI customer support agent. For a shop that wants one chat on the site and in messengers: live chat for an online store.

Prices change, and SleekFlow's vary by region. If you spot something out of date, say so in the comments and I will correct it.

How to connect WhatsApp, Telegram and email through ChatGPT or Claude

Dialog Brain — Thu, 22 Oct 2026 09:30:00 +0000

Connecting your channels no longer means finding your way around settings. Tell ChatGPT, Claude or Claude Code what you use and it sets it up: it connects what can be connected from the chat, and for the rest it sends you a link straight to the right screen.

Ask for it the way you would ask a colleague

DialogBrain puts your WhatsApp, Telegram, Instagram, email and website chat into one inbox, with an AI agent that answers customers. Until now, setting that up meant a sign-up wizard and a settings page.

If you already spend your day in an AI assistant, you can now do it from there. You do not need to know where anything is in DialogBrain, you describe what you want, and the assistant does the settings and tells you when it is done.

These are ordinary requests it understands, and you can paste them as they are:

Connect my WhatsApp and my work email.

Put a chat widget on example.com. Only allow my domain
and keep replies as drafts I approve.

Create an agent that answers customers on WhatsApp and
the website chat. Never promise prices, say a colleague
will confirm. Test it before it answers anyone.

Where did we lose leads this week?

Connect your assistant once

In Claude open Settings → Connectors; in ChatGPT open Plugins → Add → Add custom MCP server, which the free plan has too. Add DialogBrain with the address below and sign in with your DialogBrain account. There is no key or password to paste into the chat, and the assistant can do only what your own account can do.

In Claude Code, install the DialogBrain plugin with two commands and type /mcp to sign in. The plugin comes with ready-made step-by-step instructions for the common jobs, connecting a channel, the website chat, an agent, the task board and a weekly lead report, so Claude Code knows what to do without being told each step.

The home page and the first screen after sign-up have a "Set it up from your AI tool" block that shows the exact line for your assistant, including Codex, Cursor and Gemini CLI.

https://api.dialogbrain.com/mcp/

claude plugin marketplace add saloprj/dialogbrain-claude-plugin
claude plugin install dialogbrain@dialogbrain

WhatsApp and Telegram: a link to the exact screen

Connecting WhatsApp means scanning a QR code with the phone that owns the number, the same way you link WhatsApp Web. No assistant should do that for you, so it does not try. It sends you a link that opens DialogBrain directly on the WhatsApp step; if you are not signed in, you sign in first and land in the same place. You scan the code, and the chats start arriving.

Telegram, Instagram, Facebook Messenger and a Google mailbox work the same way: a link, then a scan or a sign-in with that service. Your WhatsApp session and your Google password never pass through a chat window, if an assistant ever asks you for them, do not give them.

Email and a Telegram bot: done from the chat

A mailbox at any provider other than Google is connected right in the conversation. The assistant asks for the address, an app password and your provider's mail server names, connects the mailbox and tells you when email is arriving. Use an app password rather than your normal one, you create it in your email settings and can revoke it at any time.

If your email is Gmail or Google Workspace, say so, and you get the Google sign-in link instead.

A Telegram bot is connected the same way: create the bot with @botfather, give the assistant the token it shows you, and the bot is live in your inbox.

A chat on your website and an agent that answers

Ask for the website chat and the assistant creates it, restricts it to your domain and gives you two lines of code to paste before the closing tag, or into the footer box of WordPress, Shopify or Wix.

Ask for an agent and tell it what matters: what you sell, the questions people ask most, what it must never promise, and when a person should take over. The assistant writes the agent's instructions from that; ask it to test the agent and it tries a sample question and shows you the answer before the agent talks to anyone. Replies wait as drafts until you are happy to let it answer on its own.

When something is blocked, it tells you why

A colleague with view-only access who asks their assistant to connect a channel is told they do not have permission, and nothing changes. If your workspace needs a payment method before another channel can be added, the assistant or the connect screen tells you, with a link to the billing page. These are the same rules as in the app, the assistant never gets around them.

Questions and answers

Can ChatGPT connect to WhatsApp?

Yes, through DialogBrain. Add DialogBrain as a connector in ChatGPT and ask it to connect your WhatsApp. It sends you a link to the WhatsApp step; you scan the QR code with your phone once, and from then on ChatGPT can read your WhatsApp conversations through your DialogBrain inbox and, on ChatGPT plans that let connectors take actions, reply to them.

Can Claude answer my customers on WhatsApp and Telegram?

Claude can set up an AI agent in DialogBrain that answers customers on WhatsApp, Telegram, Instagram, email and your website chat. You decide whether replies go out on their own or wait as drafts for your approval.

Is it safe to give my email password to ChatGPT or Claude?

Give an app password, never your main password. Email providers create app passwords for exactly this, and you can revoke one at any time. For Gmail and Google Workspace, use the Google sign-in link instead.

Do I need Claude Code or any technical skills?

No. ChatGPT and Claude on the web work fine: you add one address in their connector settings and ask in plain words. Claude Code gets a plugin with ready-made instructions, which helps if you already use it.

Which channels can I connect this way?

WhatsApp, Telegram, Instagram, Facebook Messenger, email, a Telegram bot and a chat on your website all arrive in the same DialogBrain inbox. YouTube and phone numbers for voice calls can be connected too, but they need your own Google Cloud or Twilio/Telnyx account, and the link opens a short setup wizard.

Originally published at dialogbrain.com.

Telegram voice via MTProto: what the Bot API cannot do

Dialog Brain — Tue, 20 Oct 2026 13:00:00 +0000

Bots cannot place, answer or join a Telegram call. This is the layer that can, the constraints it puts on you, and the three audio rules we learned from calls that went out sounding wrong.

The Bot API has no voice calls at all

This is usually discovered late, after the bot is built and someone asks it to ring a customer. The Bot API can send a voice message and a video note, recordings, files with a play button. It has no method to place a call, no method to answer one, and no way to join a group voice chat.

No token scope changes that. Calls are not a permission a bot can be granted; they live on a different protocol layer entirely.

# There is no such method. Not "restricted", not "beta": absent.
curl "https://api.telegram.org/bot$TOKEN/getMe"           # works
curl "https://api.telegram.org/bot$TOKEN/sendVoice"       # a voice *file*
curl "https://api.telegram.org/bot$TOKEN/startCall"       # 404: no such method

# The Bot API surface has sendVoice and sendVideoNote: recordings.
# Placing, answering or joining a live call is not part of it.

MTProto is a user account, not a bot

Telegram calls run over MTProto, the protocol the real clients speak. To take part, software has to sign in as a user account, the same way the desktop app does: phone number, login code, session. That has consequences worth deciding on before you build.

The caller sees a person, not a bot: your account name is what rings. The account is subject to the ordinary rules of a Telegram account, including the ones about automation. And an account is a single physical line, which brings the first constraint.

One call at a time, and no ringing callback

MTProto allows exactly one 1:1 call per account at a time. A second outbound call while the first is up is refused by Telegram itself, so a system that dials on demand needs either a pool of accounts or a queue, and it needs to know which account is busy before it tries.

The subtler constraint is that there is no pre-pickup event. Nothing tells you "it is ringing" and then "they answered". You learn the call connected because the playback call returns normally instead of raising, and every failure mode arrives as a different exception: declined, busy, rang out, cancelled mid-ring. If your product needs an "answered" timestamp, for billing, for a follow-up, for an answering-machine rule, that return is the only edge you get.

# MTProto gives no "ringing → answered" callback. You learn the callee
# picked up because the play call returns instead of raising.
try:
    await pytgcalls.play(chat_id, audio_stream)     # returns == answered
    await post("/internal/voice/call-answered", {"call_id": call_id})
except CallDeclined:                                # they pressed decline
    outcome = "declined"
except CallBusy:                                    # already on a call
    outcome = "busy"
except TimedOutAnswer:                              # rang out
    outcome = "no_answer"
except CallDiscarded:                               # cancelled mid-ring
    outcome = "cancelled"

Group voice chats are a different animal

A group voice chat is not a 1:1 call with more people. The agent joins as a named, visible participant, hears each speaker separately, and can speak into the room. That is what makes an assistant in a team call useful: it can attribute what was said to who said it, answer when addressed, and translate for one participant without translating for everyone.

It is also why an account already sitting in a group call will busy-decline personal calls: to Telegram it is on a line.

Bridging the audio is where it actually gets hard

Getting into the call is a week. Sounding right is the rest. Our agent lives in a media room; the call lives on Telegram; something has to carry frames between them. We wrote that bridge four times, Telegram, WhatsApp, Twilio, the browser, and fixed the same three defects in each, once per channel, before we made the rules shared.

Route by participant identity, never by "everything that is not me is the agent". A bridge that assumes the rest of the room is one speaker will happily interleave a human operator with the agent the moment somebody takes over a call. We shipped exactly that: the operator sounded rasping for four months.

Let exactly one browser publisher through, latest wins. Two tabs overlap for a second on every take-over; consuming both corrupts shared resampler state and produces audio nobody can debug from a log.

Mix several sources sample-wise with int16 saturation, never by concatenating into one queue. This is the one that passes every unit test.

# Rule 3, the one that sounds fine in tests and wrong on a call.
# Two sources are summed sample-wise with int16 saturation, never
# concatenated into one queue: a 10 ms interleave is audible as crackle
# even when one of the two sources is pure silence.

import audioop

def mix(tts_chunk: bytes, other: bytes, gain: float) -> bytes:
    if audioop.rms(other, 2) == 0:        # silence: return the chunk as is
        return tts_chunk
    if len(other) != len(tts_chunk):      # never mix mismatched lengths
        return tts_chunk
    return audioop.add(tts_chunk, audioop.mul(other, 2, gain), 2)

And the rates will get you

Telegram audio is 48 kHz; agent rooms commonly run at 16 kHz. Every boundary needs a resampler, and, the part that is easy to miss, the amount you push per tick has to equal the amount of time that tick represents.

We once fed a bridge 10 ms of audio every 20 ms. Nothing errored. Every log line was healthy, the room state was healthy, the transcript was fine. The voice trembled, and only a person listening could say so. Feed rate is not something you can assert in a unit test; put a real ear on the call before you ship one.

# pytgcalls speaks 48 kHz. The agent room runs at 16 kHz.
# Resample at the boundary, and push exactly one tick's worth per tick:
#   48000 samples/s * 0.020 s * 2 bytes = 1920 bytes per 20 ms
#
# Push 960 bytes on a 20 ms tick and the caller hears a trembling,
# warbling voice: you are feeding at half real time. We shipped that
# bug once and only an ear caught it: every log line looked healthy.

Or do none of this

All of the above is why we sell it. Connect a Telegram account once, then a call is one request: the agent dials, greets, holds the conversation, and the transcript lands in the same conversation as your text history with that contact.

The same endpoint reaches a group voice chat with an @name, a WhatsApp number, a phone number in E.164 or a Google Meet link, the target string decides the channel.

curl -X POST https://api.dialogbrain.com/v1/calls \
  -H "X-API-Key: $DIALOGBRAIN_KEY" \
  -H "Idempotency-Key: call-9f21c7" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": 118,
    "target": "telegram:123456789",
    "greeting": "Hi, this is the assistant calling about your order."
  }'

# 202 Accepted
# {"call_id":"7a6d…","status":"dialing","channel":"telegram",
#  "target":"telegram:123456789","thread_id":6808472}

Questions and answers

Can a Telegram bot make or answer voice calls?

No. The Bot API has no call methods at all, it can send voice messages and video notes, which are recordings. Live calls require an account speaking MTProto, the protocol the regular Telegram clients use.

What is MTProto and why is it needed for calls?

MTProto is Telegram’s own client protocol. Voice calls, group voice chats and their media negotiation live there, not in the HTTP Bot API, so participating means signing in as a user account rather than as a bot.

How many Telegram calls can one account handle at once?

One 1:1 call at a time. Telegram refuses a second concurrent call on the same account, so concurrency needs several accounts or a queue, and the dispatcher has to know which account is busy before dialling.

How do you detect that the callee picked up?

There is no pre-pickup callback. The playback call returning normally is the answer signal; declined, busy, rang out and cancelled each arrive as a distinct exception instead.

Can an AI agent join a Telegram group voice chat?

Yes. It joins as a named participant, hears speakers individually, can answer when addressed and can translate the conversation live. An account in a group call will busy-decline personal calls while it is there.

Do I have to build the MTProto side myself?

No. DialogBrain connects your Telegram account and exposes calls as one API request: POST /v1/calls with an agent id and a target such as telegram:123456789 for a person or @group for a group voice chat.

Originally published at dialogbrain.com.

How to get WhatsApp and Telegram messages in Claude Code

Dialog Brain — Sun, 18 Oct 2026 08:00:00 +0000

If you already spend the day in Claude Code, the conversations that matter can come to you there. A customer writes on WhatsApp, Telegram or email, and a second later the message is in your open session: Claude reads the chat, looks at who this person is, and shows you a reply to send, or tells you none is needed.

What happens when a message arrives

DialogBrain keeps your WhatsApp, Telegram, Instagram, email and website chat in one inbox. Normally an AI agent inside DialogBrain answers there. With this set up, you pick some conversations and hand them to your own Claude Code session instead.

When a message in one of those conversations comes in, DialogBrain pushes it into the session that is open on your computer. It is not a notification to go and look somewhere else. The message, the chat it belongs to and the instructions for what to do with it arrive in the session itself, and Claude starts on them straight away.

Claude can open the whole conversation, the contact and their history on other channels, because the DialogBrain tools are already in the session. When it answers, the reply goes back into the same WhatsApp or Telegram chat, from the same number the customer wrote to.

Nothing runs inside DialogBrain to make this happen: no model, no intermediate agent, no charge per message. The thinking is done by Claude Code, on the Claude plan you already pay for.

How we use it ourselves

One conversation that matters. A hotel owner from Thailand filled in our ad form, answered our first message and asked what it costs per month. We pinned that WhatsApp chat to our Claude Code session. Every time he writes, the message shows up in the session with a suggested answer. We change a word if needed and say "send". Our agents keep handling every other chat as before.

A reply we are waiting for. When a deal hinges on one person getting back to us, the chat with that person wakes the session. Claude reads the answer against everything said earlier and tells us what changed and what to do next, instead of us checking the phone every hour.

A new lead worth a closer look. Our intake agent answers every lead within seconds. For the ones that deserve more thought, an agent can put a task on the board addressed to our desktop session: research the company, suggest an approach. The task board keeps the status and the history.

What we do not do is send the whole inbox to the session. At a hundred conversations a day that is a hundred interruptions. Pick the chats, people or events that are rare enough to deserve your attention.

What you need

Claude Code signed in with a claude.ai account or an Anthropic Console key. Channels, the Claude Code feature this is built on, are in research preview. On Pro and Max accounts they work without anything to switch on. On Team and Enterprise plans an owner first has to enable them under claude.ai → Admin settings → Claude Code → Channels.

Node.js 20 or newer on your computer. Claude Code installed as a standalone app does not bring one with it, so check with node --version first.

A DialogBrain workspace with the channels you want connected. The 14-day trial is enough to set everything up.

Step 1. Install the plugin

Install the DialogBrain plugin in Claude Code and type /mcp to sign in. The plugin adds the DialogBrain tools, the step-by-step skills and the channel that carries the messages.

claude plugin marketplace add saloprj/dialogbrain-claude-plugin
claude plugin install dialogbrain@dialogbrain

Step 2. Give it a key and a name for this computer

Create an API key in DialogBrain under Settings → Developer, and put it in a small file together with a name for this computer. The name is how DialogBrain knows which session a conversation goes to, so use one you will recognise, such as office-laptop.

# ~/.claude/channels/dialogbrain/.env
DIALOGBRAIN_TOKEN=<the key from Settings → Developer>
DIALOGBRAIN_CHANNEL_NAME=office-laptop

Step 3. Start Claude Code with the channel on

Start Claude Code with the channel switched on. Claude Code only lets messages into a session that was started with a flag naming the channel. It reads the flag at start, so an open session has to be restarted, and every new session needs the flag again. A shell alias saves typing it.

The flag has "dangerously" in its name because during the research preview Claude Code only approves channels from Anthropic's own list, and the DialogBrain channel is not on it yet. The flag tells Claude Code you are choosing to load it anyway. If your company manages Claude Code for you, an admin can instead add the DialogBrain plugin to the approved channels in managed settings, and then the shorter claude --channels plugin:dialogbrain@dialogbrain is enough.

claude --dangerously-load-development-channels plugin:dialogbrain@dialogbrain

Step 4. Say which messages should reach you

Tell Claude which messages should reach you, in plain words. The plugin knows how to set it up: it creates a "Claude Code" agent in your workspace and a rule for the chat, person, keyword or channel you named, pointed at this computer. To check the connection, ask which Claude Code sessions are connected, and your computer's name should be in the answer.

You can also do it in the DialogBrain app: New AI Agent → the Claude Code card, then add a trigger with the chats you want. With one computer connected, that is all it needs. Choosing a specific computer when several are connected is done from Claude Code for now.

Wake me here when the hotel lead from Thailand writes
on WhatsApp. Show me the message and a suggested
reply, and don't send anything until I say so.

Which of my Claude Code sessions are connected?

Stop waking me for that chat.

Who presses send

Claude answers the customer by calling the DialogBrain send tool, and that message goes out straight away. It is not held as a draft in DialogBrain. Your control is Claude Code itself: unless you have told it to skip permission prompts, it asks you before every send. Keep that prompt on for customer conversations, or tell Claude in the rule to only suggest a reply.

If Claude decides no reply is needed, for example the message is just "ok, thanks", it simply does not send anything.

When a message does not arrive

The session has to be open. Messages are pushed only to a session that is running at that moment. Nothing is saved and replayed later, so what arrives while Claude Code is closed stays in the DialogBrain inbox and is not delivered to the session.

The session has to have been started with the flag. Without it Claude Code quietly drops what arrives, and the plugin's tools keep working as if nothing were wrong.

After you edit the settings file, restart Claude Code. The file is read once, when the session starts.

If the computer slept or the connection dropped, type /mcp and reconnect the DialogBrain channel. Then ask again which sessions are connected.

With two Claude Code windows open, give each a different name, and say in the rule which one should receive the chat. If you do not, DialogBrain delivers to neither rather than making both do the same work.

If you cannot switch channels on

You still have two options that need no channel. An agent can message you on Telegram or WhatsApp when the event you care about happens, and you open the conversation from there. Or it can put a task on the DialogBrain board, which you can pick up from any assistant, including ChatGPT or Claude on your phone.

More on channels: Claude Code channels documentation. The plugin, its skills and the channel code: dialogbrain-claude-plugin on GitHub.

Questions and answers

Can Claude Code receive WhatsApp messages?

Yes, through DialogBrain. Connect WhatsApp to DialogBrain, install the DialogBrain plugin in Claude Code and start it with the channel switched on. Messages from the chats you pick then arrive in your open session, and Claude can reply in the same WhatsApp chat.

Does it cost anything per message?

Not inside DialogBrain. No model runs there for these messages; the work happens in Claude Code, on your Claude plan. You pay DialogBrain for the channels as usual.

Does Claude Code have to be open?

Yes. Messages are pushed only to a session that is running. If you want it around the clock, keep a session running on a computer that stays on, or leave those chats to an agent inside DialogBrain, which works without your computer.

Will Claude answer my customers on its own?

Only if you let it. Claude Code asks you before each send unless you have turned permission prompts off. You can also tell it in the rule to only suggest replies.

Does it work with Telegram, Instagram and email too?

Yes. The rule is about conversations in your DialogBrain inbox, so it works for any channel connected there: WhatsApp, Telegram, Instagram, Facebook Messenger, email, LINE and the chat on your website.

Is the "dangerously" flag safe?

It lets a channel that is not on Anthropic's approved list send messages into your session. Here that channel is the DialogBrain plugin you installed yourself, and it only delivers messages from your own workspace. If your company manages Claude Code, ask an admin to approve the plugin instead, and you will not need the flag.

Originally published at dialogbrain.com.

How to publish an MCP server in the Claude connectors directory

Dialog Brain — Thu, 15 Oct 2026 07:58:41 +0000

On 30 September 2026 we submitted DialogBrain to Anthropic's connectors directory and it went live the same day. This is what the portal asks for, which rules quietly hold a submission, and why running every one of your own tools before you submit is the step that actually pays.

What a listing is, and what it is not

A connector listing puts your remote MCP server in the directory people browse inside Claude. They add it in one click, sign in with your OAuth, and your tools are in their conversation. It is not a plugin: a plugin is a bundle of skills and configuration that comes from a GitHub repository and is a separate submission. If you have both, you submit both.

The listing is published as a Community connector by default. An automated policy scan runs first; some submissions also get a human reviewer. Ours went from submitted to approved to published inside a day, but the portal says review can take weeks, so do not plan a launch around a date.

Everything below follows the portal at claude.ai/directory/manage, which any paid Claude plan can open.

Decide which tools you are submitting

This is the decision that matters, and it comes before the form. A reviewer reads every tool your listing exposes. Our full MCP catalogue carries raw SQL, a Python sandbox, an Android device farm and browser-session capture, all legitimate for the engineers who connect it themselves, and all wrong for a listing anyone can install. OpenAI had already rejected exactly that surface for the same reason.

So the server answers on two paths. The full catalogue stays where it was; a second path serves a curated set: read and answer conversations, search, contacts, tasks, notes, reminders, knowledge, agent drafts, call transcripts. The paths cannot be merged, because the resource value a client reads back from the protected-resource document has to be the URL it registered: one shared path breaks one of the two listings.

If your server was built for your own users, assume you will need this split. It is a dozen lines and it is the difference between a listing a reviewer can approve and a conversation about why you expose a SQL console.

# One tool set, one path per directory. The resource a client reads back
# must be the URL it registered, so the paths cannot be merged.
PROFILES = {"directory": DIRECTORY_TOOLS}

PROFILE_PATHS = {
    "/mcp/chatgpt": "directory",
    "/mcp/claude-directory": "directory",
}

Check the four things the portal reads automatically

Remote and reachable over HTTPS. A local server cannot be submitted on its own; it belongs in a plugin.

OAuth 2.0 with dynamic client registration, or no authentication at all for public data. The portal detects which you have. Ours advertises a registration endpoint in /.well-known/oauth-authorization-server, and the 401 your server returns without a token has to point at the protected-resource document for the exact path being submitted.

Every tool carries a title and the applicable readOnlyHint or destructiveHint. The portal flags the ones that do not, and a wrong label is a common rejection: anything that sends or deletes is destructive, anything that writes is not read-only.

Documentation URL, privacy policy URL, support contact and an icon. All four are public links a reviewer will open.

curl -i -X POST https://api.dialogbrain.com/mcp/claude-directory \
  -H 'Content-Type: application/json' -d '{}'

# HTTP/2 401
# www-authenticate: Bearer error="invalid_token",
#   resource_metadata="https://api.dialogbrain.com/
#   .well-known/oauth-protected-resource/mcp/claude-directory"

Run every tool before you submit: this is where the bugs are

The portal asks you to confirm you have run each tool, and it is tempting to tick that box because the tools obviously work. We ran them instead: added the server as a custom connector in Claude, signed in as the reviewer account, and asked Claude to call each tool in turn and report the result. It took twenty minutes and found three real defects, two of which had been shipped for weeks.

A read tool that answered "agent_id is required. Pass it as a parameter when calling from MCP." A person asking "what reminders are set?" has no agent id and cannot get one, so that tool could not answer for anyone connecting over MCP. It had been in our ChatGPT listing since September.

A tool whose error message pointed at another tool the listing did not expose: files.read refuses a binary file and tells you to use files.get_base64, which was outside the curated set. The advice led nowhere and a customer's photo could not be opened.

A tool that reported success for work it had not done: removing a tag that was never on the conversation answered success: true, indistinguishable from a real removal.

None of these would have been caught by a reviewer in the first five minutes, and all three would have been found by a user in the first week. Twenty minutes of your own time is a cheap way to not learn about them from a stranger.

Call each of these tools exactly once, in order, and do not ask me
anything in between: workspace_current, channels_list, search_threads,
contacts_find, messages_read_history, tasks_create, tasks_update,
notes_save, reminder_set, reminder_list, reminder_cancel, files_read.
Then print one line per tool: the name, OK or FAILED, and for a failure
the exact error text.

The ten steps, and what each one actually wants

Connection. Paste the URL and authorise. The portal reads your tool list live. If your server hides tools for channels a workspace has not connected, the count here is what that account can see, not your full set: say so in the notes rather than letting a reviewer wonder.

Tools. Your tools and their annotations, synced from the live connection. Anything flagged here is fixed on your server, not in the form.

Listing. Name, slug, a one-liner up to 200 characters, a description up to 2,000, categories, documentation, privacy, support, icon. The slug is permanent once published: ours is dialogbrain, and that is the one field you cannot take back.

Use cases. Three things people will do, each with an example prompt, plus what they need before connecting, and whether the connector reads, writes, or both.

Company, Authentication, Data handling. Company name and a contact a reviewer can reach; the authentication mode, which is detected; and whether the API is your own, whether personal health data is involved, whether any content is sponsored.

Test & launch. Access instructions detailed enough for a reviewer to connect and run the tools: the URL, real credentials for a populated account, and what to try. Say plainly which tools reach real people: ours deliver messages to actual customers, so the instructions ask reviewers to read and not send.

Compliance. Seven acknowledgements, including prompt injection and conversation-data collection. Read them. If your product stores other people's private messages, as an inbox does, say so in the notes instead of hoping the checkbox covers it.

Review and submit. A summary and the button.

Two traps worth knowing

Reconnecting the server resets fields you already filled. We reconnected on the Connection step to pick up two newly added tools, and the portal silently put the listing name and slug back to the auto-derived api.dialogbrain.com and api-dialogbrain-com. The slug is permanent after publishing. Check the Listing step again after any reconnect.

A draft lives in the browser tab. The form says "Draft saved in this tab". Leave that tab and the draft is not in your submissions list; come back to the same tab and it is still there, on the step you left. Do not close it.

After it is live

The listing appears in the directory within about an hour, with Community and New badges. Health, rank and usage start about a day after the first calls.

Edits after publishing go through review before they replace what is live, so the listing you publish is the one people see for a while. Edits before publishing send the submission back to draft for another review, which is why, if you are staring at an approved submission and a small copy change, publish first and edit after.

Questions and answers

Do I need a separate submission for a plugin?

Yes. A connector is one remote MCP server submitted by URL. A plugin is a bundle of skills, commands and MCP configuration read from a GitHub repository, submitted as "Plugin bundle". If your plugin references a server you run, submit the server as a connector too.

Can I submit while another submission is in review?

Yes. Unlike Meta's app review, the portal is open for new submissions at any time, and an organisation can create up to ten in 24 hours.

What happens if a tool fails while a reviewer is testing?

It becomes a question you answer by email, and the listing waits. That is the argument for running every tool yourself first: a failure you find is a commit, a failure a reviewer finds is a week.

Does the listing cost anything?

No. Any paid Claude plan can submit, and a Community listing is free. What it costs you is the work of making the tool surface defensible.

Can I change the name or slug later?

The name follows the listing and can be edited through review. The slug is permanent once the listing is published, so decide it before you press publish.

Originally published at dialogbrain.com.

The call transfer that reported success and rang nobody

Dialog Brain — Wed, 02 Sep 2026 04:21:46 +0000

Our voice agents can hand a live phone call to a human. Getting there took two rewrites, and the first one shipped without ever delivering a single call — while our own logs said it worked. This is what the feature does now, and what the failure taught us.

What the caller hears

Someone asks to speak to a person, or the agent decides the question is not its own: a complaint, a payment, something outside its instructions. The agent says one short line, and from there the caller hears real ringing — the second number is being dialled.

When the phone is answered, the agent goes quiet. Two people are on the line and nothing else is on it with them. If nobody answers, nothing happens: the caller stays with the agent, which knows the dial failed and can offer a callback or take a message.

The route a transfer takes

A transfer here is not "hand the line to the carrier". It is a second call, dialled into the same conversation.

Is the number on the agent's approved list? If not, refused — and the agent is still on the line.
Is this a phone call at all? A messenger chat or a web voice widget has no second line to connect.
Dial the second number into the same call. The caller hears ringing; the agent is still there.
Did they pick up within 45 seconds? If not, the dial is cancelled and the caller stays with the agent.
They picked up — the agent loses the right to speak, and the two of them talk.

Both gates sit before anything is dialled, so a refusal never costs the caller a single ring. The pickup fork is the only place where a call becomes a transferred one.

Why not SIP REFER

Telephony has a cheaper way: a REFER, after which the carrier connects the two parties itself and you leave the call — the minutes stop flowing through you.

We built that first. It never delivered a call. Telnyx answered every REFER with 200 OK and did nothing: no progress NOTIFY, no ring at the destination. Meanwhile our own bookkeeping recorded outcome = transferred, so the dashboards were green while the caller was simply dropped.

The documentation explains it. REFER-based external transfer on a SIP trunk requires an active inbound call to your own number to match against, plus a Diversion header carrying that number. We were sending REFER on calls we originated — the one shape it cannot work on. And LiveKit's TransferSIPParticipant has no field for a custom header, so the requirement is unreachable from there anyway.

Two other explanations were tested and disproved rather than assumed: enabling third-party call control on the connection changed nothing, and neither did a sip: URI instead of tel:.

Three things measurement changed

Presence in the room is not a pickup signal. The dialled participant appears in the media room the moment dialling starts — measured at 310 ms, with no call at the destination. Only wait_until_answered tells you a human lifted the handset.

Removing the agent takes the call with it. Measured in isolation on a live call: RemoveParticipant, and within five seconds the room was empty, carrier leg included. The room does not outlive its agent job. So the agent is silenced, not removed.

Silencing alone is not enough. Revoking publish stops the agent being heard. Its job keeps running: nine seconds after one handover it composed and "spoke" a line that went into the call history, while it carried on transcribing two people who had just been handed to each other. It now gets an explicit stand-down.

The honest cost

Bridging means the conversation runs over our media path, and minutes are billed on both legs — exactly what a REFER avoids. In exchange it works identically on inbound and outbound calls, on any carrier, with nothing to configure on the telephony side.

If your logs can say "transferred" without anyone's phone ringing, that is the bug worth looking for first.

Originally published at dialogbrain.com, where the same piece has a flow diagram.