Assistants by OsmO are AI phone agents that screen calls, transfer urgent ones, collect requests, and share call summaries. They also make outbound calls, navigate phone menus, and handle recurring calls. Available on iPhone and Android with a 7-day free trial.
Launch Team
Tines The single, secure environment for agents, apps, and automations.
Promoted
@getosmo Can OsmO handle multiple calls at the same time ?
@dipanshu_kushwaha5 yes it does
Searchable transcripts are much more useful than vague voicemails, especially when a caller shares several details.
@punit_kumar Thanks, Punit — agreed that the details matter more than a vague voicemail. OsmO shares the call transcript so you can review the names, numbers, requests, and next steps the caller actually gave before deciding how to follow up.
The outbound half is the part I keep rereading: screening spam is table stakes now, but navigating phone menus and sitting on hold is where the actual hours go. I build voice AI that calls aging parents every day, and the thing that bit us hardest early on was turn taking. Older folks pause mid sentence, and a naive endpointing threshold makes the agent talk right over them. How are you handling barge in and silence thresholds on outbound calls when the other end is a human receptionist rather than an IVR tree? Also curious what "runs on your existing number, no new SIM" looks like under the hood, conditional call forwarding?
@igorgurovich Great question — and I agree: a fixed silence cutoff is not enough for human conversations, especially with longer mid-sentence pauses. I don’t want to overstate the current implementation publicly: turn-taking, interruption recovery, and pause handling are areas we test and tune across human and IVR calls, rather than claiming one threshold solves them. On the number setup, yes: incoming handling uses call forwarding, with availability depending on carrier, country, device, and configuration. Outbound calls are placed by OsmO for bounded tasks such as availability checks, follow-ups, and hold queues; you keep your existing number and don’t need a second SIM. Would genuinely enjoy comparing failure cases with you.
we build voice AI for calls too, so the question I'd ask is less about the tech and more about the legal side: two-party consent states in the US require both sides to agree to a call being recorded/transcribed, and that gets messy fast when OsmO is taking a message from someone who has no idea they're talking to an AI that's logging a transcript. do you play a disclosure at the start of an inbound call, and does that change by region, or is it on the user to configure that themselves
@galdayan You're right to flag this, Gal. Consent and disclosure requirements vary by jurisdiction and use case, and I don't want to overstate OsmO's current region-specific behavior here. The safe standard is that callers should be clearly informed before recording or transcription wherever required; putting the burden entirely on the user would not be a sufficient product answer. I'm confirming the exact current disclosure/configuration behavior with the team so I can give you a precise answer rather than guess. Which jurisdictions or call flows have created the hardest edge cases in your work?
@getosmo the hardest edge case for us is outbound calls to states like California or Florida where both parties need to consent, but the callee has no idea it's an AI until the call connects. a spoken disclosure at the top of the call solves the legal side but tanks completion rates because people hang up the second they hear "this call may be recorded by an AI." we ended up doing a short neutral opener instead of a hard legal disclaimer, and it's still a compliance question we revisit every few months. curious if you've seen a version of the disclosure that doesn't kill the call.
@galdayan That’s a very useful failure mode, Gal—thank you. I don’t have a verified OsmO result showing a disclosure variant that preserves completion rates, so I don’t want to invent one or imply that a neutral opener necessarily satisfies the applicable consent rule. We’re treating this as both a compliance and product-design constraint: disclosure must be clear where required, while wording and timing should be tested with counsel rather than optimized past informed consent. Your example gives us a concrete scenario to validate; I’ll return with OsmO’s exact current behavior once confirmed.
@getosmo that's honestly the answer I'd trust more, "not optimizing past informed consent" over a slicker demo number. good luck getting the counsel read on it, that's the unglamorous work that actually matters for a product like this.
The forwarding setup lets me keep using my phone normally while OsmO catches the calls I miss.
@new_user___2672026a1aa371e239a94fb Thanks, Ankit — that’s exactly the balance we wanted: you keep using your existing phone normally, while call forwarding gives OsmO a chance to catch and summarize the calls you miss. Really appreciate you calling that out.
I have been using Osmo from starting , works best my screening . Saves a lot of time!!
@abhishek_chauhan46 Thank you for sticking with OsmO from the start — it means a lot, and I’m glad the screening flow is saving you time. Which part has been most useful in practice: filtering unknown callers, seeing the transcript before deciding to respond, or transferring the calls that actually need you?