In-app agents
An agent that runs inside your mobile app, sees the screen your customer is on, and can act on it — rather than a chat box that only reads what they type.
An in-app agent lives inside your Android or iOS app. It knows which screen the customer is on, which field failed validation, and how long they have been sitting there without touching anything — and it can fill that field, move them to the next step, or hand off to a person.
That is the difference from the website embed. Both talk. Only this one can see and act.
Every released version and what changed is in the changelog.
Conversations open on the agent's web-call variant, exactly as the website embed does. The two share a prompt but are separate runtime agents, so nothing you do here can affect your outbound phone calling.
What it changes
Consider a customer stuck on PAN verification, step 2 of 4, with an empty field and a rejection message on screen.
A chat widget can only wait to be opened, and then ask what the problem is — which is the question the customer least wants to answer. An in-app agent already knows, because your app told it. It can open itself and offer to fix the specific thing that is wrong.
The two directions
Everything on this page reduces to two flows you wire up once.
You write the two ends. Everything in the middle — masking, ordering, retries, friction detection, the transport — is the SDK's, which is why an agent behaves the same in your app as in anyone else's.
| What it is | You write | |
|---|---|---|
| Screen context | Your app tells the agent what the customer can see | One hook per screen — Screen context |
| Actions | The agent asks your app to do something, and waits for the answer | One handler per action — Actions |
Both are optional and independent. An agent given context but no actions is a very well-informed adviser. An agent given both is a co-pilot.
What you keep from the embed
Everything below is unchanged, so nothing has to be rebuilt:
- The same dashboard, knowledge base, voices and analytics
- Interactive components — product lists with pictures, plan cards, quick actions, calendar slots — render natively in the app, from one definition that also serves your website. Their content can come from your own API at call time
- Conversations appear in your call history alongside web and phone calls
What you do not reuse is the agent itself.
Give the app its own agent, cloned from the website one. Actions are declared per agent and the model is offered all of them on every surface that agent serves — so a shared agent offers your website tools that only exist inside the app, and it picks worse for having them. Full reasoning in One agent per surface.
Clone rather than start over: the clone carries the prompt and knowledge base across, and you then change only the parts that differ.
Availability
React Native today, covering Android and iOS from one codebase. Native Android and iOS SDKs speak the same protocol and are in progress.
For a website, use the script-tag embed instead — it needs no build step.