Atomic tests web applications with a team of narrow AI agents and a lot of plain code keeping them on track. This is how it’s put together and why it ended up this way.
Where Atomic started
Before any of Atomic was written, Edgescan’s team spent time examining agentic architectures and their reliability in the cybersecurity space. This included open-source AI pentesting tools already on the market. The team ran them against Edgescan’s own testbeds, the same apps over and over, and watched what they did.
The problems showed up quickly. The agents lost context fast. Instructions given at the start of a run were forgotten partway through. Scope wasn’t reliably held, so an agent would drift onto things it had no business touching. Agents in the same run repeated each other’s work. The results changed every time: one scan would catch a vulnerability, and the next scan against the exact same app would miss it and report something else. They also burned through far more tokens than the work needed.
The team also tried plain frontier models with their stock harnesses. A standard, general-purpose AI coding agent, with no security tooling wrapped around it, was pointed at the same targets and did better than the purpose-built tools.
The extra layers in those tools weren’t helping. In places, they were getting in the way.
So Edgescan built its own, starting with recon.
Fig. 1 One long session compared with the Atomic Harness running focused specialists.
The problem with one long session
Most of what the team saw comes back to one design choice. A lot of agent tools run as one long conversation, or one big agent, that keeps going until the job is done. Everything it reads, every tool output and every dead end piles into the same context.
There’s a good amount of research on what happens next, and very little of it is specific to security. Models are worse at using information buried in the middle of a long context than information at the start or end (Liu et al., 2023). Chroma tested 18 models and found performance “grows increasingly unreliable as input length grows”, even on simple tasks (Context Rot, 2025). Researchers at Microsoft and Salesforce measured an average 39% drop when a task is spread across a multi-turn conversation, and found that once a model takes a wrong turn, it tends not to recover (Laban et al., 2025). A 2023 study of LLM-driven penetration testing named loss of session context as the main reason runs failed (Deng et al., 2023).
That matched Edgescan’s own testing. In long sessions, candidates didn’t all get tested. Some got tested halfway. Things found early didn’t reach the part of the job that needed them later. A better prompt doesn’t fix this, because the prompt is one of the things being forgotten.
In fairness, models are getting better at long context all the time, and simple “find the planted fact” tests are close to solved. Testing a whole application means hundreds of small judgments across a lot of noisy data, and that’s where the research still shows things slipping.
Recon first, and where to draw the line
Atomic started as recon only. Recon is the most important part of any test, and if it’s weak, everything after it is weak. The goal was to gather as much as possible about the target and store it in a way later agents could use.
That’s where the layout came together, and it’s shaped by one question the team keeps coming back to: what should the agent do, and what should the harness do? The harness is the ordinary code around the agents. It runs the tools, stores the results, enforces the rules, and decides who gets what. Whenever behavior must be reliable, it’s a candidate to move into the harness.
Crawling is a good example. Early on, the agents found the application’s pages themselves. That sounds reasonable, but agents make poor crawlers. They’re slow, and they miss things, or they aren’t consistent enough with coverage. Now the harness maps the application first with standard tooling, and the agents reason over what it found. The AI still makes the judgement calls, like which directories are worth a deeper look, and the harness does the fetching.
JavaScript review, for example, went the same way. It started as one agent inside recon, told to read every script it could find. It did, slowly, and with no sense of which files mattered. Now it’s a phase of its own after recon: a lead agent picks the scripts and pages worth reading, the harness fetches each one once, and two small teams split them up. Nothing gets read twice. The line moves the other way too. A filename filter was taken out of the code and that call was handed back to the lead, because telling the app’s own code from a third-party library is judgement, and judgement is the AI’s job.
Owning the harness also gives Atomic full visibility. Every agent’s reasoning and every tool call is tracked; the system and user prompts are under Atomic’s control. It started as a way to see what was going on, and it became the thing that lets Atomic hand each agent only the information and context it needs.
A team of specialists, coordinated by code
Giving each agent a small, clean context is where the wider field has landed. Anthropic’s engineering team describes sub-agents handling focused tasks “with clean context windows” (Effective context engineering, 2025). An entire application can’t be tested inside one small context, though. There are too many pages, endpoints, login flows and vulnerability classes. A small context per agent means specialists, and specialists mean more agents. More agents were never the goal. The size of the job decided how many were needed.
However, this needs care, because “add more agents” has a poor track record on its own. A Berkeley study of more than 1,600 multi-agent runs catalogued 14 ways these systems fail, most of them down to agents misunderstanding each other or nobody checking the work (Cemri et al., 2025). Cognition, which argued against multi-agent designs in 2025, has since written that it works when changes stay on one controlled path and the extra agents “contribute intelligence rather than actions” (Cognition, 2026).
That’s close to how Atomic works. Agents don’t talk to each other. The harness hands out the work. A shared store holds everything they find, each piece linked back to its evidence, and anything that touches the target goes through the harness. Adding a new capability usually means adding a new team with its own narrow job, which is far easier than teaching one big agent a new trick.
Atomic also matches the model to the role. Planning and lead roles get a stronger model, and the routine work gets a smaller, faster one. In Edgescan’s testing, putting a bigger model on the routine work didn’t find anything the smaller one missed. It overstepped, attempting to go further than its job allowed. The harness stopped it, which proved the control works, but the tokens were spent either way. A better model doesn’t automatically mean better testing. Outside security, this is well established too: routing work between strong and cheap models can cut cost substantially without losing quality (RouteLLM, 2024).
One more rule sits under all of this. Whether a finding exists is decided in code. How serious it is and what it means is left to the AI. Agents can miss things when there’s a lot of evidence to get through, so a finding never depends on an agent happening to notice it.
From candidate to confirmed finding
A scan runs in phases. Recon maps the application. Specialist teams, like JavaScript analysis, dig into what recon found. Verification teams then double- check and independently test it, and a final step writes the report.
Anything that looks suspicious along the way becomes a candidate, with its evidence attached. A candidate isn’t a finding yet. It’s a lead that something might be wrong, and it gets handed to a verification team whose only job is to test that kind of issue. Only a candidate that passes verification becomes a confirmed finding. Anything that can’t be confirmed stays in the report marked as unverified, so it isn’t quietly dropped and it isn’t dressed up as more than it is.
This is where a lot of AI tools fall down. An agent’s own summary of its work is easy to believe and often wrong, so when a lead needs testing, the agent that raised it isn’t the one that signs it off. The result is a report that separates what was proven from what’s worth a closer look. The detail of how candidates and verification work is a post of its own, and the team will cover it.
Fig. 2. The Harness runs every step and enforces scope.
Safety is part of the architecture
This deserves its own post that will come at a later date, but the short version belongs here because it’s the same design at work.
Scope is enforced in code. Every tool call is checked against the agreed target before it runs, and anything outside it is refused, so the AI never has to remember where the boundary is. When Atomic moves from finding to testing, the AI selects and the harness sends. The agent picks from a vetted set of test points and payloads. It doesn’t write its own attack strings or pick its own targets. That’s the kind of control OWASP recommends against “excessive agency” (LLM06:2025), and it follows the design patterns researchers have proposed for keeping agents safe when they read untrusted content (Beurer-Kellner et al., 2025). An application under test is untrusted content by definition.
Humans in the loop, the whole way through
Human-in-the-loop usually gets pictured as someone approving every command an agent runs during an engagement.
In many AI testing tools, the agent stops and waits whenever it wants to do something that needs sign-off, and it sits there until that approval. That’s friction. Scans stall waiting on people, and the speed the AI brings gets lost in a queue. Atomic’s harness lets those decisions be made up front instead. What the agents are allowed to do, and how far they’re allowed to go, is set before the scan starts, and the harness enforces it throughout. The control is the same, and nobody has to sit and wait for an approval request.
Fig. 3. Human control before, during and after a scan.
Before a scan starts, a person sets it up: the target, the scope, credentials, the approach and the limits. The agents only work within what they’re given. During the scan, every agent’s reasoning and tool calls stream live, so behavior can be watched and alerted on, and the scan can be paused or stopped at any point. After the scan, every finding links back to the evidence behind it, so an expert can check it.
That’s also where the speed comes from. Given the same tool output a tester would work through, the agents read it and connect it far faster than a person can. Edgescan isn’t claiming the AI is a better tester than an experienced human. Atomic does the legwork at machine speed, and Edgescan’s experts check it. Regulation is heading the same way, with the EU AI Act putting human oversight at the center for higher-risk AI systems (Article 14), and Atomic is built for that from the start.
Built by people who test for a living
Atomic is built by a team including experienced penetration testers. They know how these vulnerabilities are found and how the underlying technology works, so they know what a good test looks like. A lot of security tooling, it could be argued, is built the other way round, by developers working from a partial picture of the problem or a brief from a security expert, and it shows in odd edge cases and awkward architecture. Behind the build team is Edgescan’s wider testing department, people pentesting every day, and that experience is behind every decision in Atomic.
The AI does the thinking. The code makes sure the whole app gets tested, every time. Everything that has to be reliable was moved out of the AI and into code, and every finding can be traced back to the evidence that produced it.
To see how Edgescan runs autonomous testing with a team of specialist AI agents, request a demo.
Want to see Atomic for yourself? Join the Atomic Under the Hood sessions with Michael and see how it works, how we keep autonomous testing safe, what we’ve learned, and how it all stacks up.
