How It Works

Appilots is made of three pieces that work together: the SDK embedded in your app, the CLI that describes your app to Appilots, and the hosted API that runs the AI agent. This page walks through how they fit together, end to end.

The three pieces

• @appilots/sdk — a React Native package you embed in your app. It renders the chat UI (<AppilotsChat/>), wraps your app in <AppilotsProvider/>, and exposes navigation and registration hooks so the SDK knows what's on screen at any moment.
• The appilots CLI (@appilots/cli) — a build-time tool that statically analyzes your app's source code (screens, navigation graph, forms, actions) and produces an MCP document. Running appilots sync uploads that document to your project on the Appilots backend.
• The Appilots API + dashboard — a hosted service. The API (api.appilots.com) runs the AI agent loop against the active MCP document for your project and returns replies and actions. The dashboard (app.appilots.com) is where you create a project, get an API key, and configure the model, persona, and permissions used at runtime.

These three pieces run on different schedules: the CLI runs at build/CI time, the SDK runs on-device at runtime, and the API runs on Appilots' servers whenever a user sends a chat message.

Putting it together

1. You add @appilots/sdk to your React Native app and register the screens, fields, and actions you want the agent to be aware of.
2. You run the appilots CLI against your app's source. It generates an MCP document describing your screens and navigation graph, then appilots sync uploads it to your project.
3. On the dashboard, you configure the project: model, persona, permissions, and any human-escalation routing.
4. At runtime, a user opens the chat and sends a message. The SDK sends the message plus the current screen context to the Appilots API.
5. The Appilots API runs the agent turn against the project's active MCP document and returns a reply plus zero or more actions (navigate, form_fill, ui_interaction, scroll_list, confirm, custom).
6. The SDK executes those actions locally, against the live UI, using the registry of screens and elements you registered in step 1.

The API/agent is intentionally opaque here — from the outside it's a black box that takes a message and screen context and returns a reply and a list of actions. What happens inside a single agent turn isn't part of the public contract; what matters for integration is the shape of what goes in and what comes out.

Where to go next

• MCP documents — what's in the document the CLI generates and how it's kept in sync with your app
• Agent actions — the full action model the SDK executes
• Permissions — how you constrain what the agent is allowed to do
• Sessions and users — how conversations and end users are tracked