How We Automated X (Twitter) With an AI Agent on a Real Phone

Creating and managing a new X account takes more than just posting. If you want to build a consistent presence, you need to regularly open the app, read through your timeline, engage with relevant posts, reply to conversations, and keep up with what is happening in your niche.

We wanted to see how much of that routine work an AI agent could handle on its own.

So we gave our agent access to an X account running on a dedicated Android device and let it handle the routine engagement for a month.

Here's exactly how we set it up, what we told the agent, and what we learned from the experiment.

Why a phone and not the API?

The obvious question is why use a phone at all when X has an API.

The API and the mobile app are fundamentally different interfaces. API access comes with its own pricing, limits, and supported functionality. More importantly, there are many things you can do inside the mobile app that are not necessarily available through an API.

With a real Android device, the agent operates the same interface that a person uses. It opens the app, reads what's on screen, scrolls through the timeline, taps on posts, writes replies, likes posts, and reposts content.

There is no separate automation API involved in the actual interaction.

This is the core idea behind Mobilerun: you can automate an app even when the app does not expose the functionality you need through an API, because the agent operates the app itself.

The setup

There were three main parts to our setup.

The Cloud Phone

We used a Mobilerun Cloud Phone as the dedicated Android device for the account.

The important part here is persistence. This isn't a temporary session that starts, runs a task, and disappears. The device maintains its state over time.

The login stays there. The app data stays there. The cache and history stay there.

That meant the same device was being used throughout the experiment rather than creating a completely new environment for every run.

This is useful for any long-running mobile automation workflow where maintaining application state matters.

The network configuration

Our Cloud Phone was configured with a consistent network environment using a SOCKS5 proxy.

We kept the same proxy throughout the experiment instead of changing it between sessions.

The goal wasn't to make the activity look like something it wasn't. It was simply to keep the environment consistent throughout the experiment.

Mobilerun's Smart IP functionality can also align the device's location, timezone, and language with the proxy country, helping keep the device configuration internally consistent.

A real account and email

The account was created using a genuine email address that we own and can access.

Verification works normally, recovery works normally, and the account has a real identity behind it.

For any automation experiment involving a third-party platform, using an account you actually own and legitimate credentials is the obvious place to start.

What we actually told the agent

Mobilerun takes natural language instructions, so our instruction was close to what we'd tell a person:

Open X. Scroll the timeline and find posts relevant to [our niche]. Reply to some with something substantive and specific to the post. Like some. Repost a few. Quote-tweet occasionally with your own take. Don't do all of these on every post, vary it. Spend a while reading between actions.

We deliberately didn't define a rigid sequence or specify an exact number of actions.

We didn't tell the agent to reply to exactly 12 posts or follow a fixed sequence of taps and actions.

Instead, we gave it a goal and let the agent navigate the application to accomplish it.

The agent uses vision and the accessibility tree together. This allows it to understand what is actually on the screen and select posts based on their content rather than simply interacting with fixed coordinates or predetermined UI elements.

That makes the automation much more flexible.

For example, if the timeline changes, the agent can still understand what it is looking at and decide what to interact with.

How we scheduled the automation

The other part of the experiment was deciding when the agent should run.

We didn't want to manually start every session, so we connected the Cloud Phone to Claude through MCP and let Claude handle the scheduling.

The sessions also weren't identical every day. We varied the timing and duration of the tasks so that the automation wasn't simply executing the exact same workflow at the exact same time every day.

Some sessions were shorter, some were longer, and some days had no session at all.

The important takeaway isn't that there is a magic schedule for X. The useful part is that Mobilerun lets us automate a recurring workflow without requiring us to manually open the app and start the agent every day.

What happened after a month?

We tracked the account's reply impressions throughout the experiment.

At the beginning, the account was getting very little visibility on its replies.

After consistently engaging with relevant conversations over the course of the experiment, reply impressions increased significantly.

The increase gave us a useful signal that consistent activity was helping the account participate in more conversations and reach more people.

The important part for us wasn't simply the number itself.

It was seeing how much of the repetitive work involved in maintaining an active presence could be delegated to an AI agent.

Connecting Mobilerun to Claude

Starting the automation manually every day would still leave us with a daily task.

So we connected the Cloud Phone to Claude using MCP.

For Claude Code, it's one command:

1claude mcp add --transport http mobilerun https://api.mobilerun.ai/v1/mcp \
2  --header "Authorization: Bearer dr_sk_YOUR_API_KEY"
Copy

For Claude Desktop, Cursor, or VS Code, add Mobilerun to your MCP configuration:

1{
2  "mcpServers": {
3    "mobilerun": {
4      "url": "https://api.mobilerun.ai/v1/mcp",
5      "transport": "http",
6      "headers": {
7        "Authorization": "Bearer dr_sk_YOUR_API_KEY"
8      }
9    }
10  }
11}
12
Copy

Grab the API key from cloud.mobilerun.ai. It starts with dr_sk_.

Once connected, Claude can control the Mobilerun device. We described the workflow once, configured the recurring schedule, and let Claude handle the execution.

Now, instead of writing a new instruction every day, we can let the system run the workflow and check the results.

The same thing works on a physical phone

This setup isn't limited to the cloud. The same framework can run locally against a real Android device over ADB with the Portal app, or an iPhone through the iOS portal flow. Mobilerun is open source, MIT licensed, and LLM-agnostic. You can install it with: pip install mobilerun. mobilerun run "Open X and reply to the top post in my timeline"

That means you can start with an Android phone you already have. When you need the automation to run continuously without keeping your own phone awake and connected, you can move the workflow to a Mobilerun Cloud Phone.

What we learned

The biggest takeaway from the experiment wasn't that an AI agent can click buttons inside X. That part is relatively straightforward.

The interesting part is that an agent can operate a real mobile application based on what it sees and understands, without requiring a dedicated API for every action. We gave the agent a goal instead of a rigid sequence.

It navigated the application, read posts, selected relevant conversations, and carried out the actions we asked for.Then we connected that workflow to Claude through MCP and removed the need for us to manually start it every day. That's the broader use case we're interested in with Mobilerun.

There are countless mobile workflows that people perform repeatedly because there is no API, the API doesn't expose the required functionality, or building a custom integration isn't worth the engineering effort.

With an AI agent operating the actual application, those workflows can be automated through the same interface people already use. The value isn't making automation look human.

The value is taking repetitive work off our hands while keeping the account, device, and workflow under our control. Automate an account you genuinely own and automate actions you would actually stand behind.The tedious work is what the agent should handle.