The AI Assistant Paradox: Apple Can Build the Platform, but Can It Convince Developers?

The Promise of a Personal AI Agent

Imagine waking up tomorrow and asking your personal AI assistant:

Find the cheapest suitable flight to London next week, book it, arrange airport parking, and make sure it doesn't conflict with anything on my calendar.

You don't open an airline website. You don't compare dozens of flights. You don't navigate through checkout screens or enter payment details.

Your assistant simply gets things done.

This is the future that personal AI agents are promising us. A world in which computers stop being collections of applications we operate manually and become intelligent systems that perform tasks on our behalf.

But there's a fundamental architectural problem hiding underneath this vision.

How does an AI assistant actually get permission to do things in the digital world?

Two competing approaches are emerging, each with different advantages and serious limitations.

On one side are operating system platforms like Apple's Siri and Google's Gemini, deeply integrated into devices with established security and permission models.

On the other are independent AI agents that operate across applications, websites and services, often using the same interfaces humans use.

Both want to become your personal assistant.

Neither has completely solved the problem.

The Operating System Advantage

Apple and Google have something independent AI companies cannot easily replicate: control over the operating system.

Consider what this means.

Your smartphone already knows how to authenticate you. It can use biometrics, manage passwords, securely store cryptographic keys and enforce permissions between applications.

Apple's Secure Enclave, Keychain and Apple Pay infrastructure provide established mechanisms for handling sensitive information and authorising transactions.

When making an Apple Pay purchase, for example, payment authorisation involves the Secure Element and Secure Enclave, with biometric or passcode authentication used to establish the user's approval.

Apple also has Private Cloud Compute, an architecture designed to process more demanding AI requests in the cloud while limiting exposure of personal information.

This doesn't mean everything Siri does happens on-device. It means Apple can combine device-level security, local processing and protected cloud computation within a coordinated architecture.

Google has comparable advantages through Android's security architecture, credential management and privileged integration with Gemini.

Now imagine an AI assistant using these capabilities to complete a bank transfer, access a medical record or purchase an expensive international flight.

Rather than giving an external agent unrestricted access to your accounts, the operating system could coordinate a workflow in which applications execute authorised operations and the user approves sensitive actions through trusted interfaces.

This is an attractive architecture.

In fact, for high-risk activities, I would argue it is preferable to allowing a general-purpose AI agent to operate with broad credentials.

But there is a catch.

The operating system cannot simply assume that every application will expose everything the assistant needs.

And this is where the real challenge begins.

The Problem Nobody Wants on Their Product Roadmap

I've spent years working in software engineering, and one pattern has remained remarkably consistent.

Product teams prioritise features that deliver measurable business value.

Revenue. Conversion. Retention. Customer engagement. Regulatory compliance. Competitive differentiation.

Every engineering investment competes with something else.

Now imagine an iOS engineer proposing a new initiative:

We should expose our application's core business operations through Apple's App Intents framework so Siri can execute them.

Technically, this might be an excellent idea.

But what happens when the product manager asks:

• How many customers are requesting this?
• Will it increase revenue?
• What happens to our conversion rate?
• Can we measure the return on investment?

Those questions are entirely reasonable.

And today, the answers are often uncertain.

Apple's App Intents framework enables developers to expose structured actions and application data to Siri, Spotlight, Shortcuts and Apple Intelligence.

Google is pursuing a related approach through Android AppFunctions, allowing applications to expose capabilities to AI assistants using an on-device architecture.

These are interesting engineering solutions.

But the technical availability of an API does not automatically create a business incentive to adopt it.

Supporting such integrations requires engineering work. Developers must model application actions, define parameters and entities, handle authentication, manage errors, test workflows and maintain compatibility as applications evolve.

For particularly sensitive operations, there are additional security and regulatory considerations.

And crucially, the work doesn't end when the integration first ships.

Every significant change to an application's business logic may require its AI-facing interfaces to be reconsidered.

This is a continuing maintenance commitment.

For a product team already struggling with competing priorities, it's easy to imagine where such an initiative lands.

Somewhere below the features customers can actually see.

The Incentive Problem Is Bigger Than Engineering Cost

There's another reason companies might hesitate.

Many digital businesses have spent years optimising their customer journeys.

They invest in onboarding experiences, recommendations, personalised promotions, cross-selling, subscriptions and loyalty programmes.

What happens when an AI assistant becomes the primary interface between the customer and the business?

Imagine asking an assistant to order groceries.

It finds the products, compares prices and completes the transaction without opening the retailer's application.

Wonderful for the customer.

But what happens to the retailer's carefully designed shopping experience?

Its recommendations?

Its opportunities to promote higher-margin products?

Its ability to build a direct relationship with the customer?

An assistant that optimises for the user's interests may not optimise for the business's interests.

This creates an economic conflict.

The company benefits from being accessible to customers, but it may lose control over how those customers interact with its services.

Not every company will resist this transition. Some will see it as a new distribution channel.

But assuming that every major digital business will willingly surrender control of its customer interface seems optimistic.

The problem for Apple and Google is not simply making AI integration possible. It's making AI integration worth prioritising.

Independent Agents Have a Different Strategy

This is where independent AI agents become particularly interesting.

Consider systems such as OpenClaw, or broader computer-use agents capable of interacting with websites and applications.

They don't always need a business to provide a special AI integration.

They can use browser automation, screenshots, mouse clicks, keyboard input and, where available, APIs or authorised connectors.

Instead of requiring a developer to expose a bookFlight() function, an agent can attempt to navigate the airline's existing booking interface.

Instead of waiting for a retailer to implement an AI-specific checkout API, an agent can interact with the checkout flow designed for human customers.

This is a profound difference.

A structured API requires cooperation from the application developer.

Computer use can sometimes operate without that cooperation.

And that gives independent agents a potentially enormous advantage in reaching the existing digital world.

They can work with services that were never designed for AI.

Of course, this flexibility comes at a cost.

The Security Problem We Cannot Ignore

Imagine giving your independent AI agent access to your bank account.

You want it to transfer £10,000 between two accounts.

How does it authenticate?

Perhaps it uses a browser session where you're already logged in. Perhaps it has access to an OAuth token. Perhaps a remote service manages the connection.

These mechanisms have very different security properties.

A self-hosted agent operating inside an isolated local browser is not equivalent to a cloud agent retaining reusable session credentials.

But both raise questions that become increasingly important as we grant agents more authority.

• Who controls the credentials?
• What can the agent access?
• Can its permissions be limited to one operation?
• What happens if malicious instructions appear inside a webpage, email or document the agent reads?
• Who is responsible if the agent performs the wrong transaction?

Prompt injection is particularly concerning.

An AI agent processes information from sources it does not necessarily trust. A malicious webpage might contain instructions designed to manipulate the agent into revealing information or performing an unintended action.

These are not merely hypothetical security categories. OWASP has documented agentic AI exploitation patterns, including tool misuse, excessive agency and sensitive-information disclosure.

Now consider three situations.

Banking: An assistant interprets an instruction incorrectly and transfers money to the wrong recipient.

Healthcare: An assistant accesses sensitive medical records or incorrectly modifies an important appointment.

Travel: An assistant purchases non-refundable international tickets using the wrong passenger details.

In each case, the problem is not necessarily malicious behaviour.

The agent might simply make a mistake.

And unlike generating an incorrect answer in a chat conversation, some mistakes have irreversible consequences.

This is where the distinction between authentication and authorisation becomes essential.

Proving that an agent is acting for a particular user is not the same as proving that the user authorised a particular action.

An agent might legitimately have access to a bank account while having no authority to transfer £10,000 to an unfamiliar recipient.

An authenticated agent is not necessarily an authorised agent.

For high-risk operations, we need narrowly scoped permissions, transaction-specific approvals, strong auditing and the ability to revoke delegated authority.

And ideally, the AI model itself should never need access to reusable passwords or raw payment credentials.

The Missing Layer: Delegated Trust

The encouraging news is that the technology industry is beginning to address this problem.

The Model Context Protocol's authorisation specification builds on OAuth-based mechanisms for connecting agents to protected services.

Meanwhile, payment companies are developing approaches specifically designed for agentic transactions.

Stripe has introduced Shared Payment Tokens, allowing agents to initiate approved payments without exposing underlying payment credentials.

Visa's Trusted Agent Protocol explores ways for merchants to recognise legitimate agents.

In October 2026, Visa, BILL and Billtrust announced a live pilot in which authorised agents execute previously approved business invoice payments using tokenised credentials rather than shared supplier-portal logins.

This is important because it points towards a future in which an agent does not need to possess unrestricted access to a user's accounts.

Instead, the user could grant it something much more specific:

Purchase these tickets for these passengers, with a maximum budget of £800, and ask for my approval before completing payment.

The agent would have permission to perform a defined operation, within a defined boundary.

But these mechanisms are still developing, and a payment-specific permission cannot automatically solve every kind of agent interaction.

Healthcare, banking, government services and travel each have different requirements.

A universally trusted authorisation layer remains an unsolved ecosystem problem.

The Strongest Counterargument: What if the OS Doesn't Need APIs?

So far, the argument appears to favour independent agents in capability and operating systems in security.

But there's an important development that could change the balance.

Google is already exploring precisely the approach that makes independent agents attractive.

In February 2026, Google described Android's intelligent UI automation, designed to let Gemini perform tasks in selected applications without developers having to implement new integrations.

That matters enormously.

If an operating system assistant can operate existing applications through their interfaces, it no longer depends entirely on product teams implementing dedicated AI APIs.

Google is effectively pursuing two paths: structured application functions when developers provide them, and interface automation when they don't.

This directly challenges my argument about developer adoption.

But it also introduces a new tension.

Structured integrations make it easier to define what an assistant is allowed to do and how the application should execute an action.

Interface automation is more flexible, but potentially more fragile. It must interpret visual state, handle changing interfaces and avoid unintended actions.

And even if the operating system manages the automation, the underlying AI still faces risks involving untrusted content and ambiguous instructions.

Operating system ownership can strengthen security boundaries. It does not magically eliminate the security challenges of computer-use agents.

This suggests that the eventual solution may combine both approaches rather than choosing one.

What Happens Over the Next Ten Years?

I suspect the industry will move through several overlapping stages.

Initially, independent agents will continue attracting attention because of their flexibility.

They can connect existing tools, automate browsers and work across services without waiting for every application developer to cooperate.

Operating system assistants will enjoy strong security and integration advantages but may struggle to offer equivalent breadth of functionality.

Over time, Apple and Google could expand their computer-use capabilities, reducing their dependence on dedicated integrations.

At the same time, independent agents may gain access to increasingly sophisticated delegated authorisation and payment infrastructures.

The distinction between the two approaches could become less obvious.

And businesses will face a changing economic calculation.

If significant numbers of customers begin using AI assistants as their primary interface, supporting agent interactions becomes a distribution problem rather than an optional engineering improvement.

Product managers may start asking a very different question:

How much business are we losing because AI assistants cannot use our service?

That could change everything.

But it requires a shift in customer behaviour large enough to make the investment commercially measurable.

Until then, I remain sceptical that most product teams will voluntarily prioritise extensive assistant integrations.

Not because product managers are failing to recognise innovation, but because they are responding rationally to the incentives in front of them.

Who Actually Wins?

My initial instinct is that operating system vendors have a structural advantage.

They control devices, identity infrastructure, application permissions and many of the mechanisms through which sensitive actions are authorised.

For activities involving personal data, money or legal consequences, these are substantial advantages.

But the more I examine the problem, the less convinced I am that controlling the operating system is sufficient.

An assistant that cannot interact with the services people actually use will struggle to fulfil its promise, however secure its architecture might be.

Independent agents have the opposite problem.

They can potentially reach much more of the digital world, but broad access without sufficiently constrained authority creates serious risks.

So perhaps the eventual winner won't be determined by who builds the smartest model, the most secure operating system or the most impressive browser automation.

It will be whoever makes universal access and verifiable trust work together.

That might be Apple. It might be Google. It might be an independent agent platform built on open protocols.

Or perhaps the future will consist of independent intelligence operating through security and identity infrastructure provided by the platforms.

There is one conclusion I keep returning to.

The next decade of personal computing may be defined less by what AI agents can understand and more by what they're allowed to do.

And the companies deciding what they're allowed to do won't necessarily be the AI companies.

They may be the product teams who have yet to find a reason to put AI integration on their roadmaps.