Think about the last ten things you did that involved money or another person: paying a friend back, booking a cab, ordering dinner, approving a bank login, replying to your landlord on WhatsApp.
How many of them happened in a desktop browser? For most people, almost none. That matters right now, because agents are starting to do these things for us, and most of them are still being built for the browser.
What a16z means by B2A
Recently a16z published Welcome to the B2A Economy, by Olivia Moore and Justine Moore. B2A is business-to-agent.
The argument is simple: as agents move from answering questions to completing tasks, they start choosing which products to use and where to spend money on our behalf. Businesses that treat agents as real customers win. The ones that keep building walls to keep bots out may lose.
Two lines from the piece stood out to us.
The first: "Right now, most of this traffic is happening via browser." An agent takes over your browser, or spins up its own browser in a VM, and clicks around like a person would.
The second is about what's still missing. Under agent infrastructure, they write that they're already seeing "system strain at fairly low agent volume on payments, fraud and identity, and communication (iMessage, calls, email, etc.)."
The piece also includes a market map of agent infrastructure. One of its sections is called "Computer & Phone Use", and it splits into browser infra, phone use and computer use. Droidrun is listed in the phone use row.
We were glad to see phones get their own row. We'd go further, though. For a big part of the B2A economy, the phone isn't one row on the map. It's where the work actually happens.
Most real tasks live in apps
Here are the numbers.
Sensor Tower's State of Mobile 2026 says people spent 5.3 trillion hours in mobile apps in 2025. Its State of Web 2026 puts total time on websites, desktop and mobile combined, at 1.6 trillion hours. So apps got more than three times as much attention as the entire web.
Even the web itself is mobile first by visits. StatCounter shows phones at 60.87% of worldwide web traffic in October 2026. And that only counts web page views. Time inside apps isn't in that number at all.
Desktop still wins one thing: Sensor Tower found desktop holds over 70% of time spent on the web. That fits. Long reading, spreadsheets and coding happen on a laptop. That's also why coding agents took off first.
But the tasks a consumer agent would be asked to do look different:
- Ride-hailing and delivery: Uber, DoorDash, Swiggy, Grab. They were built for the phone first, and the app is the main way people use them.
- Banking and payments: many banks give you a web view, but approving a login or moving money often needs the app.
- Messaging: WhatsApp, Telegram and iMessage are phone first, and the number is the identity.
- Loyalty and app-only offers: prices and deals that only exist in the app for your account.
- Verification: OTPs arrive by SMS to a real number.
a16z makes the same point about past shifts: "Uber could not have existed without the mobile phone." A lot of the products agents will need to use are the ones that were born on the phone.
Why a browser agent hits a wall here
A browser agent is a good tool. If the task lives on a website, use one. The problem is what happens when the task doesn't.
There's often no web version. Some services ship a smaller web app, some ship only a marketing site. The real flow (the booking, the payout, the chat) is in the APK or the IPA.
There's often no API either, at least not one you can use. Public APIs cover a slice of what the app does, if they exist at all. Then there's the verification step. A sign-in sends a code to a phone number. Plenty of apps reject virtual numbers, so a script with an SMS API never even gets the code. We cover this in detail in our post on why OTP breaks automation.
And device trust is another thing, apps check what they're running on. An emulator, a rooted image or a datacenter IP can be enough to get a flow blocked or an account flagged. A real device with a consistent identity behaves like a normal user's phone, because it is one.
That's the "fraud and identity" and "communication" strain a16z describes, seen from the phone side. An agent that wants to act for a person in the real world needs a phone, a number and an identity that apps accept.
How Droidrun approaches it
Droidrun is the company behind Mobilerun. It started with an open-source agent framework that lets an LLM drive a phone, and that framework now ships as Mobilerun on GitHub under the MIT license, with around 10,000 stars.
A few choices shaped it:
- It reads the accessibility tree. The Portal app on the device exposes the UI as structured elements (buttons, text fields, labels), so the agent knows what's on screen without guessing from pixels. Screenshots are added when a screen needs them, and there's a vision-only mode for apps with a poor tree.
- It's LLM-agnostic. You can bring OpenAI, Anthropic, Gemini, xAI, DeepSeek, Ollama or any OpenAI-compatible model.
- It runs where you run. Android over adb or the Portal app, iPhones over USB with mobilerun-ios, plus emulators and the iOS Simulator for testing.
How Mobilerun provides it
Running one phone on your desk is easy. Running fifty for agents in production is a different job: devices, numbers, proxies, logs, retries. That's what Mobilerun is for. It's the infrastructure layer between your agent and the phones.
What you get with Mobilerun:
- Devices: Cloud Android phones, dedicated physical iPhones in a Mobilerun data center, or your own Android or iPhone connected to the cloud. You can claim one free personal phone slot as well.
- Plain-language tasks: you send a goal, the hosted agent does the taps, and you get the result back. No model key needed, since LLM usage comes from your credits.
- Structured output: pass an outputSchema and the result comes back as JSON you can store.
- Numbers and inboxes: phone numbers whose inbound SMS you can read over the API, and mailboxes with an endpoint that returns the latest OTP.
- Webhooks: task.run.completed, sms.received, mailbox.message.received and more, so your backend reacts instead of polling.
- Deterministic replay: record a run once, then replay it with mobilerun macro replay. Add --on-mismatch agent and the agent takes over only when the screen no longer matches the recording.
The honest limits
Mobile agents are slower than API calls. Every screen has to load and every step costs model tokens. If a service offers a good API or MCP connector, use that. The a16z piece is right that connectors are growing fast, and we'd rather your agent use one than tap through screens for no reason.
Cloud Android phones are virtual devices. When a flow needs real hardware (eSIM, camera, payments), use a dedicated iPhone or connect a physical phone you own.
And none of this makes it fine to break an app's terms or run fake accounts. Automate accounts you own and actions you'd stand behind.
The takeaway
The B2A economy will be decided where people actually spend their time, and that's in apps on a phone. Browsers gave agents the web. MobileRun gives them the phone. Spin up your first device at cloud.mobilerun.ai.
