We build agents all day, and the thing I keep noticing is that they almost never fail in the middle. They fail at the very last step, when something has to happen in the real world.
Ours kept dying in the same spot: a signup form that texts a six-digit code. Everything up to that point ran fine, and then it just sat there waiting for a human to go and read a text message.
I'm curious what everyone else's version of this is. Not the thing your agent does badly - the thing it does perfectly, right up until it has to stop and hand it back to you.
Verification codes? A booking that only happens by phone? A supplier who answers email once a week? Something that needs an actual human voice on the other end?
Mostly I want to know whether the wall sits in the same place for everyone, or whether it moves depending on what you're building.
Been using this since the early builds.
I don't sit and wait for Claude to finish anymore- it just texts me when it's done, or calls if it needs a decision from me🔥🧑🏻💻
Dial
@yarin_dayan great usecase!
Dial
I'm Omri, Co-Founder & CTO of Dial. 👋
A quick look under the hood, because "give your agent a phone number" turned out to be far less of a thin wrapper than we assumed. Three things were genuinely hard:
1. Making the agent the user, not you. No dashboard step, no API key to copy. The agent fetches a skill doc, signs itself up, provisions its own number and starts using it. Everything a human would click, it does over the same API.
2. One shape for every channel. A voice call, an SMS, an iMessage and a WhatsApp message are four completely different beasts underneath. They all come back to a single webhook in one format, so your agent handles one thing instead of four.
3. Letting an agent wait. dial wait-for message.received blocks until the text lands and hands the code back. That is what turns a phone-gated signup from a dead end into just another step.
Setup is two lines pasted into any agent:
Get yourself a Dial phone number and call me. Follow https://getdial.ai/skills.md
$5 in credit on signup, no card.
I'm around all day. Especially curious what people want the webhook payload to carry that it does not yet.
Seen that product being built from the ground up!
Instead of stitching together a bunch of legacy solution - twilio,vapi and the alikes - you can spin up a number within minutes. The 10DLC feature is the killer capability imop
Dial
@nvoitenkov thank you so much for your continuous support!
Love this product so much, from the moment I started reading the docs!
The simplicity, the reliability, the call quality and the customization capabilities are very impressive!
Dial
@miki_manor thank you for trusting us! I hope your agent loves us at least as much as you!
Monid
This is a really clean use case for agents. Giving them a real number in seconds feels like a missing piece. Congrats on the launch!
Dial
@jasper0122 thank you! really appreciate your support! we're both making agents with the right toolkit!
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.