DEV Community: Priya Negi

The B2A economy runs on phones: a16z

Priya Negi — Thu, 12 Nov 2026 09:43:28 +0000

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.

How to Get Clients on LinkedIn Using mobilerun AI

Priya Negi — Wed, 11 Nov 2026 11:08:52 +0000

Most B2B founders eventually turn to LinkedIn for outbound.

And for good reason.

LinkedIn is one of the few places where your prospects have already told you who they are: their job title, company, industry, location, career history, and often what they are currently working on. That makes targeting unusually precise.

Instead of buying a list and hoping the data is accurate, you can search for exactly the people you want to reach:

Head of Mobile Engineering at companies with 200–1,000 employees, working in fintech, based in India, who recently changed jobs.

You can then open the results and immediately see whether those people actually fit your ICP. The problem isn't finding the right people. It's doing the same outreach work every day.

Search. Open profiles. Read them. Write messages. Send connection requests. Check who accepted. Follow up. Track conversations. Repeat. The strategy is very simple but the execution isn't. That's where AI agents become interesting.

Execution is the real bottleneck

If you already do LinkedIn outreach, you know the loop. Run a search. Open a profile. Read it. Write something that proves you read it. Send the request. Log it in a sheet. Check back in three days to see who accepted. Message the ones who did. Log that too. Repeat tomorrow.

None of that is hard. All of it is repetitive, and it has to happen every single day, forever, or the pipeline dries up. This is why teams hire five SDRs to do the same thing in parallel, and why most solo founders quit LinkedIn outreach after three weeks.

The work is not intellectually demanding. It is just work that requires a human sitting in front of the app. Which is exactly the shape of the problem an agent should be solving.

What changes when the agent uses the actual LinkedIn app?

There are plenty of tools that interact with LinkedIn through browser extensions, APIs, databases, or scraping infrastructure. mobilerun takes a different approach.

The agent operates a real Android device and interacts with the LinkedIn mobile app through the device itself. That means you can give it instructions in the same way you would brief a person doing prospecting.

Setting it up takes about five minutes:

Connect a device. Either plug in a phone you already own, or spin up a fresh device in mobilerun Cloud if you would rather keep this off your personal hardware.
Install LinkedIn on that device and log in to the account you want to run outreach from.
Tell the agent what to do, in plain English. That is the whole configuration step. There is no campaign builder, no field mapping, no CSV import.

The workflow is pretty straightforward:

1. Connect a device

Connect an Android phone you already own, or use a device in mobilerun Cloud.

2. Install LinkedIn

Set up the LinkedIn app and sign in to the account you want to use.

3. Give the agent instructions

Describe the audience, your positioning, the tone you want, and what the agent should do. You don't need to build a complicated campaign or manually map every field. The important part is that you define the strategy and the agent handles the repetitive execution.

Personalization without writing every message yourself

Personalization is where most automated outreach falls apart. A generic message like this one (below) does not feel personalised.

"Hi Lisa, I came across your profile and thought our product could be a great fit for your team."

The alternative is manually researching every prospect and writing every message, but it is hard to scale. mobilerun agent sits somewhere in between. For eg, you give it the context it needs:

Our pitch: We help mobile teams reduce QA cycle time by automating testing on real devices.

Audience: Mobile engineering leaders.

Tone: Short, conversational, no corporate language.

Instruction: Reference something specific from the person's profile when relevant. Don't force personalization if there isn't anything useful to mention.

You can also give it a rough template:

"Hi {name}, saw you're leading {function} at {company}. We help teams like yours {benefit}. Worth a quick chat?"

The template is just an example, not something you should swear by. For eg.

Robert H. : Head of Mobile Engineering at a fintech

His profile mentions a recent post about flaky Appium test suites slowing down releases. A contextual message might be:

"Hi Rahul, saw your post about flaky Appium suites holding up releases. That's a problem we work on running tests on real devices instead of relying only on emulators. Worth comparing notes?"

Sarah T. : VP Engineering at a logistics startup

Her profile shows that she recently joined the company and is building out the engineering team. The message could instead be:

Hi Sarah, congrats on the new role. Building out a mobile team usually means QA gets complicated pretty quickly. That's one of the things we help teams with. Worth a chat?

See the pitch has not changed but the context has. That's the important distinction between personalised automation and simply sending the same message to everyone.

Two ways to build the workflow

Your LinkedIn setup will look different depending on whether you use Sales Navigator.

Option A: You have Sales Navigator

Sales Navigator gives you the good filters, seniority, headcount, industry, technology, recent job changes, and saved lead lists that update themselves. Point the agent at those.

Connection requests with notes. Same as above, but your search is sharper, so your acceptance rate is better.

Direct messages without connecting first. Normally your outreach only lands once someone accepts your request. With Sales Navigator you can skip that step entirely for some prospects, using InMail. So the instruction becomes:

"Find VPs of Engineering at Series B fintech companies in Bangalore. Send each one a personalized InMail about our QA automation."

The agent finds them, reads each profile, writes each message, sends it.

No spreadsheet needed. Sales Navigator already logs what you have sent and to whom, and keeps your lead lists in sync. You do not need to duplicate that tracking anywhere. Let the platform hold the record and let the agent do the work.

Path B: if you do not have Sales Navigator

You can run the whole motion on a free account. It just needs more structure, because you are working with tighter limits and you will mostly be relying on connection requests rather than notes.

Step 1: search and queue.

"Search LinkedIn for Head of Product at Series A SaaS companies. Send connection requests to 15 of them."

10-12 a day is the number to hold on to. More on why in a moment.

Step 2: set a recurring job for follow-ups. This is the part people skip, and it is where the actual conversations come from. Ask the agent to check daily for newly accepted connections and message them:

"Every day at 10am, check who has accepted my connection requests since yesterday. Send each of them a personalized opener based on their profile. Wait two days, then send one follow-up to anyone who hasn't replied."

Now you have a real sequence running, without a sequencer.

Step 3: track it in a Google Sheet. Without Sales Navigator you need your own record, and the agent can maintain it:

"Keep a Google Sheet with one row per person: name, title, company, date request sent, accepted yes/no, date accepted, message sent, replied yes/no. Update it after every run."

After two weeks that sheet tells you what you actually need to know, which job titles accept, which openers get replies, and which segments are a waste of time. That is the feedback loop that makes the next month better.

How much LinkedIn outreach should you send?

LinkedIn caps connection requests at roughly 100 per rolling seven-day window. It is a rolling window, not a Monday reset. Your cap frees up seven days after each request was sent.

A few things people get wrong about this:

The cap is the same on every tier. Free, Premium, and Sales Navigator all sit at roughly the same ceiling. You cannot buy your way past it.
New accounts are throttled harder, sometimes to 20 or 50 a week, until you build up history and a decent acceptance rate.
Daily pace matters too, not just the weekly total. Staying at 15–25 a day keeps you well inside the envelope. Firing 100 in one afternoon does not.
Free accounts are limited on personalised notes specifically. If notes are central to your approach, that is the real argument for a paid tier not the invitation count.

Hitting the cap is not catastrophic; you just stop until it resets. But sustained aggressive behaviour is what triggers actual restrictions, and those escalate: limited search, feature restrictions for one to three weeks, and in the worst case a permanent suspension.

Once it is set up, you stop doing anything

This is the actual payoff. The agent runs on your own device, or a device in mobilerun Cloud 24*7.

You are not sitting in the LinkedIn app. You are not remembering to check who accepted. You are not maintaining a sequence in a tool that costs $80 a month per seat. You set the targeting, you set the pitch, you set the volume, and then you check the replies.

Getting started

If you already do LinkedIn outreach manually, you have the hard part done. You know who you are targeting and you know what to say to them. The only thing missing is someone to do it every day.

Connect a device in mobilerun, install LinkedIn, and describe the loop you are already running by hand. Start at 15 requests a day, watch the first week's acceptance rate, and tune the message from there.

I Gave Grok Bot Access to a Mobile| Here's How

Priya Negi — Tue, 10 Nov 2026 08:41:02 +0000

We connected Grok Bot to a real cloud phone on Mobilerun and asked it to shop in the Amazon app. It worked. Grok Bot now has a phone it can use the same way it uses a browser: it opens apps, taps, types and reports back. Here's what we did and how you can set it up yourself.

Watch the demo on X

Why we tried this

In the last week, people were all over X talking about Amazon blocking Grok Bots from ordering. Grok Bot does its work in a cloud computer with a browser, so when a website shuts the door, the task just stops.

So we tried something else. Instead of the website, we gave Grok Bot a real phone in the cloud and asked it to use the Amazon app. It finished the task without any trouble. Sometimes it's not the agent. It's the infrastructure it runs on.

What you're actually building

There are three pieces, and they fit together simply.

Grok Bot is the brain. You message it like a teammate, and it works on its own cloud computer even when your laptop is closed.

Mobilerun Cloud is the phone. It gives you real Android and iOS phones in the cloud, not emulators. You can read more about how they work in What are Mobilerun Cloud Phones.

The Mobilerun MCP server is the bridge. It's a hosted connector that lets Grok Bot see your phones, look at the screen, and tap, swipe and type. There's no ADB, no cable and nothing to install on your laptop.

Areas	Grok Bot on its own	Grok Bot + Mobilerun
Where it works	Websites, in a cloud browser	Websites and mobile apps on a real phone
Apps with no website	Can't reach them	Opens the app and uses it
What the service sees	A browser session	A real phone running the official app
Setup	None	One API key and one connector

How to set it up

Step 1: Get a Mobilerun account and API key

Sign up at cloud.mobilerun.ai and copy your API key from the API Keys tab. It starts with dr_sk_. Treat it like a password.

The free plan includes 60 device minutes and 500 credits ($5) a month, which is plenty for a first test. If you'd rather use your own Android phone, you can also claim your free personal phone slot.

Step 2: Connect Mobilerun to Grok Bot

Grok Bot works with remote MCP servers, and Mobilerun's is hosted, so it's a good fit.

Ask your Bot in chat. Message Grok Bot something like "Add this MCP server: https://cloud.mobilerun.ai/api/mcp" and sign in with your Mobilerun account when the browser opens. This uses OAuth, so you don't paste any key into chat.
Add it with your API key. Point Grok Bot at https://api.mobilerun.ai/v1/mcp and add a header Authorization: Bearer dr_sk_YOUR_API_KEY.

Once it's connected, Grok Bot can see your Mobilerun phones as devices it can use.

Step 3: Give it a task

Now just ask, in plain language. Start with something small so you can watch it work:

Spin up a phone on Mobilerun and take a screenshot of the home screen.

Then try something real:

Open the Amazon app on my Mobilerun phone, search for a USB-C charger and show me the top three options with prices.

Grok Bot looks at the screen, decides the next step, taps, and looks again until the job is done. You can watch every step live in the Mobilerun dashboard.

What Grok Bot can do with a phone

Task	Example prompt
Use apps with no website	"Check my latest order status in the app."
Compare prices across apps	"Search for this product in two shopping apps and compare prices."
Test your own app	"Go through the sign-up flow in our Android app and report any issues."
Social media	"Open Instagram and check the comments on my last post."
Run on many phones	"Run the same task on five phones at once."

Grok Bot can also save a task as a skill or routine, so you can run the same phone task on a schedule. [TODO: confirm we've tested a Grok Bot routine with Mobilerun before keeping this line.]

How this compares to the Claude setup

If you've read our guide on giving Claude access to a mobile, this will feel familiar. The phone side is the same; only the agent changes.

	Claude	Grok Bot
How it connects	MCP server (one command in Claude Code, or config in Claude Desktop)	MCP server, added as a remote connector
Mobilerun endpoint	api.mobilerun.ai/v1/mcp	Same endpoint, or OAuth at cloud.mobilerun.ai/api/mcp
Runs when your laptop is closed	Depends on your setup	Yes, Grok Bot works on its own cloud computer
Phones	Cloud phones or your own Android	Cloud phones or your own Android

We've done the same with OpenClaw and TypeSafe's Jev too.

A few things worth knowing

A phone is not a free pass. A cloud phone doesn't override an app's terms of service. We wrote more about this in Why AI Agents Keep Getting Blocked.

Keep a human on purchases. Let Grok Bot search, compare and fill the cart, but approve anything that spends money yourself. Watch your credits. Some actions, like creating a new phone, use credits on your Mobilerun account.

Keep your key private. Never paste your dr_sk_ key into a group chat. If you can, use the OAuth sign-in instead.

The bigger picture

AI agents are getting better every month. What holds them back is often not the model, but where it runs. Websites can block a browser session. A real phone running the real app is a different story.

Give Grok Bot a phone, and it can work in the places people actually spend their time: mobile apps.

Get started

Create a free account on Mobilerun Cloud, grab your API key, and give your Grok Bot a phone today. For the full tool list, see the MCP server docs.

Why can't my AI agent use mobile apps?

Priya Negi — Mon, 09 Nov 2026 09:55:01 +0000

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.

How do AI agents stay logged in between runs?

Priya Negi — Mon, 09 Nov 2026 09:53:52 +0000

AI agents need an environment that remembers where they left off, this is called persistent environment. If every run starts in a fresh container, browser or device, login sessions disappear and data gets removed. The agent has to authenticate again, sometimes triggering another verification step. A persistent environment preserves the session, app data and device state between runs, so the agent can pick up where it left off.

Why agents keep getting logged out

Most agent infrastructure is designed to be disposable. For code execution, that makes sense: create a clean environment, run the task, and discard it. But workflows that depend on logged-in accounts need something different.

Being logged in involves more than entering a username and password. Several pieces of state work together:

Session cookies and tokens: Websites store these in the browser profile. Delete the profile, and the session is usually gone.
App data: Mobile apps keep login tokens and other account data in local storage, sometimes protected by the operating system. Reset the device, and that data may disappear.
Device trust: Some services remember devices after a successful verification step. If an agent uses a new device every time, it may be asked to verify again.
Local state: Preferences, saved items, drafts, uploaded files and conversation history can all be tied to the environment.
Session expiration: Even persistent sessions eventually expire. Agents still need a way to authenticate again when that happens.

With a disposable environment, the pattern is predictable: the agent signs in, completes a task, and loses its session when the environment is destroyed. The next run starts from scratch.

That means repeated authentication, more credential handling and additional verification prompts. It also creates unnecessary work for the agent, which has to spend time and tokens restoring a state it already established.

Ways to preserve state today

Persistent state is relatively straightforward in browser automation. Mobile automation adds another layer because app data and device state also matter.

1. Persist the browser profile

Most browser automation frameworks let you reuse a browser profile or user data directory across runs. This preserves cookies, local storage and other session information. For web-based workflows, it is often enough.

Browser profiles contain sensitive session data, so they should be stored securely and access should be restricted.

2. Use OAuth and refresh tokens

When a service supports OAuth, this is usually the cleaner approach. The agent can use an access token and renew it through a refresh token without repeatedly going through a login page.

Whenever an official API or supported authentication flow is available, prefer it over automating the sign-in process.

3. Keep a long-running container with persistent storage

A container with a mounted volume can preserve files and other data between executions. This works well for desktop and web workloads, but the environment needs to be maintained, secured and managed over time.

4. Store credentials in a vault and authenticate when needed

An agent can retrieve credentials from a secrets manager and sign in at the start of each run. This keeps the execution environment disposable, but it does not preserve the session. Verification steps may still be required, making this approach slower and less reliable for frequent workflows.

5. Use a dedicated phone or emulator

Teams can maintain a dedicated Android device or emulator image and reuse it across tasks. This can work, but managing multiple devices introduces operational overhead: provisioning, updates, connectivity, storage and recovery.

The underlying requirement is the same across these approaches: the environment must retain the state the agent needs between runs.

How Matix and Mobilerun approach persistent mobile execution

For mobile workflows, preserving a browser profile is not enough. The agent also needs the app data and device state associated with its previous activity.

Matix provides a mobile runtime for AI agents, built around isolated, stateful real phones that agents control through an API. Instead of provisioning a fresh device for every task, an agent can work with a device that retains its existing app and account state between tasks.

That means the apps installed on the device and their locally stored data can remain available, rather than being discarded with a temporary execution environment. Whether a particular login remains active still depends on the app's session policies, token expiration and security checks.

Mobilerun is the open-source framework agents use to interact with these devices. You can install it with:

pip install mobilerunCopy

Together, Matix and Mobilerun provide the infrastructure and automation layer for agents that need to work across mobile apps without rebuilding their execution environment for every task.

When a persistent environment is not the right choice

Persistence is useful when an agent needs to return to an existing account or continue work across multiple sessions. It is not necessary for every workflow.

Stateless tasks: A one-time lookup or independent task does not need a persistent device. A fresh environment is simpler.
Strict data-retention requirements: If compliance rules prohibit storing authenticated sessions on third-party infrastructure, a disposable environment may be more appropriate.
Official token-based authentication: If an API and refresh-token flow are available, using them is usually simpler than maintaining an entire device.
Large-scale clean testing: If you need hundreds of independent devices to test app behavior from a clean starting point, fresh emulators or device images may be a better fit.
Unclear retention requirements: If you need specific guarantees about how long data is retained or how it is deleted, verify that the infrastructure provider can meet those requirements before relying on persistence.

Is it safe to let an AI agent control a phone?

Priya Negi — Mon, 09 Nov 2026 09:52:54 +0000

Is it safe to let an AI agent control a phone? The answer depends on the phone and the access you give it. Giving an AI agent control of your personal phone means exposing it to your messages, photos, accounts and potentially sensitive apps. A safer approach is to give the agent a separate device with dedicated accounts and only the permissions it needs.

The goal isn't to make an AI agent incapable of making mistakes but to limit the damage those mistakes can cause.

Why giving an AI agent access to your phone is risky

A smartphone brings together an enormous amount of personal information. Messages, email, banking, photos, contacts, saved passwords and logged-in accounts often live on the same device.

An AI agent that can interact with your screen can navigate those apps and perform actions on your behalf. That's what makes mobile automation powerful, but it also creates several risks.

1. Access to more data than the task requires

An agent might only need to send a message or update an order. But if it's operating on your personal phone, other apps and accounts may be accessible too.

The problem is excessive access. The agent gets a much broader view of your digital life than the task actually requires.

2. Accidental actions

AI agents can misinterpret screens, tap the wrong button or misunderstand what an action will do.

A misplaced tap could send a message to the wrong person, delete a file or confirm a purchase. When the agent is operating on your personal accounts, even a small mistake can have consequences.

3. Prompt injection

An agent doesn't only see the instructions you give it. It also reads content inside the apps it uses.

That content can include messages, webpages, emails and product descriptions written by other people. Someone could include instructions designed to manipulate the agent into doing something outside its original task.

For example, an agent asked to summarize an email might encounter text telling it to forward private information to another address. If the agent treats that text as an instruction rather than untrusted content, it could take an unintended action.

This is known as prompt injection. It remains an open security challenge for AI agents. Separating the agent's environment can limit the data and accounts it can access, but it does not prevent prompt injection itself.

4. Mixing personal and automated activity

When an agent uses your personal accounts, its actions become mixed with yours.

Messages, searches, purchases and changes to app settings may all happen in the same environment. It becomes harder to distinguish what you did from what the agent did, and harder to audit its activity.

5. Unattended access

An agent that runs while you're away can continue interacting with apps without you watching every action.

The longer it has access, the more important it becomes to define what it can do independently and which actions require your approval.

How to give an AI agent a safer environment

You don't necessarily need a sophisticated security setup. You need to separate the agent's work from your personal digital life and limit what it can do. Here are a few practical approaches.

1. Use a dedicated phone

The simplest option is a separate Android or iPhone used exclusively for automation.

Start with a clean device, create dedicated accounts for the agent's tasks and avoid signing into your personal apps. This creates a clear boundary between your data and the agent's working environment.

The trade-off is operational overhead. You have to keep the device charged, connected, updated and available.

2. Use separate Android users or work profiles

Android supports multiple user profiles and work profiles, which can separate apps and data on the same physical device.

This can be useful when you want to keep work and personal activity apart without maintaining two phones.

However, profile separation is not the same as complete device isolation. The profiles still share the underlying hardware and operating system.

3. Use an emulator or simulator

For development and testing, an Android emulator or iOS simulator can provide a separate environment without using a personal phone.

They're convenient for testing app behavior and running automated workflows. However, some apps depend on physical hardware or device-specific capabilities that may not be available in a simulator.

4. Apply least-privilege access

Regardless of the environment, give the agent only the access its task requires.

For example:

Use dedicated accounts instead of personal accounts.
Avoid giving access to banking or other sensitive apps unless absolutely necessary.
Set spending limits where supported.
Require human approval before payments, deletions or other irreversible actions.
Restrict access to credentials and sensitive information.

A separate device is useful, but the accounts and permissions on that device matter just as much.

5. Keep an activity log

Record the actions an agent takes, especially when it interacts with accounts, sends messages or changes data.

Logs make it easier to investigate mistakes, understand what happened and improve the workflow. Where possible, keep records of both the agent's requested actions and the actions actually performed.

How Matix and Mobilerun approach mobile agent isolation

If an AI agent needs to interact with mobile apps, it shouldn't have to use your personal phone.

Matix provides a mobile runtime for AI agents, built around isolated, stateful real phones that agents control through an API.

Instead of giving an agent access to your everyday device, you can give it a separate mobile environment for its work. The apps, accounts and data on that device are separate from those on your personal phone, provided you keep personal accounts and information off the agent's device.

Think of it like a sandbox for mobile automation. E2B provides isolated environments for running code; Matix provides mobile environments for agents that need to interact with apps on real phones.

Mobilerun is the open-source framework agents use to control those devices. The important distinction is that device separation limits the agent's access to your personal digital life. It doesn't make the agent inherently safe.

If you sign into your personal email or banking account on the agent's device, those accounts are still exposed to the agent. And prompt injection, unintended actions and mistakes can still happen within the environment it controls.

A sensible setup starts with a few principles:

Use a dedicated device for each agent or workload where practical.
Create accounts specifically for the agent's tasks.
Give those accounts the minimum permissions required.
Require human approval for sensitive or irreversible actions.
Keep an audit trail of the agent's activity.

A note on security: Device separation is only one layer of security. Customer isolation, network boundaries, credential handling, data encryption, retention and deletion policies also matter. Confirm the specific guarantees provided by your infrastructure before using it for sensitive workloads.

When a separate mobile environment is not the right fit

A dedicated mobile environment isn't necessary for every agent or workflow.

Your agent needs access to your personal data: If you're building a personal assistant that reads your messages, photos or personal apps, a separate device may not provide the experience you want. That requires a different permission and privacy model.
Your data has strict infrastructure requirements: If you need on-premises deployment, specific data residency guarantees or particular security certifications, verify that the infrastructure meets those requirements before using it.
You're automating sensitive accounts: Banking, healthcare and other high-impact accounts require additional safeguards. A separate device alone is not sufficient.
You expect isolation to prevent every security issue: It limits what an agent can access, but it doesn't guarantee that the agent will follow instructions correctly or resist malicious content.
You're only testing your own app: An emulator or simulator may be simpler and more cost-effective if you don't need physical-device capabilities.

10,000 Stars on GitHub: Our Journey Building Mobilerun in Public

Priya Negi — Fri, 06 Nov 2026 14:07:18 +0000

Hitting 10,000 stars on GitHub is not just a number for us. It shows that sharing our journey openly was the right move, and that developers really believe in what we’re building.

If you’ve been following along, you might know us as Droidrun. Same project, same community — the open-source framework is now called Mobilerun.

The Beginning

Our journey began about 19 months ago, in April 2025, when this was nothing more than an idea. After weeks of development, we created our first working model. Instead of perfecting it in silence, we decided to share our progress with the community.

We recorded a short demo video showing the capabilities and released it to the community. The response was amazing — within 72 hours, over 800 developers signed up for our waitlist. The traction told us we were onto something important.

Early Validation and Recognition

Soon after, we launched on Product Hunt and were awarded Product of the Day. That early validation increased our reach to thousands of potential users and contributors.

Funding

The momentum continued in the months that followed. In July 2025, we closed our first funding round of €2.1 million. That gave us the resources to accelerate development, expand our team, and invest in the infrastructure we needed.

What we’ve built since

The last time we wrote about this milestone, we had just crossed 7,000 stars. Since then, Mobilerun has grown into an open-source, MIT-licensed, LLM-agnostic framework for running AI agents on real Android and iPhones. Agents can inspect the UI, tap, swipe, type, and run multi-step workflows from a CLI or Python. Not an emulator.

We also open-sourced more of the stack around it — skills so tools like Claude Code, Codex, and OpenClaw can control real phones, the Android portal app, a local iPhone bridge, MCP plugins, SDKs, and examples — so builders can automate real devices without waiting on us.

The community has grown with it: 10,000 GitHub stars, 1,800+ people on Discord, and more than 3 million prompts run through the product. On public benchmarks, the framework scores 100% on AndroidWorld (116 tasks) and 98.34% mean on iOSWorld (133 tasks).

Looking Ahead: The Momentum Continues

We’re excited about what lies ahead. Mobile automation is still in its early phase, and we’re just scratching the surface of what’s possible. We’re committed to maintaining the transparent, community-driven approach that got us here.

Join Us in Building the Future

This journey has been extraordinary, but it’s far from over. We want you to be part of what comes next. Whether you’re interested in trying the framework, contributing code, or building on top of it, we’d love to have you in our community.

The project is completely open-source, the community is welcoming, and the possibilities are still wide open.

Explore the repo and join our community:

github.com/droidrun/mobilerun

How to give your AI Agent access to a Real iPhone

Priya Negi — Thu, 29 Oct 2026 14:25:02 +0000

For a long time, mobile automation has been much easier to demonstrate on Android than on iOS. Android has ADB, emulators, and relatively accessible automation tooling. iOS has a different set of constraints, especially when you want to interact with a physical device and the apps installed on it.

But what if you could give an AI agent access to your actual iPhone, describe a task in plain English, and let it carry out the steps?

That's what we've been working on at Mobilerun.

Why iPhone automation is difficult

AI agents have become good at reasoning, writing code, and interacting with websites. Mobile apps introduce another layer of complexity.

An agent might need to navigate multiple screens, locate a button, enter information, handle a dialog, and verify that an action actually succeeded.

On iOS, automation is harder because of Apple’s restrictions, connection issues, and the setup needed to control a real iPhone.

Traditional automation often relies on predefined scripts or app-specific integrations. These work well when the workflow is known in advance, but they can be restrictive when you want an agent to handle different tasks dynamically.

An AI agent that can interact with a phone's UI has another option: it can observe the screen, decide what to do next, and perform the necessary interactions.

Instead of building a separate integration for every task, you can describe the outcome you want and let the agent work through the interface.

From a prompt to a real iPhone

With Mobilerun Cloud, you can connect your own iPhone through a Mac or Linux or Linux and make it available for automation.

The workflow is straightforward:

Connect your iPhone to your Mac or Linux or Linux using a USB cable.
Follow the setup instructions to connect it to Mobilerun Cloud.
Open your connected device and give your agent a task.
Watch the agent interact with the phone.

Once connected, you can issue a command and let the agent navigate the UI, tap controls, type text, and move between screens.

You don't need to build a dedicated automation script for every prompt.

Setup takes under two minutes in the supported configuration. You'll need an iPhone running iOS 27 or later and a Mac or Linux.

Follow the iPhone connection guide to get started.

What can you automate?

The interesting part isn't simply getting an AI to tap a button. It's being able to describe a task and have the agent work through the steps on a real device.

Here are a few examples worth exploring.

1. Messaging workflows

You could ask an agent to open Messages, find a conversation, and draft or send a message.

For example:

Open Messages, find my conversation with Maa, and send her a message saying I'll call her this evening.

This is a simple example, but it demonstrates the core idea: the task is described in natural language, and the agent translates it into UI interactions.

Always review messages and confirm the intended recipient before allowing an agent to send anything important.

2. Navigating apps

An agent could be asked to open an app, find a particular section, search for information, or navigate through a multi-step workflow.

Rather than specifying every tap in advance, you describe what you want it to accomplish.

3. Repetitive mobile tasks

Many mobile workflows involve repeating the same sequence of actions: opening an app, finding a record, updating information, or navigating through several screens.

These are useful places to experiment with agent-driven automation, particularly when the process is tedious to perform manually.

The exact tasks an agent can complete will depend on the app, the UI, permissions, and the reliability of the underlying automation.

Why use a real iPhone instead of a simulator?

Simulators are valuable for development and testing. They provide a controlled environment where you can reproduce scenarios and inspect application behavior.

Physical devices matter when you need to work with the actual hardware and software environment.

A real iPhone gives you access to the device you already own, including its installed apps and existing setup, subject to the permissions and capabilities available to the automation system.

This is useful for developers experimenting with mobile agents, teams testing real-device workflows, and anyone exploring what AI can do beyond a browser.

It doesn't mean simulators are obsolete. Both approaches have their place, depending on what you're trying to build or test.

Try it yourself

If you have an iPhone and a Mac or Linux, you can connect your device to Mobilerun Cloud and start experimenting.

Connect your iPhone: Read the setup guide
Try Mobilerun Cloud: cloud.mobilerun.ai
Explore Mobilerun: mobilerun.ai
Inspect the benchmark: iOSWorld results

We're curious to see what developers build with this.

What would you want an AI agent to do on your iPhone that you can't easily automate today?

That's probably the most interesting question to explore next.

Why AI Agents Keep Getting Blocked and What It Will Take to Fix It

Priya Negi — Tue, 20 Oct 2026 07:11:01 +0000

AI agents are becoming capable of doing more than answering questions. But as their capabilities improve, anew problem is emerging: many online services are actively restricting AI agents from accessing or usingtheir platforms.

Agents that can complete a task in one environment may fail in the next. Some encounter CAPTCHAs and anti-bot checks. Others face explicit access restrictions or warnings that their activity violates a website’s terms ofservice.

This raises an important question: if an AI agent is acting on behalf of a legitimate user, why is accessbecoming so difficult?

The answer involves more than companies resisting automation. It touches on security, business models,accountability, and the infrastructure agents use to interact with the internet. Understanding these factors isessential to figuring out what comes next.

Why are websites blocking AI agents?

The recent restrictions on AI agents across e-commerce, travel, financial services, and other online platformspoint to a growing tension between how agents operate and how websites are designed to function.

Several factors explain why this is happening.

1. Websites cannot always distinguish helpful agents from harmful bots

Most websites already have systems designed to detect automated activity. These systems help preventcredential stuffing, scraping, spam, fraud, and other forms of abuse.

The problem is that many of the signals used to identify malicious bots can also appear when a legitimate AIagent accesses a website.

An agent might navigate pages, submit forms, compare products, or sign in to an account automatically. Froma website’s perspective, these actions can resemble the behavior of a scraper or an automated attack.

Anti-bot systems are not necessarily designed to determine whether the automation is acting on behalf of areal customer. They often rely on signals such as request patterns, browser behavior, session information, andother indicators of automated activity.

As a result, legitimate agents can be blocked alongside malicious bots. Even services that are open to workingwith AI agents can encounter false positives when existing security systems are not designed for them.

This is particularly challenging for agents that rely on browser interfaces rather than official APIs. They mustinteract with the same pages, forms, and security checks as human visitors, leaving more room for automateddefenses to interfere.

2. AI agents challenge existing business models

Websites are not simply interfaces for accessing information. Many businesses depend on how users interactwith those interfaces to generate revenue.

E-commerce platforms earn money through advertising, sponsored placements, product recommendations,and other parts of the shopping experience. Travel websites may promote particular offers, while contentplatforms monetize visits and engagement.

An AI agent changes this dynamic.

Instead of browsing multiple pages, viewing recommendations, and comparing sponsored listings, a user canask an agent to find the best option and complete the purchase. The agent may go directly to the result,bypassing much of the interface through which the business generates revenue.

For businesses, this creates a difficult question: if an agent uses the service but does not participate in theexperience that generates revenue, how should that access be handled?

Some companies may choose to restrict automated access. Others may explore licensing agreements,dedicated APIs, or paid access models. The underlying issue is not necessarily that businesses oppose AI. It isthat the economics of serving an AI agent can differ significantly from the economics of serving a humanvisitor.

3. Account security becomes more complicated

The stakes are higher when agents access personal accounts, particularly those involving financialinformation, purchases, travel bookings, or sensitive data.

Consider an agent that logs into a user’s account to check a balance, make a booking, or purchase a product.The website needs to establish not only that the user is legitimate, but also that the agent is authorized toperform the requested action.

Questions quickly emerge. Who controls the credentials? What information can the agent access? Can it makepurchases without confirmation? What happens if its instructions are manipulated or it performs anunintended action?

These are not hypothetical concerns that can be dismissed in the name of convenience. An agent can makemistakes, misunderstand instructions, or interact with malicious content. If it has broad account access, theconsequences can extend beyond a failed task.

Financial institutions and other services with strict security requirements have additional reasons to becautious. They need reliable authentication, access controls, and audit trails before allowing automatedsystems to operate within customer accounts.

Until these issues are addressed, restricting agents may be the simplest option for a company that cannotconfidently distinguish authorized activity from unacceptable risk.

4. Businesses bear the cost when agents make mistakes

AI agents can misunderstand a request, select the wrong product, miss a booking condition, or complete anaction the user did not intend.

When this happens, the consequences often fall on the business providing the service. A retailer may have tohandle a return, an airline may need to resolve a booking dispute, and a financial service may have toinvestigate suspicious activity.

This creates an imbalance: the company building the agent may benefit from its capabilities, while the websitebeing accessed bears some of the operational and support costs.

Businesses therefore have a legitimate interest in establishing clear rules for automated activity. They need toknow what an agent is permitted to do, who is responsible for its actions, and how mistakes will be handled.

Without these safeguards, allowing agents unrestricted access can introduce costs that a website has littleincentive to accept.

5. Competition is also part of the picture

Security, revenue, and liability explain much of the resistance to AI agents, but competition can also influenceaccess decisions.

An AI assistant that can compare products across multiple retailers may change where customers shop. Anagent that interacts directly with a platform can reduce the importance of that platform’s own interface orrecommendation system.

Businesses may therefore have commercial reasons to limit access to certain agents, especially when thoseagents are operated by competing companies.

It is difficult to attribute every restriction to a single motive. A decision can reflect legitimate security concernsand commercial interests at the same time.

The important distinction is between a business establishing reasonable conditions for access and usingtechnical restrictions to prevent customers from using tools that serve their interests.

What does this mean for users?

For users, the appeal of AI agents is straightforward: delegate a task and let the software handle the steps.

Instead of visiting several websites to compare products, an agent could gather the information and presentthe best options. Instead of manually navigating an app, a user could describe the desired outcome and let anagent carry out the workflow.

When access restrictions interrupt these tasks, that promise becomes less reliable.

The problem is not always obvious. An agent might work on one website but fail on another. A workflow thatworked yesterday may stop working after a security update. Sometimes the user receives an explicit warning;in other cases, the task simply fails.

These restrictions can also affect accessibility. Automated interfaces and assistive technologies help peopleinteract with digital services in different ways. Security measures that indiscriminately block automation cancreate additional friction for legitimate users, too.

At the same time, users have a stake in keeping their accounts secure. Giving an agent unrestricted access topasswords, payment methods, and personal information is not a reasonable trade-off for convenience.

The goal should be to make authorized automation dependable without removing the safeguards that protectusers and businesses.

Why blocking agents alone is unlikely to solve the problem

Blocking automated traffic can reduce unwanted activity, but it does not address the underlying question ofhow legitimate agents should access online services.

There is also a practical limitation: modern agents can operate through real browsers and interact withinterfaces in ways that resemble human behavior. Detection systems may identify some automated activity,but reliably separating every legitimate agent from every malicious bot is difficult.

This creates a potentially counterproductive cycle.

Websites introduce stricter controls. Agent developers encounter more failures and try different technicalapproaches. Websites respond with additional detection mechanisms. Legitimate users experience morefriction, while developers may be incentivized to make their agents less transparent.

That is not a good long-term outcome.

The objective should not be to make agents indistinguishable from humans. It should be to makelegitimate agents identifiable, authorized, and accountable.

A more sustainable approach would give businesses meaningful control over access while allowing users todelegate tasks without having to navigate a new set of restrictions on every website.

What needs to change?

There is unlikely to be a single solution. A more reliable agent ecosystem will require improvements in identity,permissions, access methods, and accountability.

1. Give AI agents a verifiable identity

Websites need better ways to establish which agent is making a request and, where appropriate, which user ororganization it represents.

A verifiable identity could help distinguish a registered agent from an unknown automated client. It would notautomatically make every request trustworthy, but it would give websites more information when decidingwhether to allow access.

Emerging approaches such as Web Bot Auth and Cloudflare’s Bot Management initiatives illustrate how agentand bot identity could become part of the access-control process.

Identity should be combined with other safeguards, including reputation, rate limits, and authorization. Simplyidentifying an agent does not establish that it should be allowed to access every resource or perform everyaction.

Still, it is a necessary starting point. A system that can recognize legitimate agents has more options thanone that must treat all automation as suspicious.

2. Establish clear permissions and delegated access

An agent acting for a user should not automatically receive unrestricted access to everything that user canaccess.

Permissions should reflect the task being performed. An agent asked to compare prices may need to readproduct information, while an agent asked to make a purchase may need additional authorization beforesubmitting payment.

Where possible, delegated authentication and scoped permissions should replace the practice of sharingbroad account credentials with an agent.

Users should also be able to understand what an agent can access, revoke its permissions, and reviewimportant actions it has taken.

This approach benefits businesses as well. Clear authorization makes it easier to determine whether an agentis operating within the boundaries established by the user and the service.

3. Move beyond scraping when structured integrations are available

Many agents currently interact with websites by navigating pages and clicking buttons. This approach can beuseful when no other option exists, but it is inherently fragile.

A website redesign can break a workflow. A pop-up can interrupt navigation. A security check can prevent anagent from completing a task that would otherwise be straightforward.

APIs and structured interfaces provide a more predictable alternative. Instead of interpreting a page designedfor a human, an agent can interact with defined actions and receive structured responses.

Standards and initiatives such as WebMCP and the Universal Commerce Protocol reflect the broadermovement toward making website functionality available to agents through more structured mechanisms.

For commerce, this could mean allowing an agent to discover products, initiate checkout, and complete apurchase through an approved flow rather than attempting to automate every step of the browser interface.

Not every website will expose an API or support these protocols immediately. Browser automation will continueto have a role, particularly for legacy systems and services without suitable integrations. But where anapproved, structured route exists, it should generally be the preferred option.

4. Create sustainable models for access

Businesses need a way to account for the costs and commercial implications of agent traffic.

Some services may offer free access within defined limits. Others may provide paid APIs, data licensing, orcommercial agreements. Transaction-based arrangements may also make sense when an agent completes apurchase or another valuable action.

The right model will vary by business.

What matters is that access rules are transparent enough for developers to understand the conditions andbuild reliable products around them. A clear permission or pricing model is more useful than an unpredictablesystem in which an agent can be blocked without explanation.

5. Make agents accountable for their actions

Trust also depends on what happens after an agent is allowed in.

Agents should communicate clearly when they are acting autonomously, keep appropriate records ofimportant actions, and ask for confirmation when a task involves significant financial or personalconsequences.

Developers should make it possible to investigate failures, correct mistakes, and identify which instructions ledto an action.

Businesses, in turn, need clear channels for handling problems caused by automated interactions.

No identity system or protocol can eliminate every mistake. But a combination of clear permissions,auditability, and defined responsibility can make agent access less risky for everyone involved.

The role of infrastructure in making agents work

Even with better access policies, another challenge remains: agents need a reliable environment in which toexecute tasks.

An agent is not just a model generating a sequence of decisions. It also depends on the tools, sessions,credentials, browsers, and devices through which it interacts with services.

For website-based workflows, that may mean a browser with a stable session and the appropriate integrations.For mobile workflows, it may mean access to an Android or iOS environment where the agent can open apps,navigate screens, and perform actions.

These environments introduce their own challenges. Sessions can expire, authentication flows can change,and an app may behave differently from its website. An agent that reasons correctly can still fail because theenvironment does not support the action it needs to perform.

This is why improving the model alone will not solve every agent reliability problem.

The surrounding infrastructure needs to support persistent sessions where appropriate, controlled access toaccounts, dependable execution, and visibility into failures. It also needs to respect the access restrictions andsecurity requirements of the services being used.

For mobile workflows in particular, cloud-based device environments can give agents a place to interact withreal app interfaces instead of relying exclusively on browser-based alternatives. Platforms such as Mobilerunprovide cloud Android and iOS environments for these kinds of workflows.

That is one part of the broader solution, not a universal workaround for access restrictions. A cloud phonedoes not automatically grant permission to use a service, remove its terms of service, or resolveauthentication and liability concerns. The same principles of authorization, transparency, and responsibleautomation still apply.

The larger point is that reliable AI agents require both capable software and an environment in which thatsoftware can operate responsibly.

What should agent developers do?

The transition toward more agent-friendly services will take time. In the meantime, developers can takepractical steps to make their systems more dependable.

Use official integrations where possible. Prefer supported APIs, structured tools, and approvedcommerce flows over brittle page automation.
Be transparent about identity. Identify agents where supported, and avoid deliberately impersonatinghuman users to evade restrictions.
Limit account access. Use delegated credentials and scoped permissions rather than storing or sharingmore sensitive information than a task requires.
Respect access policies. Treat rate limits, access controls, and stated restrictions as meaningfulboundaries rather than obstacles to bypass.
Design for failure. Explain when a task cannot be completed, preserve useful error information, and offerlegitimate alternatives instead of retrying indefinitely.
Keep consequential actions under control. Require appropriate confirmation for purchases, bookings,financial transactions, and other actions with significant consequences.
Build for reliability beyond the model. Monitor sessions, authentication, browser or device state, andexecution errors so failures can be diagnosed rather than mistaken for reasoning problems.

These practices will not prevent every block. Some services will continue to restrict agents, and others willoffer access only through specific partnerships or integrations. But they provide a more sustainable foundationthan trying to outmaneuver every new defense.

What comes next?

AI agents are becoming more capable, and the services they interact with are still adapting to what that meansfor security, revenue, and customer relationships.

The next stage will likely be uneven. Some businesses will open their services through APIs, agent-specifictools, or commercial agreements. Others will continue to limit automated access, especially where the risksare difficult to manage.

Over time, better identity mechanisms, clearer permissions, structured interaction protocols, and more reliableexecution environments can make the distinction between legitimate automation and harmful activity easier tomanage.

This does not mean every website must allow every agent. Businesses have valid reasons to protect theirsystems, data, and customers. But blanket restrictions are unlikely to be the best answer to a world in whichpeople increasingly expect software to act on their behalf.

The more useful question is how to enable that delegation safely.

For developers, that means building agents that are transparent, authorized, and accountable. Forbusinesses, it means creating access models that protect their interests without unnecessarily excludinglegitimate customers. For infrastructure providers, it means making agent execution more reliable acrossbrowsers, apps, and devices.

The future of AI agents will depend on all three.

The internet does not need to choose between unrestricted bots and a web that refuses to work withautomation. There is room for a more practical middle ground: agents that can prove who they are, operatewithin clear permissions, use supported interfaces where available, and complete tasks in environmentsdesigned for dependable execution.

Getting there will require cooperation rather than an endless contest between agents and the systemsblocking them.

Mobilerun Achieves 100% on AndroidWorld, Beating Google ARTEMIS

Priya Negi — Fri, 02 Oct 2026 08:11:47 +0000

Mobilerun just achieved a 100% official score on AndroidWorld, Google Research's benchmark for evaluating AI agents on Android.
For context, Google's open-source ARTEMIS reports a 99%+ task completion rate on AndroidWorld. Mobilerun achieved a full 100%, completing every one of the benchmark's 116 tasks.
This is a meaningful milestone for mobile AI agents. But the interesting part isn't just the number, it's what the benchmark actually tests.

What is AndroidWorld?

AndroidWorld is a benchmark designed to measure how well AI agents can perform tasks inside Android applications.
It contains 116 tasks spanning 20 Android apps, with workflows that require agents to understand instructions, interact with mobile interfaces, perform multiple actions, and ultimately reach the correct outcome.
These aren't simply isolated UI actions. An agent might need to:

Navigate through an application
Locate the right UI element
Enter or modify information
Perform several actions in sequence
Handle the current state of the application
Verify that the requested change actually happened A tool successfully executing a tap or typing text doesn't necessarily mean the task was completed. AndroidWorld's official score evaluates the result of the task, rather than simply whether individual actions were executed.

116/116: A 100% official score

For our latest evaluation, we ran AndroidWorld using mobile-harness, our set of mobile tools and instructions for running mobile tasks through coding agents. The evaluation used:

Tasks:116
Full scores:116
Official score:100%
Recorded interactions: 1,419
Device: Pixel 6 emulator
OS: Android 13 / API 33
Model:gpt-6-astra / low

Every one of the 116 tasks received an official score of 1.0. That gives us a perfect benchmark score: 116 / 116 = 100%

We also recorded the interactions, screenshots, tool operations, answers, judgments, and timing for the evaluation. The individual trajectories are available on our benchmark explorer, so you can inspect what happened task by task rather than relying on a single aggregate number.

How does this compare with ARTEMIS?

Google's ARTEMIS is an open-source system for natural-language Android automation. It combines UI understanding, accessibility information, OCR, visual targeting, execution profiles, diagnostics, and MCP integrations for AI coding assistants.

System- AndroidWorld result:

mobilerun / mobile-harness: 100%
Google ARTEMIS: 99%+

The difference is small numerically, but reaching a perfect score means completing every task in the 116-task suite.

One important caveat: these are not identical evaluation configurations. Our run used mobile-harness with gpt-6-astra / low, app cards and shared memory, while ARTEMIS has its own architecture and evaluation configuration. So the comparison should be understood as a comparison of reported AndroidWorld results, not a controlled head-to-head experiment.

The role of mobile-harness

The result wasn't achieved by building another completely isolated mobile agent. Instead, we wanted to explore a different question:
What happens when you give a general-purpose coding agent the right tools, mobile-specific knowledge, and memory to operate mobile apps?

That's the idea behind mobile-harness. It provides mobile tools and instructions that allow agents such as Claude Code, Codex, and OpenClaw to operate Android and iOS environments. The harness combines three important components:

1. Mobile tools

The agent gets the ability to interact with the device rather than merely describe what should happen. It can observe the mobile environment, interact with UI elements, and execute workflows.

2. App cards

App cards provide structured knowledge about applications and their workflows. Instead of starting every task completely from scratch, the agent can use information learned about how particular apps work.

3. Shared memory

Mobile tasks often involve recurring patterns. An agent that discovers how an application behaves shouldn't necessarily have to rediscover the same information every time.

Shared memory allows useful lessons from execution to be carried forward. Together, these components give a general-purpose coding agent a more structured way to operate mobile environments.
Execution is not the same as completion.

One of the things we focused on during the benchmark was outcome verification. Imagine an agent is asked to add an item to a list. It could:

Find the input field.
Type the requested text.
Press a button.
Receive a successful tool response.

But that doesn't necessarily prove the item was actually saved. The application could have rejected the input. The wrong button could have been pressed. The screen could have changed without the intended state being persisted.

That's why our evaluation uses both accessibility information and screenshots to understand the state of the application and calls for reading back changes where appropriate. The benchmark's official scoring then determines whether the intended outcome was actually achieved.

From 63% to 91.4% to 100%

This result is also part of a longer progression for us. Earlier in our AndroidWorld work, Droidrun achieved 63.0% across the 116-task benchmark. We later reached 91.4%, after changing our agent architecture to use a dynamic manager-executor feedback loop instead of relying on a rigid sequence of planned actions.

Now, with mobile-harness, we've reached 100%. That progression reflects something we've learned repeatedly while working on mobile agents, and that is reliable mobile automation isn't just about choosing a better model, the surrounding system also matters.
Tools, state, application knowledge, memory, recovery, verification, and the way an agent interacts with its environment can all affect whether an instruction actually becomes a successful outcome.

Explore the full benchmark: https://mobilerun.ai/benchmark/
Explore the github repo: https://github.com/droidrun/mobile-harness

How to Automate Facebook Marketplace in 2026 Complete guide

Priya Negi — Wed, 16 Sep 2026 09:04:03 +0000

Facebook Marketplace is one of the largest places to discover second-hand products, local deals, and resale opportunities. But if you use it regularly, you quickly run into the same problem: there is a lot of manual work involved.

You have to search for products, scroll through listings, compare prices, check descriptions, identify good deals, collect information, contact sellers, and sometimes create listings yourself. For someone buying or selling dozens of products, this can turn into hours of repetitive work every week.

That is why people are increasingly looking for ways to automate Facebook Marketplace. The challenge is that Marketplace wasn't designed around a simple automation API. Developers trying to build Marketplace scrapers frequently report running into login walls, bot detection, broken browser automations, and outdated scraping solutions.

A different approach is to automate the mobile interface itself. With an AI-powered mobile automation platform such as mobilerun, you can build workflows that interact with apps through their actual interfaces rather than depending on an API.

What does Facebook Marketplace automation actually mean?

When people say they want to "automate Facebook Marketplace," they can mean different things. For a buyer or reseller, automation might mean:

Searching for specific products
Filtering listings by price or location and collecting information about them
Comparing prices, Organizing results
Identifying potentially profitable deals
Monitoring new listings and opening promising listings
Preparing messages for sellers and negotiating prices

For a seller, it might mean:

Creating listings and entering product information
Uploading photos and updating listings
Managing multiple products and responding to repetitive inquiries

The important point is that Marketplace automation is not one task but a workflow. So the more repetitive steps you can connect, the more time you can save.

Why automate Facebook Marketplace?

The biggest motivation isn't usually technical. People want automation because manually searching the Marketplace doesn't scale.

Imagine you are looking for used iPhones to resell. You could manually search the Marketplace every morning, open individual listings, record prices, compare them with other listings, determine which ones look interesting, and contact sellers.

Doing this for 20 listings is manageable but not for 200. And if a good deal gets posted while you're not looking, you may never see it. This is why Marketplace automation is particularly interesting for resellers, local retailers, used electronics buyers, furniture resellers or buyers, deal hunters etc.

Users need the marketplace automation for collecting price and description data and automatically comparing a listing against similar products to determine whether it was worth buying.

The goal isn't really scraping but finding valuable information without manually searching for it.

The traditional way to automate Marketplace

The conventional approach is browser automation. A developer might use tools such as Selenium or Playwright to:

This flow looks pretty straightforward on the chart but it is difficult to maintain. Developers report encountering JavaScript-rendered pages, login challenges, bot detection, changing page structures, and scrapers that stop working after updates.

There is also an important platform-policy consideration: Meta has stated that automated scraping of its products requires permission. Anyone building a Marketplace automation workflow should therefore review and comply with Facebook's current terms and applicable policies rather than assuming that technical access means permitted access.

This creates a fundamental problem with traditional scraping: You are automating the underlying website rather than the task a human actually performs.

A different approach: automate the mobile interface

Instead of building a scraper specifically for Facebook's underlying web infrastructure, you can automate the application interface itself. This is where mobile agents become useful.

Mobilerun provides an environment where an AI agent can interact with mobile applications using natural-language instructions. Instead of writing a separate script for every button and page, you can describe the workflow you want the agent to perform.

For example:

Open Facebook Marketplace and search for used iPhone 15 Pro listings under $500. Collect the title, price, location and listing details from the relevant results.

The agent can then navigate the mobile interface and perform the workflow. This approach is particularly useful when the task involves multiple steps and decisions, rather than simply extracting a fixed set of HTML elements.

Step 1: Define what you're looking for

The first step in Marketplace automation is defining your criteria. For example:

Product: iPhone 15 Pro
Maximum price: $500
Location: Within 50 miles
Condition: Used, working
Goal: Resell

You can make the criteria more sophisticated as well. For example:

Find used MacBooks under $700, prioritize listings posted recently, and identify listings where the price appears significantly lower than comparable products.

The more clearly you define the objective, the more useful your automation becomes.

Step 2: Automate Marketplace search

Once your criteria are defined, the agent can navigate the Marketplace and perform the search. Instead of manually entering the same keywords and filters repeatedly, the workflow can handle those interactions.

For example:

Search → select Marketplace → enter keyword → apply filters → inspect results

This is especially useful for people monitoring multiple products. Instead of spending an hour searching iphones, macBook etc. you can build workflows around each search.

Step 3: Collect listing information

The next step is turning Marketplace results into useful information. For every relevant listing, you might want product name, price, location, description, seller info, listing link, images etc. The important difference is that the automation doesn't have to stop at collecting raw listings. It can move on to understanding them.

Step 4: Use AI to identify interesting deals

This is where Marketplace automation becomes more powerful.

Suppose your automation finds 100 listings but you don't want all 100. You just want to know “which ones are worth looking at?”

An AI model can analyze the information collected from the listings and apply your criteria.

"Identify listings priced at least 20% below the apparent market price."

Or:

"Find listings that appear suitable for resale and exclude damaged or incomplete products."

The workflow becomes: Search → collect → analyze → filter

Instead of: Search → manually open 100 listings → manually compare them

Step 5: Build a deal-monitoring workflow

You can take the process one step further by turning it into a recurring workflow. For example you can ask the agent:

Every morning open the marketplace, search for selected products, collect new listings, filter by price and location, analyse potentially interesting listings, create a shortlist and notify you of the results.

This changes the Marketplace from something you manually browse into a source of continuously monitored opportunities.

A similar motivation appears in Marketplace automation discussions going back several years: users have wanted scripts that continuously search for keyword matches and alert them when relevant listings appear.

Step 6: Automate repetitive seller workflows

Marketplace automation isn't only useful for buyers. Sellers often have the opposite problem. They have products to sell but don't want to repeatedly perform the same listing process.

A listing workflow might involve: Open Marketplace and select "Create listing". Select the product category, upload photos, enter title, description, price, location. Then finally review the listing and publish it.

When you have one product, this isn't a big problem but if you have dozens of products, it becomes repetitive.

People have specifically asked about automating Marketplace listing creation because manually creating large numbers of listings is time-consuming. With mobile automation, these repetitive UI interactions can become part of an automated workflow.

Step 7: Automate repetitive message workflows carefully

Another area where automation can help is communication. For example, a seller may receive the same questions repeatedly:

Is this still available?
What's the lowest price?
Can you meet today?
Is delivery available?
What condition is it in?

A workflow could help organize and handle repetitive parts of this process. For more consequential interactions such as negotiating prices, making commitments, or sending large numbers of messages it is generally better to keep a human review step.

Step 8: Connect the entire workflow

This is where the idea of a Marketplace "agent" becomes more interesting than a simple scraper. A complete workflow could look like:

Why mobile automation can be useful here

Traditional scraping is usually designed around data extraction. Mobile agents are designed around interaction..

A scraper might answer: "What listings exist?"

A mobile agent can potentially handle a broader workflow: "Search Marketplace for these products, inspect the results, identify relevant listings, and organize the information."

This makes mobile automation useful for applications where there isn't a convenient API for the exact workflow you want to build. It also means you don't necessarily have to build and maintain a custom automation script for every individual UI interaction.

Automate Facebook Marketplace without building everything from scratch

With mobilerun ai, you can connect a mobile device and use an AI agent to interact with applications through their interfaces. That means you can build workflows around Facebook Marketplace without having to start by developing an entire custom browser automation stack.

For example, a workflow could be instructed to: Search Facebook Marketplace for a specific product, collect relevant listings, and organize the results based on price and location.

The same mobile agent can be used for other apps and workflows as well, making the infrastructure reusable beyond Marketplace.

Reddit Marketing in 2026 How to Get It Right

Priya Negi — Tue, 15 Sep 2026 07:32:27 +0000

Reddit is one of the most interesting marketing channels for brands today. It has millions of active users across thousands of communities, each built around a specific interest. That makes Reddit valuable for reaching highly relevant audiences without necessarily relying on traditional advertising.

But Reddit marketing is not the same as marketing on LinkedIn, X, Instagram, or TikTok. On most social platforms, brands can openly promote themselves. A polished product video, a strong CTA, and a link to the website are often expected.

On Reddit, that approach can work against you. Reddit is fundamentally community-driven. People come to individual subreddits to discuss topics, ask questions, share experiences, debate ideas, and discover interesting things. Promotional content is often treated with skepticism, especially when it feels like it was created primarily to sell something.

That means successful Reddit marketing is less about “How do I promote my product?” and more about “How do I create something this community actually wants to react to?”

Why Reddit Is Different From Other Marketing Channels

The biggest mistake marketers make on Reddit is treating it like another social media distribution platform. You can't simply take a LinkedIn post, add a Reddit title, paste your website link, and expect the same results.

Reddit is organized around communities, not followers

On platforms such as Instagram or LinkedIn, your audience is largely built around your account. But on reddit a person might follow very few accounts but actively participate in dozens of communities. Each subreddit has its own culture, expectations, vocabulary, and rules.

A post that performs well in one subreddit can completely fail in another. This means audience selection matters as much as content creation.

Before posting, analyse:

Who actually uses this subreddit?
What kinds of posts get engagement?
Are people there looking for advice, entertainment, discussion, news, or solutions?
Does my content naturally belong here?
Would someone post or discuss this topic even if my company didn't exist? That last question is particularly useful.If the answer is no, the post probably needs to be reworked.

Reddit rewards conversation over promotion

Reddit users don't necessarily want to be marketed to. They want something worth discussing. That's why a simple statement can sometimes outperform a highly produced advertisement.

For example: “My AI agent controls my mobile device.” That's not a traditional marketing headline because it does not explain every feature or ask you to sign up.

But it creates a question in the reader's mind, how is it working, that curiosity can drive comments and discussion. This is where statement-based content works particularly well on Reddit.

Instead of: “Our AI platform can automate tasks across mobile apps. Try it today.”

You might frame the same capability as: “AI agents controlling phones feels very different from traditional automation.”

Create Content for Reddit, Not Just Content You Post on Reddit

Once you've found the right subreddit, the next challenge is content. One of the most useful approaches is to separate content creation from content distribution. A good video isn't automatically a good Reddit post.

The same video can perform completely differently depending on the headline, subreddit, timing etc. This is why distribution deserves as much attention as creation.

Test Multiple Hooks for the Same Video

You don't always need to create five different videos to test five ideas. Sometimes, you can use the same video with different hooks. For example, imagine a 25-second video showing an AI agent ordering something through a mobile app.

You could test:

AI agents can now operate mobile apps.
I let an AI agent use my phone.
What happens when an AI gets control of a phone?
Mobile a utomation is getting weird. This is what an AI agent actually doing things on a phone looks like. The underlying video stays the same but the framing changes. This makes it easier to learn what kind of messaging attracts attention.

Don't Judge Reddit Content Too Quickly

Reddit marketing requires consistency. One post isn't enough to determine whether Reddit works for your product. Give an approach 2–3 weeks of consistent testing before making a major judgment.

During that period, try different headlines, angles, tone, videos, posting formats, subreddits etc. Try to understand what the Reddit audience responds to.

Maybe technical explanations work better than product demonstrations. Maybe short videos outperform longer ones. Maybe controversial statements generate more comments. Maybe videos without voice perform better. The only way to know is to test.

Short Videos Don't Always Need to Be Polished

This is another major difference between Reddit and many other social channels. On platforms such as Instagram or TikTok, marketers often spend significant time making content look polished.

On Reddit, rough can sometimes beat slick. A screen recording showing something genuinely interesting can be more effective than a heavily edited promotional video. Because Reddit users are often evaluating the idea, not the production quality.

Change the Story and reuse the Video.

One of the most efficient Reddit strategies is content reuse with contextual adaptation. You don't necessarily need a completely new video for every subreddit. The same video can be posted in multiple relevant communities, provided the content genuinely fits each community's interests and the post isn't spammy or repetitive.

The key is to change the framing. Imagine you have a video showing an AI agent completing a workflow inside a mobile app.

In one subreddit, the headline could focus on AI: “AI agents are starting to interact with software visually.”
In another, it could focus on automation: "This is what mobile automation looks like when you don't rely on APIs.”
In another, it could focus on the experiment: “I wanted to see how far an AI agent could get using a real mobile app.”
The important part is that the headline should actually reflect why the content belongs in that particular subreddit.

What If the Subreddit Doesn't Allow Videos?

Many subreddits have restrictions around video, promotional content, links, or self-promotion. Don't immediately discard the community. If the audience is highly relevant, change the format.

Instead of forcing a video into the post, create something designed to generate discussion.

The Rules That Matter Most

Reddit marketing becomes much easier when you treat Reddit like a collection of communities rather than one giant social network. Here are the rules worth keeping in mind.

1. Find the right subreddit :

Relevance comes first. Don't post something simply because a subreddit has a large audience. A smaller subreddit containing exactly the people interested in your topic can be far more valuable.

2. Check the community rules

Before posting, look at the community rules for videos, text, link, promotion, karma requirement, preferred post format etc. Ignoring these rules is one of the fastest ways to get posts removed.

3. If videos aren't allowed, change the format

Don't fight the subreddit. If you think the audience is valuable, create a text post that encourages discussion instead.

4. Avoid unnecessary links

Links can make a post look promotional and may also trigger spam filters or community moderation. If someone asks where they can try or learn more, that's a much more natural opportunity to share it.

5. Don't make every post a product pitch

A Reddit account that only talks about its own product will quickly look like a marketing account. Mix the format or keep your profile private.

Ask for Opinions

Sometimes the simplest Reddit post is the best one. You can post a video and ask: “What do you think?” This gives people an obvious reason to comment. And importantly, it doesn't require an aggressive CTA.

You're not asking someone to sign up. You're just asking them to participate. That distinction can make the post feel much more native to Reddit.

Authenticity Matters More Than Branding

One of the most important principles of Reddit marketing is authenticity. People are generally more receptive to content that feels like it came from a member of the community rather than from a marketing department.

That means you don't need to turn every post into a branded announcement. You can lead with the interesting thing itself.

But don't confuse authenticity with deception

There's an important distinction here. You should avoid pretending to be an independent user when you're actually representing a company.

You don't need to make every post a corporate announcement, but you also shouldn't manufacture fake grassroots support or conceal a material affiliation when the community's rules require disclosure. The goal is native communication, not fake identity.

The Core Principle

Reddit marketing isn't about finding the perfect advertisement. It's about finding the right conversation.

The best Reddit posts often don't feel like advertisements at all. They feel like someone discovered something interesting, tested something unusual, asked a good question, or started a debate.

That's ultimately what makes Reddit valuable. You're not simply buying attention. You're learning what people actually care about.

When you get that right, Reddit can become more than a distribution channel. It can become a source of audience insight, content ideas, product feedback, and highly relevant organic discovery.

With tools like mobilerun, the repetitive execution behind that strategy can also become easier to manage. Instead of spending time repeating the same mobile workflows, marketers can automate parts of the process and spend more of their time on what actually matters: choosing the right communities, creating interesting content, and understanding what resonates.

DEV Community: Priya Negi

The B2A economy runs on phones: a16z

What a16z means by B2A

Most real tasks live in apps

Why a browser agent hits a wall here

How Droidrun approaches it

How Mobilerun provides it

The honest limits

The takeaway

*Also Read:*

How to Get Clients on LinkedIn Using mobilerun AI

Execution is the real bottleneck

What changes when the agent uses the actual LinkedIn app?

1. Connect a device

2. Install LinkedIn

3. Give the agent instructions

Personalization without writing every message yourself

Two ways to build the workflow

Option A: You have Sales Navigator

Path B: if you do not have Sales Navigator

How much LinkedIn outreach should you send?

Once it is set up, you stop doing anything

Getting started

I Gave Grok Bot Access to a Mobile| Here's How

Why we tried this

What you're actually building

How to set it up

Step 1: Get a Mobilerun account and API key

Step 2: Connect Mobilerun to Grok Bot

Step 3: Give it a task

What Grok Bot can do with a phone

How this compares to the Claude setup

A few things worth knowing

The bigger picture

Get started

Why can't my AI agent use mobile apps?

Why the problem exists

What you can do today

How Matix and Mobilerun approach it

When Matix is not a fit

How do AI agents stay logged in between runs?

Why agents keep getting logged out

Ways to preserve state today

How Matix and Mobilerun approach persistent mobile execution

When a persistent environment is not the right choice

Is it safe to let an AI agent control a phone?

Why giving an AI agent access to your phone is risky

How to give an AI agent a safer environment

How Matix and Mobilerun approach mobile agent isolation

When a separate mobile environment is not the right fit

10,000 Stars on GitHub: Our Journey Building Mobilerun in Public

The Beginning

Early Validation and Recognition

Funding

What we’ve built since

Looking Ahead: The Momentum Continues

Join Us in Building the Future

How to give your AI Agent access to a Real iPhone

Why iPhone automation is difficult

From a prompt to a real iPhone

What can you automate?

1. Messaging workflows

2. Navigating apps

3. Repetitive mobile tasks

Why use a real iPhone instead of a simulator?

Try it yourself

Why AI Agents Keep Getting Blocked and What It Will Take to Fix It

Why are websites blocking AI agents?

1. Websites cannot always distinguish helpful agents from harmful bots

2. AI agents challenge existing business models

3. Account security becomes more complicated

4. Businesses bear the cost when agents make mistakes

5. Competition is also part of the picture

What does this mean for users?

Why blocking agents alone is unlikely to solve the problem

What needs to change?

1. Give AI agents a verifiable identity

2. Establish clear permissions and delegated access

3. Move beyond scraping when structured integrations are available

4. Create sustainable models for access

Also Read: