Guiding users inside your app with an in-app agent

Every app has a screen where people give up. A document upload that keeps failing, a form with one field nobody understands, a feature that would solve their problem if they knew where it was. Most of these users never contact support. They just leave.

A help article cannot see which field is empty. A chat window in the corner can only ask "how can I help?", which is the question a stuck user least wants to answer. An in-app agent starts from what is on the screen, and can do something about it.

What an in-app agent is

An in-app agent is a Graine agent that runs inside your mobile app or website. Your users talk to it by voice or chat, and it can also call them, inside the app. It is built from the same agent you configure in the dashboard, with the same voices, languages and knowledge, but it has two things a phone agent does not: it can see the screen, and it can act on it.

It ships as native SDKs for iOS, Android, Flutter and React Native, and as an embed for the web. Each one draws the agent's bar and windows in your app's own design, and how it looks and what it says come from the dashboard, so changing either needs no app release.

It sees the screen, not the user's data

Your app tells the agent which screen is open and which fields are on it, as structured data you choose. There are no screenshots and no screen recording. Before anything leaves the device, personal data is masked: card numbers, national ID numbers, phone numbers and email addresses, plus any patterns of your own. It is masked again when it arrives.

This is all the agent sees of a document step, for example:

{
  "screen": "kyc_documents",
  "fields": [
    { "name": "pan", "value": "[PAN]", "status": "filled" },
    { "name": "address_proof", "status": "empty" }
  ]
}

That is enough for it to know the address proof is the missing piece, without ever seeing the number on the card.

It guides, and it acts

Seeing the screen turns vague help into specific help. An in-app agent can:

• Take them there. It opens the right screen instead of describing where to tap. It can only open screens your app declared.
• Point at it. It highlights the field or button it is talking about, at the moment it mentions it.
• Fill it in. From what it already knows, such as an answer given a minute ago. The user confirms instead of typing.
• Notice the sticking point. The SDK notices friction, such as a stalled form, repeated taps or an error on screen, and the agent can offer help at that moment, before the user gives up.
• Run your actions. Declare an action with a name, a description and its parameters, and it becomes something the agent can do. The description teaches it when.

And nothing else. Declaring an action creates a contract, not a free hand: the agent can call only the handlers your app implements, on the screens your app reports, and every call returns a result your app decides. In React Native, both halves fit in a few lines:

import { useGraineScreen, useGraineAction } from "@graineai/inapp-react-native";
 
function DocumentsStep({ pan, addressProof, openUploader }) {
  // What the agent can see on this screen
  useGraineScreen({
    screen: "kyc_documents",
    fields: [
      { name: "pan", label: "PAN", value: pan, status: pan ? "filled" : "empty" },
      { name: "address_proof", label: "Address proof", status: addressProof ? "filled" : "empty" },
    ],
  });
 
  // What it may do here, and the result it gets back
  useGraineAction("open_uploader", async ({ document }) => {
    openUploader(document);
    return { status: "ok", message: `Opened the ${document} upload.` };
  });
}

The other SDKs follow the same two ideas, in each platform's own style.

Voice, chat and calls inside the app

Users choose how to talk. They can type in the chat window, speak to the agent from the bar at the bottom of the screen, or take a full voice call inside the app. In-app calls ring like a phone call, and work in both directions: a user can call the agent, and the agent can ring the user at a time they chose, such as a reminder to finish an application. No phone number is needed, and the whole conversation stays inside your app.

Where it helps most

The pattern is the same in every case: a user is close to finishing something, and a little specific help gets them there.

1. Onboarding. First-run setup with several choices. The agent explains each one in plain words, fills in what it already knows, and moves the user to the next step.
2. Identity and document steps. The most common place to drop off. The agent sees which document is missing or was rejected, explains why, and opens the upload.
3. Feature adoption. A user describes what they want to do; the agent takes them to the feature that does it and points at the first control, instead of linking a help page.
4. Support. The agent already knows the screen and the error, so it starts with the answer, not with questions. When a person is needed, it can say who will follow up.

The controls your security team will ask about

An agent inside your app has to earn trust, so the boundaries are explicit:

• Structured context only, chosen by your app and masked on the device.
• Actions refused by default: only the handlers you implement, on the screens you report.
• Keys that cannot be misused: the publishable key in your app reads no data and places no call, and only the apps and websites you allow can use it.
• A record of everything: every conversation, the screens the agent saw and every action it took, with its outcome, in your call history and through the API.

Rolling it out

Start with one screen where users drop off. Report that screen's fields, declare one or two actions, and test the agent with your own team. Then add screens one at a time, reading the conversations as you go: they show exactly where users were stuck, in their own words.

If you have a screen in mind, write to us at hello@graine.ai and we will scope it with your team, or create an account and try the SDK in your own app.