A batch reduces round trips. It should not hide uncertainty. Put the steps you already understand in one call, then inspect the resulting screen before crossing into an unfamiliar state.
Mobilebox accepts 1 to 20 actions per batch. Actions run in order, the batch stops at the first failure, and the response includes the results and current screen. A batch stops starting new actions after its 120-second budget.
A small batch with a clear boundary
{
"actions": [
{ "type": "open_app", "package": "com.android.settings" },
{ "type": "wait_for", "text": "Search settings" }
]
}The text in a wait_for action must match the UI you actually observe on your build and locale. This example illustrates the shape; it is not a claim that every Android Settings build uses that label.
If the initial screen is unfamiliar, opening the app is a reasonable batch boundary. Read it before guessing the next label. For known screens, a text-targeted tap and type operation can share a batch.
HTTP success is not action success
The action endpoint can return HTTP 200 with a failed per-action result. Check every results entry’s ok field. Do not treat the transport status as proof that all actions ran.
When action three fails, actions one and two may have changed the app and actions four onward did not run. Resume from the returned state. Do not replay the entire batch unless you have established that replay is safe.
Wait for meaning, not just time
Use wait_for for a visible condition, or scroll_to to find text below the fold. A fixed wait may be appropriate for a known transient animation, but adding longer sleeps to every step makes a workflow slower without proving readiness.
wait_for is bounded; it does not wait forever. A timeout should trigger observation and diagnosis, not an unlimited retry loop. The reference lists the exact action limits.
Keep the final assertion outside the action plan
A successful tap on Save tells you the input was delivered. Observe the saved item, reopen it where practical, and verify the expected content. The difference between a successful action and a completed task is the most useful boundary in an agent test.