TR Book a 30-min call

Capabilities

What works today, what is shown in demos, and what is planned

Every capability on this page carries one of three maturity labels, taken from a single source that this site and Antrek Labs share. Live-verified means evaluated against a live model and run on real systems. Demonstrated means it works end to end in demos. Roadmap items stay listed, with a date or a pilot condition.

How to read the labels

Live-verified
Evaluated against a live model and run on real systems (Jira Cloud or Xray, GitHub, GitHub Actions). Evidence and date are shown on the card.
Demonstrated
Works end to end, shown with recorded model outputs (REPLAY) or on a live platform. The live model evaluation is not complete.
Roadmap
Not available yet, or only designed. Each item states a quarter or a pilot condition.

Concepts: maturity labels and REPLAY mode

Working in demos today

Capabilities you can see working

Problem, how it is solved, who decides, and the current label.

  • Requirement review

    Demonstrated
    Problem
    Ambiguous or incomplete stories turn into wrong tests.
    How it works
    AI reads each story for ambiguity, missing acceptance criteria and contradictions. Story content is treated as untrusted data and the output must match a schema.
    Who decides
    The analyst decides on every finding; the product owner approves the corrected story in Jira.AIHuman

  • Code and data consistency check

    Demonstrated
    Problem
    A story can disagree with what the code and data actually do.
    How it works
    AI compares the story with your code, read-only, and with masked results of restricted queries. Each finding cites a file and line or a query result, re-verified without a model.
    Who decides
    The analyst decides whether the document or the code is wrong.AISystemHuman

    Live model evaluation pending.

  • Test case generation and Jira/Xray publishing

    Demonstrated
    Problem
    Hand-written test cases trail behind delivery.
    How it works
    AI drafts positive, negative and boundary cases linked to acceptance criteria. After a preview, approved cases are published to Jira Test issues or Xray Cloud.
    Who decides
    The analyst approves, edits or rejects every case. Each approval is bound to the content of the case.AIHuman

    Live model evaluation pending.

  • Template-bound Playwright code and pull request

    Demonstrated
    Problem
    Generated code that invents selectors is hard to trust and maintain.
    How it works
    An agent verifies each step in the running app and maps it to your page objects. The model does not write TypeScript; the spec is filled from a template and opened as a pull request.
    Who decides
    The engineer reviews and merges. The platform's bot never merges.AISystemHuman

    Code agent packages await live evaluation.

  • Break-to-Verify

    Demonstrated
    Problem
    A green test can be green no matter what the app does.
    How it works
    Each test runs on the normal app, with a controlled fault switched on, and on the normal app again, similar to mutation testing.
    Who decides
    A test that stays green on the broken app merges only with an explicit, logged acceptance.SystemHuman

    Deterministic; no model evaluation needed. Becomes Live-verified with live platform evidence.

  • Control Tower

    Demonstrated
    Problem
    Stories, approvals, pull requests and runs are spread across tools.
    How it works
    One view across the flow, with review metrics shown next to their source tables.
    Who decides
    Managers follow progress, trigger deploy and nightly runs, and report.SystemHuman

  • Triage, repair PRs and bug drafts

    Demonstrated
    Problem
    Nightly failures pile up, and silent self-healing hides real regressions.
    How it works
    Rules classify failures first, AI second. A changed test ID becomes a repair PR that changes only the test ID; a real defect becomes a bug draft checked for duplicates.
    Who decides
    Engineers merge repair PRs; testers file, link, edit or reject bug drafts.SystemAIHuman

  • MCP client channel (e.g. Claude Code)

    Demonstrated
    Problem
    Engineers work in their IDE, not in yet another portal.
    How it works
    MCP clients such as Claude Code connect to the platform's MCP endpoint with API tokens and can submit drafts from the IDE.
    Who decides
    API tokens can submit drafts but cannot approve. Approval stays with people in the portal.AIHuman

  • CI results into Control Tower and triage

    Demonstrated
    Problem
    CI results live apart from the requirements they test.
    How it works
    The platform collects JUnit XML, Allure and Playwright reports from each run of the suite it generated, writes one result comment on the pull request and feeds the Control Tower.
    Who decides
    A system step. Failures go on to triage and human review.System

Roadmap

Planned, and listed on purpose

A roadmap item is not a feature. It stays visible so you can raise it early in a pilot conversation.

  • Manual test case import and learning library

    Roadmap
    Problem
    Many teams already hold large sets of manual test cases.
    How it works
    Import existing manual cases and build a library that learns from approved ones.
    Who decides
    Planned with the same approval gates as generated cases.AIHuman

    Condition: Date set by pilot demand.

  • Desktop (FlaUI) and mobile (Appium) code generation

    Roadmap
    Problem
    Not every application under test is a web app.
    How it works
    Template-bound code generation for desktop (FlaUI) and mobile (Appium).
    Who decides
    Planned with the same review and merge gates.AIHuman

    Condition: Date set by pilot demand.

    Antrek Labs delivers desktop and mobile test automation as a service today; the product does not generate this code yet.

  • Azure DevOps (Boards, Repos, Pipelines, Test Plans)

    Roadmap
    Problem
    Some teams plan, build and test in Azure DevOps.
    How it works
    Adapters for Boards, Repos, Pipelines and Test Plans behind the same ports as Jira and GitHub.
    Who decides
    The same approval gates apply.System

    Condition: Date set by pilot demand.

  • Azure OpenAI and other model providers

    Roadmap
    Problem
    Your policy may require a specific model provider.
    How it works
    The swappable model gateway keeps provider-specific code in adapters. Anthropic Claude is the working adapter today.
    Who decides
    Every prompt bundle passes its evaluation set against a live model before use.System

    Condition: Date set by pilot demand.

    Swappable model gateway; Anthropic Claude today.

  • Risk-based regression selection

    Roadmap
    Problem
    Full regression runs take time on every change.
    How it works
    Select the tests most likely to catch a regression for a given change.
    Who decides
    Teams decide when selection replaces the full run.SystemHuman

    Condition: Unlocks when the criterion below is met.

    Risk-based selection unlocks once it catches ≥ 95% of full-run failures over 4 sprints.

  • Selenium to Playwright migration

    Roadmap
    Problem
    Existing Selenium suites hold years of knowledge.
    How it works
    Migrate Selenium tests to Playwright with the same template-bound approach.
    Who decides
    Every migrated test would be reviewed as a pull request.AIHuman

    Condition: Available today as an Antrek Labs service.

  • Sauce Labs cloud runs

    Roadmap
    Problem
    Some teams need the same tests on many cloud browsers.
    How it works
    A separate, non-blocking GitHub Actions job is built to run the approved Playwright suite on Sauce Labs. The adapter is ready; it has not been shown in a demo yet.
    Who decides
    A system step with no AI. Sauce credentials live only as GitHub Actions secrets.System

    Condition: Adapter ready as a GitHub Actions job; first run in a pilot.

Day one

What works on day one in your test estate?

Cells show maturity labels, not check marks. Labels differ by the kind of application you test.

Capability Web application (Playwright)Existing Selenium/Playwright suitesMobile / desktop applications
Requirement review Demonstrated Demonstrated Independent of the application under test. Roadmap Pilot condition: validated in the first mobile/desktop pilot.
Test case generation and Jira/Xray publishing Demonstrated Demonstrated Roadmap Pilot condition: validated in the first mobile/desktop pilot.
Template-bound Playwright code and pull request Demonstrated Prerequisite: a page object library and test IDs. Roadmap Selenium to Playwright migration. Roadmap
Break-to-Verify Demonstrated Prerequisite: controlled faults prepared in the test environment. Roadmap Pilot condition: verified in the pilot. Roadmap Needs prepared faults in the application.
CI results into Control Tower and triage Demonstrated Results from suites the product generates. Roadmap Importing JUnit XML from your existing suites. Pilot condition: verified in the pilot. Roadmap Pilot condition: validated in the first mobile/desktop pilot.
Triage, repair PRs and bug drafts Demonstrated Repair PRs change test IDs in generated tests. Roadmap Pilot condition: verified in the pilot. Roadmap
Not available todayApplies to every type of test estate.
Jira Data Center / Server Roadmap Date set by pilot demand.
GitLab, Jenkins and Azure DevOps pipelines Roadmap Date set by pilot demand.
Single sign-on (OIDC / SAML) Roadmap Date set by pilot demand.
Kubernetes / OpenShift deployment Roadmap Date set by pilot demand.

Start with one story.

In a 30-minute call we look at your stack and a few of your stories, and tell you honestly whether a pilot fits.

Book a 30-min call Read the security overview