Iris

Iris, the approval layer for voice agents

One-line summary: Call a business after hours and you get voicemail. Iris answers instead, runs the whole conversation, and stops short of committing. Every action that costs money or changes an existing booking waits for a person, and once they approve it, Iris calls the customer back to confirm.

--

Problem Statement

Call a small business at eight in the evening and you reach voicemail. Most people do not leave one. They call the next business on the list, and the first business never learns it lost the customer.

The obvious fix is an AI voice agent, and voice quality crossed the threshold some time ago. The adoption problem is not the voice. It is trust. No owner will let an agent book appointments or quote prices unsupervised, because one wrong price or one double-booked slot is their reputation. So the agent gets restricted to answering questions, which makes it voicemail with better diction.

ElevenLabs ships a transfer-to-human tool, but transfer assumes someone is available to take the call. After-hours is defined by nobody being there. The missing piece is not a smarter agent. It is a way for an agent to finish a call and still not act alone.

--

Solution

Iris answers when the office is closed. She knows the hours, the services and the published prices, and she can check open slots, take a message and record who called.

What she cannot do is commit. Her tools are split into two classes, and the split is the product.

Commits immediately: answering from the knowledge base, checking availability, capturing a lead, taking a message. All read-only or harmless.

Proposes only: booking an appointment, changing an existing one, or escalating anything outside policy. These write a pending action and nothing else. Iris tells the caller the truth, that someone will confirm shortly, and she is structurally prevented from claiming it is done. The API returns the exact sentence she is permitted to say, so the honesty rule is enforced server-side rather than requested in a prompt.

In the morning the owner opens a console, sees every decision waiting with the transcript behind it, and approves or rejects. Approving commits the action and places an outbound call so the customer hears the confirmation in the same voice that took their call.

The interesting work was in the restraint. Deciding what an agent may never do unsupervised is harder, and more valuable, than making it capable of more.

--

Tech Stack

--

Key Features

• Two classes of tool. Read-only actions commit immediately. Anything that costs money or changes a commitment writes a pending action and waits. The boundary is enforced in the API, not just described in the prompt.
• Server-enforced honesty. When a propose-only tool fires, the response carries the sentence the agent is allowed to say. She cannot report something as booked when no booking exists.
• Failure is not reported as success. If a tool call errors, the agent treats it as nothing recorded, says so plainly, and gives the caller a real next step rather than a callback that will never come.
• Live call console. Calls appear the moment they connect, marked live in green, with the transcript filling in as the conversation happens. Pending actions land in real time.
• Approve, then confirm. Approving commits the action and triggers an outbound call so the customer hears the confirmation directly.
• Grounded knowledge base. The agent answers only from what the business actually told her. Unlisted prices and uncovered topics are escalated, never estimated.
• Post-call triage. Every substantive call gets a one-line summary and an urgency rating, so the owner does not read transcripts to learn what happened.
• Ask about any call. A question box scoped to a single call record. Asked something the record does not contain, it says so rather than inventing an answer, the same rule the agent follows on the phone.
• Enterprise SSO. The console shows customer phone numbers and transcripts, so it sits behind real OIDC single sign-on rather than a password.

--

What this shows

Every failure that mattered during this build was silent.

The retrieval config pointed at an embedding model whose index did not exist, so retrieval returned nothing and the model filled the gap: it invented a price, invented an address, and agreed to a service the practice does not offer. It sounded completely normal while doing it. A tool returned a 500 and the agent still told the caller their request had been written down. A conversation id was left for the model to fill, so it invented one and the console showed a single call as two. A callback URL contained a hyphen that rendered identically to a standard one and failed every string comparison for an afternoon.

None of these announced themselves. Each looked correct until something compared it against the truth.

That is the same problem the product solves. An agent that sounds confident is easy. An agent that knows the edge of what it is allowed to claim, and stops there, is the part worth building. The engineering judgment was in deciding where that line sits and then enforcing it structurally, so the agent cannot cross it even when a model would like to be helpful.