A good human QA tester doesn’t approach a product as a blank slate. After a few cycles, they can remember where the fragile pages are, how users move between screens, which bug likes to crawl back after every release, all that jazz. That type of memory is actually what makes them fast.
Test agents don’t really have this advantage. If an agent needs to rediscover your product from scratch on every run, the whole testing process ends up being slow, inconsistent, and, frankly, quite expensive.
So, the important question here is can an agent actually remember your product.
One practical way to provide an agent with this kind of memory (and one I will walk you through in this piece) is a knowledge graph, which is a structured representation of your product that the agent can reason over before it writes a single test.
TL;DR:AI coding has moved the bottleneck from writing code to verifying it. Scripted tests check predefined steps, whereas agentic tests focus on intent, and that intent needs memory. Mind you, it’s structured agent memory we’re talking about here, not just a pile of screenshots and unstructured context.A knowledge graph turns your product (its pages, actions, tests, past failures) into connected memory that the agent can query. However, it may not always be worth building, which is why I’ll cover both when it’s considered an investment and when it might be overkill.
Bottleneck Shift
Features that used to take weeks now land in days. But just because you’re shipping faster doesn’t mean there’s no need to check the work. Every AI-generated change has the potential to break the flow that’s three screens away, and every fix needs to be retested. Before long, you find yourself in a loop, constantly generating, fixing, validating, rinse, repeat.
And if you start to fall behind, the numbers end up being unforgiving. For example, a bug that has escaped to production costs far more to fix than one that’s been caught earlier (industry estimates put it at several times higher). As code volume climbs, review quality can start to slip, and more of those expensive bugs can get through. A human clicking the same regression suite for the tenth time this month simply can’t keep up with the pace of generation.
Agentic Testing vs. Scripted Testing: Steps vs. Intent
Classic automation follows a familiar recipe. Go to /checkout, find an element with this data-testid, click it, and assert this text. Works beautifully… Until the product changes. Move a button, rename a selector, or split a flow across two pages, and the script breaks because these tests verify steps, not outcomes.
AI-assisted authoring makes writing scripts much faster. A large language model can draft your Selenium script in no time, but you still end up with just another script.
Agentic testing takes a different approach. You give the agent an intent ("verify a user can apply a discount and complete checkout"). Then, it observes the UI, acts, evaluates the result, and decides the next step.
The Problem of Unstructured Context
I’ve made this argument before about retrieval-augmented generation (RAG). The hard part is almost never retrieval or generation itself. It’s how the surrounding context is represented.
Test agents hit the same wall. An agent can spend all day crawling your app and collecting screens, actions, and flows, but if those observations are just a pile of screenshots and disconnected notes, the test-creation step has to reconstruct the same understanding every time, which is expensive and inconsistent.
A knowledge graph fixes the shape of that memory. It stores entities (pages, features, actions, tests, documents) and, more importantly, the relationships between them.
So, when the agent creates a test near the discount logic later, it doesn’t just see that a checkout page exists. It knows which actions belong there, what goal they serve, and even that the total once failed to recalculate after a coupon was removed.
Turning Product Behavior Into a Graph: Meet QA.tech
QA.tech doesn’t treat a web app as a list of pages or static steps. Instead, it models the product's behavior as a knowledge graph, then uses that graph for structured context when tests are created.
Here’s what it looks like in practice:
- Crawl.Before you write anything, agents explore the product the way a new user would. QA.tech calls this- epistemic foraging: autonomously mapping pages, flows, and interactive elements.
- Model.Those observations become graph entities:- project, feature, page, action, test, document, section, chunk. At the action level, it also stores metadata like screenshots, surrounding HTML, embedding vectors, icon-recognition traces, and visit counts.
- Create.You brief a test in plain language. Then, the assistant pulls the relevant slice of the graph (feature, pages, docs, prior failures) and scopes a test around intent.
- Verify.The graph is wired into the development loop. When a PR opens, QA.tech reads the diff and linked tickets, queries the graph for the flows the change touches, runs those tests on the preview environment, and posts a pass or fail on the PR with links to recordings and reproduction steps.
A product changes constantly, so a memory that cannot forget becomes a liability. QA.tech solves this by timestamping its graph through a controlled ontology, retiring links that vanish, and adding new ones on revisit.
Memory is only one half of a self-improving agent, though. The other half is giving it a way to report friction when it hits a wall, which is a topic I covered in Let the Agent Complain. This aspect shouldn’t be overlooked, since a graph does say what the product is, but a complaint says what is missing.
When a Knowledge Graph is Overkill
A knowledge graph isn’t free, and it isn’t always the right call. Sometimes plain memory wins. Letta's "Is a Filesystem All You Need?" experiments found that agents scored 74.0% on the LoCoMo memory benchmark just by storing history in files, outperforming a graph configuration that reached 68.5%.
Graphs can be harder for an LLM to use than the simpler tools it already understands. So, if your product is small or stable, you may not need one just yet.
They can also cost you at update time. Microsoft's GraphRAG builds rich graphs, but recomputing them on frequent changes is slow, which is a poor fit for a product that ships daily.
| Situation | Reach for | Why |
|---|---|---|
| Small or stable app | Scripts, or simple file/vector memory | Graph overhead isn’t justified yet. |
| Fast-moving UI, broad flows | Incrementally updated knowledge graph | Structure survives refactors and redesigns. |
| One-off or throwaway checks | Whatever is fastest to write | You will not reuse the memory. |
| Large product, many interconnected flows | Knowledge graph as shared memory | Agents navigate and recover more intelligently. |
Going Beyond QA
The goal of agentic testing was never to generate a bigger pile of scripts. The future is less about writing more tests and more about letting agents explore the app the way real users do, catching what scripted tests miss.
If you’d rather not build and babysit that graph yourself, QA.tech takes care of the knowledge graph, keeps it current, and runs agents against your flows from PR to production.
Frequently Asked Questions (FAQ)
What is a knowledge graph in software testing?
It’s a structured memory of your product that stores entities (pages, features, actions, tests, documents) and the relationships between them.
How is a knowledge graph different from RAG?
RAG (retrieval-augmented generation) retrieves relevant text chunks and hands them to a model. A knowledge graph preserves structure: which action belongs to which page, which test covers which flow, and which past failures sit near a change. QA.tech uses the graph as structured context.
Do I need a knowledge graph to do agentic testing?
No. For small or stable products, scripts or simple file-based memory can be enough. One benchmark found file-based memory outperforming a graph configuration. Graphs pay off on large, fast-changing products with many interconnected flows.
Where does QA.tech fit in?
QA.tech is an agentic QA platform that builds and maintains the knowledge graph for you, then uses it to scope and run intent-based tests across your development loop, from PR checks to production runs, without touching your code or relying on brittle selectors.