Zendesk for StartupsUp to 2 years free for startups + AI Agents & Copilot
Promoted
Launched this week
Your agent can deploy in seconds but cannot get a phone number. Dial fixes that - one API call and it gets a real one in about 10 seconds. It places and receives voice calls, sends and receives SMS in 200+ countries, and messages over iMessage. It can even read inbound verification codes, so phone-gated signups stop being a dead end. Works via REST API, CLI, MCP servers, and SDKs. Free credit on signup, no card.
Hello team,
We're evaluating Dial for adding phone-based reachability (voice, and potentially SMS/iMessage/WhatsApp) to an existing AI agent product. Our voice agent is orchestrated with LangGraph specifically, not just LangChain, with real-time audio currently running through a separate pipeline.
A few specific questions:
1. Does Dial's SDK/MCP server support a LangGraph-based voice agent out of the box, or does that require custom bridging on top of your LangChain integration?
2. For real-time voice: how does Dial attach to an existing agent's audio pipeline - does it expect us to move audio transport onto Dial entirely, or can it sit alongside/bridge into a voice pipeline we already run, rather than replacing it?
3. Do you have a reference implementation or example specifically for a LangGraph agent wired to Dial (as opposed to generic LangChain examples)?
Happy to hop on a call if that's easier to walk through.
Thanks,
Raj H.
This might be the way I guess - https://docs.getdial.ai/documentation/platform/self-hosted
Following up on our earlier question about LangGraph support — we dug into the self-hosted docs (LLM mode / audio mode, the wss:// contract, HMAC auth, G.711/PCM frames) and have a follow-up specific to our setup.
Our real-time voice agent already runs on LiveKit — audio flows over WebRTC into/out of a LiveKit room, not as raw PCM frames on a plain WebSocket. A few questions:
1. Does Dial's self-hosted audio mode have any existing pattern (or reference integration) for bridging into an existing WebRTC/LiveKit room, rather than us building a custom adapter that terminates your raw-audio WebSocket and re-publishes it as a LiveKit participant?
2. Alternatively - can a Dial phone number be pointed at a SIP trunk instead of (or in addition to) the WebSocket audio-mode contract? LiveKit has its own SIP integration for bridging PSTN calls directly into a room, and if Dial can hand off via SIP, that'd likely be a much smaller integration for us than building a raw-audio bridge.
3. Do you have any existing customers running LiveKit (or another WebRTC-based agent framework) in self-hosted mode we could learn from, even at a high level?
Appreciate the help - trying to figure out the smallest integration surface before committing to a design.
Thanks,
Raj H.
Dial
@xriminact
1. work out of the box
2. You can use self-hosted text-to-text or audio-to-audio. you can also use managed, and you have nothing to worry about :)
sure! https://docs.getdial.ai/documentation/sdks/langchain
Giving an agent its own phone number feels weirdly obvious after seeing this 😅
Really smart infrastructure layer. Curious how you’re handling number reputation and spam detection as usage scales?
Dial
@bencohen that’s totally an issue! We have in place automatic risk models that manages each number reputation. Maintaining high reply rate, high calve satisfaction, etc
@galdayan The first thing I'd wire up isn't a signup, it's the agent telling me it's stuck. My biggest time sink this year is a long Codex run that quietly blocks on a question and sits there for half an hour while I assume it's working. A text when it needs a decision would recover more of my week than anything it's ever got wrong. The thing I'd want to know before building on it is what happens when a number goes bad, whether I get told or whether my agent just silently stops receiving codes and looks broken.
Dial
@asadmalik901 good question, and it's the one that keeps me up at night honestly. right now if a number goes bad (carrier flags it, gets ported, whatever) you get an explicit webhook event and a dashboard status change, not silence - we designed it that way specifically because "silently stops working" is the failure mode you're describing with the Codex run, and we didn't want to reproduce it. what we don't have yet is a built-in retry/escalation policy (like "if no delivery confirmation in N minutes, page a human") - that's on us to add, we've just been leaning on customers wiring their own alerting off the webhook for now.
@galdayan The webhook isn't the gap, the gap is nobody's watching it at 2am. What saved us with a different vendor was a dead man's switch on their side, no successful delivery in N minutes and they page us, so the timer lives in their code instead of mine. If every customer wires their own alerting, every customer gets that timer slightly wrong.
Congrats on the launch team! Love how Dial removes one of those small but very real blockers for AI agents especially around verification codes and phone-gated workflows. Quick question here - what has been the most common use case you have seen agents using Dial for so far?
Dial
@yogesh_builds thanks! honestly the OTP/verification code case is still the biggest one, way more than I expected going in. second most common is agents doing outbound calls for scheduling, restaurants, appointments, that sort of thing, where they need a callback number that actually rings back to them
Dial
@yogesh_builds customer support, cold outbound, customer churn minimization, otp extraction and much more!
Ofek here, one of the builders
the moment that still get me:
1. you tell your agent to get a phone number,
2. register with a OTP in chat
3. walk away
4. boom a minute later your own phone rings. No dashboard, no signup form, no one clicking anything,
Dial
@ofek_ben_yaish1 agents rule the world!