Google Play now has a rule for how your app talks to AI agents. A memo for the person who owns your Android app

To the owner of our Android app

Re: Google Play's October 29, 2026 policy update, and what it means for anything our app exposes to AI agents.

Short version: if our app uses Android's AppFunctions API, or we're planning to, we need to review how each function describes itself, what it can do without the user's say-so, and whether any of them can complete a purchase. Google gives developers at least 30 days from October 29 to comply, and its Policy Deadlines page, as we read it on October 31, lists the AppFunctions policy under April 14, 2027. That's time to do this properly, not a reason to wait: someone should confirm the date on that page and put it on the release calendar.

What Google said

The policy announcement adds a new policy for the AppFunctions API, the Android feature that lets an app offer actions, such as "book a table," "reorder my usual" or "find an open appointment," that AI agents on the device can call on a user's behalf. The wording is short:

"Developers building AppFunctions must comply with all existing Google Play policies. AppFunctions are strictly prohibited from deceiving or manipulating AI agents, bypassing security controls, or interfering with other applications."

In the same announcement, Google says it's providing additional guidance on how its Payments policy applies to apps that facilitate digital purchases through AI or agentic experiences.

Two things are worth noticing. First, this is the first time many teams will see a store policy aimed at how an app treats software, not people. Second, the three prohibitions are broad. "Manipulating AI agents" isn't defined in the announcement, which means Google will decide case by case.

Why the descriptions are the risky part

When an app offers a function to an agent, it describes it: a name, what it does, what it needs, what it returns. The agent reads that description and decides whether and when to call it. That's very different from a button a person looks at.

A description written for a person can get away with a little enthusiasm. A description written for an agent is an instruction, and Google is now treating it like one.

Here's the kind of thing that would worry us in a review:

• Overclaiming. A function called "find the best price" that only searches our own catalog. An agent asked to find the best price for a user would reasonably call it and repeat the answer.
• Steering. Descriptions that tell the agent to prefer our app, or to call our function first, or to avoid mentioning alternatives. That's the plain-language version of manipulating an agent.
• Hidden side effects. A "check availability" function that also places a hold, or a "save for later" that signs the user up for emails.
• Stale descriptions. Functions whose behavior changed in a release but whose description didn't.

We saw the same idea in Apple's rules about features that aren't disclosed in review: stores increasingly expect an app to be exactly what it says. Agents raise the stakes, because nobody reads the description before the action runs.

Security and other apps

The other two prohibitions are about boundaries.

Bypassing security controls means a function can't do something on the agent's behalf that the user couldn't do directly, or that would normally require a confirmation, a login or a permission. If paying in our app requires the user to confirm, a function shouldn't skip the confirmation because the request came from an agent.

Interfering with other applications means our functions shouldn't try to block, override or tamper with what other apps offer to the same agent. If a user asks an agent to compare two delivery apps, our function answers for us, not about the other one.

Neither of these is likely to be a problem for a well-built app. But "likely" isn't a review. The places where they slip are usually shortcuts: a function added for a demo that skipped the usual checks, or a background permission granted years ago for a different feature and quietly reused. Someone should read each function with these two questions in mind.

Purchases

If any function can complete a purchase of digital goods, a subscription, a credit pack, an upgrade, the new Payments guidance applies, and we should read it carefully before the deadline. The questions we'd ask:

• Can an agent complete the purchase without the user confirming on screen?
• Does the purchase go through Google Play's billing where Play's policy requires it?
• Is the price and what's included stated in the function's output, so the agent can tell the user accurately?

Physical goods and services follow different rules, but the honesty principle is the same: the agent should be able to tell the user exactly what they're agreeing to.

What I'd like us to do this month

1. Inventory every AppFunction we ship or plan to ship, with its name, description, inputs and side effects.
2. Rewrite descriptions to say what the function does, plainly, and nothing more. No steering language. Read each one aloud and ask: if an agent repeated this to a customer word for word, would it be true?
3. Check confirmations for anything that spends money, changes an account or shares data.
4. Read the Payments guidance for any agent-triggered digital purchase.
5. Add descriptions to code review, so a change in behavior can't ship without a change in description.
6. Confirm the April 14, 2027 date on the Policy Deadlines page and put it on the release calendar.

None of this is a big build. It's a careful read, a few rewrites and one new habit in code review. The cost of skipping it is a policy strike on the app that pays the bills.

There's an upside, too. Agents are going to become one of the ways customers find and use apps, and the apps that describe themselves clearly will be the ones agents call with confidence. A plain, accurate description isn't just safer under this policy. It's how an agent learns when our app is the right answer, and when it isn't, which is also how a customer learns to trust it.

If you'd like a second pair of eyes on how your app presents itself to agents, our mobile applications team reviews and builds these integrations. Get in touch and send us the list of functions you expose today.

Related work: Paddle8.