Arbigent: AI Agent Testing for Android, iOS, Web and TV
AI Agent for testing Android, iOS, and Web apps. Get Started in 5 Minutes. Arbigent's intuitive UI and powerful code interface make it accessible to everyone, while its scenario breakdown feature ensures scalability for even the most complex tasks.
At a glance
- What is it?
- Arbigent is a Kotlin testing framework that drives AI agents through Android, iOS, Web and TV interfaces, with scenario dependencies and a UI for authoring them. Its design bets on decomposition and provider customization rather than a fixed model stack.
- Who is it for?
- Adopt Arbigent if your test targets change often enough that selector-based UI tests keep breaking, and you want QA staff authoring scenarios in a UI while engineers run the saved YAML from existing infrastructure. Avoid it if you need deterministic, offline test runs or cannot send UI state to a hosted model provider.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The failure mode Arbigent was built around
Selector-based UI tests break when the interface changes underneath them. The README lists the usual culprits: A/B tests, updated tutorials, unexpected dialogs, dynamic advertising and user-generated content. Each of those can invalidate a test without any code change, and the maintenance burden lands on whoever owns the suite.
AI agents were the proposed fix, but the README is candid that they introduce their own problem. An agent given a long, compound task may open another app or click the wrong button. Arbigent's answer is to decompose the goal. A complex objective becomes smaller scenarios that depend on each other, with login feeding search as the README's example. The orchestrator manages execution flow across those interconnected scenarios.
The audience is split deliberately. QA engineers get a UI for scenario creation. Software engineers get a code interface and YAML files they can execute from existing test infrastructure. Arbigent is for teams whose interfaces move faster than their test suite can follow, and who are willing to trade determinism for that resilience.
Scenario dependencies and the orchestration layer
The mechanism that distinguishes Arbigent from a single-prompt agent is the dependency graph between scenarios. Instead of asking one agent to complete an end-to-end journey, you define a chain of smaller scenarios where each one starts from the state the previous one produced. The framework acts as mediator, deciding what runs when.
That decomposition is the whole argument. A short scenario has fewer places to go wrong, and when it does go wrong the failure is localized. The README frames this as making agent testing predictable and scalable, which is a claim about variance rather than speed. Nothing in the material quantifies how much variance drops, so treat the benefit as structural: you get smaller units to debug, not a measured improvement.
Two reliability features sit alongside the graph. Stuck screen detection notices when the agent is looping on the same screen and prompts it to reconsider. AI-powered image assertion, borrowed from Roborazzi, verifies decisions through image-based prompts and lets the AI re-evaluate. Both are recovery mechanisms, which tells you the authors expect agents to fail mid-run rather than assuming they will not.
How the framework sees a screen
Before an agent can act, it needs a representation of the interface. Arbigent optimizes and filters the UI tree to improve model comprehension, and it does not depend on accessibility information being present. Where accessibility data is missing, it supplies annotated screenshots instead.
That fallback matters for TV interfaces, which the README calls out separately. D-pad navigation is handled, and TV is listed among the supported targets alongside iOS, Android and Web. Accessibility trees on TV apps are frequently sparse, so the annotated screenshot path is not a nicety there; it is the primary channel.
The provider layer is where the OkHttp interceptor inspiration shows. The README states that the framework exposes interfaces for customization so users can adapt it to their own AI provider, OS or form factor, rather than waiting for upstream support. The default model is gpt-4.1, with gpt-4o-mini named as a cheaper option. That default is a cost decision as much as a capability one, and it is the first thing to check against whatever provider you actually intend to use.
Getting a run started
The README's promise is zero to AI agent testing in minutes, and the path it describes has two entry points. In the UI, you author a scenario visually and save it. From code, you execute the saved scenario, which the README describes as YAML files, and wire that into your existing test infrastructure.
The customization surface is a code interface for custom hooks: initialization and cleanup methods that run around scenario execution. That is where you put setup your scenarios should not have to know about.
Maestro YAML integration is the pragmatic piece. Existing Maestro flows can run as initialization methods inside an Arbigent scenario, so a login flow written in Maestro can establish application state before the AI agent takes over. The README gives onboarding completion and timing-sensitive setup sequences as examples. This is the right shape for adoption: you do not rewrite what already works.
MCP support extends the agent beyond UI interaction. Servers are configured as a JSON string in Project Settings, with an enabled field to disable a server by default at project level, and mcpOptions to override that per scenario. The README's example JSON nests a filesystem server and a github server under mcpServers, with enabled set to false on the second. Named uses include installing and launching applications, checking server logs, and retrieving debug logs.
Where Arbigent is the wrong tool
The framework sends UI structure and screenshots to a model provider. If your application handles data that cannot leave your infrastructure, and your provider is a hosted API, that constraint is not something scenario decomposition solves. The customization interfaces exist, but the README does not describe a shipped local-model path, so treating provider substitution as a configuration detail would be optimistic.
Cost and latency follow from the same design. Every step involves a model call, and the image assertion path adds another evaluation on top. The README positions gpt-4o-mini as the cost-effective choice, which is an acknowledgment that the default is not cheap. For a suite that runs on every commit across many devices, that arithmetic changes the calculus quickly.
Determinism is the other boundary. Arbigent is built for interfaces that resist stable selectors. If your app has a stable, well-labeled UI, a conventional instrumentation test will be faster, cheaper and reproducible, and an agent adds a probabilistic layer for no gain. The README's own motivation section is about interfaces that change, not about interfaces that do not.
The README also carries a warning about a spam account posing as Arbigent, naming two X accounts as the creator's. Verify the source before installing anything.
Maestro and Roborazzi: what Arbigent borrows and how it differs
Maestro is the closest comparison, and Arbigent integrates with it rather than replacing it. Maestro executes declarative YAML flows against a UI, and those flows are as deterministic as the selectors and timing they encode. Arbigent's agent decides what to do next from the current screen state, which is why it tolerates a moved button or an unexpected dialog that would break a Maestro flow.
The difference in approach is where control lives. In Maestro, you write the steps. In Arbigent, you write the goal and the scenario boundaries, and the model fills in the steps. Arbigent's Maestro integration is effectively an admission that the two are complementary: use Maestro for the parts that are stable and precise, use the agent for the parts that are not. If your flows are already reliable, adding an agent on top buys you nothing.
Roborazzi is a different kind of dependency. Arbigent pulls in its AI-powered image assertion to double-check agent decisions, and the README points to Roborazzi's own documentation for the behavior. That is the right place to look, because the semantics of the re-evaluation loop are defined there, not in Arbigent's README.
Version cadence, licence and what to watch
The release history is dense. Versions 0.80.0, 0.81.0 and 0.81.1 all landed within roughly a week in September 2026, and 0.81.0 is marked deprecated in the release listing, superseded the same day by 0.81.1. A cadence like that means pinning a version and reading release notes before upgrading, because a deprecated release appearing and being replaced within hours suggests the API surface is still moving.
The project is Apache-2.0, which permits use, modification and distribution, and the README lists the absence of licensing costs as a cost-saving feature. That covers the framework, not your model provider bill, which is where the real recurring cost sits. Apache-2.0 also includes a patent grant and requires attribution and notice retention; if you redistribute Arbigent inside a product, read the licence text rather than relying on a summary, and get legal input if the distribution is commercial.
Maintenance cost splits in two. The framework itself is a dependency you upgrade on the project's schedule. The scenarios are yours, and every one of them encodes assumptions about your app's flow. Decomposition limits the blast radius when a flow changes, but it does not eliminate the work of updating the scenario that covered it. The README does not describe a migration path for scenarios across major versions, so treat scenario YAML as something you own and version alongside your tests.
Editorial conclusion
Adopt Arbigent if your test targets change often enough that selector-based UI tests keep breaking, and you want QA staff authoring scenarios in a UI while engineers run the saved YAML from existing infrastructure. Avoid it if you need deterministic, offline test runs or cannot send UI state to a hosted model provider. Before committing, verify the MCP JSON parsing path in Project Settings, confirm which model IDs your provider exposes against the gpt-4.1 default, and read the AI-powered image assertion behavior in Roborazzi's documentation, since that assertion is what re-checks the agent's decisions.
Community notes