Early in October, I was in Budapest for HUSTEF. In three days, I taught a tutorial with Lalit Bhamare, ran a masterclass on memory, gave a talk about completion theater, and received the audience-voted Best Presentation Award. The last evening, I attended an Agentics Foundation meetup. It was a concentrated few days of the things I enjoy about this work: building something, trying to explain it, and finding people who help me understand it better.
Later in the month, my father’s illness meant I had to cancel my trip to Sofia. My parents need care at home, and the situation has been exhausting. I have had to slow down “a little,” while obligations have kept accumulating. The walking routine that usually gives me some space has been harder to keep.
These are not two separate versions of October. The work continued, and some of it moved forward in important ways. But I did it with less time and energy. The positive experience in Budapest came at the right moment; it helped keep the difficulties that followed from blocking me completely.
Budapest and the Questions That Came Home
I have already written a fuller account of HUSTEF, so I won’t repeat the whole conference here. What stayed connected to the work afterward was the relationship between the three things I was teaching.
The tutorial with Lalit focused on reclaiming time for the intellectual side of testing: investigation, risk, judgment, and deciding what is worth examining. The memory masterclass asked how agents could carry useful experience forward. The completion-theater talk examined what happens when they report success without establishing the result. These subjects belong together.
If we automate the activity but lose the judgment, then retain its output as experience, the next session can inherit the same mistake with more confidence.
Other people’s work helped me explain that more clearly. Kris Nordstrom’s examples gave me better ways to describe things I had been building. Lisi Hocke connected security to everyday engineering practice. Lalit and I approached the tutorial from our respective work in testing and agentic QE. That is one reason I value being in these rooms: I can bring a working system and still leave with a better explanation of what it is for.
The audience vote meant a lot. So did hearing what people wanted to try when they returned to work, in settings with different constraints from mine. The Budapest Agentics Foundation meetup extended it beyond the conference, into production work and what changes for humans when agents become part of the team.
In the September article, I left one question deliberately open: was the experience we were retaining actually improving later decisions? October did not produce a single, satisfying yes. It gave me a clearer way to ask the question, and several concrete places where the answer needed work.
When the Tests Share the Mistake
One case in my Budapest material captures the problem better than a definition. Unit tests and end-to-end tests both passed, but their fixtures repeated the same wrong assumption about an API. The two layers looked like separate confirmations. They were drawing confidence from the same misunderstanding.
Correcting the fixture exposed the defect. That established something important about the test and the implementation, but it didn’t confirm that the production fix had been verified. There is still a difference between revealing a problem and following its repair through to the running result.
This matters more as agents become better at generating tests. A test can be executable, detailed, and closely aligned with the code while offering very little resistance to the code’s underlying mistake. If the implementation and the expected result come from the same assumption, adding more cases may simply repeat it more thoroughly.
Addy Osmani’s October essay on agentic verification is useful here. It brings attention back to user journeys, properties that should remain true, comparisons between implementations, and feedback stable enough to guide a repair. The warning about unstable feedback is particularly relevant: a system can learn to keep retrying until it gets a favorable result instead of learning to remove the defect.
For a quality engineer, the practical question is where the expected behavior comes from. A user journey can expose a gap the component tests share. A property can challenge a whole family of examples. A comparison can reveal disagreements worth investigating. None of these removes the need for judgment; they give that judgment something more independent to work with.
The Agentic QE test generator took a small, useful step in this direction in October. Supplied behavior examples can now become executable equality assertions, rather than calls with placeholder arguments followed by a check that something was defined. When neither behavior examples nor an LLM is available, the deterministic generator produces explicitly skipped scaffolding with no assertions. Generated coverage stays unmeasured. The supported syntax is limited, and a supplied example can be wrong, but a user can now see what behavior was actually specified instead of mistaking a scaffold for a test.
Memory Needs a Reason to Be Trusted
The memory discussion at HUSTEF included two different uses. The fleet needs operational memory for the work it performs. My personal metamemory needs to carry context across projects. In both cases, retrieval is only the beginning. An old solution may be relevant enough to find and still be wrong for the current task. Without an applicability check, memory can make it easier to repeat an old mistake.
The RuVector and SONA integration is part of the work on that connection: matching patterns to new tasks, recording outcomes, and retaining experience across sessions. The vector-storage and domain-expansion work in Nagual-QE extends the context that can be connected. These capabilities extend what the system can retain and connect. We still need to evaluate whether using that experience improves the next decision.
Before we could answer that, though, the fleet had to answer a simpler question: would the knowledge still be there after the process restarted?
Chris brought a reproducible durability report. A foreground write could be acknowledged as persisted, then disappear because an unrelated background consolidation operation rolled back or the connection closed. His reproduction checked what remained after independently reopening the database. That was a more consequential question than whether the original write call had returned successfully.
The repair changed how the background “dream” work interacts with live knowledge. It now computes its proposed changes in memory, then commits them in a short transaction. Foreground changes take precedence, and canceling a dream commits none of its output. The tests include independent-process reopen and abrupt process termination. There are still limits to conflict detection, including a write that restores exactly the value originally loaded, but the durability contract is much clearer.
For someone using the fleet, this is ordinary reliability with an unusually important consequence. You should not have to re-teach a system something it already told you it had saved. Nor should a background attempt to improve its knowledge put your current work at risk. Chris’s reproduction gave us a way to examine that promise from outside the session making it.
The measurement side needed similar honesty. October changes removed fabricated fallback outcomes and random padding from learning comparisons. Only recorded strategy metrics count; too little evidence produces an inconclusive result. A held-out result can now reduce confidence rather than being absorbed into a flattering average. That makes it possible to distinguish an interesting proposed strategy from one whose improvement has actually been observed.
Rudy contributed several repairs to the same foundation. He replaced fabricated optimizer input with recorded experiences, including failures, and kept fallback vectors from being mistaken for genuine model embeddings. He also fixed a shared-knowledge path that looked in the wrong place for its own records. These are practical details with direct consequences for users: experience has to reach the next task, and the system has to represent what that experience contains honestly. His contributions deserve particular thanks.
A fresh report from Jordi illustrates the remaining boundary. In his predominantly Python repository, the fleet had accumulated many learning outcomes without measured runs through the relevant pathway. The report remained open on October 25. In that environment, the accumulated records still lack the execution evidence needed to judge effectiveness.
This is why other people’s use of the project matters so much. Chris tested a durability promise beyond the successful response. Rudy repaired paths that determine whether recorded experience can be retrieved and used honestly. Jordi followed the outcome count back to execution in his own environment. They bring questions, fixes, and conditions my own sessions don’t provide, and the project improves because they take the time to investigate and contribute. Big thanks to all contributors.
Asking the Reviewer to Make a Prediction
At Cognitum, the October work pushed the same question further into the quality process itself. If the QE system reviews a change, what would allow us to evaluate its advice afterward?
One part of the answer is to record the prediction before we know the outcome. Otherwise, it is remarkably easy to explain why a finding was important after a related problem appears, or why an approval was reasonable after nothing obvious happens.
A pre-registered prediction gives us a claim that cannot quietly adapt to the result it is supposed to explain.
The change-outcome work then connects that claim to what was actually observed. A suspected follow-up fix is weaker evidence than an independently established incident. A change that nobody observed is not a successful change for evaluation purposes. A configured check does not establish that the relevant journey ran against the revision we care about. Keeping these distinctions intact gives a maintainer a more useful basis for deciding how much weight to give the next recommendation.
The reviewer also needs tests of its own. Can it distinguish an introduced regression from an older problem? Does it raise alarms on a control where the change did not create the defect? What happens when part of the examination cannot run? Replay-based evaluation exposed weaknesses, and the response included better change awareness and an explicit inconclusive result. An incomplete review should tell the human reviewer what it could not establish.
There was also a practical correction to adversarial review. More rounds are not automatically more useful. Repeated findings and arguments about pre-existing issues can consume the attention the system was meant to protect. The work now includes bounded rounds, duplicate handling, and a record of how findings were resolved. An ignored finding does not become a false positive just because somebody merged the change.
This is progress in the way we can examine the QE system. It is not yet a broad demonstration that the system reliably improves decisions or can authorize its own evolution. The distinction matters because the next useful step is to collect evidence under a protocol that can contradict the claim, not to give the architecture a more ambitious name.
There is a connection here to Lalit’s October writing on testability: the conditions for useful testing begin in the requirements, context, and instructions, not only in the test runner. An agent working around missing visibility may finish a task while leaving the important question unanswered. For the person relying on its work, making that gap visible can be more valuable than another confident completion message.
When the Response Window Shrinks
“Black October” has become an informal label for this month’s concentration of security disclosures. On October 21, PHP issued urgent fixes for critical vulnerabilities. AWS reported exploitation attempts in its MadPot sensors dating to October 17, four days before public disclosure.
Defenders cannot assume a grace period after an advisory appears.
At Cognitum, this is where the QE system has practical value. Last week, we used a coordinated sweep of our source inventory and locked dependency versions to turn new advisories into scoped investigations. A coordinator assigned bounded work to parallel agents, carrying ownership and evidence into each task. That lets us investigate affected dependencies without asking every session to rediscover the same context, or treating every alert as proof that a deployed service is vulnerable.
The pieces connect through a shared workflow. Ruflo provides the orchestration, while Agentic QE’s specialist agents and skills give the work its testing focus. RuVector supports carrying relevant knowledge across tasks. Around that open-source foundation, we have built a dedicated QE runner, a harness for checks and independent review, and on-call handling for findings that need attention. Additional purpose-built skills carry the context and constraints of particular jobs. My work has been to make those handoffs useful: the next agent should receive the affected scope, the open question, and the evidence already collected, rather than restarting the investigation.
The repairs still had to survive independent review and regression checks, including tests inside the actual built image. In one scoped handoff, two source fixes reached merge the same day. Deployment and verification of the running version remained separate steps, with human authorization at the release boundary. A successful CI run helps us move forward, but the evidence also needs to reach the artifact and version we intend to run.
For me, this is a concrete reason to build the system. The response depends less on someone manually connecting an advisory, a dependency, an owner, and a set of checks. Agents can investigate and prepare bounded repairs in parallel, while people retain responsibility for priorities and release decisions. When several disclosures arrive together, that organization matters: it gives us actionable work with evidence attached, rather than another growing queue of alerts.
The Life Around the Work
My father’s illness brought me back to the realities of aging parents who need care. Canceling Sofia was one consequence. Exhaustion and disrupted routines have been others. I miss walking. I miss having that part of the day available without taking it from something else. Slowing down hasn’t made the obligations disappear; they keep piling up.
A few days ago, my younger daughter turned eighteen. She is now officially an adult, with her life ahead of her. Having that milestone arrive while my parents need more care has brought finitude, the movement of generations, and growing up very close together. I am watching my daughter enter adulthood while realizing that being the adult for my parents asks something different of me now.
I don’t have a neat resolution for that. There is meaningful work happening, people contributing to it, and much that I still want to build and share. There is also a limit to what I can give it at the moment. A useful account of this month has to make room for both.
That is where Budapest belongs in my story. The teaching, the conversations, and the award were genuinely positive at a time when I needed them. They didn’t erase what came afterward. They helped me keep going.
Then, on Sunday, there was another reason to look ahead. The Student List’s victory in Serbia’s parliamentary election renewed my hope after a difficult month. With my younger daughter just turning eighteen, the question of what we leave to the next generation feels very close. Seeing students help shape the country’s future gives that question a more hopeful direction. There is still a great deal of work ahead, but I want to make room for this feeling too.
What I carry forward from October is more than the work that shipped. It is the questions that became clearer, the people who helped me see something I had missed, and the encouragement I brought home from Budapest. It is also a sharper awareness of time: my daughter beginning adult life, my parents needing more care, and me learning to make room for both. Sunday added something I needed: renewed hope for the country my children will carry forward. I am still finding my pace, but I am glad to end this month with that hope.
Keep learning. Keep sharing. Knowledge is power.
This is the thirty-sixth article in The Quality Forge series. Previous: “When the Pipeline Became the Bottleneck” covered simplifying an overengineered delivery pipeline and left open whether retained experience improves later decisions. This one covers October: HUSTEF in Budapest (full account), tests that share a mistake, behavior-example assertions in the Agentic QE test generator, memory durability and measured-only learning comparisons, pre-registered predictions for the Cognitum QE reviewer, and a coordinated dependency sweep during “Black October.” Cognitum is at cognitum.one.
Dragan Spiridonov is the Head of Agentic Quality Engineering @ Cognitum One, Founder of Quantum Quality Engineering, Secretary of the Agentics Foundation BoD, Chair of the Agentics Foundation Training Committee, and one of the AI Chapter leads for the Ministry of Testing. He is currently building the Serbian Agentic Foundation Chapter in partnership with StartIt centers across Serbia.