Does your mobile app need an AI agent?

A useful implementation example, with limits.

On 28 September 2026, Google published an Android walkthrough of cloud-hosted, in-app agent workflows. Its Jetpacker demo coordinates travel tasks on a backend and sends progress and interactive choices to a native Android interface.

The example combines ADK for agent execution, AG-UI for communication, and A2UI for describing interface components. The Android renderer dependencies shown in the post are alpha versions. This is a dated implementation walkthrough, not evidence that every part of the stack is stable or that adding agents improves retention.

For a small team, it offers a concrete architecture to evaluate. The product decision comes first: which recurring task would become meaningfully easier if the app could choose and carry out several steps?

Choose the smallest workflow that needs judgment.

Our starting rule: use ordinary application logic when the steps are known. Try a single model call when you only need to extract or transform information. Consider an agent when the next useful action depends on intermediate results and the task needs several tools.

In a hypothetical shift-planning app, extracting dates from a rota image may need one model call followed by validation. Checking those shifts against existing calendar entries, asking about an ambiguous date, and proposing conflict-free changes is a broader workflow. Start by producing an editable draft; writing to the calendar can be a separate, confirmed step.

Write down the input, allowed tools, finished result, and conditions for stopping. A narrow assistant should be able to say that it cannot finish. If the benefit remains unclear, return to testing the underlying problem before adding orchestration.

Closing the app should not lose the job.

Cloud execution separates the work from the phone’s screen, but durable recovery still needs engineering. ADK’s session documentation states that its in-memory session service loses conversation data when the server application restarts. Moving a demo to a server does not automatically make it resumable.

For a pilot, give each job a stable identifier, persist its progress, and let an authenticated user reconnect to that job. Keep tool credentials on the backend and check access there. Show whether the job is running, waiting for input, finished, or needs intervention.

Test a dropped connection immediately after a write succeeds. On reconnection, check the recorded outcome before retrying. Repeating the same request should not create another calendar entry; use an operation identifier and a duplicate check at the write boundary. Also test cancellation and a server restart, not just a happy-path animation.

Show the proposed change before applying it.

A2UI describes interfaces as data rendered with components the client supports. That can make a choice easier to inspect than a long chat reply. It does not give a model unlimited permission to invent executable screens or perform actions.

In the shift-planning example, show the proposed dates, destination calendar, conflicts, and exact changes in a review card. Let the user correct or decline them. Bind approval to that specific proposal; if the proposal changes, request a new decision. Validate permissions and arguments when the server applies it.

ADK offers tool confirmation, but its current documentation labels the feature experimental and lists DatabaseSessionService and VertexAiSessionService as unsupported. Check compatibility with your chosen persistence setup before committing to it. A demo confirmation flag is not a complete recovery design.

Keep the client and server’s component catalogs compatible. The A2UI catalog guidance covers versioning and fallbacks for unknown components. Test an older installed app against the newer backend: users do not all update together. New client capabilities still require client work.

Measure completed work, including the failures.

Pick an observable completion rule before testing. For our hypothetical pilot, that might be “the user reviewed a proposal and the intended calendar entries were saved correctly.” A confident answer, a rendered card, and a tool call are intermediate events.

Include failed attempts, retries, model calls, paid tool calls, and attributable infrastructure in the numerator. Use one defined enrollment period and follow-up window; classify unfinished jobs separately instead of silently dropping them. If no jobs complete, the ratio is undefined.

Compare with the existing flow on equivalent tasks. Record completion, elapsed time, user corrections, duplicate writes, and abandonment. Choose a minimum useful improvement and an acceptable cost before reading the results. A successful staged demo does not establish a retention lift or profitable unit economics.

Add a small set of job outcomes to your event plan, without logging calendar contents or other unnecessary personal data. Include AI operating costs when you later calculate cohort contribution.

Make the first test easy to stop.

Choose one task, one audience, a limited tool set, and a development budget. Begin with draft output and test interruptions before enabling writes. Keep a usable manual path and a way to disable the assistant without disabling the app.

Continue when people complete the task more reliably or with less effort, at a cost the product can support. Revise a specific failure when the evidence suggests a fix. Stop if the added coordination creates more work than it removes. The walkthrough makes an approach concrete; your pilot establishes whether the approach belongs in your product.