Klarent (fore ai): agentic QA that writes and heals your tests, scored 6.0 on the U365 CI-First Review
Updated: 12 hours ago
Status: Active | Last tested: 2026-09-25 (Klarent as of the 2026-08-10 rename and the 2026-09-11 Microsoft Marketplace listing) | Re-check: trigger-based (max 6 months)
Active: the tool is current and recommended.
What Active means here. Active means current and recommended for the team this review describes: a web and mobile regression and smoke suite, in an authorised environment, with a named reviewer for repaired tests and at least one deliberately failing test in the suite. It does not mean the product is verified. No independent measurement of its reliability exists, its published accuracy figures disagree with each other, and its price is quoted rather than published. A reader who needs a measured guarantee, a published rate card, or a contractual commitment to resolve failures within a stated time should treat those as not yet available and act accordingly.
In this Tool Review
Status and Re-check
Re-check triggers:
A first independent measurement of generated-test accuracy or reliability. No third party had published one at the time of writing, and every tool directory found carries zero reviews, including one that publishes a 4.86 out of 5 score with no approved reviews behind it. Until a repeatable measurement exists, the Quality sub-score rests on vendor figures and on the product's own verification artefacts.
Publication of a public rate card. Pricing is an annual licence that scales with generated tests and test runs, and no list price is published. The figures a reader can currently check are an archived entry range on the vendor's previous product page and a per-test unit rate in the vendor's own blog. If a rate card appears, the Time and Quantity reasoning should be re-run against it.
A change to the self-healing workflow. The website describes automatic detection with a step-by-step diff reviewed before anything is applied. The product documentation describes opening a run, choosing Heal this test from the run menu, and the system healing the test automatically. If the diff review becomes a mandatory default, this review's Skill Illusion reasoning should be revisited.
A change to the data and model rights clause. Section 5.3 of the terms gives the provider sole property of any data models and algorithms generated from use of the service and from Customer Data, usable at the provider's free discretion. Any narrowing or widening of that clause changes the adoption calculus in section 7c.
Publication of an independent security assessment, or a change to the certification claims. The trust pages state ISO 27001 certification and SOC 2 compliance in some places and SOC 2 Type II compliance in others. The Trust Center itself requires an access request.
A named customer willing to speak publicly about measured results. Three named customers give attributed quotations on vendor-hosted case studies. The largest claim in the set comes from an anonymised Tier-1 bank and is labelled by the vendor as a modelled projection. A named, quantified, independently verifiable result would move the Quality sub-score.
A material change to the vendor's size or funding position. A company of 10 to 49 employees is being asked to sit behind a production-facing quality function. Third-party funding databases disagree with each other about how much has been raised, which is itself the reason to re-check.
The Klarent naming, stated before the review begins
A reader who searches for Klarent meets three different products and two names for the same company. The distinction belongs at the top.
Name | What it actually is | Relationship to this review |
Klarent | The product reviewed here: an agentic QA platform that generates, runs and maintains end-to-end tests for web and mobile applications from plain-English instructions | The subject of this review |
fore ai | The company, fore ai AG, registered in Zurich, Switzerland. It was also the product's name until 2026-08-10 | The vendor, and the product's former name |
Klarent CLI | A command-line interface shipped with the rename that lets a coding agent generate and run Klarent tests from a shell | A surface of the same product, documented in the vendor's announcement rather than in the public docs index |
Klart AI | An unrelated AI assistant for email, labelling and prompt generation, listed on G2 and GetApp | Not related. It appears in the same search results |
Clarent Labs | An unrelated UK vendor selling audit and accountability infrastructure for AI agents in regulated financial services | Not related |
Clarent / Clearent | A payment-processing product by Xplor Technologies | Not related, and it dominates Capterra results for similar spellings |
Two consequences follow. First, the rename is a branding change with a legal notice attached: the vendor's terms state that fore ai AG remains the contracting provider under all existing orders, that the change does not create a new agreement, and that all terms, obligations, pricing and support commitments continue unchanged. A reader who signed a fore ai contract has not signed a new one. Second, the older name still appears in the live product: the SAML endpoints in the vendor's own SSO documentation point at auth.foreai.co, the Trust Center is hosted at foreai.eu.trust.site, and the security contact in the privacy policy is security@foreai.co. That is ordinary migration residue rather than a finding, and it is recorded here so a reader who meets those strings during a security review knows they belong to the same vendor.
Tool Snapshot
Klarent (fore ai AG)
Tagline: "Autonomous testing for Web, iOS & Android. Klarent writes, runs, and maintains your tests, so your team can ship faster, without sacrificing quality." (klarent.ai, read 2026-09-25.)
Category: Agent platform applied to software quality assurance. A cloud service with a multi-agent engine that maps an application, plans a test from a plain-language instruction, generates executable code, verifies the result against the screen, runs the suite on demand or from a pipeline, and repairs tests when the interface changes. The vendor's own term is an agentic QA platform.
Primary use cases:
Replace a brittle scripted regression suite with tests described in plain English, maintained by the platform rather than by an engineer.
Let people who are not QA specialists author and own end-to-end tests, including product managers and business users.
Generate coverage from an artefact the team already has: a URL, a product requirements document, a Jira ticket, a Figma link, or an existing test.
Put a regression or smoke suite into the pipeline so every pull request or deployment runs it and a critical failure blocks the merge.
Test native iOS and Android applications without writing XCUITest or Espresso code, from a single plain-English definition.
Produce audit-ready execution evidence: per-step screenshots, traces with console and network detail, and an explicit triage of each failure as a real regression, a bad test, or an environment problem.
Pricing summary: An annual licence that scales with the number of generated tests and the number of test runs, quoted per customer, with no published rate card. Three figures from the vendor's own surfaces are the only ones available, and they answer three different questions rather than one. The product FAQ states the model and directs the reader to the sales team. An archived version of the vendor's previous product page, captured between December 2025 and March 2026, states that "smaller projects typically start at EUR 60-80k per year; enterprise deployments typically start in the six-figure range". The vendor's own unit-economics post states, in the author's own words, "We charge somewhere between $8 and $20 per maintained test per month." A free tier exists on the old pricing page (a single user, 100 test executions per month, then one cent per execution) and a free trial and a free exploration account are both stated on the current site. Prices read 2026-09-25 from klarent.ai, from the archived foreai.co pages, and from the vendor's blog.
Official links:
Product site: https://klarent.ai/
Product documentation: https://klarent.ai/docs/
Documentation quick start: https://klarent.ai/docs/quick-start/
Product FAQ in the documentation: https://klarent.ai/docs/product-faqs/
Test creation and instruction guidance: https://klarent.ai/docs/create/test-creation/
Test generation, step by step: https://klarent.ai/docs/generate/generations-main/
Self-healing, as documented: https://klarent.ai/docs/run/runs-self-healing/
Advanced debugging, including Playwright traces: https://klarent.ai/docs/run/runs-debugging/
Mobile test generation: https://klarent.ai/docs/create/creating-mobile/
Test data management: https://klarent.ai/platform/test-data/
Test management: https://klarent.ai/platform/test-management/
Integrations: https://klarent.ai/platform/integrations/
CI/CD integration guide: https://klarent.ai/docs/integrations/ci-cd-integration/
SSO via SAML: https://klarent.ai/docs/configuration/config-sso-saml/
Use cases: https://klarent.ai/use-cases/
Comparison pages: https://klarent.ai/comparison/
Case studies: https://klarent.ai/case-studies/
Clients: https://klarent.ai/clients/
About the team: https://klarent.ai/about/
Newsroom: https://klarent.ai/news/
Trust and security: https://klarent.ai/trust/
Trust Center (access request): https://foreai.eu.trust.site/
Privacy policy: https://klarent.ai/privacy-policy/
Terms and conditions, including the service level agreement in Annex 1: https://klarent.ai/terms/
The rename announcement: https://klarent.ai/blogs/introducing-klarent/
The Microsoft Marketplace announcement: https://klarent.ai/blogs/klarent-now-available-on-microsoft-marketplace/
Microsoft Marketplace listing: https://marketplace.microsoft.com/en-us/product/saas/fore-ai.fore-ai-autonomous-software-testing
YouTube channel: https://www.youtube.com/@klarent-ai
LinkedIn: https://www.linkedin.com/company/fore-ai
Agent platform fields:
Agent architecture: a coordinated set of named agents rather than one. The vendor names Explorer, Planner, Coder, Verifier, Runner and Notifier, and describes the work as six agents in one workforce. The Microsoft Marketplace listing describes Explorer as mapping and navigating the application, Planner as building the test plan and anticipating edge cases and business intent, Coder as generating scripts across devices and browsers, Verifier as acting as the quality gate that monitors the test and checks the result against the aim, Runner as executing and reporting, and a final agent as dispatching alerts. One vendor page calls the healer rather than the runner the agent that carries self-healing.
Separation of concerns, and it is a real design choice: the agent that reasons over screenshots is not the agent that writes the code, so the coding step never processes images. The vendor states this directly in a comparison page, and it is the reason the coding step is cheap relative to the visual step.
Inputs: natural-language instructions, a website URL, a product requirements document, a Jira ticket, a Figma link, existing tests, and an application binary (APK) for mobile.
Outputs: an executable test built from generated Python and Playwright code, per-step screenshots, Playwright traces with console and network detail, pass and fail results with a triage, and alerts in Slack, Microsoft Teams, Jira, Linear or email. The library can also export the test code so it runs on the customer's own runners.
Coverage: Chrome and Chromium, Firefox, WebKit and Safari, Edge, custom viewport sizes, native iOS and native Android on cloud-hosted devices, plus Flutter and React Native applications from a single definition. The browser is selectable per pipeline run.
Execution: on demand, on a schedule, or triggered from a pipeline. Parallel across browsers and viewports. A test can be narrowed to the area that changed rather than run whole.
Test data: per-test variables, project-wide encrypted secrets that are masked in logs, output and screenshots, and shared file assets referenced with the at symbol.
Structure: projects as isolated workspaces with their own secrets, variables and configuration; nested folders mirroring the application; test suites grouping any combination of tests for joint execution.
Integrations: GitHub and GitHub Actions, GitLab, Bitbucket, Jenkins, Azure DevOps, Tekton, CircleCI, Jira with two-way sync, Linear, Slack, Microsoft Teams and email. Custom API integrations are stated as supported.
Deployment: public cloud, private cloud or VPC, or on-premises. The Microsoft Marketplace listing states the platform is built on Microsoft Azure.
Security and access: ISO 27001 certification, SOC 2 compliance stated in some places and SOC 2 Type II in others, encryption in transit and at rest, role-based access control, multi-factor authentication, audit logs, and SAML single sign-on documented against Microsoft Entra ID as the example identity provider.
Model layer: not disclosed. The vendor states that its agents are trained models, that it fine-tunes domain-specific models on customer test data as a service, and that its internal quality reporting benchmarks and swaps models for planning, coding and self-healing. No model, vendor or architecture is named in public documentation.
At a Glance Dashboard
Field | Value |
Category | Applied AI / Agent Platform for software quality assurance |
CI-First Benefit Score | 6.0 / 10 (CI-First Positive) |
Sub-scores | Time 7 / Quantity 7 / Quality 6 / Skill 4 |
CI-First Profile | Primary: Co-Worker and Assistant (level 2). Secondary: Analyst and Tester (level 4), and narrowly Coach and Tutor (level 3) |
Collaboration Mode | Centaur. Cyborg is not available on a surface that runs a suite unattended in a pipeline and can revise tests between runs |
Humics Protection | Humics-Neutral (-1 / +3): Creativity 0, Critical Thinking -1, Social Authenticity 0 |
AI Imposture Risk | Medium overall, with Skill Illusion High, Time Illusion Medium, Quantity Illusion Medium |
Status | Active |
Last tested | 2026-09-25 |
Released | Renamed and relaunched as Klarent on 2026-08-10, with native mobile testing and the Klarent CLI shipped in the same release; listed on Microsoft Marketplace 2026-09-11 |
Access | Browser workspace at app.klarent.ai; cloud, private cloud or VPC, or on-premises; triggerable from CI/CD |
Price | Annual licence scaling with generated tests and test runs, quoted per customer. No published rate card |
Vendor | fore ai AG, Zurich, Switzerland. 10 to 49 employees per a third-party directory profile |
Framework version applied | CI-First Evaluation Framework v1.2 |
Independent measurement | None published at the time of writing |
The Problem
Software testing has been the one part of the delivery chain that artificial intelligence made harder before it made it easier. Code is now written faster than it can be reviewed. A change that used to arrive as a diff of forty lines arrives as a diff of four hundred, and the reviewer's attention is the same as it always was.
The traditional answer was scripted automation, and the traditional answer has two costs that are both worse than they used to be. The first is authoring: a Playwright or Selenium suite is written by a specialist, one selector at a time, and the specialist is the scarcest person on the team. The second is maintenance, and it is the one that quietly consumes the budget. A locator is an address, and the address changes whenever the interface does. Every release hands the team a repair list. The vendor's own unit-economics post puts a number on it: for a single end-to-end test running twice a day, about $4.80 of compute, about $100 of an engineer's hour spent writing it, diagnosing the flake and re-reading the failure that turned out to be a timing issue, and about $10 of tokens if an agent authored it. Compute is four per cent of the total. The rest is a person attending to brittle selectors.
That arithmetic pushes teams into a predictable set of compromises. Coverage shrinks to whatever can be maintained. Testing gets compressed into the time left before a release, which is never enough. The most rigorous validation a stretched team can manage is a dozen or so user journeys, chosen not because they are the most important but because they are the ones someone could check. And the gap between "the site is up" and "a customer can complete the task they came for" is exactly where regressions hide.
Two things have changed at once. Agents can now read an interface the way a person does, by purpose rather than by address, which makes repair a different problem from rewriting. And a test can be described in a sentence rather than composed in a language, which moves the authoring bottleneck from the specialist to anyone who knows what the product is supposed to do. The Gartner projection the vendor cites in its own buyer guide, that 70 per cent of enterprises will run AI-augmented testing by 2028 against about 20 per cent in early 2025, is a statement about how quickly that shift is expected to arrive.
The problem Klarent addresses is therefore not "how do we test more". It is "who maintains the suite, and what happens to the suite when the interface changes".
The Outcome
An agentic QA platform does not remove the work of testing. It moves it.
The work that leaves is writing selectors and repairing them. The work that arrives is deciding what should be tested, reading a failure and judging whether it is a real regression, a badly specified test, or an environment problem, and reviewing what the platform changed when it healed something. The vendor states this division itself, in the sentence a buyer should read twice: most teams step in less than five per cent of the time, only to define what to test or to unblock an agent that is stuck.
That is the honest shape of the outcome. A team that adopts this gets a suite that grows faster than its own capacity to write one, running at a frequency it could not previously afford, with evidence attached to each run. A team that adopts it and stops reading the results gets a large green suite and no idea what it covers, which is the failure mode the independent category writing describes in one sentence: two thousand green tests that catch nothing.
Who Should Use Klarent
Learner type | Difficulty | Typical ROI | Career path |
Students (Bachelor, Master) | Intermediate for the concept, and the concept is the value. Running the platform requires no code; judging whether a generated test asserts the right thing does | Modest as a student tool, because the annual licence is aimed at enterprises and there is no individually published price. Where it earns its place is as a case study you can read: the product's own documentation explains test generation step by step, and the vendor's blog explains why an agent that is 95 per cent accurate per step only completes a twenty-step workflow about 36 per cent of the time. That is a better lesson in agentic reliability than a lecture | UIT (Technology, AI, Data Science) tracks, particularly software quality, test automation and agent reliability. Programme anchors in the U365 Institutes Alignment table |
Professionals (career upskilling) | Intermediate to Advanced | Strong for a QA or engineering team carrying a brittle suite: the maintenance line is the one the product genuinely attacks, and the plain-English authoring moves test creation to people who know the business rules. Advanced only in the sense that the judgement work does not disappear, it concentrates. A tester who moves from writing scripts to owning coverage strategy and triage is more valuable, not less | UIT (Technology, AI, Data Science) quality and engineering tracks for agent supervision, test specification and defect triage, and UIB (Business Management, Entrepreneurship) for the build-versus-buy and unit-economics side, which the vendor publishes unusually openly. No cost per completed task is computable from this release, which is why the business case is assessable as analysis rather than as a costed decision |
Everyone (lifelong learners) | Beginner to Intermediate | Not a personal tool at this price point. The useful transferable lesson is the one the vendor's own writing makes available for free: what a generated end-to-end test actually costs to own, and why the review time is the largest line in it | SL-OS daily routine, LIPS Collect and Review phases, for readers studying how automation changes where human attention goes |
Skill level required: Intermediate overall. Writing an instruction precise enough to generate a correct test is a real skill and the documentation says so, with guidance to imagine guiding an experienced tester who has just joined and does not know your product, to avoid vague wording such as "verify the content", and to state what should not happen as well as what should. Advanced for the parts that decide whether the platform is a net benefit: judging a failure, refusing a heal that weakens an assertion, and keeping the suite's meaning under your own control.
Prerequisites: A Klarent licence or a trial account, which the vendor offers through app.klarent.ai. An application you are authorised to test, in an environment you are authorised to point a cloud service at, including the credentials or secrets the tests will need. A decision about where the tests run, because the platform is not permitted to be used against third-party sites that you do not own. For mobile, the application binary. For pipeline integration, the usual access to the repository and the CI system.
Typical time to first result: Minutes from a login to a first generated test, since the quick start is three steps: log in, fill in a test name, a website address and an instruction, and click create. The generation, execution and screenshot verification run in front of you. The vendor's own customer account reports first suites live and stabilised within two to three days from kickoff, with the vendor's services team building them.
Typical time to competence: Two to four weeks of real use before you can tell a well-specified test from a plausible one, and that is the skill the platform is really paying you to acquire. The single most valuable habit available is to read the generated step list and ask what the test does not cover, because the platform will report success on exactly what you described and nothing else.
U365 Institutes Alignment
The alignment rates the operational competency the tool exercises rather than what it produces. No CI-First score changes with this alignment.
Institute | Relevance | Why | The limit that holds the row |
UIT (Technology, AI, Data Science) | High (primary) | Software quality is the subject matter, and the four competencies the product exercises are this institute's territory: specifying a testable outcome including what should not happen, reading generated code and judging whether an assertion tests what it claims, triaging a failure with evidence, and running a suite as a release gate. The documentation is a usable teaching artefact: the generation loop is documented step by step, the generated code is Python and Playwright, and the run trace exposes console and network detail | The tool substitutes for specialist authoring rather than teaching it, it builds no programming skill, and one of the four competencies has no published assessment home in the U365 catalogue |
UIB (Business Management, Entrepreneurship) | Medium | Two genuine competencies. Technology investment appraisal: the vendor publishes the review line as the dominant cost of owning a test, the export path as a documented exit, and an in-house build that consumed over 400,000 dollars of engineering time and never shipped. Accountable automation governance: who reviews a repaired test, what a gate blocks a merge on, and what risk is accepted | The tool teaches no management, finance or entrepreneurship content of its own, and with no published rate card the appraisal is assessable as analysis rather than as a decision a Fellow can cost |
UIC (Digital Communication, Marketing) | Low | Coursework observation only. The outputs are pass and fail reports, run summaries and alerts attributed to the platform and delivered to a channel. Nothing in the product builds brand voice, audience judgement or campaign craft. No disciplinary relevance and no credential anchor | There is no UIC competency to build here. The row is published so the judgement is visible |
UID (Digital Design, UX/UI) | Low (corrected downward from the drafted rating) | Coursework observation only. A UI regression suite can protect a design surface, and the vendor's published publisher case study covers a paywall across browsers including dark mode and cross-browser rendering. That is a testing judgement applied at a design surface, not design work. No design competency and no credential anchor | The product produces no design artefact, evaluates no design against a brief, and teaches no part of the UID curriculum |
The drafted UID rating downward to Low, confirms UIT at High, UIB at Medium and UIC at Low, and maps no UIC or UID credential chain.
Primary alignment: UIT (Technology, AI, Data Science)
Four competencies, and a Fellow who holds them is doing software quality work rather than writing test code.
Test specification as a precision skill. Writing an outcome a machine can act on, including what should not happen, and refusing vague wording. The competency is teachable independently of the product, which is why it is the one to build first.
Code comprehension and review discipline applied to machine-generated artefacts. Reading generated Python and Playwright code and judging whether an assertion tests what it claims.
Defect triage with evidence. Classifying a failure as a real regression, a bad test or an environment problem, and defending the classification from the trace rather than from the summary.
Release engineering and the judgement of a gate. Running a suite in a pipeline that blocks a merge on a genuine failure, and knowing when it should not.
The teaching case worth singling out. The product's advertised promise is a suite that maintains itself, and the vendor's own writing describes a relationship with humans in the loop and a repair a person triggers. The documented self-healing workflow is weaker than the advertised one: the website describes a proposed fix reviewed as a difference before it is applied, while the product documentation describes selecting a repair action on a run and the system rewriting the test. A Fellow who reads both pages and can say which one describes what the product does has learned the habit that matters for every agentic tool they will evaluate: check the documented workflow, not the claim. This case survives after the launch material stops being current.
Secondary alignment: UIB (Business Management, Entrepreneurship)
A Fellow in this institute can run two exercises on this product.
First, the total cost of ownership analysis. Not the licence price but the cost of owning a suite, with the review line counted. The vendor's own unit economics put the engineering line at roughly 87 per cent of the monthly cost of owning one test, and the review commitment scales with the suite: the same vendor states that teams step in less than five per cent of the time to define what to test and to unblock agents, which on several hundred tests is a standing obligation rather than an exception. The Fellow records a baseline, logs the review minutes, and computes cost per maintained test per month against the vendor's published unit rate of 8 to 20 dollars. The learning outcome is a measured recommendation rather than an impression.
Second, accountable automation governance. Define the check, name who reviews a repaired test, set the rule for what blocks a merge, and decide explicitly whether a suite nobody inspects is acceptable for this process. The learning outcome is an accepted-risk decision with a named owner.
The limit that keeps the row at Medium. The product teaches no management, finance or leadership content. And because pricing is quoted per customer with no published rate card, the analysis a Fellow can complete is a cost model, not a costed decision.
UIC (Digital Communication, Marketing), Low, no disciplinary relevance. The product produces reports and alerts, not communication. It writes nothing in a person's voice. No credential chain is mapped.
UID (Digital Design, UX/UI), Low, coursework observation only. How this class of tool is applied at a design surface is the whole of the connection, and it is a testing judgement rather than design work. It builds no design competency and produces no design artefact. No credential chain is mapped.
What would move the UID row. It would move only if the platform exposed an artefact a design Fellow could be assessed on as design work, for example a coverage proposal expressed in design-intent terms (which component states, which contrast conditions, which viewports, and what the design intent behind each check is) rather than as a list of executed steps, and if a design-quality programme existed to assess that artefact. Neither is on the current record.
How Klarent Works
Inputs: A plain-language instruction, plus the starting address of the application. Optionally a product requirements document, a Jira ticket, a Figma link, an existing test to expand, or an application binary for a mobile test. Per-test variables, project secrets and shared file assets referenced from the instruction. Optionally an authentication flow, since the documentation states that saying "login" plus a stored secret covers most web applications. Then the application itself, reached over the network or on a cloud device.
Outputs: An executable test made of Python and Playwright code, generated step by step and shown to the reader. A per-step screenshot taken when the code executes without error and checked against the expected outcome of that step. A run record with pass and fail results, a Playwright trace containing actions, console messages and network messages, and a triage that names the failure as a real regression, a bad test or an environment problem. Alerts in Slack, Microsoft Teams, Jira, Linear or email with a pass and fail summary and a link to the failure detail. Optionally, the exported test code, for running on the customer's own infrastructure.
Underlying technology, as far as the vendor discloses it:
A multi-agent engine, named rather than described in the abstract. Explorer maps and navigates the application. Planner builds the test plan from the instruction and anticipates edge cases and business intent. Coder generates the executable code. Verifier monitors the test and checks the result against the aim. Runner executes and reports. A final agent dispatches alerts; one vendor page gives the healing role to the runner, another names a separate healer.
A deliberate split between the agent that reasons over screenshots and the agent that writes code, so the coding step never processes images. The vendor states this in a comparison page and treats it as the reason coverage does not wait on a modelling phase.
The generation loop, documented in steps rather than described in principle. Every test starts by visiting the configured address. The agent analyses the current state of the application, writes the title and description of the next step to serve the instruction, generates Python and Playwright code for that step, executes it, and on an error either regenerates or reworks the code and executes again. When the code runs without error it captures a screenshot and verifies whether the screenshot matches the expected outcome of that step. It repeats until the instruction is fulfilled or cannot be completed.
Test data is separated from test logic. Variables are scoped to one test. Secrets are project-wide, encrypted at rest and masked in all output, run logs and screenshots, with only the name shown in step definitions. Assets are files shared across a project and referenced with the at symbol.
Structure is file-system-like rather than database-like: projects as isolated workspaces, a nested folder tree, and suites that group any combination of tests without duplication.
Repair is a distinct workflow rather than a rerun. When a step fails because an element, identifier or locator changed, the platform can rewrite the affected part of the test based on the latest application flow.
Deployment is offered cloud, private cloud or VPC, and on-premises, with the vendor's Microsoft Marketplace listing stating the platform is built on Microsoft Azure.
Where the vendor's own pages describe the same mechanism differently, and it matters. The website states that when a locator or flow changes, Klarent detects the failure, proposes the fix, and shows you exactly what changed before anything is applied, with a step-by-step diff to review and accept. The product documentation describes a different sequence: open Recent runs, open the relevant run, click the three-dot menu, select Heal this test, and the system heals the test automatically based on the latest application flow. Both describe the same capability and they are not the same workflow. In the documented version the human triggers the repair and the platform chooses the repair; in the website version the human approves a specific diff before it is applied. A reader deciding how much control they will have should read the documentation page, because it is the one that describes what the product does.
Where the architecture puts the trust boundary. The application under test is reached by the vendor's infrastructure, and for a mobile test it is reached on a cloud-hosted device. Your test data, including any secret you store, lives in the vendor's project. The instruction, the application state and the artefacts the platform captures therefore pass through a third party, and the vendor's privacy policy addresses this position explicitly, stating that test data is processed solely on the customer's behalf as a data processor under a data processing agreement and is not used for the vendor's own purposes. The terms say something narrower and worth reading next to it, and section 7c quotes both. For a regulated application this is a decision to take deliberately rather than by clicking through a trial: the deployment options exist precisely because some customers need the platform inside their own perimeter, and the vendor documents a private cloud and on-premises path and a SAML single sign-on configuration.
Getting Started with Klarent
Required accounts: One Klarent account, created through app.klarent.ai or supplied by an administrator if your organisation uses SAML single sign-on. For the trial path the vendor states you can explore the platform for free. For enterprise deployment, an order with fore ai AG, which is the entity that remains the contracting provider.
Installation: Nothing to install for the web workflow. You work in a browser at app.klarent.ai. A pipeline integration is a configuration in the code host or CI system rather than a local install. For mobile, you upload an application binary either ahead of time under Test Data and Assets or directly from the test creation dialog. The vendor's own documentation covers the browser workflow in full, and the SAML guide covers identity federation against Microsoft Entra ID.
First-time configuration:
Sign in and create a project. Projects are isolated workspaces, so create one per application or per team rather than reusing a single workspace.
Add the credentials your tests will need as secrets at project level, not as literals in instructions. The documentation states that secrets are encrypted at rest and masked in logs, output and screenshots.
Open Create a test and switch the toggle to Website or Mobile App depending on what you are testing. For a website, enter the starting address. For a mobile app, select the application binary.
Write the instruction the way the documentation tells you to: imagine guiding an experienced tester who has just joined and does not know your product. Be explicit about what should happen and about what should not. Avoid vague wording such as "verify the content". Use the at symbol to reference stored secrets and variables rather than typing values.
Create the test and watch the generation. Read each generated step and its code before you trust it, because this is the moment where a mis-specified instruction becomes a test that passes and checks the wrong thing.
Put the test in a suite, and put the suite on a schedule or in the pipeline. Add a notification channel, since results are only useful where your team already reads them.
Decide the healing policy before you have failures. Agree who reviews a healed test and on what evidence, because a heal that keeps a test green while weakening what it asserts is the failure mode that costs the most and shows up the least.
Notes for the operator:
Tests are generated against a live application, so point them at an environment you control and are authorised to test, and use a non-production environment before you point anything at production. The vendor's largest published case study describes a bank running agents against its live e-banking environment, which is a deliberate decision a bank can make and a default a smaller team should not inherit.
The first generated test is a demonstration, not a suite. The value arrives when a suite runs on every change, which is when the maintenance saving compounds and when the coverage question starts to matter.
Keep the exported code. The vendor built the export path deliberately and argues its own case for it in public. Exporting your suite once, early, tells you what you own and what you would lose.
Trace data is partially obfuscated by design to avoid leaking sensitive values, which is correct behaviour and also means a trace is evidence rather than the whole truth.
First 15 minutes checklist:
☐ Sign in and create a project named for the application you are testing.
☐ Store one real credential as a secret and confirm it is masked in the run output and in the screenshots.
☐ Create one test from three sentences of plain English and watch the generation and the first run.
☐ Read the generated step list and the exported code, and identify at least one thing the test does not cover.
☐ Open the run, open the trace, and confirm you can see the step, the screenshot, the console and the network detail.
☐ Create a second test that should fail, on purpose, and confirm the platform reports it as a failure rather than a pass. This is the check most teams skip and the one that tells you whether the green suite means anything.
Result: After fifteen minutes you should have one working test, one credential stored correctly, one verified run, one deliberate failure, and a first reading of what the platform does and does not check for you. The deliberate failure is the item that makes the rest of the review actionable, because a suite you have never seen fail is a suite you cannot yet trust.
Real Workflows
Each workflow below is written to be run as described, with the prompt written in the U365 prompting method and a verification checklist you can apply without the vendor's help.
Workflow 1: Turn a manual regression checklist into a scheduled suite
The situation. Your team has a written regression checklist, maintained in a spreadsheet, executed by hand before each release and trimmed whenever the release is late. It covers between ten and twenty journeys. Nobody has automated it because nobody has the time to write the tests, and the last attempt produced a suite that broke on the first interface change.
The prompt.
Context: We are a [team size] team maintaining [application]. Our regression checklist is [n] user journeys, held in [where]. It is executed manually before each release, and under deadline pressure it gets trimmed. The journeys that matter most are [name the three highest-risk ones, with the business reason]. Profile: Act as a Co-Worker and Assistant (level 2). I own what counts as a pass. You generate and run the tests. Task: For the following journeys, generate one end-to-end test per journey from these instructions. Run each one, and for any that fails, tell me whether the failure is a real regression, a badly specified test, or an environment problem, and say which evidence you based that on. Constraints: Use only the credentials stored in the project secrets. Do not create or modify data in the test environment beyond what the flow requires, and do not send any outbound message, email or notification from within the flow. If an instruction is ambiguous, stop and ask me rather than choosing a reading. State plainly which journeys you could not express as a test and why. Output format: For each journey, in order: the test name, the step list, the result, and the triage. Then one list of the journeys you could not express, with the reason.
The verification checklist:
Evidence: open every run and open its trace. Confirm you can see the step that asserted the outcome, and not just the steps that navigated.
Coverage: take two journeys off the list that you wrote as instructions and confirm the generated test checks the thing the business cares about, and not merely that a page loaded.
Adversarial: introduce one deliberate break in a test environment, for example hide a button or change a required field, and confirm the suite fails and names the right step.
Human check: have the person who currently runs the checklist by hand read the generated step list for their journey and say what is missing.
Workflow 2: Put a pre-release gate in the pipeline that a team can actually trust
The situation. You want every pull request to run the critical paths and block the merge on a genuine failure, without handing the team a red build at every deploy. The obstacle is not the pipeline, it is confidence: a gate nobody trusts is a gate people learn to click past.
The prompt.
Context: Our pipeline is [GitHub Actions / GitLab / Azure DevOps / Jenkins]. Our critical paths are [name them]. We deploy to [environment] on merge, and we have been burned by a suite that failed on environment noise rather than on a real break. Profile: Act as an Analyst and Tester (level 4). I interpret the results and decide whether the merge proceeds. You produce the evidence. Task: Build a smoke suite from these instructions and trigger it from the pipeline on every pull request. Over the next [n] runs, report which failures were real regressions, which were bad tests, and which were environment problems, and give me the counts. Constraints: Never mark a test passing that did not assert its outcome. Do not weaken an assertion to make a test pass, and if you think an assertion is wrong, propose the change with its reasoning and wait for my approval. Name the environment and the build for every run. State any run in which you could not determine the cause. Output format: A table of runs with the build, the result, the triage and the evidence link. Then one paragraph naming the ratio of real regressions to noise, and what you would change in the suite to raise it.
The verification checklist:
Evidence: confirm the pipeline result links to a run with a screenshot at the failing step and a trace, not to a summary line.
Coverage: confirm the suite fails when it should, by breaking one critical path intentionally on a branch and checking that the merge is blocked.
Adversarial: check where the suite could pass without testing anything. Look for a test whose only assertion is a page load, and for a step whose screenshot verification accepts a partially loaded page.
Human check: ask one engineer who did not build the suite whether the failure message tells them what broke without opening anything else.
Workflow 3: Test an interface you cannot write tests for, and read the result honestly
The situation. You have a native mobile application, or an application whose interface churns weekly, and conventional automation has never held. Your first goal is not a large suite, it is an honest reading of how reliable this class of tool is on your own application.
The prompt.
Context: We are testing [application, platform, version]. The interface changes [how often]. Our previous automation attempt was abandoned because [reason]. We have [n] devices or emulators available to us in the platform. Profile: Act as an Analyst and Tester (level 4). I am measuring reliability, not asking for coverage. You report, and you do not repair. Task: Generate and run [n] flows of moderate complexity, on the same build, twice, without changing the instructions between runs. Report which flows passed both times, which passed once, and which failed both, and for every failure say whether the test or the application is at fault. Constraints: Do not heal anything during this exercise. Do not change an instruction after seeing a failure. Report the same flow's two results side by side. If a flow cannot be completed because of something in the application rather than in the instruction, say so plainly. Output format: A table with the flow, run one, run two, and the triage. Then one sentence on whether the failures were consistent, because a flow that passes once and fails once is the measurement that matters most.
The verification checklist:
Evidence: for each failure, open the screenshot at the failing step and judge for yourself whether the screen looks different from what the test expected.
Coverage: confirm the two runs used the same build and the same instructions, or the comparison means nothing.
Adversarial: count the flows that passed both times and ask what the smallest change to the interface would need to be to break each one. Flows that cannot be broken by a plausible change are testing less than you think.
Human check: show the two-run table to whoever owns the release decision, without commentary, and see what they conclude. If they conclude "it works", the table is not saying what you think it is.
Connects to: UIT (Technology, AI, Data Science) software quality and release engineering tracks. Verified U365 credential anchors for this workflow: the Software Developer diploma, for reading and judging generated code, and the Full-Stack Web Developer diploma, whose published programme includes version control and continuous delivery foundations. Both were verified as published on university-365.com on 2026-09-25.
Strengths, Limits, and AI Imposture Risk
Strengths
CI-First Benefit | Strength | Evidence |
Time | The two most expensive lines in test automation are authoring and repair, and the product attacks both rather than one. A test is described in a sentence instead of composed selector by selector, and a break caused by a changed element is repaired by the platform rather than by an engineer | The vendor's documentation states that generation produces the steps and the code from a plain-language instruction, and that healing rewrites the affected part when an element, identifier or locator changes. The vendor's own unit-economics post puts the engineering line at about an hour per test per month and names it as the dominant cost, which is the same conclusion this review's Time sub-score reaches independently |
Quantity | Coverage stops being limited by how much a specialist can maintain. Tests are described rather than coded, and the vendor's case studies show the mechanism operating rather than asserted: one customer went from rigorously validating 10 to 15 journeys before each deployment to hosting more than 130 automated tests with the full set completing in a few minutes, and reporting four times the test frequency | The OnlineFuels case study states the before and after figures and the suite runtime. The Neue Zürcher Zeitung case study states that more than half of the end-to-end tests are now written directly by product and business teams rather than by QA engineers, which is the specific mechanism by which volume rises |
Quality | The verification surface is real and specific, which is what a quality claim needs. Generated tests execute against a live application before you rely on them, each step captures a screenshot that is checked against that step's expected outcome, failures arrive with a Playwright trace containing console and network detail, and the triage asks explicitly whether the failure is a real regression, a bad test or an environment problem | All of this is documented in the vendor's own public documentation rather than only in marketing. The vendor's blog also states the reasoning: the value is not the generated code but the loop around it, because debugging someone else's generated code is the least pleasant work in software |
Skill | The generated code is readable, exposed, and editable, and the product's documentation teaches the transferable skill the tool actually requires: writing an instruction precise enough to be tested, including what should not happen | The documentation states that code is shown and that users can give coding hints to the models, that generation produces Python and Playwright, and that the exported code runs on standard runners. The instruction guidance is a genuine authoring lesson about test specification rather than about the product |
Limits
No independent measurement exists. Every accuracy and effort figure in this review comes from the vendor or from a customer quoted on the vendor's own site. There is no benchmark, no third-party evaluation, no published completion rate and no editorial hands-on review from an independent publication. The tool directories that exist carry zero reviews, and one of them publishes a 4.86 out of 5 score with no approved reviews behind it. The most important limit is not a defect in the product; it is that nobody outside the vendor has measured it.
The vendor's own accuracy numbers do not agree with each other. The customers pages carry roughly 94 per cent execution accuracy. A comparison page claims 96 per cent precision, described as the most precise solution in the market, with no methodology published. The homepage carries roughly 90 per cent success on first run. The release-speed multiplier is 3 to 5 times in the FAQ, 6 times on the customers pages, and 10 times on the site's own call to action and in the Microsoft Marketplace listing. Four different numbers across three surfaces is not a range, it is four claims.
The documented self-healing workflow is weaker than the advertised one. The website describes automatic detection, a proposed fix, and a step-by-step difference reviewed before anything is applied. The product documentation describes opening a run and choosing Heal this test from the run menu, after which the system heals the test based on the latest application flow. The second description puts more judgement on the platform and less on you than the first.
"Zero maintenance" is a marketing absolute the vendor's own writing contradicts. The old fore ai product page states zero maintenance, and the Microsoft Marketplace listing states zero manual maintenance. The vendor's own blog describes healing as a relationship rather than a delivery, states that there are humans in the loop, and acknowledges that "mostly maintained" is where teams quietly go back to fixing things by hand.
The category's most dangerous failure mode is documented and the product's surface makes it hard to see. Independent category writing records two findings that matter here. Self-healing reduces flake substantially but partially, with one 2026 buyer's guide putting it at roughly 70 to 85 per cent of locator-driven flake eliminated and the remainder coming from timing, data and race conditions that no locator change addresses. And a healed locator pointing at the wrong element quietly stops catching the regression it was written for. The product provides the evidence to catch this if you look; it does not put the risk in front of you.
Pricing cannot be budgeted without a sales conversation. The model is an annual licence scaling with generated tests and test runs. The only figures available are an archived entry range of EUR 60,000 to 80,000 per year for smaller projects with six figures for enterprise deployments, and a per-test unit rate of $8 to $20 per maintained test per month in the vendor's own blog. Those are not contradictory, since one is a contract value and the other a unit rate, and together they still do not let a reader estimate a bill. For a European institution the entry point alone is a procurement decision rather than a trial.
The contractual position on model rights is broader than the privacy policy's plain-English reassurance. Section 5.3 of the terms gives the provider sole property of any data models and algorithms generated from use of the service and from Customer Data, to be used at the provider's free discretion for any purposes. The privacy policy states that test data is processed solely on the customer's behalf as a data processor and not used for the provider's own purposes. Section 7c quotes both and sets out the decision they put in front of you.
The provider is one small company and the platform is not something you can operate yourself. The vendor is a Zurich company of 10 to 49 employees by a third-party directory profile, and third-party funding databases disagree about how much has been raised, with figures of $2.5 million, $5.3 million and $10.6 million appearing across three sources. A team that puts its release gate behind a single small vendor is taking a concentration risk that belongs in the decision rather than in the small print.
The service level is modest and the support window is narrow. Annex 1 of the terms commits the provider to use commercially reasonable efforts to reach 99 per cent availability per calendar month, excluding scheduled maintenance and force majeure, with a helpdesk operating 08:00 to 17:00 UTC-1 on business days and an explicit statement that resolution times cannot be guaranteed.
The model layer is undisclosed. The vendor states that its agents are trained models and that it fine-tunes domain-specific models on customer test data as a service, and it publishes a thoughtful account of how it benchmarks and swaps models internally. It does not name a model, a provider or an architecture anywhere in public documentation, which means a reader cannot assess where the reasoning comes from or what happens when a model is withdrawn or repriced.
AI Imposture Risk
Trap | Rating | Evidence |
Time Illusion | Medium | The saving is structural rather than claimed: writing a suite selector by selector and repairing it by hand are both removed, and the vendor's own unit-economics post shows why that matters, since the engineering line is roughly 87 per cent of the monthly cost of owning one test. Two things hold the rating at Medium rather than Low. The authoring overhead is real and the vendor documents it, with guidance to write instructions that state what should not happen and to avoid vague wording, which is specification work rather than a two-minute task. And the review burden scales with the suite: the vendor's own figure is that teams step in less than five per cent of the time to define what to test and to unblock agents, which on a suite of several hundred tests is a standing commitment rather than an exception |
Quantity Illusion | Medium | The volume increase is real and documented by category and by case study: more than 130 tests where a team previously validated 10 to 15 journeys by hand, four times the test frequency, and more than half of a publisher's end-to-end tests now authored outside the QA team. The illusion risk is the direct consequence of that success, because a suite that grows faster than the team's capacity to judge it produces exactly the outcome the independent category writing names: a large green suite that catches nothing. Not rated High because the product supplies step-level evidence rather than a bare pass or fail, and because its failure triage forces the question of whether a failure is real. Not rated Low because nothing external measures how many generated tests are meaningful, and because the tool directories publishing high scores with zero reviews behind them are the same failure of judgement at a smaller scale |
Skill Illusion | High | Two mechanisms, and the second is the one to sit with. The first is authoring: the product's stated purpose is to let people who are not QA specialists create and run reliable end-to-end tests, and a business user who could not previously evaluate a test now holds a suite and a pass rate. The independent category evidence is explicit about where that leads, including the widely reported April 2026 case in which a company cut its twelve-person QA team and an automated pipeline shipped a faulty discount that set every price to zero, at a reported cost of roughly six million dollars in lost orders, because nothing validated the change and no reviewer remained. The second mechanism is healing, and it is specific to this product. When a test is repaired because an element changed, the repaired test passes, and the evidence that it still asserts what it was written to assert is a difference you have to review. Independent writing records the failure mode in one sentence: a healed locator pointing at the wrong button quietly stops catching the regression it was meant to catch. A test that passes after being repaired is a claim the platform makes on your behalf about a flow you may not have re-examined. The mitigation is available and cheap, and it is the same one this review repeats: read the generated steps, read the healed difference, and keep at least one deliberately failing test in the suite so you know what failure looks like |
Overall Imposture Risk: Medium. One trap is High with an identifiable mitigation, and two are Medium. Under framework Section 5.3, one High with clear mitigations lands at Medium rather than High.
Stated plainly, because the band label will otherwise read as comfortable: this assessment sits at the top of the Medium band. The product's promise is a suite that maintains itself. The product's own documentation describes a repair you trigger and the vendor's own writing describes a relationship with humans in the loop. Both of those are honest and neither is the promise. A reader who adopts Klarent with a named reviewer for healed tests, a deliberately failing test in the suite, and a habit of reading generated steps is using a Medium-risk tool well and getting the benefit the score describes. A reader who adopts it because the accuracy numbers are high, and stops looking, is using a High-risk tool badly, and the vendor's own account of what a green suite can be worth is the best available warning.
Framework v1.2 clause note
Three clauses from framework v1.2 were checked against this tool. All three return a null, and each null is recorded with its reasoning, because a null is a finding and a null reached without checking is worthless.
Clause 5.2.3-a, agent-authored procedural memory: NULL, and the check was not trivial. The clause sets a Skill Illusion floor for any tool that creates or revises the user's skills, memory stores or standing instructions on the user's behalf, at the High threshold where the agent can revise that memory during use without a per-write human decision. Klarent does write durable artefacts that the agent authors inside: the executable test code, reusable Modules that run before a test's steps and are shared across tests, and the suite structure the Explorer agent proposes when it surfaces scenarios and edge cases. That is close enough to the clause's territory that it had to be examined rather than waved past, and two facts settle it. First, the artefacts are the product's deliverable rather than a record the agent keeps about the user, and each one is created against an instruction the user wrote and can read. Second, the one workflow in which the agent revises an existing artefact during use, healing, is documented as a human-triggered action on a specific run rather than a silent revision, and the website goes further and describes a difference reviewed before anything is applied. The clause does not bite, and the near-miss is recorded here so a future reviewer can see the boundary that was drawn. This is a different outcome from the three earlier applications in this series, where the tool maintained a memory store or a skills file about the user's own work.
Clause 4.2-a, agent-mediated conversation: NULL. The clause concerns agent-authored text presented as a person's own voice in a human-facing channel, or the substitution of agent interaction for human contact. Klarent produces reports and alerts that arrive in Slack, Microsoft Teams, Jira, Linear and email. Those are machine outputs delivered to a channel, attributed to the platform rather than composed as the user's own message, and no part of the product drafts or sends communication in a person's name. Social Authenticity is therefore scored neutral rather than eroded, and the reasoning is stated so the null is not confused with a gap.
Clause 7.5, team-level rooms: NULL. The clause addresses a shared channel in which a human coordinates with several named agents as peers, and requires a profile per agent in that case. Klarent is described by the vendor as several agents working as one, and a reader meeting the agent names might reasonably ask whether the clause applies. It does not: the human addresses the platform and not six peers, the agents coordinate inside one execution under the vendor's service, and no agent holds a conversation with the user in its own name. The consequence for Collaboration Mode is separate and is stated in Section 8: Cyborg is unavailable here for a different reason, because the suite runs unattended in a pipeline and tests can be revised between runs.
Section 7c: Vendor terms, data and model rights, and the company behind the product, stated plainly
This section is not part of the CI-First score and changes no sub-score. It is here because an institution adopting a platform that reaches into its applications, holds its test credentials, and generates code that runs on every deployment is also adopting that vendor's contract, its data position and its corporate substance, and a review that stayed silent would be technically complete and practically less useful. The framework measures benefit to the human, so nothing below moves the number, and saying so is deliberate: a reader who sees an unchanged score next to a governance finding should not read the finding as discounted.
The two sentences on data that a buyer should read together. Both are the vendor's, both are current, and they answer different questions. The privacy policy states: "When you use fore ai to run automated tests, the platform may process content from the applications under test ('Test Data'). Test Data is processed solely on your behalf as a data processor, in accordance with our Data Processing Agreement (DPA). We do not use Test Data for our own purposes." Section 5.3 of the terms states: "The Customer acknowledges that any data models and algorithms generated by the Provider based on the use of the SaaS-Service by the Customer and on Customer Data are the sole property of the Provider to be used by the Provider at its free discretion for any purposes." The same clause adds a protection: the provider shall not disclose or make Customer Data available to other customers except in aggregated and anonymised form.
Read together, the position is coherent and it is narrower than the first sentence alone suggests. Your raw test data is not used for the vendor's purposes and is not shared with other customers. Models and algorithms derived from your use, which is to say the thing the vendor describes selling as custom fine-tuning on your test data, are the vendor's property to use as it chooses. That is not unusual for a software vendor and it is also not what a reader takes from the privacy policy. The decision it puts in front of you is concrete: if the models your test usage produces are an asset you would not hand over, negotiate section 5.3 before you sign rather than after.
The rest of the contractual position, quoted rather than summarised.
The provider may sub-contract any of the services, including support, at its own free discretion and without requiring the customer's consent.
The agreement is governed by the substantive laws of Switzerland, excluding its conflict of law provisions and the United Nations Convention on International Sale of Goods, with exclusive jurisdiction in the City of Zürich.
Annex 1 commits the provider to use commercially reasonable efforts to reach at least 99 per cent availability per calendar month, excluding scheduled maintenance windows and force majeure events, with a helpdesk operating 08:00 to 17:00 UTC-1 on business days defined as Monday to Friday excluding Swiss national holidays and holidays in the municipality of Zürich, and with resolution times explicitly not guaranteed.
The provider's limited liability excludes loss of profits, income, revenue, use, production or anticipated savings; loss of business, contracts or commercial opportunities; loss of or damage to goodwill or reputation; loss or corruption of any data, database or software; and special, indirect or consequential loss or damage.
The warranties are limited in the way enterprise software warranties usually are: the provider gives no warranty that the platform will be wholly free from defects, errors and bugs, and no warranty that it will be entirely secure, and it does not warrant compatibility with any application not specifically identified as compatible in Annex 1.
The Trust Center, which carries the certifications and security documentation, is at foreai.eu.trust.site and requires a request for access to see its contents. The public statements elsewhere on the site are ISO 27001 certification and SOC 2 compliance, with SOC 2 Type II stated on the software-as-a-service and customers pages. The privacy policy adds details that a security review will want: TLS 1.2 or higher in transit, AES-256 at rest, role-based access controls on least-privilege principles, and multi-factor authentication for platform access.
What the vendor publishes about itself, which is more than most in this category. The vendor's own blog contains the strongest argument against uncritical adoption of its own category, and it wrote it before anyone asked. It states the arithmetic that a per-step accuracy figure hides, that an agent which is 95 per cent accurate per step completes a 20-step workflow only about 36 per cent of the time and that roughly 99.7 per cent per-step accuracy is needed for a 20-step pipeline to fail less than 10 per cent of the time. It cites Gartner's expectation that more than 40 per cent of agentic AI projects will be scrapped by 2027 and a reported 37 per cent gap between benchmark performance and real production reliability, with most failures clustering at handoff points and on messy real-world inputs. It describes a Fortune 100 company that spent over $400,000 of engineering time across six to nine months on its own autonomous QA tool and never finished, and puts the ongoing maintenance of such a tool at an estimated $200,000 a year had it shipped. It also publishes the honest counter-argument to its own pricing: a team that reduces headcount and removes reviewers amplifies whatever discipline it lacked.
That candour is a genuine credit and it is also the reason this review can state the category's risks precisely rather than infer them. A vendor that writes the failure arithmetic for its own product category into its own marketing site has given the reader the most useful document in the release.
The company, and the concentration it represents. fore ai AG is registered in Zurich and employs between 10 and 49 people according to a third-party directory profile. Third-party funding databases do not agree: one reports $5.3 million from Agile Partners, Moonfire and Tiny Supercomputer Investment Company; another reports $10.6 million with Venturelab added to that list; a third reports $2.5 million over three rounds with the most recent round in May 2026. The three are reading different filings and none can be treated as authoritative, which is itself the finding: the company's financial position is not publicly legible. The vendor's commercial position is enterprise-only, with an archived entry range of EUR 60,000 to 80,000 per year for smaller projects. A team that puts its release gate behind a vendor of this size is taking a real concentration risk, and the mitigations are stated in the vendor's own material: export the code and run it on standard runners, keep the platform's role and the suite's ownership separable in your architecture, and read the export button as the exit plan it is documented to be.
What the section does not do. It does not assert that Klarent is unsafe, and it does not suggest the terms are unusual for enterprise software, because in most respects they are not. It does not advise against the tool, which would substitute a judgement for the reader's own. It states what the vendor published, quotes the clauses that change an adoption decision, records the disagreement between third-party funding sources, and names the decision each of those puts in front of the reader: negotiate the model-rights clause or accept it, deploy inside your perimeter or accept the cloud flow, plan an exit or carry the concentration.
U365 Co-Intelligence Rating
CI-First Profile
Primary profile: Co-Worker and Assistant (level 2).
Secondary profile(s): Analyst and Tester (level 4), which is the product's second real mode, because the Explorer agent surfaces scenarios you did not specify and the run analysis finds regressions you did not look for. Coach and Tutor (level 3), narrowly, for a reader who uses the visible generated code and the step-by-step generation log to learn what a well-formed end-to-end test looks like.
Why level 2 and not level 1. Assigning level 1 would mean the human and the tool build on each other's thinking, which is the pattern for an ideation partner. Klarent's design point is the opposite: you state what should be tested, the platform plans, writes, verifies, runs and repairs, and you read the result. That is delegation with review, which the framework places at level 2. The same reasoning placed Claude Opus 5.5, MiMo-V2.6-Pro and Rabbit OS3 at level 2, and it is recorded here so the series reads consistently.
Why level 4 rather than a null. The framework's test for Analyst and Tester is that the tool's primary value is finding what the user missed. Two parts of this product meet that test rather than merely performing it: the Explorer agent proposes scenarios, edge cases and flows the team did not think to write down, and the failure triage classifies each failure as a real regression, a bad test or an environment problem, which is analysis the user would otherwise do. The 45-degree case is that both are agent conclusions the user must judge, which is why this is a secondary profile rather than a claim that the tool thinks for you.
What does not fit. Challenger and Devil's Advocate (level 5) does not apply. The product tests the application, not the user's assumptions, and nothing in it argues against your coverage plan or your release decision. The nearest thing it does is surface a flow you missed, which is coverage extension rather than challenge.
Collaboration Mode
Recommended mode: Centaur.
Alternative mode: None recommended. Cyborg is not available here.
Mode rationale: Two independent grounds, and both belong on the record. Framework Section 7.2 assigns Centaur when the Imposture Risk is Medium or High, which it is. The independent ground is specific to this tool: Cyborg requires a stopping criterion the human applies inside a fast iteration loop, and a test suite runs unattended on a schedule or inside a pipeline, with the platform able to revise a test between runs. There is no loop to stop in the sense Cyborg needs, and the controls that make a Centaur boundary real are procedural rather than interactive. Define the test boundary before the suite runs, name who reviews a healed test, keep at least one deliberately failing test in the suite so a failure is a known quantity, and read the generated steps when a flow matters. The division of labour is the whole point: you own what counts as a pass, the platform owns producing and maintaining the evidence.
CI-First Benefit Score
Dimension | Score (0-10) | Rationale |
Time | 7 | Strong savings, from structure rather than from a claim. Authoring collapses from composing a suite selector by selector to writing a sentence per flow, and repair moves from an engineer to the platform. The vendor's own unit-economics post sets the engineering line at about an hour per test per month, roughly 87 per cent of the monthly cost of owning one test, and names it as the dominant cost, which is the same conclusion this sub-score reaches independently. Held below 8 because the authoring overhead is real and the vendor documents it, including guidance to state what should not happen and to avoid vague wording, and because the review commitment scales with the suite rather than shrinking: the vendor's own figure is that teams step in less than five per cent of the time, and on several hundred tests that is a standing obligation |
Quantity | 7 | Strong increase, with the mechanism documented rather than asserted. A team that could rigorously validate 10 to 15 journeys before each deployment now hosts more than 130 tests with a full run completing in minutes and a fourfold increase in test frequency, and a publisher reports that more than half of its end-to-end tests are authored by product and business teams rather than by QA engineers. Held below 8 because the scored quantity is verified and usable output, and independent category writing records what happens when a suite outgrows the team's capacity to judge it: a large green suite that catches nothing. Coverage has grown; the capacity to judge coverage has not grown with it |
Quality | 6 | Moderate improvement, and it survives verification where the verification exists. Generated tests execute against a live application before they are relied on, each step captures a screenshot checked against that step's expected outcome, failures arrive with a Playwright trace carrying console and network detail, and the triage explicitly separates a real regression from a bad test from an environment problem. Those are real quality mechanisms rather than marketing, and they are documented. The dimension is capped at 6 for the reason the framework's Quality test requires: no independent measurement of reliability exists, the vendor publishes four different accuracy and speed figures across its own surfaces, and the category's documented failure mode, a healed locator that keeps a test green while it stops testing what it was written for, is exactly a quality risk that only a reader who inspects the difference will catch. A quality claim without a measurement is not a quality benefit |
Skill | 4 | Marginal to moderate benefit, and scored conservatively as the framework directs. There is a genuine learning surface: the generated code is visible and editable, the generation log shows how an instruction becomes steps, the documentation teaches test specification as a skill, and a reader who works at it learns what a well-formed end-to-end test looks like and why an assertion that checks the wrong thing is worse than no test. Against that, the product's stated purpose is to remove the specialist bottleneck, which is skill substitution by design, and the judgement the framework cares about most, deciding what a pass means and whether coverage is real, is the part the product moves to the people least equipped to exercise it. A reader gains vocabulary and pattern recognition and does not gain the capability the vocabulary describes. Clause 5.2.3-a returns a null, so the 4 is URC's judgement rather than a floor |
CI-First Benefit Score: (7 + 7 + 6 + 4) / 4 = 6.0 / 10 (CI-First Positive)
Why this score is not higher, and why it is not lower
6.0 is CI-First Positive, and it sits at the top of that band one tenth below Strong. The band label matters: this is a real recommendation for the team it fits, not a criticism. A QA or engineering team carrying a brittle suite, at a company large enough to sign an enterprise contract, has a genuine and measurable net benefit available here, and the score says so.
The score is not higher for one reason, and it is the same reason three times over. The framework measures benefit net of overhead, and the overhead here is verification. Nothing independent measures this product's reliability. The vendor's own numbers do not agree with each other. And the exact failure this class of tool produces, a suite that is green and meaningless, is the failure that costs the most and shows up the least. A score in the Strong band would be a claim about reliability that no evidence supports. It would also be inconsistent with the treatment of the rest of this series: MiMo-V2.6-Flash lost a Quality point against its flagship for having 14 of 482 benchmark slots covered, and no external measurement of Klarent exists at all.
The score is not lower because the fundamentals are real and unusually well documented. The authoring and maintenance savings are structural rather than promotional. The verification artefacts are specific and inspectable. Named enterprise customers give attributed quotations. The documentation covers the whole workflow, including the small print, such as the statement that some trace data is obfuscated to avoid leaking sensitive values. The vendor publishes the failure arithmetic of its own category, including the statement that a 95 per cent per-step agent completes a twenty-step workflow about 36 per cent of the time. And the product ships an export path and documents it as an exit route, which is the opposite of the behaviour a review like this usually has to warn about. Time 7 and Quantity 7 are middle-of-band scores that reflect genuine capability.
The two dimensions that cap the total are the two the review turns on. Quality is held at 6 because a quality claim without a measurement is not a quality benefit, and because the accuracy figures on the vendor's own pages contradict one another. Skill is held at 4 because the product substitutes for the judgement it does not build, which is the exact pattern the framework's most conservative dimension exists to catch.
Humics Protection Badge
Dimension | Rating | Rationale |
Creativity | Neutral (0) | The product tests what you describe. It originates no direction, and the Explorer agent's suggestions extend your coverage rather than replace your thinking about what the product is for. There is a substitution risk for a team whose value is the test suite itself, and it is named in the Limits, but the framework's question is whether the tool replaces the user's own ideation in the common case, and here the user still decides what matters and what a pass means |
Critical Thinking | Erodes (-1) | Two mechanisms, and both are documented rather than inferred. First, the product's stated purpose is to let people who are not QA specialists create and run reliable end-to-end tests, which places the judgement of a pass in front of the people least equipped to make it, and the independent category evidence is explicit about the result: a suite that grows faster than anyone's ability to judge it, and the widely reported April 2026 case in which removing a QA team and trusting a pipeline produced a fault that set every price to zero at a reported cost of roughly six million dollars. Second, the vendor's own accuracy figures, four different numbers across three surfaces, are the kind a reader accepts rather than checks, and a green suite is a conclusion the platform reaches for you. The mitigation is available and cheap, which is why this is -1 rather than a more severe reading: keep one deliberately failing test in the suite, read the healed difference, and ask what the generated test does not cover |
Social Authenticity | Neutral (0) | The product touches no human-facing communication. Its outputs are reports and alerts delivered to a channel and attributed to the platform, and framework clause 4.2-a is explicit that agent-mediated conversation is not erosion by itself. No part of the product drafts or sends a message in a person's name, and no part of it substitutes agent interaction for human contact. The null under clause 4.2-a is recorded in the clause note, and the neutral rating here follows from it rather than from a gap in the check |
Humics Protection Score: 0 + (-1) + 0 = -1 / +3 Badge: Humics-Neutral
This is the same badge as most of this series and it should be read with its reason attached rather than as a verdict on the product. The erosion is in one place: the product moves the judgement of a pass to people who do not have it yet, and a green suite is a conclusion that arrives finished. Every part of that has a control attached, and the controls are described in the guidance below. Humics-Neutral describes a tool that neither strengthens nor weakens you on its own, and the whole point of the Co-Intelligence framework is that you decide which of the two it becomes.
Superhuman Usage Guidance
When to invite this tool:
A brittle regression suite whose maintenance cost has become the reason coverage stopped growing. This is the case the product is built for and the case where the return is clearest.
Coverage work that has been blocked by a specialist shortage rather than by budget: flows that matter, are described in a written checklist, and have never been automated because nobody had the time to write the tests.
Smoke and regression suites running on every pull request or deployment, provided someone owns the failure triage.
Native mobile flows, where writing tests conventionally means learning a platform-specific framework, and where running the same flow on both platforms from one definition changes the arithmetic.
Cross-browser and cross-viewport checking of a surface where a rendering difference is a revenue difference, which is the shape of the publisher case study in this review.
Generating a first draft of a suite you intend to own. Export the code early, read it, and treat it as the beginning of a suite rather than a finished one.
When to keep this tool out:
Any application you are not authorised to point a third-party cloud service at, and any environment whose data classification you have not checked against the vendor's data position in section 7c.
A production environment as a default. The vendor's largest published case study describes a bank running agents against live e-banking, which is a decision a bank can make deliberately and a default a smaller team should not inherit.
Any workflow where a test's assertions are the only thing standing between a release and a customer-facing error, until you have at least one deliberately failing test in the suite and a named reviewer for healed tests.
An organisation that will not staff the review work. The product moves effort from writing to judging; a team that removes the judges has removed the discipline and kept the automation.
A decision that needs to be budgeted before it can be justified, if procurement cannot proceed without a published price and the vendor will not quote.
A release gate that must survive the vendor's failure. If the gate is the last check before production, the concentration risk in section 7c is a real part of the decision, and the export path is the mitigation to put in place before you need it.
Anywhere the accuracy percentage would replace a measurement of your own. Run the two-run reliability exercise in Workflow 3 on your own application before you believe any figure on the vendor's site.
U365 method integration:
LIPS + CARE: the natural division is between Execute and Review. Let the platform execute the suite and hold the run record, and keep the Review phase as your own work, with the judgement of what the suite does not cover recorded in your Digital Second Brain rather than only in the tool's project. Your coverage decisions are an institutional asset and they should live where you own them.
ULM + EVA: relevant to Career and Quality of Life, in the sense that the time released by removing maintenance is time returned to work you would rather do. Relevant to Character in one specific way: a team that keeps its own standard for what counts as tested, when the tool will happily report a pass, is practising a discipline rather than buying one.
UP-Context: this tool needs the full method, not a shortened version. An under-specified instruction produces a test that passes and checks the wrong thing, which is worse than no test, and the vendor's own documentation says the same thing in its own words. State the context, assign the profile, name the task, set the constraints and the stops, and specify the output format. The workflows in Section 6 use that order, and the constraints line is the one that does the work.
SL-OS: a natural fit for a Microsoft-centred organisation. The platform integrates with Microsoft Teams notifications and Jira, the deployment can sit on Microsoft Azure or inside your own perimeter, single sign-on is documented against Microsoft Entra ID, and a private or on-premises deployment keeps the application under test inside the perimeter you already govern. Its results belong in the same channels your release process already uses.
UNOP: no direct fit as a product, and one indirect one. The generation log shows how an instruction becomes steps, which is a worked example rather than spaced practice. A reader who wants the transferable skill should run the deliberate-failure exercise and keep the exported code to read, which converts the tool's output into material for active recall rather than a result to accept.
Over-delegation warning. Two failure modes, and the second is specific to this tool.
The general one is that the product's ease is the risk: describing a test costs nothing, the suite runs unattended, and the result arrives as a report. The CI-First formula applies as it always does. If your Human Intelligence input falls while the Artificial Intelligence term rises, the product falls, and with a suite that runs on every deployment the fall is measured in releases that passed a gate nobody was actually applying.
The specific one is the healed test, and it is the most consequential thing in this review. When an element changes, the platform can rewrite the affected part of a test so that it passes again. The test is then green, has been run many times, and is relied on by a pipeline that will block a merge if it fails. Nothing in that sequence asks whether the repaired test still asserts what it was written to assert. Independent category writing records the outcome plainly: a healed locator pointing at the wrong button quietly stops catching the regression it was meant to catch. The honest practice is to name a reviewer for healed tests, read the difference, and check the assertion rather than the result. A team that treats a passing suite as evidence of a working product has delegated its judgement to a system that was only ever asked to maintain the tests.
U.Copilot Integration
U.Copilot is the front door to the U365 tool library, at https://www.university-365.com/ucopilot. For this tool, route through it before generating anything, because the specification work is where this class of platform succeeds or fails, and an instruction precise enough for U.Copilot to structure is usually precise enough for the platform to execute.
Route a Fellow to Klarent when they:
Hold a regression suite whose maintenance cost is the reason coverage stopped growing, and are at an organisation able to sign an annual enterprise contract
Have a written checklist of journeys that has never been automated because nobody had the time to write tests
Need plain-English authoring so the people who hold the business rules can write the tests
Need native mobile flows tested from one definition rather than two platform-specific frameworks
Need cross-browser and cross-viewport checking where a rendering difference is a revenue difference
Are willing to name a reviewer for repaired tests and to keep one deliberately failing test in the suite
Route a Fellow away from Klarent when they:
Cannot staff the review work. The product moves effort from writing to judging, and a team that removes the judges has removed the discipline and kept the automation
Need a published price before procurement can proceed, because this product is quoted per customer
Are pointing testing at an application they are not authorised to reach from a third-party service, or at production as a default
Need coverage of interfaces that never render in a browser or a mobile app, such as native desktop or mainframe terminals
Want a measured reliability guarantee. No independent measurement of this product exists
Are looking for a design, communication or content outcome. Neither UIC nor UID gains a competency from it
Have no way to read generated code or a difference. A repaired test that passes is the failure mode the platform's own documentation leaves to the reviewer
Guardrails for the conversation.
State the score beside the risk: 6.0/10, CI-First Positive, with Medium AI Imposture Risk, and name Skill Illusion High rather than only the overall Medium.
Never present a pass rate as evidence of product quality. A green suite is a statement about the tests, not about the application.
Never describe a repaired test as verified coverage. Whether it still asserts what it was written to assert is a review decision, and it belongs to a named person.
Never quote the vendor's accuracy figures as a range. Four different figures appear across the vendor's own pages, which is four claims rather than a range.
Never quote the price as a budget. The commercial model is an annual licence quoted per customer, and no published rate card exists.
Never let the tool's honesty become the reader's. The vendor publishes the strongest critique of its own category, and that is not a substitute for the reader's own measurement on their own application.
Never describe the generated suite as the Fellow's acquired skill. Skill evidence is the Fellow's coverage plan, triage and defence of a result.
The trade, stated rather than a default.
A web and mobile regression suite that the team intends to keep, with a vendor accountable for repair: Klarent is the fit, and the export path is the part of the deal that reduces the risk.
An existing suite to maintain inside an established operating model: an incumbent authoring and execution platform is the fit, because it reduces selector maintenance without replacing the way the team works.
No internal QA capacity at all and a real deadline: a managed service that writes, maintains and triages the suite for you is the honest answer.
Strong platform engineers, cost sensitivity and a long horizon: building on an open-source automation stack with a coding agent is the fit, and you pay in tokens and engineering time instead of in a licence.
Interfaces that never render in a browser or a mobile app: keep a traditional model-based tool for that footprint and move the web and mobile regression elsewhere.
No ability to read the generated code or a repaired difference: no code-generating test platform is appropriate, because the review step is the control that makes it safe.
What Users Say
Klarent is sold to enterprises and there is no independent review corpus for it at all. That is the finding, and the honest version of this section is a table that says so, alongside the customer evidence that does exist and is attributable.
Aggregate Rating Table
Platform | Rating | Number of reviews | Link |
G2 | No listing found for Klarent. A search for the name surfaces Klart AI, a different product | - | - |
Capterra and GetApp | No listing found under this name. A GetApp page carrying the fore brand describes the product and carries no reviews | - | - |
TrustRadius | Profile exists with a product description and a stated starting price. No review count or score is published | - | |
OMR Reviews | No score. The page states "not enough reviews yet" and shows category averages of 90 per cent ease of use, 87 per cent support, 90 per cent meets requirements and 89 per cent ease of setup | 0 | |
SourceForge | 0.0 / 5. The page states the software has not been reviewed yet | 0 | |
SaaSHub | No score. States 0 reviews, and describes the company as a Zurich startup | 0 | |
Slashdot | No score. States no user reviews, and invites the first | 0 | |
TechShark | 4.86 / 5 across five parameters, published 2026-09-19. The same page states "No reviews yet for Klarent" and "Based on 0 approved reviews" | 0 | |
FutureTools | Not a rating. 8 upvotes, in the database since September 2026 | - | |
ToolStory | Not a rating. Lists the product with a verified API field and a free tier field | - | |
Microsoft Marketplace | Listing live since 2026-09-11. The listing carries overview, plans, ratings and details sections; no rating and no reviews were shown on the page as read | 0 | |
Gartner's peer review platform | No product profile found for Klarent or fore ai | - | - |
Trustpilot | No review page found for klarent.ai or foreai.co | - | - |
Three honest notes on that table. First, the platforms that matter for a business adoption decision have no entry, so an IT buyer looking for one is looking for something that does not exist yet rather than for something hidden. Second, the one directory that publishes a numerical score publishes it with zero reviews behind it, which is a measurement to discard rather than a data point. Third, every figure above comes from a page that was read, and the two platforms that refuse an automated read are named as such rather than counted either way.
What Users Praise
There is no independent user sentiment to report, and it would be dishonest to manufacture any from vendor-hosted material. What exists is attributable customer testimony on the vendor's own site, and it is worth reading as testimony rather than as review evidence.
The strongest of it is specific. Volker Dietzel, the chief technology and information officer at Neue Zürcher Zeitung, is quoted saying the team shifted its perspective on how it does QA, that autonomous testing is a tool for making QA lives easier, and that QA staff now spend more time investigating and reporting on bugs, which leads to better performance and stability. Pieter Wiesner, the publisher's software quality assurance team lead, is quoted on the operational detail: testing multiple devices across multiple browsers with scheduled instances, testing different geo-specific paywalls, and scheduling tests every fifteen to thirty minutes so issues are detected in a moment's notice. Marc Noy, the chief executive of OnlineFuels, is quoted on the conversion case: the biggest win has been the ability to convert existing manual test cases into automated workflows with no overhead, which helped the team move to a more scalable QA process and establish a longer-term testing strategy.
The common theme across all three is the same and it is the theme this review's Quantity sub-score identifies: the value is not a faster version of the old process, it is a process that runs at a frequency the manual one could not reach.
What Users Complain About
There is no independent complaint corpus either. Two things can be said honestly.
The first is that the vendor's own writing contains the critique. Its build-versus-buy post states that the first working prototype is deceptively easy, that the demo fools almost everyone, and that the gap between a demo and something reliable enough to run unattended is the entire engineering problem, quoting a 37 per cent gap between benchmark performance and real production reliability with most failures clustering at handoff points and on messy real-world inputs. Its token-bill post states that most organisations, and most competitors, are spending tokens regenerating code every time something small breaks, and that a lot of current AI pricing is propped up by venture subsidy that will not last. A vendor publishing the case against its own category is unusual and it is the most useful thing on the site for a buyer.
The second is the structural complaint that a review corpus would surface if it existed and does not: the product cannot be evaluated at all without an enterprise conversation. There is no published rate card, no permanent free tier on the current site, no independent benchmark, no analyst assessment, and no review to read. The barrier to forming an independent opinion is the missing evidence rather than anything the vendor has done.
Sentiment Summary
Overall sentiment: Not yet measurable. There is no independent review corpus, and the evidence that exists is vendor-hosted customer testimony and vendor-published analysis.
Key themes:
No independent measurement exists. Every accuracy, effort and speed figure in circulation comes from the vendor, and the vendor's own figures contradict one another across its own pages.
Named enterprise customers with attributed quotations do exist, across a Swiss publisher, a German registration platform, a bank, and logo walls naming companies including Google, UBS, Sixt and Uber. That is real commercial validation and it is not the same thing as independent review evidence.
The vendor publishes the strongest available critique of its own category, including the per-step accuracy arithmetic, the benchmark-to-production reliability gap, and the cost of a failed in-house build.
The directory listings that carry numbers carry them with zero reviews behind them, which tells you more about the directories than about the product.
Cost at the enterprise entry point is the practical barrier a reader will meet first, and the published figures are an archived annual range and an in-blog unit rate that cannot be reconciled into a budget without a call.
U365 Editorial Note
The crowd and the framework are not in disagreement here, because there is no crowd. That absence is itself the finding the two have in common.
Where they agree most usefully: both put the product's real value in maintenance and in the authoring bottleneck, and both refuse to accept an accuracy percentage as evidence. The framework reaches that through the Quality dimension, and the vendor reaches it through its own reliability arithmetic. The conclusion is identical, and it is unusual to be able to say that the sharpest critique of a tool's category is published by the tool's own vendor.
Where the vendor is more candid than the framework can be: the per-step accuracy compounding argument, the 37 per cent benchmark-to-production gap, and the account of a Fortune 100 build that cost over $400,000 and never shipped are all statements the review could not have made with the same authority, because they are the vendor's own.
Where an independent review would change this evaluation most, and it is the one thing missing: a third-party measurement of generated-test accuracy, or of how many generated tests are meaningful, on a real application. Everything in this review's Quality and Skill reasoning would move on that evidence, in either direction. Until it exists, the honest position is that this is a well-documented product with real enterprise customers, an unusually honest vendor, and no external verification, and the score reflects exactly that.
The divergence that matters most for a U365 reader is the one no directory listing raises. None of the directories treats the healed test as a governance question, and none of them connects a repaired test to the fact that a pipeline will now treat it as a source of truth. It is described, when at all, as a maintenance feature. It is a feature, and it is also the strongest Skill Illusion vector in this review, because a repaired test that passes is a claim about a flow that nobody has re-examined. Directory sentiment has nothing to say about that, which is the case the framework exists to cover, and it is the reason this review rates Skill Illusion High and takes Skill down to 4 while the same product is being described in its own directory listings as a 4.86 out of 5.
Comparison and Alternatives
Alternative | "Choose the alternative if..." | "Choose Klarent if..." |
mabl (https://www.mabl.com/) | You already have a QA function, a structured regression suite and a procurement process, and you want AI to reduce selector maintenance inside an operating model you intend to keep. mabl is the established incumbent in this category, its healing is mature, and its reporting and account-management machinery suit a large-company buying motion. It is an authoring and execution tool rather than an autonomous generator: you create tests in its low-code editor or by recording a flow | Coverage planning, test creation and maintenance are the parts you want the platform to carry, and your team's scarce resource is the specialist rather than the budget. Published list price for mabl is around $499 a month at entry, which is a different order of magnitude from an enterprise annual licence |
testRigor (https://testrigor.com/) | You have manual QA testers who own the scenario knowledge and want to keep authoring tests in plain English, with broad browser and mobile coverage at a lower price point. Its plain-English steps are closer to manual test cases than to a generative agent, and it includes AI element identification to reduce selector brittleness | You want the coverage itself proposed rather than written, and you want tests generated from artefacts your team already produced, such as a ticket or a specification, rather than from a step list a person compiled. Entry pricing is published at around $300 a month, with a free public tier |
QA Wolf (https://www.qawolf.com/) | You want the QA function outsourced rather than productised: human engineers write, maintain and triage the suite for you, with a time-to-coverage commitment, and you own Playwright and Appium code at the end. It is a managed service, not a self-serve platform | You want to keep the function in-house and the platform self-serve, so that your own team's understanding of what should be tested stays inside your organisation. QA Wolf's managed tier is the honest answer when there is no internal QA capacity to build on and a deadline is real; third-party deal data cited by the vendor's own comparison puts its average annual contract around $83,100, ranging from roughly $57,000 to $271,200 |
Momentic (https://momentic.ai/) | Your engineers own the test specs and you want natural-language authoring with intent-based locators resolved at execution time rather than converted into code you then maintain | You want the suite to be something non-engineers can author and own, and you want the generated code to be an artefact you can read and export |
Tricentis Tosca or Testim (https://www.tricentis.com/) | Your testing has to reach interfaces that never render in a browser or a mobile app: native SAP GUI screens, mainframe terminals, Citrix-streamed desktop sessions. Tosca is model-based and keeps a genuine lead there, and it is sold as separately licensed products that are quoted individually | Your scope is web and mobile applications, and you would rather describe a flow in a sentence than build and maintain a module library with a trained specialist practice behind it. The common real-world outcome is moving web and mobile regression to a generative platform while keeping a narrow traditional footprint for the interfaces that are neither |
Playwright with a coding agent (https://playwright.dev/), or Playwright's MCP server with a browser agent | You have strong platform engineers, cost sensitivity, and a twelve to eighteen month horizon, and you want full ownership with no vendor relationship. Microsoft shipped a Playwright MCP server with a companion command-line tool in early 2026, and one 2026 buyer's guide reports that an open-source combination of this kind matches commercial tools on around 80 per cent of flows. You pay for model tokens and for the engineering time | You want the generation, execution, triage and maintenance to arrive as one maintained product rather than as four components you integrate, and you want a vendor accountable for the repair behaviour when an interface changes |
Where Klarent is clearly better. Two things. First, the combination of autonomous coverage planning with a self-serve platform and a documented exit: the Explorer agent proposes what to test, the platform runs and repairs it, and the exported code runs on standard runners if you leave. Very little in this category offers all three, and the vendors that offer the planning tend to keep you inside their managed service. Second, the honesty of the vendor's published material, which is a real commercial advantage for a buyer: the unit economics, the per-step reliability arithmetic, the benchmark-to-production gap and the failure mode of a weakened assertion are all on the vendor's own site. That makes the evaluation faster and it makes the vendor easier to hold to its own standard.
Where Klarent is clearly worse. Independent evidence and price transparency, and the gap is wide. There is no benchmark, no third-party evaluation, no analyst assessment and no review corpus, and the vendor's own accuracy figures contradict one another. Pricing is quoted rather than published, with an archived entry range that puts the smallest published project in the tens of thousands of euros a year. Against the open-source route you give up cost control and full ownership; against QA Wolf you give up a contractual time-to-coverage commitment; against mabl you give up a published entry price and an established installed base; and against Tosca you give up reach into interfaces that are not web or mobile. Against all of them you accept an enterprise-only commercial relationship with a company of fewer than fifty people. A reader whose need is a modern web and mobile suite with a vendor accountable for maintenance is getting a real capability in exchange for those trade-offs, and the export path is the part of the deal that most reduces the risk.
Verdict and Next Steps
Who should adopt it: A QA or engineering team that already has a regression suite it cannot maintain, or a written checklist it has never automated, at an organisation large enough to sign an annual enterprise contract and disciplined enough to staff the review work. The best fit is a team that has been honest with itself about why its coverage stopped growing and has concluded that the reason is maintenance rather than tooling.
When: The evaluation can start now, because the free exploration account and the trial path let a team run the two-run reliability check in Workflow 3 on its own application before committing. Adoption should wait on three things: a named reviewer for healed tests, at least one deliberately failing test in the suite so that failure is a known quantity, and a decision about where the tests run, because the data position in section 7c is a legal and security question rather than a technical one. For a regulated application, that decision is the one to take first and it determines whether the cloud, private cloud or on-premises path is the only one available to you.
For what: The primary task is a web or mobile regression and smoke suite that runs on every change or on a schedule, in an environment you are authorised to test, with a triage process behind the results. The secondary task is moving test authoring to the people who hold the business rules. The task to avoid is using the pass rate as evidence of product quality in the absence of a reviewer and of at least one test you know can fail.
UP-Context prompt pack:
Here are three reusable prompts written in the U365 prompting method, each in the UP-Context order with a Role line that assigns the CI-First Profile before the task and a verification close that states what the human does with the output. Copy them into Klarent with your own context. The first is the boundary prompt to run once before you generate anything real, and the third is the one that keeps the suite honest over time.
1. The coverage boundary, stated before the first test is generated.
Context: We are testing [application] in [environment]. Our highest-risk flows are [name three, with the business reason]. Our previous automation was abandoned because [reason]. We have [n] people who can review results, and [name who owns the release decision].
Role: AI as Co-Worker and Assistant (Profile 2). I own what counts as a pass and what counts as covered. You generate and maintain.
Task: Confirm back to me, before we start, the working boundary for this project: which flows you will treat as in scope, what you will do when an instruction is ambiguous, and what you will refuse to test.
Constraints: Never mark a test passing that did not assert its outcome. Never weaken an assertion to make a test pass; propose the change with your reasoning and wait. Do not create or modify data beyond what a flow requires. Do not send messages, emails or notifications from inside a flow. Stop and ask rather than choosing a reading of an ambiguous instruction. State plainly which flows you cannot test and why.
Output format: Three short lists: what is in scope, what you will ask about, and what you will refuse. Then one sentence on how you will tell me a test passed.
UP-Context verification: I read the three lists before any test exists, I check the in-scope list against our own high-risk flows, and I keep the refusal list as the record of what this suite will never cover. I name the reviewer of this project before the first test is generated, not after the first failure.
2. The suite build, with the acceptance criteria named in advance.
Context: Our regression checklist is [n] journeys held in [where], executed manually before each release. The three that matter most are [name them]. A correct run looks like [describe what a pass means for one of them, concretely]. We deploy to [environment] and our pipeline is [GitHub Actions / GitLab / Azure DevOps / Jenkins].
Role: AI as Co-Worker and Assistant (Profile 2) for the build, and Analyst and Tester (Profile 4) for the triage. I own the acceptance. You produce the tests and the evidence.
Task: Generate one end-to-end test per journey from these instructions, run each one, and for every failure tell me whether it is a real regression, a badly specified test or an environment problem, and which evidence you based that on.
Constraints: Use only project secrets, never literals in an instruction. Do not heal any test during this build; report a failure instead. Do not weaken an assertion to make a test pass. Name the environment and the build for every run. State plainly which journeys you could not express as a test and why.
Output format: Per journey, the test name, the step list, the result and the triage. Then one list of the journeys you could not express, with the reason. Then one line naming any test whose only assertion is that a page loaded.
UP-Context verification: I read every generated step list before I trust the suite, I open one run per critical journey and check that the assertion step is visible rather than only the navigation steps, and I confirm the suite fails when I deliberately break one flow. I add at least one test that must fail and keep it in the suite, so that a green run keeps meaning something. If I cannot explain what a test asserts without reopening the tool, it does not enter the suite.
3. The monthly honesty check on the suite, which is the prompt worth running on a schedule.
Context: This project holds [n] tests across [n] suites, generated over [period]. [n] of them have been repaired at least once. The person who owns the release decision is [name].
Role: AI as Analyst and Tester (Profile 4). I am auditing what the suite actually covers, not asking for more coverage. You report and you do not repair.
Task: For each repaired test, list what changed in the repair, and say whether the assertion that decides the test's outcome was among the changes. Then list the tests whose only outcome assertion is that a page or a screen loaded.
Constraints: Do not repair, edit or generate anything in this pass. Do not summarise; list. If you cannot determine whether an assertion changed, say so rather than guessing. Do not report a count of passing tests as evidence of coverage.
Output format: Two tables, one per question, with the test name, the change and your answer. Then one line naming the tests you could not assess.
UP-Context verification: I read both tables myself, I delete or rewrite what fails, I record the outcome in my LIPS Digital Second Brain rather than only in the tool, and I keep one known-failing test in the suite so a green run keeps meaning something. I re-run this check every month, because a repaired test that passes is a claim about a flow nobody has re-examined. If I cannot defend a test's assertion in one sentence, I remove the test.
---
Related U365 content:
URC's INSIDE Tools Review of Jev AI (TypeSafe AI), for the decision-model case where the deliverable is a judgement rather than an artefact, and the closest contrast to a tool that produces one.
URC's INSIDE Tools Review of Rabbit OS3, for the agent-platform case where a vendor's own terms are the most useful document in the release, and where the same practice of quoting the contract against the launch copy applies.
URC's INSIDE Tools Review of n8n, for the workflow-automation case and what happens when the reader owns the execution layer rather than renting it.
URC's INSIDE Tools Review of Hermes Agent, for the highest-scoring agent platform in this series and the own-your-record contrast with a rented quality function.
Browse the published U365 Tools Reviews index at https://www.university-365.com/tools
Status and Last Tested
Re-check: trigger-based, maximum six months. The triggers are listed above, and the first two, an independent measurement and a published rate card, would each change the score rather than only the wording.
Version reviewed: Klarent by fore ai AG, as documented at the 2026-08-10 rename and the 2026-09-11 Microsoft Marketplace listing.
Tool to Skill to Credential
Mastering this tool builds a skill, the skill maps to a U365 competency, and the competency is what a credential recognises. The chain below is stated in the table, held to the rule that no credential claim is asserted without verification.
Tool skill | U365 competency | Credential | Institute | Stacks into |
Specifying a testable outcome in plain language, including what should not happen, so that a machine can act on it without guessing | Test specification and requirements precision | Business Analysis Professional (60 days, diploma). Its published programme covers requirements articulation, agile requirements and business process modelling | Bachelor of Business Administration (B.B.A.), then Master of Business Administration (M.B.A.) | |
Reading generated code and judging whether an assertion tests what it claims to | Code comprehension and review discipline applied to machine-generated artefacts | Software Developer (60 days, diploma) | UIT (Technology, AI, Data Science) | Bachelor of Science in IT (B.Sc.), then Master of Science in IT (M.Sc.) |
Triaging a failure into a real regression, a bad test or an environment problem, and defending the classification with evidence | Defect analysis, evidence-based reasoning and release judgement | Confirm with academic team. No published U365 diploma assesses software defect triage. The nearest programmes are Software Developer for the code context and Data Analyst Expert for the evidence discipline, and neither publishes a triage outcome | UIT (Technology, AI, Data Science) | None asserted, because no credential is attached |
Building and running a test suite in a pipeline that blocks a merge on a genuine failure, and knowing when it should not | Continuous delivery practice, release engineering and risk judgement | Full-Stack Web Developer (60 days, diploma). Its published programme includes version control essentials, DevOps foundations and REST APIs | UIT (Technology, AI, Data Science) | Bachelor of Science in IT (B.Sc.), then Master of Science in IT (M.Sc.) |
Appraising the cost of owning a test suite, including the review line, and deciding between building, buying and outsourcing | Technology investment appraisal and total cost of ownership | Financial Analysis Specialist (30 days, diploma). Its published programme covers financial statement analysis, financial modelling and forecasting | UIB (Business Management, Entrepreneurship) | Bachelor of Business Administration (B.B.A.), then Master of Business Administration (M.B.A.) |
The four programme anchors were read as published in the live U365 catalogue on 2026-09-25, and each public programme page returned a successful response on the same date. No component title within any programme is asserted, and no per-programme access level is asserted, because the catalogue does not publish one.
Access level, stated plainly. University 365 has three academic access levels: DISCOVERY, INSIDER and SUPERHUMAN. Specialized diplomas and certificates have Basic, Foundation and Expert levels: DISCOVERY Fellows can enrol in Basic-level programmes only, INSIDER Fellows in Basic and Foundation programmes, and SUPERHUMAN Fellows in all of them. University degree programmes carry a single Expert level and are open to SUPERHUMAN Fellows only. Because four of the five chains above stack into a degree, the degree outcome in those four chains is open to SUPERHUMAN Fellows only, and a reader should not read this table as a degree pathway available to every Fellow.
Skill level and the honest note. The competencies above are the ones a reader actually builds by using this class of tool, and they are a step up from writing test code rather than a step down from it, because the judgement moves to you and the typing moves away. No UIC (Digital Communication, Marketing) or UID (Digital Design, UX/UI) credential chain is mapped, because no part of this product builds either institute's disciplinary competency even where it tests their outputs.
The pedagogical condition on the chains. The chains apply only when the Fellow can state why a test asserts what it claims, explain what a repaired test now covers, reproduce the run evidence independently, and name what the suite does not cover. Shipping a generated suite is not evidence of the Fellow's skill. The assessment artefact must include the Fellow's own coverage plan with what is deliberately not tested, the triage of at least one failure with the evidence used, the reviewer decision on one healed test, and the rejected alternatives.
A curriculum gap, recorded rather than filled. U365 publishes no software quality or test-automation credential, so one of the four competencies this tool exercises has no assessment home. Two candidates for a future programme, consistent with this review's own recommendation of a teachable specification skill that serves readers on any platform: test specification and verifiable outcomes, which is teachable without any product; and agentic workflow governance, covering the review of machine-authored artefacts, the reviewer decision on a repaired test, and what a gate should block on. Neither is a current programme and neither is presented as one.
SL-OS Integration
Klarent fits SL-OS as a quality-assurance execution layer that a Fellow supervises. It does not replace the Fellow's standard for what counts as tested, and a suite output enters SL-OS only with the coverage plan and the review record that make it defensible.
LIPS Digital Second Brain record. Store one record per substantive engagement, under the relevant project or under Career and Finance for skill development, containing: the application, the environment and the authorisation under which it was tested; the coverage plan in the Fellow's own words, including what is deliberately not tested and why; who owns the release decision and who reviews a repaired test; the test instruction set as written, with the constraints line and the definition of a pass; the CI-First Profile and the Collaboration Mode for the session; the gate rule, meaning what blocks a merge and the one case where it must not; run evidence kept as output rather than as a claim, meaning the run identifier, the failing step, the screenshot and the trace reference; the triage of at least one failure with the evidence used and the classification; the repair log, meaning every test that was repaired, what changed, whether the outcome assertion changed, and the date a named person read it back; the honest check, meaning the list of tests whose only assertion is that a page loaded and what was done about each; the cost and effort record including review minutes; and the Fellow's own explanation of what the suite covers and what it does not.
The repair log is the field most likely to be omitted and the one that matters most, because a repaired test reports success either way.
CARE cycle. Collect the coverage plan, the instruction set, the run records, the traces, the repair log, the review minutes and the vendor material that was tested against rather than believed. Write the Action Plan before the suite runs: the in-scope flows, the flows deliberately excluded with the reason, the definition of a pass, the reviewer of repaired tests, the gate rule and the environment authorisation. In Review, read every generated step list for the flows that matter, read the difference on every repaired test, confirm the assertion rather than the result, and keep one test that must fail. In Execute, accept the suite with the reviewer's decision recorded, the coverage gaps named in LIPS rather than only in the tool, the accepted risk stated, and the learning outcome written by the Fellow.
ULM and EVA. Career and Finance is the primary domain: the transferable skill is the judgement of a pass and the governance of an automated check, both of which are professional skills rather than tool skills, and both transfer to any tool that reports success. Quality of Life is conditional, and it improves where the tool removes a maintenance burden the Fellow already understands rather than adds a review load they did not previously carry. Character and Emotions is touched in one way: maintaining your own standard for what counts as tested, when the platform will report a pass either way, is a discipline rather than a feature. The tool is not recommended for Body and Health, Spirit and Mind, or Social and Love Relationships, because nothing in the release addresses those domains. Within EVA: Explore by reading what the platform proposes to cover and comparing it against the flows the business actually cares about; Visualize by mapping the coverage, the gaps, the gate rule, the repair log and the human decision points on one page; and set the Action Plan by deciding what the suite may run, what triggers a repair, who reviews it, and what the suite may never be trusted to conclude on its own.
My Successful Life cadence. Software-quality work: two sessions per week of 45 to 90 minutes, each closing with a coverage gap named in writing and one triage defended from the trace. Release engineering: one weekly read of the repair log and the gate rule, checking that the assertion still holds rather than only that the suite is green. Business and investment work: one costed workflow case, then a monthly review of cost per maintained test, review minutes, accepted risk and owner accountability. Communication and design Fellows: on demand, for approved observation of a content or design surface under test, and no dedicated routine is warranted because no competency in those institutes is built here. All Fellows: a monthly honesty check, using the third prompt in Section 11, with the outcome in LIPS rather than in the vendor's project alone.
Microsoft 365. The integration is genuine rather than manual, and it is the strongest platform-level fit in this review. Results and alerts are delivered to Microsoft Teams, and work items can be raised in Jira or Linear. Deployment can run on Microsoft Azure or inside the institution's own perimeter, with private cloud and on-premises options documented. Single sign-on is documented against Microsoft Entra ID as the example identity provider. The practical pattern for a Microsoft-centred team is to keep the suite project inside the tenant's governance, deliver notifications to the Teams channel the release process already uses, and keep the coverage plan in OneNote or SharePoint rather than in the tool alone. One rule does not move: never store application credentials, API keys or unredacted secret-bearing logs in LIPS. The vendor documents masking secrets in output and obfuscating some trace data, and a masking claim is not a reason to place a secret in an instruction.
The fit statement. A natural fit for a Microsoft-centred organisation, and a conditional fit for a Fellow. The platform is the execution layer; the coverage standard, the repair review and the gate rule are the Fellow's. The product will report a pass on exactly what was described and nothing else, so the value of the tool is bounded by the quality of the specification and the Fellow's willingness to read results. Adopted with a named reviewer and one deliberately failing test, it returns maintenance time to work the Fellow would rather do. Adopted as a green light, it reports success on a suite nobody has read.
Learn More at U365
Related micro-course: None currently available for this tool.
Faculty commentary: Hubert Graef, Dean of Research (URC). The finding I would put in front of a reader is the same one the vendor puts in front of theirs, and both of us arrive at it from different directions. This class of tool genuinely removes the two costs that have always limited automated testing, and in doing so it moves the entire burden onto a judgement that no tool can make for you: whether a passing test means the product works. The vendor's own writing puts a number on the risk, that an agent which is 95 per cent accurate per step completes a twenty-step workflow about 36 per cent of the time. A team that reads that sentence and staffs the review accordingly will do well with this product. A team that reads the accuracy percentage on the homepage and stops there has bought the illusion, not the test suite.
How-To Hub content: None currently available for this tool. The candidate article is the deliberate-failure exercise in Workflow 3, which is the fastest available way for a team to learn what its suite does not cover.
Further reading: the tool reviews named in the Related U365 content list above, and the U365 Tools Reviews index at https://www.university-365.com/tools.
Migration Path
Not applicable. Klarent is Active and recommended, so no Migration Path is required and none is included. The status badge and the re-check triggers above are the whole of the standing.
U365's Recommendations to Learn More
Official learning resources
The product documentation index, which covers the whole workflow from test creation to trace reading and is the single most useful document set on the site: https://klarent.ai/docs/
The test creation guide, and specifically the instruction-writing guidance about imagining an experienced tester who just joined and about stating what should not happen. This page is the difference between a suite that tests your product and a suite that tests nothing: https://klarent.ai/docs/create/test-creation/
The generation guide, which sets out the step-by-step loop from analysing application state to verifying a screenshot against the expected outcome of the step: https://klarent.ai/docs/generate/generations-main/
The self-healing page, which is short and should be read next to the website's description of the same capability, because the two do not describe the same workflow: https://klarent.ai/docs/run/runs-self-healing/
The advanced debugging page, which explains what a Playwright trace contains, including the note that some data is obfuscated to avoid leaking sensitive values: https://klarent.ai/docs/run/runs-debugging/
The mobile test generation guide, for the APK-based workflow and what the agent analyses on a mobile screen: https://klarent.ai/docs/create/creating-mobile/
The SAML single sign-on guide, for the Microsoft Entra ID configuration and the two values the vendor needs from you: https://klarent.ai/docs/configuration/config-sso-saml/
The terms and conditions, and specifically section 5.3 on data and model rights, section 7 on liability, the sub-contracting clause at 1.2.2, and the service level agreement in Annex 1: https://klarent.ai/terms/
The privacy policy, read next to section 5.3 of the terms, because the two answer different questions about the same data: https://klarent.ai/privacy-policy/
The trust page and the Trust Center, the latter requiring an access request: https://klarent.ai/trust/ and https://foreai.eu.trust.site/
The build-versus-buy post, which contains the reliability arithmetic and the account of a failed in-house build: https://klarent.ai/blogs/build-vs-buy-autonomous-qa-tool/
The token-cost post, which is the vendor arguing against the pricing model most of its category runs on: https://klarent.ai/blogs/nobody-budgets-for-the-token-bill/
The unit-economics post, which sets out what one end-to-end test costs to own per month and which line dominates: https://klarent.ai/blogs/unit-economics-of-one-e2e-test/
The agent-quality post, which explains why a score without a comparison means nothing and how the vendor calibrates its own benchmark: https://klarent.ai/blogs/how-we-track-ai-agent-quality/
The export post, which states the vendor's own case for making it easy to leave: https://klarent.ai/blogs/no-vendor-lock-in/
Video tutorials and channels
The vendor runs a small channel with four published videos, all of which were verified as resolving before this list was written. Each identifier was checked through the YouTube oEmbed endpoint on 2026-09-25, with a known-live identifier returning the same result and a known-dead identifier returning an error, so the check was working rather than passing by default.
"Klarent by fore ai | Autonomous QA Demo", the general product walkthrough: https://www.youtube.com/watch?v=BL00aBXyFT0
"Autonomous Mobile Testing | Android | iOS", which shows the native mobile workflow and is embedded in the vendor's own mobile documentation page: https://www.youtube.com/watch?v=G76CUqzyu1w
"How test healing works in Klarent", which is the video to watch next to the healing documentation page and next to the website's description of the same capability: https://www.youtube.com/watch?v=KSgWBqvF9OY
"Introducing Klarent CLI: All of Klarent, In Your AI Agent", on the command-line surface that shipped with the rename: https://www.youtube.com/watch?v=PcNWhO-Bhzk
Watch them for what the product looks like and how a flow is described in the interface, not for how it behaves on your application. They are vendor demonstrations on prepared setups, and no reliability claim in this review rests on them.
Written tutorials and deep-dive articles
The vendor's own build-versus-buy analysis, for the per-step accuracy arithmetic and the abandoned in-house build: https://klarent.ai/blogs/build-vs-buy-autonomous-qa-tool/
The vendor's unit-economics analysis, for the cost breakdown of owning a single test: https://klarent.ai/blogs/unit-economics-of-one-e2e-test/
The vendor's agent-quality analysis, for why a quality number without a comparison tells you nothing: https://klarent.ai/blogs/how-we-track-ai-agent-quality/
The publisher case study, for cross-browser and cross-device regression at high frequency and for the share of tests authored outside the QA team: https://klarent.ai/case-studies/safeguarding-nzz-digital-revenue/
The registration-platform case study, for the before-and-after coverage and frequency figures: https://klarent.ai/case-studies/online-fuels-turning-hours-of-qa-into-minutes/
The bank case study, for the largest claim the vendor makes and its own labelling of that claim as a modelled projection: https://klarent.ai/case-studies/tier-1-bank-autonomous-qa/
One 2026 buyer's guide on AI testing tools, which is written by a competing vendor and is candid about its conflict of interest: https://getautonoma.com/blog/ai-testing-platform-comparison
A 2026 cost and return guide from a software services firm, which carries the measured numbers this review relies on for partial healing and for what a green suite can be worth: https://www.forasoft.com/blog/article/ai-testing-optimization
A category comparison from a competing vendor, useful as an alternative reading of the same field: https://www.qawolf.com/blog/the-12-best-ai-testing-tools-in-2026
A practitioner account of an autonomous testing agent pointed at a live production application and what it did and did not find, which is the clearest short illustration of the surface-level failure mode: https://www.linkedin.com/posts/joecolantonio_i-let-an-ai-qa-agent-loose-on-my-live-production-activity-7493432124193124353-mnmV
Community and social
The vendor's LinkedIn page, which carries product announcements and customer posts: https://www.linkedin.com/company/fore-ai
The vendor's newsroom, for the two announcements since the rename: https://klarent.ai/news/
The Ministry of Testing community page created for the vendor in September 2026, which is a community presence rather than a discussion thread: https://www.ministryoftesting.com/community-stars/klarent-ai-sep-2026
TestGuild, the longest-running independent practitioner community in test automation, which is the most likely place for an independent assessment of this product to appear: https://testguild.com
The Microsoft Marketplace listing, which is where an enterprise buyer inside Microsoft's product set will meet the product: https://marketplace.microsoft.com/en-us/product/saas/fore-ai.fore-ai-autonomous-software-testing
One honest note: no community discussion of this product was found. There is no subreddit thread, no forum thread and no review corpus to read, which is the same absence Section 9 reports and the reason the vendor's own published analysis is the best material currently available.
Resources on X
Dedicated X channels:
Klarent on X, the product account: https://x.com/klarent_ai
fore ai on X, the company account: https://x.com/fore_ai
TestGuild on X, for independent practitioner coverage of the category: https://x.com/TestGuild
Joe Colantonio on X, whose feed carries practitioner commentary on agentic testing and the account quoted in this review's sources: https://x.com/joecolantonio
X posts with video content:
The product account's feed, which carries product demonstrations including the mobile testing workflow: https://x.com/klarent_ai
The company account's feed, for the rename and Microsoft Marketplace announcements: https://x.com/fore_ai
The practitioner post quoted in this review, in which an autonomous testing agent was pointed at a live production application and reported the surface-level findings it could reach: https://x.com/joecolantonio
Dedicated X channels for this category
For a reader following agentic testing rather than one vendor, the accounts worth adding are TestGuild and Joe Colantonio for independent practitioner coverage, mabl at https://x.com/mabl and Tricentis at https://x.com/tricentis for the incumbent platform view, testRigor at https://x.com/testrigor and QA Wolf at https://x.com/qawolf for the adjacent approaches, Applitools at https://x.com/applitools for visual regression, and Artificial Analysis at https://x.com/ArtificialAnlys for independent measurement where measurement exists. On this product in particular, the account to watch first is the vendor's own, because a published rate card, a first independent measurement or a change to the healing workflow would be announced there before it reached a documentation page.
Glossary
CI-First Benefit Score
The average of four dimensions, each scored 0 to 10: Time, Quantity, Quality, and Knowledge and Skill. It answers whether using the tool makes Co-Intelligence more profitable than Human Intelligence alone. Bands: 0 to 2.0 CI-First Negative, 2.1 to 4.0 CI-First Neutral, 4.1 to 6.0 CI-First Positive, 6.1 to 8.0 CI-First Strong, 8.1 to 10.0 CI-First Transformative. The score accounts for the overhead of prompting, supervising and verifying, not just the benefit the tool produces. Klarent scores 6.0.
CI-First Profile
The role the AI plays in your working relationship. (level 1) Co-Creator and Thought Partner, (level 2) Co-Worker and Assistant, (level 3) Coach and Tutor, (level 4) Analyst and Tester, (level 5) Challenger and Devil's Advocate. Lower level numbers indicate higher AI autonomy. Assigning a profile before giving the AI a task is a core CI-First discipline. Klarent is primarily a Co-Worker and Assistant (level 2), with Analyst and Tester (level 4) as a substantial secondary and Coach and Tutor (level 3) narrowly.
Humics Protection Badge
A rating of whether a tool protects, leaves neutral, or erodes three human capabilities: Creativity, Critical Thinking, and Social Authenticity. Each is scored +1, 0, or -1, and the sum gives the badge. +2 to +3 is Humics-Friendly, -1 to +1 is Humics-Neutral, -2 to -3 is Humics-Risky. It measures whether the tool strengthens the human or contributes to AI Obesity. Klarent is Humics-Neutral at -1 / +3: Creativity neutral, Critical Thinking eroded, Social Authenticity neutral.
AI Imposture Risk
The likelihood that a tool traps you in one of three illusions. The Time Illusion is the appearance of saving time when net time is lost. The Quantity Illusion is high volume that looks good but does not survive inspection. The Skill Illusion is the appearance of competence in you while the underlying skill is absent or eroding. Each trap is rated Low, Medium, or High with cited evidence, and the overall level is Low when all three are Low, High when two or more are High. Klarent is Medium overall, with Skill Illusion High.
User Sentiment
The aggregated public opinion from review platforms, community forums, and repository activity. It is reported separately from the CI-First score because crowd sentiment can contradict a rigorous evaluation. Where the two agree, the finding is stronger. Where they diverge, the divergence is worth explaining. For a product sold to enterprises with no independent review corpus, the honest report is that no user sentiment exists, and the directory pages that carry scores carry them with no reviews behind them.
Review Status
Review Status records the current standing of the tool at the time of the last test. Active: the tool is current and recommended. Active (updated): recently re-checked and the content was refreshed. Changed: a re-check trigger fired and an update is pending, so read the review with that in mind. Risky: the tool has significant unresolved issues, or it has been clearly surpassed by newer alternatives. Use it with caution and read the Limits section. Stale: this review has not been re-checked in over 6 months, so treat details such as pricing and features as unverified. Retired: the tool still works but is no longer recommended. Deprecated: the tool has been shut down or fundamentally changed. Retired and Deprecated posts include a Migration Path section. Klarent is Active, with the conditions stated at the status badge.
Sources
Vendor primary sources
fore ai AG, Klarent product page, for the positioning, the six-agent description, the discovery inputs, the self-healing claim, the notification channels and the FAQ answers on pricing and trials: https://klarent.ai/
fore ai AG, product documentation, welcome and quick start, for the three-step first-test workflow and the statement that the platform is AI-powered and uses Playwright: https://klarent.ai/docs/ and https://klarent.ai/docs/quick-start/
fore ai AG, product documentation, FAQs, for the no-coding statement, the login-flow answer, the supported browsers and the support route: https://klarent.ai/docs/product-faqs/
fore ai AG, product documentation, test creation, for the instruction-writing best practices including the guidance to state what should not happen and to avoid vague wording such as "verify the content", and for variables, secrets, modules and browser state: https://klarent.ai/docs/create/test-creation/
fore ai AG, product documentation, generating a test, for the step-by-step generation loop including screenshot verification against the expected outcome of each step: https://klarent.ai/docs/generate/generations-main/
fore ai AG, product documentation, self healing, for the documented Heal this test workflow: https://klarent.ai/docs/run/runs-self-healing/
fore ai AG, product documentation, advanced debugging, for the Playwright trace contents and the note about obfuscation of sensitive data: https://klarent.ai/docs/run/runs-debugging/
fore ai AG, product documentation, mobile test generation, for the APK workflow, the cloud-hosted device and the mobile UI hierarchy analysis: https://klarent.ai/docs/create/creating-mobile/
fore ai AG, product documentation, SSO via SAML, for the Microsoft Entra ID configuration steps, the auth.foreai.co endpoints and the onboarding meeting: https://klarent.ai/docs/configuration/config-sso-saml/
fore ai AG, test data management page, for variables, secrets and assets, and the statement that secrets are encrypted at rest and masked in all output, run logs and screenshots: https://klarent.ai/platform/test-data/
fore ai AG, test management page, for projects, nested folders, suites and scheduling: https://klarent.ai/platform/test-management/
fore ai AG, integrations page, for the CI/CD, issue-tracking and notification integrations and the auto-created GitHub issue on failure: https://klarent.ai/platform/integrations/
fore ai AG, use cases index, for the six web and mobile scenarios and their stated metrics: https://klarent.ai/use-cases/
fore ai AG, SaaS customers page, for the multi-tenant coverage claims, the compliance statements including SOC 2 Type II and GDPR, and the results block carrying 90 per cent less manual QA effort, 6 times faster release cycles, roughly 94 per cent execution accuracy, 4.1 times annual return and an average cost per execution falling from about $1.54 to about $0.30: https://klarent.ai/customers/saas/
fore ai AG, finance and banking customers page, for the regulatory framing, the PCI-DSS and SOX audit-support statement, the six-agent description and the same results block: https://klarent.ai/customers/finance-banking/
fore ai AG, mabl comparison page, for the agent roles, the 90 per cent coverage in two weeks claim and the 96 per cent precision claim: https://klarent.ai/comparison/mabl-vs-klarent
fore ai AG, QA Wolf comparison page, for the managed-service comparison, the per-maintained-test pricing model and the third-party deal data cited from Vendr: https://klarent.ai/comparison/qa-wolf-vs-klarent
fore ai AG, Tricentis Tosca comparison page, for the modelling-layer contrast, the Playwright export statement and the interface-reach limits: https://klarent.ai/comparison/tricentis-tosca-vs-klarent
fore ai AG, glossary entry on AI test automation, including the vendor's own statement of the category's challenges, that teams need cycles of validation to trust test logic they did not write and that working out why a test passed or failed can call for new tooling: https://klarent.ai/glossary/ai-test-automation/ai-test-automation-overview/
fore ai AG, case study, Neue Zürcher Zeitung, for the paywall and cross-browser regression scope, the hourly and fifteen-to-thirty-minute schedules, the 75 per cent faster smoke testing, the share of tests authored by product and business teams, and the attributed quotations from Volker Dietzel and Pieter Wiesner: https://klarent.ai/case-studies/safeguarding-nzz-digital-revenue/
fore ai AG, case study, Elequo by OnlineFuels, for the 10 to 15 journey baseline, the 130-plus automated tests, the sub-four-minute suite, the fourfold test frequency and the attributed quotation from Marc Noy: https://klarent.ai/case-studies/online-fuels-turning-hours-of-qa-into-minutes/
fore ai AG, case study, Tier-1 global bank, for the anonymised engagement, the 80 highest-risk journeys in the initial phase, the roughly 90 per cent reduction in manual QA effort, the zero maintenance backlog, the Swiss and EU data residency statement, the live e-banking environment, and the vendor's own labelling of the savings and hour figures as modelled projections at full enterprise rollout rather than realised results: https://klarent.ai/case-studies/tier-1-bank-autonomous-qa/
fore ai AG, about page, for the mission statement, the founder list, the Zurich base and the attributed customer quotations: https://klarent.ai/about/
fore ai AG, clients page, for the customer logos and the same attributed quotations: https://klarent.ai/clients/
fore ai AG, newsroom, for the two announcements since the rename: https://klarent.ai/news/
fore ai AG, "Say hello to Klarent", 2026-08-10, by Asheem Panakkat, for the rename rationale, the native mobile testing release and the Klarent CLI release naming Claude Code, Antigravity and Codex as agents that can drive the platform: https://klarent.ai/blogs/introducing-klarent/
fore ai AG, Microsoft Marketplace availability announcement, dated 2026-09-11, for the Azure build, the agent lifecycle description, the managed-service option and the SOC 2, encryption, role-based access control and audit-log statements: https://klarent.ai/blogs/klarent-now-available-on-microsoft-marketplace/
fore ai AG, Microsoft Marketplace listing, for the agent list, the enterprise customers named including Sixt, NZZ and UBS, the up-to-90-per-cent effort reduction and up-to-10-times faster release claims, and the zero-manual-maintenance statement: https://marketplace.microsoft.com/en-us/product/saas/fore-ai.fore-ai-autonomous-software-testing
fore ai AG, trust and security page, for the ISO 27001 certification, the SOC 2 compliance statement, encryption, deployment flexibility, custom model fine-tuning and the enterprise support claim: https://klarent.ai/trust/
fore ai AG, Trust Center, confirming the organisation and the access-request requirement: https://foreai.eu.trust.site/
fore ai AG, privacy policy, for the data controller identification, the test-data processing statement and the DPA reference, and the TLS 1.2 or higher, AES-256, role-based access control and multi-factor authentication statements: https://klarent.ai/privacy-policy/
fore ai AG, terms and conditions, last updated 2026-08-07, for the rename notice preserving existing contractual terms, and for section 1.2.2 on sub-contracting, section 5.2 and 5.3 on data ownership and model rights, section 6 on warranties including the no-defect and no-security-warranty clauses, section 7 on liability exclusions, section 8 on data protection, section 10 on term and termination, section 13.11 on Swiss law and Zurich jurisdiction, and Annex 1 for the service level agreement: https://klarent.ai/terms/
fore ai AG, "We built the export button first", by Asheem Panakkat, for the export path, the failure-triage claim and the vendor's own statement of the risk it is taking by removing lock-in: https://klarent.ai/blogs/no-vendor-lock-in/
fore ai AG, "Build vs buy analysis", by Sanu Krishnan, for the per-step reliability arithmetic, the Gartner projection, the 37 per cent benchmark-to-production gap, the Fortune 100 build account and the mid-level QA salary range: https://klarent.ai/blogs/build-vs-buy-autonomous-qa-tool/
fore ai AG, "Nobody budgets for the token bill until it's too late", by Ryan Short, for the token-regeneration critique of the category, the Uber budget anecdote and the statement that self-healing avoids a fresh generation call: https://klarent.ai/blogs/nobody-budgets-for-the-token-bill/
fore ai AG, "The unit economics of one end-to-end test", by Dyuwan Shukla, for the cost breakdown, the $8 to $20 per maintained test per month figure and the statement that the review time exceeds the product cost: https://klarent.ai/blogs/unit-economics-of-one-e2e-test/
fore ai AG, "How we actually know our AI agents are getting better", by Kirill Shakhnovich, for the benchmarking methodology, the calibration discussion, the statement about quotas and regional availability, and the plus-23-point internal improvement over a year: https://klarent.ai/blogs/how-we-track-ai-agent-quality/
fore ai AG, "fore ai" product page as archived by the Internet Archive, snapshots of 2025-12-12 and 2026-03-16, for the annual licence model and the statement that smaller projects typically start at EUR 60-80k per year with enterprise deployments typically in the six-figure range: https://web.archive.org/web/20260316080329/https://foreai.co/products/web
fore ai AG, pricing page as archived by the Internet Archive, snapshot of 2025-11-10, for the free starter tier at one user and 100 executions per month, and the custom-quoted enterprise tier: https://web.archive.org/web/20251110035600/https://foreai.co/pricing/
fore ai AG, YouTube channel, for the four published videos whose identifiers were verified through the oEmbed endpoint: https://www.youtube.com/@klarent-ai
Independent sources
Autonoma AI, "AI Testing Platforms Compared: How to Choose in 2026", by Tom Piaggio, which opens by naming its own conflict of interest and then classifies eleven platforms by architecture, for the six-way category taxonomy and the assessment of mabl, Testim, QA Wolf, testRigor, Katalon, Virtuoso QA, Functionize and Applitools: https://getautonoma.com/blog/ai-testing-platform-comparison
Fora Soft, "AI Testing Tools in 2026: A Buyer's Guide to Cost and ROI", for the Gartner adoption projection, the finding that self-healing removes roughly 70 to 85 per cent of locator-driven flake with the remainder coming from timing, data and race conditions, the statement that auto-merging tests produces two thousand green tests and zero regression coverage, the account of a company that cut its QA team and shipped a fault that set every price to zero at a reported cost of roughly six million dollars in lost orders, the finding that a healed locator pointing at the wrong button quietly stops catching the regression it was meant to catch, and the 2026 entry prices for mabl, testRigor, Katalon and Applitools: https://www.forasoft.com/blog/article/ai-testing-optimization
QA Wolf, "The 12 Best AI Testing Tools in 2026", written by a competing vendor, for the distinction between generating code that runs in your pipeline and interpreting the page at execution time: https://www.qawolf.com/blog/the-12-best-ai-testing-tools-in-2026
Momentic, "Best AI Tools for Automated Software Testing in 2026", dated 2026-07-30, and "Agentic Testing: How AI Agents Change Test Automation", dated 2026-06-04, both written by competing vendors, for the category comparison table and for the stated limits of agentic testing, including that it is not a good fit for highly regulated systems that need reproducibility and that false positives can slip through without human verification: https://momentic.ai/blog/ai-test-automation-tools and https://momentic.ai/blog/agentic-test-automation-changes
mabl, "5 Best Agentic AI Testing Solutions for Modern QA Teams", written by a competing vendor, for the incumbent's own framing of inner-loop against outer-loop coverage and audit-ready evidence: https://www.mabl.com/blog/agentic-ai-testing
TrustRadius, Klarent product profile, for the capability summary, the deployment and security fields, the competitor set and the stated starting price: https://www.trustradius.com/products/klarent/details
OMR Reviews, Klarent profile, for the zero-review count and the category-average figures: https://omr.com/en/reviews/product/klarent
TechShark, Klarent review page, dated 2026-09-19, for the parameter scores totalling 4.86 out of 5 and, on the same page, the statements "No reviews yet for Klarent" and "Based on 0 approved reviews", which is the reason this review treats the score as a measurement to discard: https://techshark.io/tools/klarent/
SourceForge, SaaSHub, Slashdot, TopBusinessSoftware and ToolStory product entries, for the absence of reviews, the company fields including the Zurich location and the 10 to 49 employee band, and the integrations list: https://sourceforge.net/software/product/Klarent/, https://www.saashub.com/klarent, https://slashdot.org/software/p/Klarent/, https://topbusinesssoftware.com/compare/Virtuoso-QA-vs-Klarent/ and https://toolstory.ai/tools/134836/klarent
FutureTools, Klarent entry, for the eight upvotes and the September 2026 addition date: https://futuretools.io/tools/klarent-15bc54ee
Ministry of Testing, Klarent community page, created September 2026, for the community presence: https://www.ministryoftesting.com/community-stars/klarent-ai-sep-2026
Clutch, Klarent company profile, for the minimum project size of $25,000, the 10 to 49 employee band, the Zurich location and the stated founding year of 2023: https://clutch.co/profile/klarent
Dealroom, PitchBook and Crunchbase company records for fore ai, read through search indexing for the funding figures of $5.3 million, $10.6 million and $2.5 million across three sources, the investor names Agile Partners, Moonfire, Tiny Supercomputer Investment Company and Venturelab, and the founding year disagreement between 2022 and 2023. The three sources disagree and none is treated as authoritative: https://app.dealroom.co/companies/fore_ai, https://pitchbook.com/profiles/company/539808-49 and https://www.crunchbase.com/organization/fore-ai
Joe Colantonio, practitioner post on an autonomous testing agent pointed at a live production application, for the account of finding genuine errors while never reaching below the surface, and for the distinction between agents that drive everything and agents that produce reviewable code: https://www.linkedin.com/posts/joecolantonio_i-let-an-ai-qa-agent-loose-on-my-live-production-activity-7493432124193124353-mnmV
Readability of the sources above, stated rather than hidden. Every link in this review was fetched on 2026-09-25. Ten hosts declined a plain automated read: G2, Trustpilot, TrustRadius, Clutch, SourceForge, Slashdot, TopBusinessSoftware, Crunchbase, PitchBook and Dealroom. Where those carry substance in this review, the content was reached through search-indexed retrieval rather than by a direct fetch, which is how the minimum project size, the employee band, the starting price, the funding figures and the product descriptions in Section 9 were obtained. Two of them, G2 and Trustpilot, returned no listing at all for this product, and they are reported as having no listing rather than as containing anything. No rating or review count in Section 9 comes from a page that could not be read. Two vendor surfaces, the Klarent pricing page and the Klarent security page, return a not-found response at the addresses they are linked from, which is why the pricing figures in this review come from the archived product page and from the vendor's blog rather than from a current rate card.
Community and community-reported evidence
No community discussion of this product was found. No subreddit thread, no forum thread and no review thread exists as of 2026-09-25, and the vendor's LinkedIn page is the only social surface carrying discussion. That absence is reported as the finding rather than as a gap in the search.
Ministry of Testing community page, for the vendor's presence in a practitioner community: https://www.ministryoftesting.com/community-stars/klarent-ai-sep-2026
The Klarent and fore ai accounts on X, for product demonstrations and announcements: https://x.com/klarent_ai and https://x.com/fore_ai
Internal sources
CI-First Evaluation Framework v1.2, the scoring rubrics, the Humics rating, the imposture risk assessment, the profiles, the collaboration modes and the scoring procedure: https://www.university-365.com/tools
INSIDE Tools Post Template, including the Agent Platform variant and the Infrastructure and DevOps variant, both of which apply here: https://www.university-365.com/tools
Published INSIDE Tools Reviews used as internal comparisons: Jev AI (5.5, the decision-model case and the first URC-scored review under the current ownership model), Rabbit OS3 (4.5, Humics-Risky, the agent-platform case where the vendor contract was the most useful document, post 7be3165a-a6c0-4c1d-8278-18fc7889dee3), MiMo-V2.6-Flash (5.5, the clearest precedent for scoring Quality down for unverifiable measurement), MiMo-V2.6-Pro (5.8), n8n and Hermes Agent (7.8, the highest-scoring agent platform in this series): https://www.university-365.com/tools
This is a new review rather than a refresh of an earlier one: https://www.university-365.com/tools
Faculty Note on Evidence Quality
Six claims from this release did not survive checking, and the pattern across them is worth stating before the list. This is a vendor whose product documentation and whose blog are noticeably more careful than its marketing pages.
First, the accuracy figure depends on which page you read. The customers pages state roughly 94 per cent execution accuracy. A comparison page claims 96 per cent precision, described as the most precise solution in the market, with no methodology, sample or definition published. The homepage states roughly 90 per cent success on first run. These are three different measurements of three different things, presented as though they were one number, and no page defines what it is measuring or on what it was measured. The claim to discount is not that the product is inaccurate; it is that any single figure on the site is a specification.
Second, the release-speed multiplier moves by a factor of three across the vendor's own pages. The product FAQ states three to five times faster release cycles. The customers pages state six times faster. The site's own call to action and the Microsoft Marketplace listing state ten times faster. Each is presented flatly, none carries a source, and they cannot all be the same measurement.
Third, "zero maintenance" is stated on two surfaces and contradicted on the vendor's own blog. The archived fore ai product page lists zero maintenance, and the Microsoft Marketplace listing states zero manual maintenance. The vendor's own post on the export path describes a relationship rather than a delivery, states that there are humans in the loop when the model and the platform cannot resolve something alone, and makes the argument that "mostly maintained" is where teams quietly return to fixing things by hand. The marketing absolute and the vendor's own writing cannot both be true, and the writing is the one to believe.
Fourth, self-healing is described as two different workflows. The website describes automatic detection of a failure caused by an interface change, a proposed fix, and a step-by-step difference shown before anything is applied. The product documentation describes opening a run, choosing Heal this test from the three-dot menu, and the system healing the test automatically based on the latest application flow. The documentation version gives the platform more discretion and the human less of a review step. The vendor's own documentation is the honest document here, and a reader should plan for the workflow it describes.
Fifth, the certification statement is stated at two strengths. The trust and security page and the product FAQ state SOC 2 compliance. The software-as-a-service and finance customers pages state SOC 2 Type II compliance. The second is a specific and stronger claim than the first, and only one of them can be the accurate description of the report the vendor holds. The Trust Center that would settle it requires an access request. The claim to discount until then is the stronger one.
Sixth, the founders are listed differently on the vendor's own pages. The about page presents Asheem Panakkat and Momchil Ivanov as the founders. A third-party company profile and a directory listing name Asheem Panakkat and Simon Hecker. The vendor's own author page describes Simon Hecker as chief revenue officer. This is a small inconsistency and it is reported because a reader building a picture of the company behind an enterprise platform will meet all three versions.
What the vendor got right, stated with the same emphasis, and it is a longer list than this section usually carries. The vendor publishes the strongest available critique of its own product category: that an agent which is 95 per cent accurate per step completes a 20-step workflow only about 36 per cent of the time, that roughly 99.7 per cent per-step accuracy is needed for a 20-step pipeline to fail less than 10 per cent of the time, that a reported 37 per cent gap exists between benchmark performance and real production reliability with most failures at handoff points and on messy real-world inputs, and that Gartner expects more than 40 per cent of agentic AI projects to be scrapped by 2027. It publishes the cost arithmetic that argues against the pricing model most of its category uses. It publishes the honest account of an in-house build that cost over $400,000 and never shipped, and of the salary line a build-versus-buy decision usually omits. It built the export path deliberately and states its own risk in doing so. Its documentation covers the whole workflow including the small print, such as the statement that some trace data is obfuscated to avoid leaking sensitive values. Its largest case study carries two named customers with attributed quotations, and the one anonymised result is explicitly labelled by the vendor as a forward-looking modelled projection rather than a realised outcome, which is more disclosure than most vendors in this category provide. And its rename notice preserves existing contractual terms in writing rather than leaving customers to infer it.
The pattern is consistent and it is the reason this review's score is a recommendation rather than a caution. Where this vendor is describing a mechanism, it is precise and it is often arguing against itself. Where it is describing a result, the numbers multiply by three depending on the page. A reader of this review should take the first category as the evidence and the second as marketing, and should treat the vendor's own reliability arithmetic as the most useful sentence in the release.
Review conducted by URC under the CI-First Evaluation Framework, version 1.2. Scoring date 2026-09-25. Tool version reviewed: Klarent by fore ai AG, as documented at the 2026-08-10 rename and the 2026-09-11 Microsoft Marketplace listing. Framework version applied: 1.2. Framework clauses checked: 5.2.3-a returns a null, with the reasoning recorded because the tool does write durable agent-authored artefacts inside the user's own test inventory and the boundary therefore had to be drawn explicitly; 4.2-a returns a null, because the product produces platform-attributed reports rather than communication in the user's voice; 7.5 returns a null, because the agents coordinate inside one execution under the vendor's service rather than in a shared room the human participates in.
Comments