Goal-based agentic testing introduces a new layer within the automation pyramid, prompting questions about its precise placement.
Where does this actually sit in the automation pyramid?
The idea feels a bit new and unclear compared with the usual unit/integration/UI testing stack, so it’s worth clarifying how it fits into a real testing strategy
In this post, I’ll explain where I think goal-based agentic testing lives relative to the traditional mobile automation pyramid, and why it doesn’t replace the layers you already depend on.
A Quick Recap: What the Mobile Automation Pyramid Is
For mobile apps, we usually think in terms of:
The goal is simple:
- Lots of stable, fast tests at the bottom.
- Fewer, slower, less stable tests at the top.
It’s a sensible strategy because:
- Unit tests are cheap and fast.
- API/integration tests validate contracts.
- UI tests confirm behaviour from the user’s perspective.
That structure helps balance feedback speed with confidence.
Where Does Goal-Based Agentic Testing Live?
Right at the top of the pyramid, alongside UI/end-to-end tests.
Like UI tests, goal-based agentic tests:
- Interact with the app surface.
- Run against real screens and flows.
- Require actual app builds (emulator/device).
They operate in the same environment as Espresso, XCUITest, etc.
But unlike traditional UI tests, which are step-by-step scripts, goal-based agentic tests are defined by outcome rather than exact steps.
For example:
“Reach the logged-in home screen with a valid user”
…rather than:
“Tap here, type this, tap that.”
That’s the key difference: the goal is the focus, not the path.
So technically it sits in the top layer, but behaviourally it feels a bit more exploratory.
This Doesn’t Replace the Pyramid
Goal-based agentic testing is not:
- A replacement for unit tests.
- A substitute for integration tests.
- A reason to remove deterministic UI tests.
Those layers still exist and still matter.
You want:
- Strong unit coverage to catch logic bugs early
- Robust API/integration tests to validate boundaries
- Targeted UI tests for critical user journeys
Goal-based agentic tests add another angle on top; they help you cover variation and unexpected paths without brittle scripts, but they don’t reduce the need for lower layers.
Think of them as complementary, not substitutive.
A Useful Mental Model
Instead of seeing the pyramid as strictly vertical, I imagine it with a horizontal layer of behavioural exploration at the top:
The agentic layer sits with UI tests, but with a different purpose:
- Traditional UI tests = verify expected paths.
- Goal-based agentic tests = explore possible behaviours.
Neither replaces the other; they just answer different questions.
When This Makes Sense
Goal-based agentic tests are especially useful when:
- Your UI changes often.
- Scripted tests break on minor layout tweaks.
- You want broader coverage of flows without having to write lots of scripts.
- You need to deal with unpredictable mobile conditions (permissions, pop-ups, state changes).
They’re not a silver bullet, but they do reduce brittleness in UI-centric layers when used appropriately.
Final Thoughts
Goal-based agentic testing sits with your UI layer in the automation pyramid, but it behaves differently.
It’s not a standalone tier; it’s an extension of the top layer, focused on outcomes instead of rigid scripts.
And just like any layer at the top of the pyramid:
- Use it sparingly.
- Be clear about what it verifies.
- Keep it complementary to the rest.
Shift-left and strong fundamentals still matter; goal-based agentic tests just give you another way to handle variation without brittle scripts.
If you apply it thoughtfully, it can make your mobile automation stack more resilient, without uprooting the pyramid you already depend on.
