DEV Community: Shrey Mittal

If OpenClaw is the brain, Mobilerun is the hands

Shrey Mittal — Wed, 02 Sep 2026 09:03:00 +0000

OpenClaw and Mobilerun get compared a lot, usually by people trying to figure out which one to pick. Wrong question! They don't really compete. They live at different layers of the stack, and they're actually better together.

OpenClaw is the brain, a self-hosted agent that reasons, routes tools, and talks to you through your messaging apps. Mobilerun is the hands, the layer that drives a real Android or iOS phone, tapping and swiping through actual apps. One decides what to do, while the other physically does it, acting in tandem. This post breaks down what each one is, where they differ, and how they click together over MCP.

What is OpenClaw?

OpenClaw is the brain (yes, this isn’t the first or last time we will use this analogy). It started as one of Peter Steinberger's side projects and blew up into one of the fastest-growing open-source AI projects around, helped a little by its lobster mascot and ragebaity Moltbook posts. It's a self-hosted AI agent, meaning you run it yourself and point it at whatever model you want.

From there it does the thinking. It reads what you're asking for, works out the steps, picks the right tools for the job, and talks back to you right inside the messaging apps you already use. It’s honed for reasoning and routing, but there's a ceiling. On its own, OpenClaw can't reach into a real phone app and actually press the buttons or swipe right on a tinder profile. It's a brain with no hands (cue Mobilerun).

What is Mobilerun?

If OpenClaw is the brain, Mobilerun is the hands (told you it wasn’t the last time). Mobilerun is an open-source mobile automation framework that lets an AI agent control a real Android or iOS device. Not a simulator, not screenshots, an actual phone. You give it a natural-language instruction, like control Android with AI, and it taps, swipes, types, and scrolls through the same apps a person uses. No API required, which means you can automate any app with no API, even ones that never exposed a backend.

It's real device automation, and it's the piece most agents are missing. Plenty of them can reason about what to do on a phone. Mobilerun is the on-device layer that physically does it, and it exposes that over MCP so a brain like OpenClaw can drive it.

The Key Difference(s)

OpenClaw is what decides what to do, Mobilerun is the execution layer for OpenClaw (or any other AI agent such as Codex) itself. OpenClaw lives on a server and reaches you through messaging apps, Mobilerun reaches into real mobile apps and drives them for OpenClaw.

Mobilerun also isn't limited to a single phone: it runs across many devices at once, real or virtual, spinning up new ones and operating them in parallel, whereas OpenClaw on its own only has access to whatever machine it was installed on.

On their own: OpenClaw can think but can't touch a phone, but Mobilerun can operate phones but needs a brain telling it what matters. Basically, neither is the full picture alone, and for phone automations, they both need each other.

Info Alert: We're actually building something that cuts out the middleman entirely. mobilerun's new Virtual Assistant beta lets you point at one phone or a whole fleet and just tell them what to do, in plain English. No need to set up OpenClaw, no wiring up a separate brain, no glue code. Just talk, and the phones move. It's in beta, but it's live, and you can try it right now on cloud.mobilerun.ai

How they work together over MCP

So how does the brain actually signal the hands? It happens over MCP, the Model Context Protocol. MCP is the universal adapter ("nerve endings" in our analogy) that lets an AI agent chat with outside tools without any custom-coded integrations.

Mobilerun plugs in as a standard tool, so when OpenClaw acts as the brain, it sees mobilerun sitting there as an available pair of hands, without a single extra line of code or config. OpenClaw processes the logic, realizes it needs to touch a real phone, and passes that step to mobilerun to execute and report back. It’s a seamless loop of thinking and doing, while running on an open and widely adopted standard. That interoperability matters: because mobilerun is MCP-native, any agent speaking the protocol can pick up these hands and drive a device.

My own favourite has been Claude Code with Opus 5, which has given me the highest task completion rate so far, with the infamous Fable 5 not being too far behind.

When to use what

So which one do you actually need? If you want a brain, something that reasons, holds a conversation, and orchestrates tools, OpenClaw is a great pick. If you need to actually get things done inside real mobile apps, tapping, swiping, filling forms on an actual device, that's Mobilerun.

But the real answer is you don't have to choose. Point OpenClaw at mobilerun over MCP and you get both, an agent that thinks and a set of hands that acts. And if you'd rather skip the setup entirely, that virtual-assistant beta we mentioned is coming, just open a page and tell it what to do. OpenClaw and Mobilerun were never really rivals. One's the brain, one's the hands, and together they're the whole automation body.

What is an AI Agent Phone?

Shrey Mittal — Fri, 28 Aug 2026 09:34:00 +0000

An AI agent phone is a real, or cloud-hosted, smartphone that an LLM-powered agent can operate on its own. It sees the screen, taps, swipes, types, opens apps, and completes multi-step tasks the same way a person would. Instead of calling an API, the agent uses the phone directly, the same Instagram, banking, or delivery app you'd use, driven by a model instead of a thumb.

The phrase gets used two ways in 2026. Some products sell phone numbers for AI agents, voice and SMS. That's not this. Here, an AI agent phone means the device itself as something an agent controls, a full Android or iOS handset that becomes an autonomous actor. If you've heard the pitch give your AI agent a phone, this is it.

Why a phone, not a browser?

Most agent tooling lives in the browser, or in desktop computer use. That misses where people actually are. The world is mobile-first, and a huge share of real workflows are app-only, ride-hailing, food delivery, mobile banking, two-factor prompts, creator tools, regional super-apps.

A browser agent can't install an APK, respond to a push notification, read an SMS one-time code, use the camera, or drive a native app that never ships a web build. A phone can. And there's a second reason: fidelity. When an agent operates the same app a customer uses, you're automating the real thing, not a mock, not some undocumented internal endpoint that breaks next release.

How it works

A mobile AI agent runs a perception-decision-action (PDA) loop against the device.

The agent builds its understanding from two sources. First, the accessibility tree, the structured hierarchy of on-screen elements the OS exposes for screen readers, which gives precise, machine-readable targets. Second, vision, a screenshot passed to a multimodal model for anything the tree misses, canvas UIs, games, custom widgets. Together, the tree gives coordinates and vision gives context.

The agent gets a goal in natural language, reasons about the current screen, picks the next action, and emits a concrete command, tap, type, swipe, back, launch. A controller executes it, the screen changes, and the loop repeats until the task is done or it gets stuck. Same pattern as browser computer-use, just grounded in mobile primitives.

Local vs cloud phones

You can run an AI agent phone two ways:

A real device, or an emulator, on your own hardware. Full control, your own SIM, your network, nothing leaves your setup. Great for development, sensitive workflows, and anything where you need the physical device. The cost is you're managing hardware.
Cloud devices hosted for you, spun up on demand, real or virtual, often with residential networking and configurable device profiles. No hardware to babysit, and you scale to many phones in parallel. The tradeoff is it's not as stealth-friendly as genuine hardware right now, if you're doing detection-sensitive work, that's worth weighing. Most teams start local to prototype, then move to cloud when they need scale or always-on runs.

Use cases

Some of the most common use cases that we see people using mobilerun for are:

QA and regression testing: Point an agent at your app and have it run real user flows across many devices, catching what breaks before customers do.
Automating app-only workflows: Anything with no public API, ride-hailing, delivery, regional super-apps, banking. The agent drives the real app, so you're not reverse-engineering endpoints that break every release.
Data collection at scale: Pull what you can only see inside a native app, many phones in parallel, real sessions.
Personal and back-office automation: The repetitive taps, filling forms, checking statuses, moving data between apps that never talk to each other.

Where it stands today (honest limits)

Its not magic, and agents still get stuck on unfamiliar screens, misread ambiguous layouts, or stall on captchas and hard login walls. Long multi-step tasks can drift.
Its important to understand that latency is real. The see-think-act loop takes time, so agent phones are slower than a hardcoded script, you're trading raw speed for flexibility and no maintenance.
Some apps actively look for automation, so environment choice matters. For the full breakdown of when to use a real device versus a virtual one, see our emulators versus real devices piece, it goes deep on exactly this tradeoff.

And it's moving fast. Models get better at this every few months, so today's limits are a snapshot, not a ceiling.

Getting started

The fastest way to see it is to try it. Spin up a phone, give an agent a goal in plain language, and watch it work.

mobilerun is an open-source framework for exactly this, natural-language control of Android and iOS, real or virtual devices, many in parallel. Install it with uv tool install mobilerun, or if you'd rather not touch infrastructure at all, the hosted beta lets you just chat with an agent and watch the phones move. Same platform, local or cloud, whichever fits. As mentioned previously, we go deep on that in our emulators versus real devices piece.

Choosing between Emulators vs Real Devices

Shrey Mittal — Mon, 24 Aug 2026 08:24:47 +0000

The very first decision you have to make when setting up a mobile AI agent (an AI agent that taps, scrolls, and reasons through Android or iOS apps) is whether to use an emulator or a real device. That choice decides how fast your agents gets flagged as bots, whether biometric and sensor flows work at all, and what your bill looks like at the end of the month. Let’s explore how you can best make that choice for your own use case, through a technical breakdown of detection, app compatibility, sensors, iOS, cost, and scale.

Where real devices make most sense

Hardware Stealth

On Android, Google's Play Integrity API became the primary attestation standard in early 2025, and it issues a device verdict. A genuine, Play Protect-certified phone earns the strong verdict, MEETS_DEVICE_INTEGRITY. An emulator, at best, gets the weaker MEETS_VIRTUAL_INTEGRITY, and some apps simply refuse to run without the strong one. iOS has its own version of this through App Attest and DeviceCheck. Banking, streaming, and social apps routinely sniff out emulator fingerprints and block them.

Some examples of apps that need a physical device include Reddit, Hinge and the UBS Access app.

Sensor Hardware

Emulators are virtual, and hence by nature don’t have any sensors, and instead have to input fake data. That typically isn’t an issue, but does block certain workflows where real sensor input is mandatory, such as any biometric prompt and camera workflow.

Virtual phones are slowly getting better at handling sensors. For example, Mobilerun’s cloud phones now come with GPS, which does a good job simulating your device’s physical location to be around the same area as your IP proxy. But for many other sensors, there is no other choice than to use a real phone.

The case for emulators

The biggest advantage for using emulators is the ease and low cost of setup and maintenance that comes with virtual devices, something that remains impossible to do with real phone hardware, not to mention the speed and performance gain.

Take iOS for example. Automating a real iPhone means going through Appium's XCUITest driver, which means building WebDriverAgent, dealing with Xcode signing, enabling Developer Mode on every device, and all of this before running a single task, without any guarantee that your device isn’t going to get insta-flagged. A simulator skips nearly all of it and boots in seconds, and even if it gets flagged, can quickly be reset and retried with.

Having instant access and low costs also makes emulators the best way to scale operations, with acquiring a new virtual phone is as simple as clicking a button in a portal. So, unless your workflows have very specific stealth or sensor requirements, cloud phones are the most scalable and hassle-free way to go.

So which should your agent(s) use?

Reach for emulators when you're doing scripted QA, CI regression, layout validation, or fast iteration. Reach for emulators when cost and parallelism matter most and stealth isn’t priority #1. Go with real devices when the target app detects and blocks emulators, when the flow needs access to real biometrics, sensors, or networking, or when the task needs to look like a genuine user as much as possible. Automating a consumer app you don't control? Assume it has anti-emulator defenses, and plan for real hardware, but if a one-time detection isn’t an issue, then try cloud phones first.

For most teams building real mobile automation, the real answer is both. Emulators upstream for speed, cost and flexibility, while real devices for the flows that demand authenticity. The boring answer is that most teams use both, picking devices based on the needs of each specific workflow.

Intent beats Scripts: Mobile AI Agents vs RPA

Shrey Mittal — Thu, 13 Aug 2026 08:45:54 +0000

Automation has traditionally meant record and replay. That built an entire industry, and a maintenance treadmill to go with it. RPA, robotic process automation, is software bots that mimic human clicks and keystrokes to run repetitive tasks. Record the steps once, replay them forever. It works, right up until the screen changes. Mobile AI agents offer a different deal: describe the outcome you want, and let the system figure out the steps. So which one is better for you?

How RPA works, and why its not ideal

RPA is how teams used to automate tasks since computers became widespread inside offices. The idea was to identify repeat workflows which always followed the exact same path, show the software the steps once where it captures the exact buttons and fields you touched, and then it repeats them. Tools like UiPath, Automation Anywhere, and Blue Prism built the category, and on mobile you'll see the same idea in things like Tasker or Appium.

Under the hood, it's hardcoded. The bot remembers precise targets, this button at this spot, that field with that name, and follows a fixed path someone drew in advance. At runtime it isn't really thinking, instead string searching for elements and hoping its still where thy were expected? If yes, it proceeds. If no (which it often does), it breaks and throws errors.

The breaking isn’t something you can really control. Most RPA workflows break and become invalid because of app updates, A/B tests or permission dialogues because some compliance process now requires them. So, unless your team gets early access to future updates, you cannot prevent process breakage, and can only optimize for how fast you fix them.

How AI agents differ

Instead of recording steps, you give it a goal in plain language. Book me the cheapest ride home. From there it runs a loop: it perceives what's actually on screen, reasons about the best next action, acts, then looks again and re-plans.

That last part is everything. Because it reads the live screen every time, it adapts. A button moved? It finds it. A new popup appeared? It deals with it. The intent survives even when the interface changes, and that's the one thing a recorded script can never do. It self-heals instead of breaking. God bless all that HTML and JavaScript training data on the internet.

It's not free, though. All that reasoning means it's slower and costs more per action, because there's a model thinking at each step. And it's less predictable, which makes it harder to audit than a fixed script. Different tool, different trade-offs.

Where RPA still wins

To be fair, RPA earns its keep in the right conditions. It's deterministic, the same steps run the exact same way every single time, which is exactly what you want for something genuinely 100% repetitive and static. It's auditable, every action is explicit and logged, which matters a lot in regulated industries where you have to prove what happened.

Furthermore, on a stable screen that doesn't change, it's fast and cheap, because there's no AI thinking in the loop, just straight execution (no tokens burnt). So if you've got a high-volume, repetitive task running on an interface you fully control, RPA is still the gold standard.

Some time should be taken to stress that RPA isn’t a bad way to automate processes, but it is a brittle one. It is shines in the flows which need to be deterministic and you have full control over. This is why, for best results, it actually makes sense to use but AI agents and RPA together, which brings us to our next section :)

Hybrids (Where true automation winners play)

The smartest setups mix both. It takes a bit more time and though to set up, but offers best of both worlds. The best automation engineers let the agent handle the messy parts, navigation, ambiguity, recovering when something unexpected shows up, then hand off to a deterministic script for the steps that must run identically or cheaply every time.

Models have gotten so good over the last couple of years that you can even flip this logic. As in, let an agent watch your RPA bots and auto-repair the selectors when they break, so a layout change becomes a shrug instead of a support ticket. There are many ways of making these mixed pipelines fit your use case. Just like how the world isnt completely solid or liquid, neither are the best automation scripts.

So, which one should you use?

Using RPA still makes the most sense when the environment it works in is fully controlled and needs strong auditing. But processes uncertainty and chaos where flexibility is needed are where embracing AI agents serve as the trillion dollar value lever. But as most things in life, the truth lies somewhere in the middle, which is why understanding and using each, and combining them together delivers the best results.

As AI gets better (and cheaper) with time, the need for RPA will likely diminish further, but there will still be niches where it is necessary. Regardless, the best automation teams will still continue to use both, and adapt as the tools improve.