Launched this week
Thinnest AI
Build Voice AI Agents in 100+ languages for ₹1.5/min
96 followers
Build Voice AI Agents in 100+ languages for ₹1.5/min
96 followers
ThinnestAI is programmable voice AI infrastructure for building human-like AI phone agents at scale. → 100+ languages with seamless multilingual conversations. → Bring your own LLM, STT, TTS, and telephony providers. → Native SIP, Twilio, and workflow integrations. → No-code flow builder with RAG knowledge bases and MCP support. → Real-time voice agents for support, sales, onboarding, and operations. Start building AI voice agents in minutes — no credit card required.
Interactive
Free Options
Launch Team / Built With
@ashutosh_thinnest
Hey Ashutosh, congrats on launching 👋
The BYOK + MCP combo is the right call - most voice infra locks you into one provider. Curious: does the MCP server expose flows to external clients, or is the agent acting as MCP client consuming external tools? That's the line between "voice product" and "voice infra" for me.
@artem_fedorovich
Both directions — and I think that's the right design for a voice platform.
MCP client (per-agent, in-call): each voice agent can be wired to an external MCP server it consumes during the call. A collections agent on a live call can hit get_loyalty_balance or create_ticket against the customer's own MCP server mid-utterance. Configured per agent: URL, auth, allow-listed tool names, timeout. In production today.
MCP server (platform-wide, out-of-call): ThinnestAI is also exposed as an MCP server. Claude Desktop / Codex / Cursor plug in with a thns_sk_* bearer and drive the workspace itself — manage agents, pull call transcripts, upload knowledge, check billing. Streamable HTTP, JSON-RPC 2.0, no separate credential type.
The split feels right: the platform exposes itself as MCP for orchestration, the agents speak MCP outbound for in-call business logic. Different threat model, different auth surface, same protocol.
What's your use case — orchestration or in-call tooling?
@ashutosh_thinnest Love the split - and yeah, "platform exposes itself as MCP for orchestration, agents speak MCP outbound for in-call business logic" is a really clean way to put it. Different threat model is the key insight most people miss.
For me it's in-call tooling, hard. Voice or chat, the moment an agent is making mid-conversation tool calls against a customer's CRM / ticketing / billing - that's where things get spicy. The allow-listed tool names per agent is the right primitive, but I'd push one level deeper: how does ThinnestAI handle the case where the tool exists and is allow-listed, but the specific argument the agent wants to pass is out of policy? Like - create_ticket is allowed, but create_ticket(priority="P0", customer_tier="enterprise") should require a human-in-the-loop step.
That's the layer I keep building manually on top of MCP and wishing the infra handled it natively. Curious if it's on your roadmap or out of scope by design.
The argument-level gap is the right frame. Tool-level allowlist is what ships today; argument-level policy with HITL is the next layer down — and I won't pretend we've solved it as a first-class primitive yet.
What's in production: an HITL service with a CONFIRM_TOOLS mode that pauses execution on every tool call, surfaces the proposed call + the agent's context to an Approvals panel, and resumes on approve / branches on deny. Voice-session-aware — the call literally waits. JWT-signed inline approvals so a supervisor can act from a widget. Tool-call audit through agent_tracing with spans + cost attribution. What's not in production: a way to say "gate this tool call only when args match a predicate." Right now CONFIRM_TOOLS is binary per tool — gate every call or none.
The shape I think it wants:
Per-agent, per-tool argument schema declared alongside the allow-list
Predicate DSL — priority == "P0" OR customer_tier == "enterprise" => require_approval — versioned per agent
HITL trigger that pauses the call, surfaces the transcript window + the proposed tool call to a supervisor queue, resumes on approve / branches the agent on deny
Replay audit — every gated call captured with the policy that fired, the approver, the decision, the latency cost
Order is honest: tool-level gate + supervisor approval is in production; declarative arg-policy DSL is roadmap, not shipped. Out of scope by design? No — wrong direction. Not shipped yet? Yes.
What predicates are you writing manually today? Curious whether "out of policy" tends to be value-comparisons (priority, tier), pattern-matches (PII / regex in args), or stateful (called this customer in the last 24h). The predicate shape dictates the runtime — would shape what we ship first.
Hey Ashutosh, went through Thinnest's site and the broken-Hindi-voice-agent story honestly hit home. one thing I wanted to ask, with BYO STT/TTS across 100+ languages, are there benchmarks on which Hindi-English code-mix setups hold up in production? Indian users switch mid-sentence and that's usually where these break.
@axlerodd
Good question — and you're testing the right thing. Mid-sentence switching is exactly where code-mix lives or dies, and it's a far better stress test than monolingual accuracy numbers.
The way we've set this up: for Hindi-English agents we run Sarvam Saaras v3, and that's a deliberate choice, not a default. Saaras v3 is trained code-mix-first - a million hours of Hinglish in the training set and built to hold word boundaries across the switch instead of forcing an utterance into a single language. That's the part that matters for the failure mode you named. A language-locked Deepgram or Whisper config, however carefully tuned, tends to break right at the switch points, because the model is being asked to work outside the distribution it was trained on.
On published code-mix benchmarks specifically — that's a genuinely under-measured corner of the space, happy to go deeper if useful.
Will be watching this. We use a voice agent and will need to have it in other languages. Congrats on your launch!
@midori_verity Thanks Midori, really appreciate it!