Intelligence 6 min read

The Android Intelligence System: AppFunctions, Remote MCP or Computer Control, and Which One Your App Needs

On Nov 5, 2026 the Android team published its Android Developer Summit round-up for intelligent apps. Strip away the product names and one idea remains: users now state a goal ("check my calendar, book a ride, and message Jingyu my ETA") and a system agent orchestrates apps to finish it. Android gives you three ways to take part, with very different costs. This post sorts them by what they demand from you, using the Android docs and the Dev Summit post, and then covers the other half: putting an agent inside your own app.

3
integration paths: AppFunctions, remote MCP, Computer Control
6
max target apps in one Computer Control session
0
code changes needed in a Computer Control target app

Status check: the Android docs label the intelligence-system features as Preview, and Computer Control as an "upcoming" API that currently works with a limited set of target apps. Treat this as a design decision to prepare for, not a feature to promise in a release.

The two modes: prompted and proactive

Per the Dev Summit post, the intelligence system offers prompted assistance, where the user explicitly asks an agent for something, and proactive assistance, where the system surfaces contextual suggestion chips on lock screens, notifications, virtual keyboards and inside apps. The three integration paths below serve the prompted flow. The system covers phones, wearables, XR glasses, TVs and cars.

Path 1: AppFunctions (Android MCP)

AppFunctions is a platform API with a Jetpack library that exposes specific capabilities of your app as discrete functions that agents can discover and execute on-device. The blog calls this "Android MCP", built on the familiar MCP standard. You write the functions, so you control exactly what an agent can do. If you adopted it earlier, my rc01 migration guide lists the API churn.

Google recommends it when your user journey:

It can also connect your own on-device in-app agent, not only the system agent.

Path 2: a remote MCP server

With the server-side approach your backend exposes capabilities to agents directly. The docs describe it as complementary and a good fit for coverage across Android and other platforms. Nothing runs on the phone, so there is no app release to ship and no on-device data. The trade-off is the mirror image of path 1: if the journey depends on local state or hardware, a server cannot see it.

Path 3: Computer Control

Computer Control lets an OEM-preloaded assistant drive your app's UI, with no integration on your side. According to the framework docs:

Because the agent reads screenshots, the docs' advice for target apps is the unglamorous kind: follow adaptive design and lifecycle best practices. Stable, labeled, predictable screens are your integration. An assistant may also choose to limit which apps it automates, so you cannot opt yourself in by polishing the UI.

The Dev Summit post describes Computer Control as the fallback: agents can use it "to complete actions without requiring any app-side integration" when neither MCP route exists. That makes the first two paths the ones where you decide the behavior and the third the one where you do not.

Choosing: a heuristic, not an API

This snippet is my own summary of the guidance above, not a library call. It is useful as a team checklist:

enum class AgentPath { ANDROID_MCP, REMOTE_MCP, COMPUTER_CONTROL_ONLY }

data class Journey(
    val usesLocalSensitiveData: Boolean,
    val needsDeviceHardware: Boolean,
    val mustRunLocally: Boolean,
    val hasServerEndpoint: Boolean,
    val needsOtherPlatforms: Boolean,
)

fun pickPath(j: Journey): AgentPath = when {
    j.usesLocalSensitiveData || j.needsDeviceHardware || j.mustRunLocally ->
        AgentPath.ANDROID_MCP
    j.hasServerEndpoint || j.needsOtherPlatforms ->
        AgentPath.REMOTE_MCP
    else -> AgentPath.COMPUTER_CONTROL_ONLY
}

The two are not exclusive. The Connected Apps Platform, which targets Gemini and Search, combines Android MCP for native on-device execution with remote MCP servers for cross-platform reach. You can test locally today with Gemini Apps Developer Mode; production access is a preview waitlist, and capacity is currently limited to selected production-ready apps in supported categories.

The other half: agents inside your app

The same post covers building intelligence in:

What I would do this quarter

Sources: the Android Developers Blog post "From in-app agents to the Android intelligence system" (Nov 5, 2026) and the Android docs pages on the intelligence system and Computer Control, retrieved Nov 6, 2026.

Comments 0

No comments yet. Be the first to leave one!

Leave a comment