AppFunctions arrived at Google I/O 2026 as an Android platform API and Jetpack library, in private preview with Gemini integration and an Early Access Program. It lets an app declare its capabilities so that AI agents can discover and execute them, and it simplifies Model Context Protocol integration — effectively letting your app behave as an MCP server. Android 17 ships the platform side of it. Most coverage filed this under "AI features". I think it is closer to a change in what an app is.
The discovery surface is moving
Think about how a user currently books a table. They unlock the phone, find the app, open it, navigate to search, type, filter, tap. Every step is a place to lose them, and the whole flow presumes they remembered your app exists. Now imagine they say "book me a table for four at eight" to an assistant that can enumerate the functions every installed app exposes, and call the right one.
In that world, being installed is not the same as being reachable. An app that exposes no functions is invisible to the surface where the user actually expressed intent. This is the same structural shift that search engines went through when they started answering questions instead of returning links — except the unit of retrieval is an action, not a document.
What MCP actually is
The Model Context Protocol is an open standard for exposing tools and data to a language model in a way the model can discover and invoke. A server declares what it can do, describes each function's parameters, and the model decides when to call it. It has become the common vocabulary for connecting models to external systems, which is precisely why Google routing AppFunctions through it matters: your app is not integrating with Gemini specifically, it is speaking a protocol that any compliant agent understands.
It is worth being clear-eyed here. AppFunctions is in private preview. The API will change. Nothing about this is a reason to rewrite an app today. It is a reason to make one design decision differently.
The design decision: does your logic live in the UI?
Here is the test. Pick the most valuable thing your app does. Can you invoke it without touching a screen — as a function, with typed parameters, returning a result? Or is it entangled with a Fragment lifecycle, a ViewModel that reads from a saved-state handle, and validation that lives in a text field's onChange?
If it is the latter, you cannot expose it to an agent, and the work to fix that is not "AI work". It is the clean-architecture separation that has been recommended for a decade and skipped for a decade because nothing forced the issue. Agents force the issue. An app whose use cases are callable functions is agent-ready almost for free; an app whose logic lives in its screens has to be refactored first. That is the whole story, and it is why this is worth thinking about before the API stabilises.
Which functions to expose
Not all of them. Start with actions that are high-intent, unambiguous, and safe to perform. Searching your catalogue, checking an order status, starting a timer, logging an expense, retrieving a document — these are read-heavy or trivially reversible, and a wrong call costs the user nothing. Do not start with anything that spends money, sends a message, deletes data, or commits the user to something. An agent misinterpreting an ambiguous instruction is not a hypothetical, and a confirmation step is not a substitute for good judgement about which actions belong behind one.
Write function descriptions for a reader who has never seen your app. The model chooses which function to call based on that text, so a vague description is a bug. "Search" is a bad name. "Search restaurants by cuisine, location and party size" is a good one. This is a genuinely new discipline: your API documentation is now a runtime input, not a courtesy to other developers.
How this connects to AI search
There is a broader pattern worth naming. Making a website legible to AI systems means structured data, clean semantics, and a machine-readable summary of what you offer. Making an app legible to AI systems means declared functions with honest descriptions. In both cases the winners are the ones who described themselves accurately, in a format a machine can consume, before it was obviously necessary. The technique differs; the posture does not.
What to do now
Three steps, none of which require the preview. First, list the five things users most often want from your app and write each as a function signature — name, typed parameters, return value. Second, check how much of each one you could implement today by calling into existing code, versus how much lives inside a screen. That gap is your agent-readiness backlog, and it is worth closing regardless of whether AppFunctions succeeds, because it is the same refactor that makes an app testable. Third, register for the Early Access Program if this is strategically relevant to you, and expect the API to change under you.
The safest prediction is not that agents will replace app UIs. It is that apps will need to be usable both by a human tapping a screen and by a machine calling a function, and that the apps which were already architected that way will find this a small change while everyone else finds it a rewrite.