By Deepak Bagada, CEO at SaaSNext & Principal AI Architect.

EU DMA Android AI Agent Interoperability Pipeline

In July 2026 the European Commission issued a binding interoperability order against Google under the Digital Markets Act, forcing Android to open eleven system capabilities to rival AI assistants. For the first time, a third-party assistant can run as a genuinely voice-activated, background-running, cross-app agent on the same footing as the platform's own assistant. This is the biggest practical change to the mobile agent landscape since the DMA itself became law, and it turns Android into the most accessible playground in the world for agentic AI products.

This guide is a complete technical and strategic walkthrough: what the order actually opens, how to build a DMA-compliant assistant agent, the compliance requirements and timeline you must respect, and the honest strategic questions you should answer before you build. The reference pipeline below is built with LangGraph plus MCP and runs on a companion Android app, mirroring the exact pattern I use for agentic products. For the broader playbook, see the Daily AI World workflows library and the MCP directory.

What the July 2026 order opens up

The binding order identifies eleven system features that third-party assistants can now access under the same terms as Google's own assistant, including:

1. Assistant invocation — voice-trigger on Android Auto, lock screen, and the hardware assistant key.
2. System UI surfacing — showing assistant cards and follow-up prompts in the same system surfaces.
3. App intents — deep intents into apps such as Maps, Calendar, Messages, Phone, and Camera.
4. Notifications — reading, responding to, and composing from notification channels.
5. Background execution — sustained processing without a visible foreground activity.
6. Media controls — playback, cast, and volume across media apps.
7. Sensors — microphone access under the same user-consent rules as the platform assistant.
8. Calendar and contacts — read and write with user consent.
9. Phone and messaging — placing calls and sending SMS via the system UIs.
10. App search — discovering and launching installed apps by semantic query.
11. Device settings — reading and toggling settings like Wi-Fi, Bluetooth, and focus modes.

The most consequential items for developers are background execution and invocation: they are what turn a widget into a real agent that is present on the device, listening when invoked, and able to carry a task across apps.

Architecture diagram

flowchart TD
    W[Wake Word / Voice] --> I[Assistant Invocation Layer]
    I --> G[LangGraph Agent Core]
    G --> C[Consent Manager]
    C --> I1[Intent Bridge: Maps / Calendar / Camera]
    C --> I2[Notification Bridge]
    C --> I3[Media Controls]
    C --> I4[Settings & Sensors]
    G --> B[Background Worker]
    B --> E[(Event Queue)]
    G --> M[MCP Tool Servers]
    M --> A1[Cloud APIs]
    G --> L[(Local State / On-device Store)]

Building a DMA-compliant assistant agent

The implementation splits cleanly into an on-device companion app and a LangGraph agent core. The on-device layer owns invocation, consent, and the system bridges; the LangGraph core owns reasoning, tool routing, and retry. This mirrors production agent stacks and keeps the pieces independently testable.

.env

# dma assistant pipeline environment
LLM_PROVIDER=anthropic
ANTHROPIC_API_KEY=sk-ant-xxxxxxxxxxxx
ASSISTANT_SERVICE_URL=https://agent.corp.example.com/v1
MCP_CALENDAR_URL=https://mcp.calendar.corp.example.com
MCP_NOTIFICATION_URL=https://mcp.notify.corp.example.com
MCP_MEDIA_URL=https://mcp.media.corp.example.com
CONSENT_REQUIRED=true
MAX_BACKGROUND_SECONDS=120
LOCAL_STATE_DIR=./state

schemas.py

from pydantic import BaseModel
from datetime import datetime
from typing import Literal, Optional

class Invocation(BaseModel):
    trigger: Literal["wake_word", "lock_screen", "android_auto", "assistant_key"]
    locale: str
    app_context: Optional[str] = None

class ConsentGrant(BaseModel):
    feature: str
    user_id: str
    granted_at: datetime
    scope: Literal["once", "session", "persistent"] = "session"

class SystemAction(BaseModel):
    target: Literal["intent", "notification", "media", "settings", "sensor"]
    app: Optional[str] = None
    payload: dict
    requires_consent: bool = True

tools.py

import httpx
from .schemas import SystemAction, ConsentGrant

def invoke_intent(action: SystemAction) -> dict:
    r = httpx.post("http://localhost:8200/intents", json=action.model_dump())
    return r.json()

def read_notifications(grant: ConsentGrant) -> list[dict]:
    r = httpx.get("http://localhost:8201/notifications",
                  params={"scope": grant.scope})
    return r.json()

def control_media(action: SystemAction) -> dict:
    r = httpx.post("http://localhost:8202/media", json=action.model_dump())
    return r.json()

def toggle_setting(action: SystemAction) -> dict:
    r = httpx.post("http://localhost:8203/settings", json=action.model_dump())
    return r.json()

graph.py

from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from .tools import invoke_intent, read_notifications, control_media

class AgentState(TypedDict):
    invocation: dict
    consent: dict
    plan: list
    actions: list
    error: Optional[str]

def plan_actions(state: AgentState) -> AgentState:
    # LLM node: turn the invocation into a tool plan
    return {**state, "plan": [...]}

def execute_action(state: AgentState) -> AgentState:
    results = []
    for a in state["plan"]:
        if a["type"] == "intent":
            results.append(invoke_intent(a))
        elif a["type"] == "notification":
            results.append(read_notifications(state["consent"]))
    return {**state, "actions": results}

def check_consent(state: AgentState) -> AgentState:
    if state["consent"]["required"] and not state["consent"]["granted"]:
        return {**state, "error": "consent_required"}
    return state

builder = StateGraph(AgentState)
builder.add_node("plan", plan_actions)
builder.add_node("execute", execute_action)
builder.add_node("consent", check_consent)
builder.add_edge(START, "consent")
builder.add_edge("consent", "plan")
builder.add_edge("plan", "execute")
builder.add_edge("execute", END)
graph = builder.compile()

main.py

import asyncio
from .graph import graph

async def handle_invocation(invocation: dict) -> dict:
    result = await graph.ainvoke({
        "invocation": invocation,
        "consent": {"required": True, "granted": False},
    })
    return result

if __name__ == "__main__":
    demo = {"trigger": "wake_word", "locale": "en-GB"}
    print(asyncio.run(handle_invocation(demo)))

Consent, privacy, and compliance requirements

The DMA order does not grant assistants a free pass to user data. Three obligations dominate compliance:

1. Transparent consent: every sensitive feature — microphone, contacts, calendar, notifications, messaging — requires explicit user consent with the same clarity the platform's own assistant must show. Your agent must be able to prove consent was given, when, and for what scope.
2. No preferential treatment in reverse: because you can now read and write system data, you are also a data controller. GDPR applies to everything your agent collects, processes, and syncs to the cloud. If your agent sends contact data to a server, that is a cross-border transfer with its own obligations.
3. Rate and fairness rules: the DMA's original fairness requirements still apply to your agent's market behavior, and the interoperability order carries reporting duties. Keep a compliance log of every system API call tied to a consent grant.

Timeline and rollout

The Commission set a staged compliance window. Basic invocation and notification access must be live by the order's effective date in late 2026; intents into Maps, Calendar, and Messages follow within the next two quarters; background execution and Android Auto deep integration are the final wave. In practice, Google controls the rollout cadence of the actual system interfaces, so treat the order's dates as deadlines on your product plan, not delivery guarantees. Build against the public Android accessibility and intent APIs first — they are stable today — and feature-flag the newly opened interfaces as they appear. Track the status of each capability against the order in your roadmap and in the latest AI news, because the details are still moving.

Strategic questions before you build

The technical pipeline is the easy part; the strategy is not. Ask yourself three questions before committing engineering time. First, what is your wedge? A third-party assistant that does everything Google does will not win on features alone — it will win on a specific vertical (health, travel, work) or a specific privacy posture. Second, what is your trust story? You now have system-level access; users will punish the first assistant that misuses notifications or microphone consent, and that punishment will be durable. Third, what is your latency budget? Voice agents die at 300 milliseconds of perceived lag; keep the LangGraph core warm, cache the consent state on device, and let background workers pre-warm context. The order removes the platform moat, but it does not remove the execution moat.

Retry Rules

System-level agent actions deserve the same retry discipline as any production pipeline:

• Retry only transient, idempotent actions. Reading notifications or toggling a setting is safe to retry; sending a message or placing a call is not — mark those actions as single-fire.
• Exponential backoff with jitter: 300 ms base, factor 2, cap 10 seconds, plus 20% jitter. Mobile radios and binder calls fail in bursts.
• Retry on transient codes and timeout exceptions only; never retry on consent denials or permission errors, which are persistent and require a user prompt instead.
• Max 3 attempts, then degrade gracefully: fall back to a visible card with a retry button rather than looping silently in the background.
• Respect background budget: each retry counts against the 120-second background window, so track elapsed time and stop the loop before the OS kills you.
• Re-request consent never automatically. If consent is revoked mid-task, halt the action chain and ask the user — an agent that keeps pushing after a no is a fast path to uninstalls.

FAQ

Q: When can I actually ship against these features?

A: Immediately for the stable intent and notification APIs, and progressively as Google releases the order's interfaces through 2027. Build with feature flags so each newly opened capability activates without an app-store dependency.

Q: Do the same rules apply on iOS?

A: No. The DMA interoperability order binds Google's Android. iOS assistants remain subject to Apple's own controls, though EU investigations into Apple's assistant access continue. If you are cross-platform, keep your LangGraph core portable and swap only the device bridge layer.

Q: What are the biggest technical risks?

A: Consent friction, background-execution limits killing long tasks, and flaky intent bridges across OEM forks. All three are manageable, but all three will show up in user reviews if you do not test them on real devices.

Q: Does my agent need to be on-device or can it be cloud-only?

A: The order requires on-device integration for invocation, consent, and the system bridges. The reasoning core can live in the cloud, but latency and privacy pressure point toward a hybrid: on-device state plus cloud reasoning. See the workflows library for hybrid patterns.

Q: How do I stay compliant with both DMA and GDPR?

A: Keep a per-action audit trail, tie every system API call to a consent grant with an explicit scope, minimize cloud sync to what the user asked for, and apply GDPR rules to whatever leaves the device. Compliance here is a feature: it is the trust story that wins users.