OS-Level Agent Frameworks: Windows, Apple, Android

Three operating systems now ship a native capability-declaration model for AI agents. Here is the only side-by-side builder/buyer comparison of all three – and a decision tree for which to target first.

OS-level agent frameworks compared: the short answer

The choice between Windows Agent Framework vs Apple App Intents vs Android AppFunctions comes down to one question the official docs never answer side by side: build for the OS your buyer actually holds, then accept that platform’s capability-declaration model and distribution gate. All three are “structured capability” systems – you declare typed actions with parameters, permissions, and return values so an agent can act without scraping your screen – but they are not interchangeable, and the economics differ by an order of magnitude. This piece breaks down OS-level agent frameworks in practical terms.

Here is the one-line verdict for each. Apple App Intents is mandatory if your users are on iPhone: without it, your app is invisible to Apple Intelligence, and there is no opting out of the App Store review gate. Android AppFunctions is the cleanest developer experience – annotate a Kotlin function and the OS indexes it as an on-device tool – but it is still a preview limited to recent Samsung hardware. Windows Agent Framework is the only one of the three that is open source (MIT), pays an 85% revenue share, and gives agents a real cross-agent message bus, making it the most builder-friendly for desktop and enterprise.

This article is the side-by-side that every existing ranking page is missing. Apple’s docs only cover App Intents. Android’s docs only cover AppFunctions. The Build 2026 recaps only cover Windows. Below is the capability-declaration matrix, the local-vs-cloud execution reality, MCP interoperability, distribution economics, and a decision tree for which to build for first.

What is a capability-declaration model, and why do all three OSes ship one?

A capability-declaration model lets an app tell the operating system, in advance and in structured form, exactly what actions an AI agent is allowed to invoke – the declared name, typed parameters, permissions, and return value – so the agent calls your app like an API instead of scraping its UI. Apple, Google, and Microsoft converged on this idea in 2026 for the same reason: screen-scraping “computer-use” agents are slow, brittle, and a security nightmare, while a declared contract is fast, inspectable, and enforceable.

The contrast that defines the category is structured capability versus screen-scraping. A computer-use agent looks at pixels, guesses where the “Send” button is, and clicks – and breaks the moment you ship a redesign. A capability-declaration system instead exposes a `SendPaymentIntent(amount: Decimal, to: Recipient)` that the agent calls directly. There is no freeform string parsing and no behavior outside the declared schema, which is precisely what makes these systems reviewable.

Each vendor uses different nouns for the same concept. Apple calls them App Intents – “enumerated, typed, and reviewable actions” like “I can log 250ml of water” or “I can send a payment.” Google calls them AppFunctions – self-describing Jetpack functions that “behave like on-device MCP servers.” Microsoft frames it at the OS level: agents register with a native service and communicate over a bus. Same north star, three very different runtimes and three very different business models.

Windows Agent Store vs Apple App Intents: how does distribution and revenue actually compare?

The distribution economics are the single biggest difference between these platforms: Microsoft’s Windows Agent Store pays developers an 85% revenue share, while Apple App Intents distribution runs through the App Store with its standard 15-30% commission and a pre-launch review gate you cannot bypass. For a paid agent or an agent-gated subscription, that delta compounds into a fundamentally different business model.

Windows took the aggressive position. At Build 2026, Satya Nadella unveiled the Windows Agent Store as a curated marketplace where agents are first-class OS citizens, with an 85% developer cut and a security review for listings. Adobe (an InDesign layout agent) and Zoom (an autonomous meeting agent) were named early design partners. Crucially, the underlying Windows Agent Framework was open-sourced under the MIT license and shipped as v1.0 on April 2, 2026 – so you can build and even fork the runtime without a store at all, and only opt into the store for monetized distribution.

Apple’s model is the opposite of optional. In 2026, an app without App Intents is invisible to Apple Intelligence entirely, so exposing intents is the price of being discoverable. But everything still routes through App Review, which inspects declared actions before launch and monitors behavior after deployment. Apple blocks on-device code generation and any agent operating beyond its declared intents, and reportedly intends to take a cut of AI subscription sales made through the platform. The contract protects the App Store as much as it enables agents.

Android AppFunctions sits distribution-wise with the Play Store and its standard commission, but the economics are almost beside the point today because the feature is still a preview. The on-device pipeline is gated to the Galaxy S26 series on OneUI 8.5 and higher, with Gemini integration in private preview, and roughly 25 apps’ use cases enabled across early partners. The wider rollout is slated for Android 17.

Android AppFunctions vs App Intents: which is the better local execution model?

Both Android AppFunctions and Apple App Intents execute on-device, but AppFunctions makes local-first an explicit design contract – functions run locally with no cloud round-trip – while App Intents runs on-device for most actions and offloads heavy AI to Apple’s Private Cloud Compute when needed. If avoiding network latency and keeping data on the handset is your priority, AppFunctions is the more opinionated choice.

The AppFunctions developer experience is the slickest of the three. You annotate a suspend function with `@AppFunction(isDescribedByKDoc = true)`, write a normal KDoc comment describing the parameters, and the Jetpack annotation processor generates an XML schema that the Android OS indexes for discovery. An agent like Gemini queries that metadata, semantically matches a user request such as “remind me to pick up my package at work at 5 PM” to your `createTask()` function, and invokes it locally. Callers need the `EXECUTE_APP_FUNCTIONS` permission, and sensitive actions like purchases require explicit user confirmation through Android’s dangerous-permission model and live-view UI.

App Intents achieves on-device action through a different mechanism: a typed Swift struct. A hydration app declares a `LogWaterIntent` with an `amount: Int` parameter, and Apple Intelligence calls it with a value and receives a typed result. The win is the same – the app acts as an API, the agent never navigates the UI – but the surrounding governance is Apple’s: actions are reviewable both at submission and after launch, and the system enforces that the agent stays inside the declared action space.

The practical tradeoff: AppFunctions gives you a cleaner annotation-driven workflow and a hard on-device guarantee, but it is a preview on limited hardware. App Intents is mature, GA, and shipping on every iPhone, but it carries Apple’s review overhead and a stricter ceiling on what agents may do. For a builder, AppFunctions is the better story to write today and App Intents is the better reach to ship today.

// Android AppFunctions: declare an on-device, agent-callable action.
// The Jetpack annotation processor turns this into an OS-indexed schema.

class TaskAppFunctions(private val repo: TaskRepository) {

    /**
     * Creates a reminder task the user can be alerted about.
     * @param title Short description of the task, e.g. "Pick up package".
     * @param dueDateTime ISO-8601 due time, e.g. "2026-06-02T17:00".
     * @param location Optional place the task is tied to, e.g. "work".
     */
    @AppFunction(isDescribedByKDoc = true)
    suspend fun createTask(
        appFunctionContext: AppFunctionContext,
        title: String,
        dueDateTime: String,
        location: String? = null,
    ): Task {
        // Runs locally on-device - no cloud round-trip.
        return repo.insert(title, dueDateTime, location)
    }
}

Do you even need App Intents or AppFunctions for agent access?

On Apple platforms, yes – App Intents is non-negotiable in 2026 because an app without it is invisible to Apple Intelligence. On Android and Windows, it is strategic rather than mandatory: agents can still reach you through MCP servers or computer-use fallbacks, but the declared models are faster, safer, and increasingly the only ones the platform assistants prefer.

Apple has effectively made App Intents a requirement by design. App Review now expects agentic behavior to route through declared intents, and Apple Intelligence cannot “see” capabilities you have not enumerated. If you ship an iOS app and want Siri or any system agent to act inside it, you declare App Intents or you are excluded. There is no third option that survives review.

On Android, you can technically expose your backend through a cloud MCP server today and have agents reach it that way – but you pay the round-trip latency and you give up the on-device privacy story. AppFunctions exists precisely to let agents act locally instead. Google’s framing is that AppFunctions are the on-device equivalent of MCP tools: same agent-orchestration mechanism, different architecture. Treat AppFunctions as a complement to your MCP server, not a substitute.

On Windows, the Windows Agent Framework is the most flexible: agents register with the OS, talk over a gRPC cross-agent bus, persist context through a Memory Service, and can bridge out to MCP servers when they need cloud tools. Because the runtime is MIT-licensed, you are not even required to use the store – you can ship a self-hosted agent on a Windows machine, a Windows 365 Cloud PC, or an Azure Arc edge device. The decision is less “do I need WAF” and more “which isolation tier and distribution path fits my agent.”

How do the security and isolation models compare across the three OSes?

All three OSes treat agents as untrusted by default, but they isolate them differently: Android leans on its dangerous-permission model plus mandatory confirmation for sensitive actions, Apple enforces a reviewed action space backed by Private Cloud Compute, and Windows offers a graduated containment spectrum from process isolation up to hardware-backed micro-VMs.

Windows is the most explicit about layered containment. The Microsoft Execution Containers (MXC) SDK is a policy-driven execution layer that abstracts isolation primitives: lightweight process isolation (already used by GitHub Copilot CLI) restricts a model-generated process’s file and network access to policy; session isolation runs agents under distinct local or Entra-backed identities to block UI spoofing and cross-session leakage; and a roadmap adds hardware-backed micro-VMs and WSL Linux containers for high-risk workloads. Governance flows through Agent 365 via Microsoft Entra and Intune, with Windows Defender providing real-time protection against prompt injection.

Apple’s isolation is the review contract itself. Because every agent action is an enumerated App Intent, the system can enforce that an agent never steps outside the declared schema, and reviewers inspect behavior before and after launch. Apple explicitly blocks on-device code generation and system-wide autonomous access, and sensitive AI processing that cannot stay on-device is routed to Private Cloud Compute rather than a general cloud.

Android’s model is permission-centric and user-visible. Discovering and invoking AppFunctions requires the `EXECUTE_APP_FUNCTIONS` permission, sensitive operations such as purchases demand explicit user confirmation, and the user can monitor progress through notifications or a live view and switch to manual control at any moment. It is less about VM-grade isolation and more about consent, transparency, and the runtime sandbox each Android app already lives in.

Which OS-level agent framework should I build for first? A decision tree

Build for the platform your buyer’s device runs, then map to execution and distribution needs: iPhone-first consumer app means App Intents first; Android consumer app betting on on-device privacy means AppFunctions; B2B desktop or enterprise agent with real monetization means the Windows Agent Framework. The framework is downstream of who your user is, not a standalone technology bet.

Walk it as a tree. First branch on the device. If your users are predominantly on iPhone, you have no real choice – declare App Intents now, because Apple Intelligence cannot reach you otherwise, and budget for App Review. If your users are on Android and you care about on-device latency and privacy, AppFunctions is the right model, but ship it as future-proofing while the preview matures on Galaxy S26 and waits for the Android 17 rollout; keep a cloud MCP server as your portable fallback. If your product is a desktop or enterprise agent – automation, productivity, vertical B2B – the Windows Agent Framework is the most attractive: MIT license, 85% revenue share, a gRPC cross-agent bus, and a containment spectrum that enterprise security teams will actually approve.

Second branch on cloud-agent need. If you are already MCP-native, Windows bridges to MCP cleanly and Apple is reportedly adding native MCP in iOS 19 / macOS 16, so your existing server investment carries over. Android deliberately does not chase cloud MCP for these flows – AppFunctions is on-device-first, so plan to maintain both an MCP server (for portability and cross-OS agents) and AppFunctions (for fast, private on-device action on Samsung hardware).

Third branch on monetization. If you are charging for the agent or gating a subscription behind it, the Windows Agent Store’s 85% share is the standout deal versus the mobile stores’ 15-30% commissions – but it only matters if your buyers are on Windows. Do not let revenue share alone pull you off the platform where your users actually are. The right sequence for most teams in 2026: App Intents for iOS reach, Windows Agent Framework for monetized B2B, AppFunctions as the on-device Android play you stage now and scale when Android 17 lands.

Builder’s take

I build agent infrastructure for a living – Cyntr orchestrates agents in production and Loomfeed runs an always-on platform agent – so I read these three frameworks as a developer choosing where to spend the next quarter, not as a press release. The honest answer is that you do not pick one religiously; you pick the one whose distribution and execution model matches your actual users. But the asymmetries are real and worth stating plainly.

• Apple App Intents is the highest-leverage, lowest-optionality bet: if your users are on iPhone, you already need App Intents for Apple Intelligence to see you at all, and there is no escape hatch – the App Store review gate is the price of admission and Apple still wants its commission on AI subscriptions.
• Android AppFunctions is the cleanest engineering story of the three – annotate a Kotlin function, get an OS-indexed on-device tool – but it is still a preview gated to Galaxy S26 / OneUI 8.5 with Gemini in private testing, so ship it for future-proofing, not for reach today.
• Windows Agent Framework is the only one you can fork. MIT license plus an 85% revenue share plus a gRPC cross-agent bus is a genuinely different deal than the mobile duopoly, and for B2B desktop agents it is the most builder-friendly economics in the market right now.
• If you are MCP-native already, Windows and (reportedly) Apple iOS 19 will meet you there; Android AppFunctions deliberately does not – it is on-device-first by design, so treat it as a complement to your cloud MCP server, not a replacement.
• Build for the device your buyer actually holds. A consumer iOS app and a Windows enterprise agent are different products with different stores, different review regimes, and different unit economics – the framework is downstream of that decision, not upstream of it.

Frequently asked questions

Primary sources

• Microsoft Just Launched the App Store for AI Agents – 85% Revenue Share, Native in Windows — FourWeekMBA
• Microsoft Build 2026: Windows becomes the platform for AI agents — Windows News
• Windows platform security for AI agents — Windows Developer Blog
• Overview of AppFunctions — Android Developers
• The Intelligent OS: Making AI agents more helpful for Android apps — Android Developers Blog
• App Intents — Apple Developer Documentation
• Apple App Store Agentic AI: What’s Allowed and What’s Not — Gadget Hacks
• What Is Apple’s WWDC AI Strategy? Siri, App Intents, and MCP Explained — MindStudio
• Microsoft Build 2026: Windows Agent Framework, WSL 3, Azure Agent Mesh, and Windows Agent Store Explained — AI Tools Recap

Last updated: June 2, 2026. Related: Agent Infrastructure.