What the agent can do mid-call

During a live call, the AI agent can send nine types of request to the platform. Examples: book a callback, ask the team to call back as soon as possible, record a do-not-call request, or move the caller to a human specialist. The platform answers each request while the caller waits. The platform writes each request into the permanent record before any other action.

One entry point, nine requests

All nine request types arrive at one entry point on the platform. A callback, an alert, and an opt-out all arrive at that one point. Each request carries a signature that only the voice service and the platform can produce, covering the full request and the time it was sent. The platform refuses a request with no signature, a wrong signature, or a time more than five minutes old, and it checks the signature in a constant time. Thus the response time gives no data to a person who tries to guess the key. The platform also confirms the request belongs to a call it really placed, with the same voice agent, before it acts.

Strict time limits apply to each request:

The hard limit is ten seconds. That is the maximum time the voice service holds the conversation open while it waits for an answer.
The practical limit is less than one second. After approximately two seconds of silence, people hang up.
Quick hangups are a pattern that spam-detection systems monitor.

One entry point, not nine, also makes maintenance simple. A tenth request type does not need a new address. One address also removes nine separate occasions for a wrong address.

A live call on the left, with the caller and the AI agent. Nine plain-language requests, drawn as buttons, flow through one guarded entry point into the platform. One rule governs them: the platform writes the request into the permanent record first, then acts on it. The platform records a repeated request once. — Nine requests, one entry point. One rule is central: the platform **writes the request into the permanent record first**, and acts on it only after that. The platform records a repeated request once.

The nine requests

1. Book a callback

The agent records the exact date and time in the timezone that the agent and the merchant agreed aloud, or notes that the merchant wants a person to call with no time set. The platform sorts the promise into one of two kinds, by how far away the agreed time is:

A callback, agreed within about the next four weeks, or no usable time at all. This promise belongs to the client's own team, not to the platform: the platform does not dial it. The lead's own calling programme ends there, and the promise appears on the client's results screen for a person to keep.
A pipeline wake-up, agreed further out than four weeks, or a vague later season with no firm date (which the platform treats as about three months out), capped at a year ahead. For this one only, the platform keeps the promise itself: the lead's own calling programme sleeps until the wake date, then starts over from the beginning, re-checking the number is still safe to call before the first new dial.

Two details are intentional:

The platform never converts the agreed time to a different timezone. A converted "2 pm Eastern" can cause the client's own team to call at the wrong hour.
The platform must be able to use the exact instant, not just read it. A time the platform cannot read — no timezone, already in the past, or nothing said at all — is saved as a callback with no time, the same as request 3 below, so a person still calls the merchant back by hand.

The client's team always gets an email that states which of the two is true: that a person on their own team must make the call, or that the platform will call again later. A merchant is never left uncalled because each side believed the other one had it.

If the merchant names a different number to be called back on, the agent reads that number back to confirm it, and the platform keeps it on the promise. The client's own results screen shows that number next to the time, so the rep calls the right phone, not the number the call happened to reach. A number the merchant did not actually change is never shown twice.

The platform reads the merchant's own spoken time itself, against a fixed, known set of day, date, and clock words. It no longer asks a general-purpose AI model to guess the meaning freely. The earlier, model-guessed approach quietly failed to record a promised time on about one call in four that asked for one. A phrase outside the known set gets a clarifying question, never a silent guess.

2. Tell the team that the booking is made

This request confirms request one. Together, the two requests cause exactly one email, worded for whichever kind was booked. The request that arrives first sends the email, and the other request sends nothing. Two emails are not possible. The email goes to the client's own reply address if one is set, and otherwise to the client's longest-standing administrator — never to every administrator at once.

3. Callback ASAP — get a human

The merchant is interested, but the agent could not capture a specific time to call back — the merchant wants a person now, and named no workable time. The agent then books a Callback ASAP for the client's rep. This is the same promise as request 1's no-time case: it appears on the client's results screen as a callback marked ASAP, for a person to make, and the lead's own calling programme ends there. The client's team gets an email at once, at the same address request 2 uses.

4. Stop calling me

The platform suppresses the number in the compliance record at that same moment, before it sends any email. After that, the safety gate blocks every future dial to that number. An opt-out that exists only in an inbox takes effect only when a person reads the mail. Thus the record always comes first. Because a stop-calling request can never be safely lost, a request the platform fails to save halts every dial on the whole platform, for every client, until a person checks it.

One exception exists. If the platform cannot identify the client that owns the call, automatic suppression is not possible. The alert email then states, in capital letters, that a person must suppress the number manually.

A stop request also closes any callback or pipeline promise still open on that lead. The platform does not keep a promise to call someone back after that same person has just asked to be left alone.

Every stop, from any one of its sources, also queues a notice to the client's own team, and the platform marks that notice sent only once the email actually went out. A client is told within a minute that one of its own leads opted out, so its own team never calls that same person again by hand, outside the platform.

5. End this programme

The merchant asked to end this specific programme only. The merchant did not ask for an end to all contact. The platform records the request and tells the team. The platform intentionally does not suppress the number automatically. Automatic suppression blocks a number for all purposes, and that is more than the merchant asked for. A person must make that narrower decision.

A merchant who closes the file and, in the same breath, adds words like “stop contacting me” is not read as a full stop request on those words alone. Ending this programme already stops the platform calling this lead; a separate, explicit opt-out phrase — such as “take me off your list” — still suppresses the number everywhere, exactly as request 4 does.

6. Email me the application link

This is one of two requests whose success signal means that the message actually went out, not only that the platform recorded the ask. If the spoken address does not have a valid format, the platform refuses the request. The refusal makes the agent ask again, politely.

Each client sets its own application-page address in its settings. The tool sends that address. If a client has not set one, the agent does not offer to send a link at all.

Business email law requires a true postal address for the sender in the message. The platform refuses to send until a LeadRefinery staff member has recorded the client's own postal address. Every one of these emails also carries a one-click unsubscribe link. One click stops every further application-link email to that address. The same address can tie to more than one lead, so one click also suppresses every one of the client's leads that carries it, across every channel, the same way a stop-calling request does. It tells the client's own team, too, the same way a stop-calling request does.

7. Text me the application link

The same link, sent as a text message to the number on the call. The text goes out from the environment's one fixed sending number, never from the number that placed the call. The same success rule applies: the signal means the text actually went out. The platform refuses to text a number that already has a stop-calling request waiting on it, whether or not that request is finished processing yet.

A link that actually sends, by either tool, counts as a successful outcome for the lead's journey. The platform stops calling that lead, the same way it stops after a live transfer or a booking. A merchant who already has the link is not called again to offer it a second time.

8. Check whether a specialist is free

Before the agent ever offers to put the merchant through, it asks the platform whether the client's specialist line can take a transfer right now. The agent only offers a transfer after this check says yes.

9. Put me through to a specialist

The agent sends a short briefing — what the merchant needs, the amount, the timing, in the merchant's own words, with no rate and no promise repeated — and the platform rings the client's own specialist line. A person at the other end hears the briefing and accepts, asks to hear it again, or declines. On accept, the platform joins the merchant straight to that person and the AI agent leaves the line. On no answer or a decline, the platform tells the agent, and the agent offers a callback instead.

The ring to the specialist line has a time limit, but no automatic machine-detection check. A real person reading a long briefing out loud was, in practice, sometimes mistaken for an answering machine, so a pressed key — not machine detection — is what proves a person answered. An earlier, shorter time limit on the connection to the voice service could also end an attempt before the desk had a chance to answer, even though the desk could still accept; the platform now keeps that connection open long enough for the full wait to finish. How the platform uses Telnyx gives the steps from the carrier's side.

The specialist line's own decision always wins, even where it disagrees with the agent's own notes of the call. The agent cannot always tell that a transfer connected, because it leaves the line the moment it hands the merchant over. The platform instead keeps the specialist line's own accept or decline as the one record of what happened, so a merchant the specialist line already took is never dialled again by mistake.

Designed for a conversation, not a computer

Every request has two types of refusal:

A business refusal is, for example, an invalid email address or a rule that blocks. It gives the agent a smooth path: ask again, or speak a fallback line.
A true platform failure gives the agent an apology line.

In both cases, the conversation continues without a failure.

The platform manages repetition in the same way. If the voice service sends the same request two times, the platform accepts the second copy but does not act again. A changed request counts as a new request. Example: the merchant moves the callback time during the call.

A merchant who leads straight into a request, before the agent has said the two required disclosures, cannot get it granted silently. The platform reads the agent's own words on the call so far. If the AI-and-recording notice has not yet been said, the platform holds the request back and has the agent say the notice first, then ask permission to go ahead. The request only proceeds once the merchant says yes.

One known gap

If the outbound email service has no configuration, the application-link request can report success without a sent email. This known gap is on the fix list.

The technical bit, translated

Retell tool invocation — the agent's conversation script includes named tools. When the script reaches a tool, the voice service (Retell) pauses and sends the request to the platform. Retell holds the conversation open for a maximum of ten seconds. This pause is the source of the ten-second limit above.
The request signature — the voice service signs each tool request with a key that only the voice service and the platform know. The signature covers the full request and the time it was sent. The platform refuses a request with no signature, a wrong signature, or a time more than five minutes old. The platform also refuses a second copy of the same request. The platform checks the signature in constant time. Thus the response timing gives no data to a person who tries to guess the key.
The call check — the platform does not take the client's identity from the request. It finds the call in its own records. The call must be one that the platform placed, with the same agent, and in progress or ended less than ten minutes ago. If not, the request has no effect.
Telnyx moves a live transfer, not Retell: Telnyx placed the call and still holds the merchant's side of it, so it is the only party that can ring the specialist line and join the two sides together. This is why the transfer request goes through the platform rather than through a feature built into the voice service.
Resend is the service that delivers the branded emails: the callback notices, including the Callback ASAP notices, and the application link.
A pipeline wake date reaches Temporal as a signal to the lead's own durable job. This job keeps the state of the lead's calling programme and survives a restart, so the wake date is still there even if a server restarts between the call and the wake-up.