> ## Documentation Index
> Fetch the complete documentation index at: https://docs.agi.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> How your AI client, AGI's cloud, and your phone fit together.

AGI Agentic Phone MCP is a three-piece system. Understanding who does what makes every other page in these docs click into place.

## The three pieces

```text theme={null}
┌──────────────────┐     MCP (HTTP/SSE)    ┌──────────────────┐              ┌──────────────────┐
│   Your AI client  │ ────────────────────> │  AGI cloud MCP   │ ───────────> │  AGI Android app │
│  Claude Code,     │                       │  server          │              │  on your phone   │
│  Cursor, ChatGPT, │ <──────────────────── │  queues + relays │ <─────────── │  executes with   │
│  your own agent   │      results          │                  │   progress   │  accessibility   │
└──────────────────┘                       └──────────────────┘              └──────────────────┘
```

<CardGroup cols={3}>
  <Card title="Your AI client" icon="robot">
    Any MCP client. It decides *what* to do, calls tools, and interprets
    results. It never touches the phone directly.
  </Card>

  <Card title="AGI cloud MCP server" icon="cloud">
    `https://api.agi.tech/v1/mcp`. Authenticates you, queues tasks, dispatches
    them to your devices, and relays progress back.
  </Card>

  <Card title="AGI Android app" icon="mobile">
    The agent itself. It executes tasks on-device using Android's
    accessibility APIs - real apps, real UI - and streams progress back.
  </Card>
</CardGroup>

## The asynchronous execution model

Phone tasks take seconds to minutes - far too long for a blocking API call. So execution is split:

1. Your client calls [`phone_run_task`](/api-reference/tools/phone-run-task).
   The server queues the task and returns a `task_id` **immediately**.
2. The phone picks the task up and executes it, streaming progress back.
3. Your client waits on
   [`phone_task_monitor`](/api-reference/tools/phone-task-monitor), which
   returns as soon as something actionable happens - completion, a pause, or a
   request for user input. If nothing happens within its timeout it returns
   `monitor_timed_out: true`, and you simply call it again.

This start/monitor split is the single most important pattern in the API. The full loop, including every outcome, is covered in [Task lifecycle](/guides/concepts/task-lifecycle).

## Why on-device execution matters

The agent operates the phone the way a person does - through the screen, via Android's accessibility APIs:

* **Real apps, not APIs.** Anything installable is automatable; no
  per-app integration is required.
* **Visible execution.** Every action happens on the phone's screen while you
  watch. There is no hidden browser or virtual machine.
* **Native trust boundaries.** App logins, payment sheets, and permission
  dialogs stay on the device, where the user handles them - the agent hands
  control back rather than working around them.

## Where MCP fits

The Model Context Protocol is the connector standard that makes the client side universal. The server speaks MCP `2024-11-05` over Streamable HTTP or SSE, with OAuth 2.1 or API-key auth. Any compliant client gets the same tools by calling `tools/list` - nothing is hardcoded per client.

Setup for each client lives on the [Connect your AI client page](/android-mcp/connect); protocol and auth details are in the [API reference](/api-reference/introduction).

## Next

<CardGroup cols={2}>
  <Card title="Devices & Sessions" icon="mobile" href="/guides/concepts/devices-and-sessions">
    How work is organized across phones and workflows
  </Card>

  <Card title="Task Lifecycle" icon="arrows-spin" href="/guides/concepts/task-lifecycle">
    The state machine every task moves through
  </Card>
</CardGroup>