Build an agent loop that fixes mobile bugs and proves each fix

Quick answer

An agent loop for mobile bugs takes an error from production to a reviewed fix. EAS Observe reports the error that users hit. An agent reproduces it on a cloud simulator with Expo Simulators, writes the fix, and runs the same steps again to prove it. Then a person reviews the proof on the pull request and decides if it merges.

Before, a bug report started a slow hunt. Someone found the app version, built it, installed it, and tried the steps, just to learn whether the bug was real. Now an agent can do that hunt, when it has the error, the code, and a running app. Then the person who used to reproduce the bug reviews the proof instead, so the fix reaches review with the hard part done.

For the general idea of agents in a mobile workflow, see What is an agentic workflow for mobile development? The loop below is the bug fix version, step by step.

Step 1: Report the error from production

The loop starts when a real user hits an error. You see it because EAS Observe records errors from your app through the expo-observe library. The library catches unhandled JavaScript errors as soon as it is imported. For render errors, you wrap a screen in ObserveErrorBoundary. The error then comes with its React component stack, and the user sees a fallback screen. For errors that your code catches, you call Observe.reportError. From expo-observe 57.0.21, the library also records native crashes on Android and iOS.

Each error lands on the Errors page of the EAS Observe dashboard, where you see how often it happens, how many users it affects, and how it splits across platforms. When a source map is stored for the build or the update, the stack trace points at your source files. Error reporting in EAS Observe is in preview and needs SDK 57 or later.

Step 2: Hand the error to an agent

You pick the error to fix, and you hand it to the agent with one click. On the error's page, Hand off to AI prepares a prompt with the error, its stack trace, the filters you applied, and the split by app version, OS, device, and country. You send that prompt to your coding agent.

With the prompt in hand, the agent maps the stack trace onto your source and pulls more context with the eas observe commands:

The first command lists the occurrences of one error with their stack traces. The second shows the full event timeline of one session. The third lists app versions with their build numbers and update IDs, so the agent knows which code your users ran. The eas-observe skill teaches the agent these commands.

Because Hand off to AI starts with your click, a person always picks which errors go to an agent. To start an agent from a ticket queue or another trigger, you use your own automation.

Step 3: Reproduce the bug on a cloud simulator

To see the bug, the agent needs the app running. A cloud agent's sandbox usually has no iOS Simulator. Expo Simulators gives it one on EAS. With the eas-simulator skill, the agent checks access with eas simulator:availability --json and picks a build. Then it starts a named session, installs and opens the app, and drives it with agent-device commands such as snapshot -i, press, and fill.

The build matters here. For a bug in a release, the agent uses a simulator build of the same commit. A release build carries the JavaScript bundle from build time, so it shows the bug the way users saw it. A matching build fingerprint only means the native code matches, and the agent builds from the commit itself.

The recording of the bug is the first half of the proof, and the reviewer sees it next to the fix.

Step 4: Write the fix and prove it

Now the agent changes the code. While it works, it can use a development build with Metro, which shows each JavaScript change with Fast Refresh and skips a rebuild. For the final proof, it makes a build of the fix and runs the same steps again, so the reviewer compares the same path on both builds.

The proof has three parts: a screenshot of the broken state and one of the fixed state, a recording of the steps on each build, and the session activity. eas simulator:events lists each action the agent took, in order. The agent stops each session when it finishes, and EAS keeps the session artifacts, such as recordings, until you delete the session.

Step 5: Put the proof on the pull request

The reviewer opens the pull request and finds the proof already there, because the agent, or your CI job, attaches the screenshots and the recordings. A create session link in the description lets the reviewer open the fixed build in the browser and tap through it. They sign in to an Expo account that can access the project, with the Developer role or higher. Each click starts a new session, and reviewers stop it when they finish. See Share a new build with a simulator link.

For more trust in the proof, a second agent can check the fix. It stays separate from the agent that wrote the fix. It starts its own session from the pull request build and tries to break the fix, so the reviewer sees a fix that held up to someone other than its author. See Human validation vs agent validation.

Step 6: Merge, ship, and watch the error

Once the reviewer is happy with the proof, they merge. A JavaScript-only fix can go out as an EAS Update, rolled out to a share of users first and then to everyone. A native fix needs a new store build, through EAS Build and EAS Submit.

Then you watch the same error in EAS Observe. Its Occurrences tab lists each report with the app version it came from, so you can see if the new version still reports it. For the trade-offs between a store release and an over-the-air update, see How to fix a production bug without waiting for App Store review.

Which Expo tool runs each step?

What stays with a person?

Through the whole loop, a person makes the calls: which errors go to an agent, whether the proof is enough, when to merge, and when the fix ships. If you release with EAS Workflows, a require-approval job holds the release until someone approves it.

Let an agent set it up

Have the agent load these Expo Skills first:

• expo-overview: the entry point that routes the agent to the right Expo skill.
• eas-observe: reads errors, sessions, and versions with the eas observe commands.
• eas-simulator: starts a cloud simulator session, drives the app, returns screenshots and recordings, and stops the session.
• eas-update: ships a JavaScript-only fix as an over-the-air update.

Install them:

• Claude Code: claude plugin install expo@claude-plugins-official
• Codex: codex plugin add expo@openai-curated
• Cursor and other agents: npx skills add expo/skills

The full list is at docs.expo.dev/skills.

Try it

Expo Simulators is in a limited beta release. The docs cover EAS Observe error reporting and letting an agent verify a change.

Try Expo Simulators

Verified on 29 October 2026.