Most of the AI agents can't use mobile apps because most agents work through APIs and browsers, and a lot of services only exist as a mobile app with no public API and no usable website. The agent can reason about the task just fine, it simply has no phone to run the app on. Giving the agent a real phone it can control through an API closes that gap.
Why the problem exists
Agent tooling grew up around the web. Function calling, browser automation and headless Chrome are all good at websites and APIs, so that is where agents ended up living. Your digital life is not organized that way. Plenty of services are mobile first, and some are mobile only, or at least the mobile app is the only place where the full feature set works.
A few examples of where agents get stuck:
- A ride or food delivery service whose account, orders and support chat live in the app, while the website is a thin marketing page.
- A bank or payment app that asks you to approve a login or a transfer inside the app itself.
- A messenger such as WhatsApp. Its official API is built for businesses, not for a personal account, so an agent that should handle a normal chat has no sanctioned way in through a browser.
- Internal company apps that were only ever built for Android or iOS, for field staff for example.
- Your own app, if you want an agent to click through it the way a customer would.
When a browser agent hits one of these, it stops, or it asks the user to do the step by hand. The world did not agree to put everything into a browser, and honestly that is the whole problem in one sentence.
What you can do today
Before you reach for a phone, check the cheaper options. They are often enough.
Use the official API. If the service has one and it covers what you need, use it. It is faster, cheaper and more stable than driving a UI. This is the right answer more often than people admit.
Use the website. Some services have a perfectly usable web version. A browser agent handles it, and you avoid the mobile layer completely.
Use a cloud simulator or emulator. If your goal is testing or previewing an app you build yourself, simulators and emulators in the cloud are a reasonable choice. Limrun, for example, describes itself as running "cloud iOS simulators, Android emulators, remote Xcode builds, and build sandboxes" for agents and developers, and its own page lists physical-device-only testing as not a fit (limrun.com/llms.txt). For build and test work that is a sensible setup.
Run an Android emulator or a spare phone yourself. You can wire up ADB, point an agent at it and see how far you get. It works for a prototype. It gets tedious once you need more than one device, someone to keep them running, and a clean state for every task.
Write a UI automation script. Fixed tapping scripts work until the app changes a button. They do not adapt, and they do not reason about what is on the screen.
How Matix and Mobilerun approach it
Matix is a mobile runtime for AI agents: isolated, stateful real phones your agents control via API. If you know E2B for code, the framing is similar. E2B for code, Matix for mobile. The agent gets a device instead of a sandbox, and it can open the app, read the screen and act in it.
Mobilerun is the open source framework on top of that runtime. You install it with pip install mobilerun, and it is the layer where you describe what the agent should do on the device. Matix provides the phones, Mobilerun is how your agent talks to them. Real iOS and Android devices both exist on the platform.
What this changes in practice: an app-only service stops being a dead end. The agent logs into the app like a person would, taps through the flow and returns the result to your code.
When Matix is not a fit
- The service has a good API. Use the API. A phone adds cost and moving parts you do not need.
- A website does the job. A browser agent is simpler and cheaper.
- You only test your own app in development. A simulator or emulator may be all you need, and it is usually the cheaper option.
- Strict latency requirements. Driving a UI through a model is slower than an API call. If you need answers in milliseconds, this is the wrong tool.
You are also responsible for using the apps within their terms of service and within the law. A device does not change what you are allowed to do.
Frequently Asked Questions
Is this just a browser agent on a smaller screen?
No. The agent works with the native app on a real phone, including things a browser never sees, like push notifications, app permissions and in-app flows.
Do I need Matix if I only build agents for websites?
Probably not. Browsers and APIs stay the right tool for web work. A mobile layer is for the part of the job that lives in apps.
What is the difference to a simulator or emulator?
A simulator or emulator imitates a phone in software. Matix uses real phones. Which one fits depends on the job: testing your own app often works fine on a simulator, while acting inside third party apps may behave differently on real hardware.
more from
the blog
Is it safe to let an AI agent control a phone?
Is it safe to let an AI agent control your phone? Explore mobile automation risks, prompt injection, device isolation and ways to give AI agents a safer environment.
How do AI agents stay logged in between runs?
Learn why AI agents need persistent environments to stay logged in, how session state works across browsers and mobile apps, and how persistent devices enable reliable mobile automation.
Why Mobile Is the Hardest and Most Valuable Environment for Computer-Use Agents
Mobile environment is becoming an important part for computer-use agents as the agents stuck and get blocked by anti-bot detection system. Here's more in this blog.