← AI-Lens

One QA agent · any product · any cloud · any model

End-to-end flow, requirement to report

Five stages over one knowledge base, invoked from the tools your team already uses, generating scripts for any framework and running them on the real application.

ENTRY POINTS — THIN CLIENTS OVER ONE ENGINE VS Code Cursor Katalon Studio CLI · CI pipeline DevRev Jira · Azure DevOps invoke · review · approve AI-LENS WORKBENCH · MODEL-AGNOSTIC · DEPLOY ANYWHERE One knowledge base what is true about the app — observed, not assumed · every run makes the next one smarter live app walk BRD · PRD · DRS Jira · DevRev history run evidence CRM · products held Voice of Customer Voice of Machine · logs, APM Context layer what every agent is told before it acts project instructions 16 hard rules skills agent definitions design brief persona & auth memory every later stage reads both EXPLORATION AGENT 1 Live walk exploration agent walks the real app or device CAPTURES screens · controls · rules verified locators → KB 2 Test case design requirement analysis, then risk-based design IN → OUT BRD · PRD · stories · KB register + RTM + pack 3 Script generation only controls the walk has verified ANY FRAMEWORK Playwright · Selenium Katalon · Appium · k6 4 Execution on web & app on the real app, through your runner SURFACES web · Android · iOS · API no model at run time 5 Reporting results, coverage, requirement defects SINKS Jira · DevRev defects RTM · dashboards · CI HUMAN GATES Gate 1 review the pack Gate 2 name the cases named ids only fails on the app → regenerate app changed · coverage gaps · defects → the exploration agent re-walks Provider adapter — model agnostic one interface; nothing above it knows which model runs Claude GPT Gemini Llama · local any OpenAI-compatible DEPLOY THE SAME ENGINE ANYWHERE AWS EKS · EC2 · Bedrock OCI OKE · compute On-premises private data centre Engineer machine laptop + attached device context layer exploration agent · knowledge base pipeline stage human decision swappable — any tool or model feedback loop
How to read it. Top to bottom. Where work is asked for; what grounds every agent (slate context, teal knowledge base); the exploration agent (teal, step 1) walking the live app and building the knowledge base; the amber stages after it, with requirement analysis inside test case design and the two green human gates between design and code; rose feedback loops; the violet model adapter; and where it all runs. The knowledge base also takes business signal — CRM, Voice of Customer and Voice of Machine — so test priority follows what customers hold, complain about and hit in production.

The loop

The whole loop, and the two places a human decides

Read it clockwise. The top row is everything the agent does on its own; the bottom row only happens to cases a person has named. Nothing crosses from one row to the other except through a green box. The small tag in each box names who does that step.

THE AGENT, ON ITS OWN ONLY CASES A PERSON NAMED INPUTS user stories · Jira the live build operator · Katalon chat WALK the live web app or device, via MCP explorer subagent KNOWLEDGE BASE screens, controls, rules, evidence domain-grapher TEST DESIGN cases, each citing a story criterion journey-designer · design subagents GATE 1 — REVIEW PACK a human reads the xlsx and accepts or rejects each case human decision named ids only GATE 2 — NAME THE CASES named ids only — never “all”, never the agent’s own call human decision MATERIALISE .tc + Groovy + .rs written to the project automation job · automator KATALON refresh the tree, press Run human · Katalon Studio SUITE RUN report tied back to the story criterion Katalon runner · no model call THE APP CHANGED — RE-WALK AN UNVERIFIED CONTROL IS NEVER EMITTED — THE GAP IS REPORTED AND RE-ENTERS AT THE WALK. GREEN BOXES ARE HUMAN DECISIONS — NOTHING REACHES THE PROJECT WITHOUT PASSING BOTH.
How to read it. Violet tags are agents (detailed in the next figure), green tags are people, slate tags are plain tools. The top row can run end to end unattended and still change nothing in the Katalon project — the only way down is Gate 1 then Gate 2.

Who does the work

One orchestrator per job, and the subagents it launches

A request from Katalon chat, an IDE or CI reaches the MCP server. A deterministic job manager — no model in it — starts one headless claude -p orchestrator per job. Each orchestrator dispatches subagents for its phases. Test design happens in two places: inside the explore job (explorer, domain-grapher and journey-designer build the knowledge base and the register) and as its own job, where a test-architect orchestrator dispatches eleven design subagents to write the review pack.

WHERE THE REQUEST STARTS Katalon Studio chat stakeholder types the ask VS Code · Cursor engineer, same tools CLI · CI pipeline headless, unattended qa-agent MCP server explore_product · generate_test_design · walk_gate · resume_walk · materialize · job_status Job manager — deterministic, no model spawns one headless claude -p orchestrator per job · sets its model (sonnet by default) · streams progress back · holds the engagement lock for walks explore job test-design job automation job EXPLORE JOB · PHASES 1–3 walk, knowledge base, test-case register Orchestrator · claude -p (sonnet) plans the walk, dispatches the three subagents, persists what they return, runs detect explorer · sonnet · read-only walks the live app or device through MCP; capture-screen proves every control domain-grapher · sonnet · read-only builds the KB from walk + BRD / PRD: screens, controls, rules, evidence journey-designer · opus · read-only 7-type taxonomy → CSV register plus one Markdown plan per journey Stops at the GATE no test code; nothing written to automation/ TEST-DESIGN JOB stakeholder ask → review-pack workbook Test architect · claude -p (sonnet) dispatches the design subagents below; no device, no lock — it runs beside a walk Reads user-stories xlsx · design brief (first) KB catalogue · methodology · shape ref 11 design subagents requirement-analyst traceability-mapper risk-assessor journey-mapper scenario-designer edge-case-analyst automation-advisor platform-planner nfr-analyst gap-analyst design-reviewer One workbook → Gate 1 review pack “Device-proven” only when the KB case is verified AUTOMATION JOB · PHASES 4–6 starts only after Gate 2 names the case ids Orchestrator · claude -p (sonnet) automates only the named scenario ids, then runs the phases below in order automator · sonnet · the only writer replays each case live, keeps the winning locator; unprovable steps → documented code-grapher · haiku indexes emitted code: object inventory, traceability, locator health code-reviewer · sonnet · read-only audits output against the rule rubric; FAIL findings block delivery → Materialise into the Katalon project .tc + Groovy + .rs; a human refreshes and runs orchestrator (one per job) subagent — model from its definition hands off to a human gate Read-only subagents physically lack Write/Edit, so the gate is enforced by the tool whitelist, not by prompt wording.
How to read it. Amber is an orchestrator — a full Claude session the job manager starts and supervises. Violet is a subagent that the orchestrator dispatches; its model and its tool whitelist come from its definition file. Phases 1–3 subagents cannot write files, which is why the gate holds. The orchestrator model can be changed per job kind (QA_MCP_MODEL_EXPLORE / _GENERATE / _APPROVE) without touching the subagents.

Three orchestrators, and who each one launches

Orchestrator

Explore job

model
sonnet (QA_MCP_MODEL_EXPLORE)
does
Plans the walk, dispatches the Phase 1–3 subagents, persists what they return, stops at the gate.
launches
explorer, domain-grapher, journey-designer
Orchestrator

Test-design job

model
sonnet (QA_MCP_MODEL_GENERATE)
does
Acts as a principal test architect: stories + KB → one review-pack workbook, every case labelled BRD-derived or AI-inferred.
launches
11 design subagents — listed below
Orchestrator

Automation job

model
sonnet (QA_MCP_MODEL_APPROVE)
does
Automates only the case ids a human named, then indexes and reviews what it emitted.
launches
automator, code-grapher, code-reviewer

Test-design subagents and the workbook sheets each one produces

SubagentProduces
requirement-analystRequirement Inventory
traceability-mapperRequirement Traceability · Coverage Heat Map
risk-assessorRisk Analysis · risk-based scope
journey-mapperJourneys · Trading Lifecycle Coverage
scenario-designerTest Cases
edge-case-analystEdge & Negative Cases
automation-advisorAutomation Recommendations · Opportunities · Regression Pack
platform-plannerPlatform Coverage · Device & OS Matrix
nfr-analystPerformance & NFR · API & Virtualisation
gap-analystGap Analysis · Assumptions · Action Items
design-reviewerQuality Assessment · Executive Summary · Key Metrics

The five stages

Stage 1 · Exploration agent

Live walk

in
The live application — web or device — plus persona credentials
does
The exploration agent walks every reachable screen, proves each control with a captured locator, and records rules and behaviour as it actually happens.
out
The knowledge base: screens, verified controls, journeys, business rules, evidence
Stage 2

Test case design

in
BRD, PRD, DRS, user stories, Jira epics, existing manual cases — plus the knowledge base
does
Starts with requirement analysis — inventory, stable IDs, ambiguity flagged rather than guessed past — then applies risk-based, scenario, boundary and negative techniques against what the walk proved the app does.
out
Test design register, requirements traceability matrix and the review pack for Gate 1
Stage 3

Script generation

in
Only the cases a human named at Gate 2, plus the verified controls from the walk
does
Emits to whichever framework you standardise on — Playwright, Selenium, Katalon, Appium and others. No framework is baked in as a default. Scripts reference real controls, so they do not fail on locators that never existed.
out
Specs, page objects, fixtures, test data
Stage 4

Execution on web & app

in
Reviewed, merged scripts
does
Runs against the live product — web and mobile app — through whichever runner you already use. A failure routes straight back to generation with the observed behaviour attached.
out
Results, traces, screenshots, run evidence
Stage 5

Reporting

in
Run results across the suite
does
Publishes results and coverage, and raises defects — including requirement defects where the application and the specification disagree.
out
Reports, RTM and coverage export, Jira and DevRev tickets

It meets your team where they already are

No new console to adopt. The engine is headless, so each surface is a thin client over the same pipeline — and the same engine runs unattended in CI.

VS CodeCursor Katalon StudioCLI CI pipelineDevRev JiraAzure DevOps

One knowledge base, continuously enriched

The knowledge base is the reason generated tests reference reality. It is built by walking the live application and is fed by everything else that already knows something true about the product.

Live app explorationBRD · PRD · DRS Jira & DevRev historyRun evidence CRM — products held Voice of Customer Voice of Machine
Business signal sets priority

CRM, Voice of Customer and Voice of Machine turn test priority into a business decision: the products customers actually hold, the journeys they complain about, and the paths that fail in production are tested first and deepest.

Model agnostic, framework agnostic, deploy anywhere