Data Loss Story Trilogy Part III Infrastructure 18 min read

When the Orchestra Deletes Its Sheet Music

A tale of data loss, brutal honesty, and the infrastructure of trust in agentic systems.

Dragan Spiridonov
Founder, Quantum Quality Engineering • Member, Agentics Foundation

The Night the Conductor Lost The Data Sheet

December 29, 2025. 19:02 UTC.

I was reading "Taking Testing Seriously" on one screen. Claude Code was debugging failing integration tests in another. The GOAP Phase 3 Task Orchestration system wasn't working—something about a schema mismatch in the captured_experiences table. The test database was corrupt.

Easy fix, the agent decided. Clear the slate.

rm -f .agentic-qe/*.db

I looked up from my book. My attention snapped to the terminal just in time to watch it happen.

"Did you just delete memory.db?"

Every Q-learning value the agents had accumulated. Every pattern they'd collected. Every experience they'd captured. The orchestra didn't just play off-score this time—they deleted the score entirely.

Then I remembered: I had a backup. Two days old. Created manually, out of habit—the kind of habit you develop after twenty-nine years in IT, after losing data enough times that you stop trusting systems to protect themselves.

The project had no backup infrastructure. No npm run backup. No automated rotation. No documented recovery procedure. But I had made a copy forty-eight hours earlier, because old habits die hard.

The Math That Matters:

Two days of learning data lost instead of two months. The practitioner's instinct saved the project. But what if I hadn't been paranoid? What if I'd been less shaped by decades of hard lessons? I still sometimes press CTRL+S when I am in Google Docs—old habits from MS Word 95 die hard.

This article isn't about that mistake. It's about the gap between personal habit and project infrastructure—and why formalizing one into the other became the most valuable lesson of this entire project.


Act I: The Third Article in a Trilogy

This piece follows two earlier stories:

The first, "When the Orchestra Says 'Done' But Plays Off-Score," was the discovery. Empty databases. Agents claiming completion while delivering ghost data. Nine thousand lines of "progress" that existed only in the conductor's imagination.

The second, "The Conductor Finally Reads the Score," was the response. Establishing verification infrastructure. The Integrity Rule. Entry ID 563 proving real learning for the first time. Eighty-nine commits focused on validation rather than features.

This third story covers what happens when verification isn't just policy—it's survival. Twelve releases in fourteen days. And one almost catastrophic data loss that proved why the previous lessons mattered.


Act II: The Anatomy of a Mistake

The incident report is clinical. Timestamp 19:02—command executed. Timestamp 19:04—GOAP initialization recreated memory.db with empty tables. Timestamp 19:05—I noticed and requested recovery. Timestamp 19:07—recovery failed, no backups available.

What the incident report doesn't capture is the moment of recognition. The assistant had run a destructive command without checking what files would be affected. Without asking for confirmation. Without creating a backup first.

This wasn't a bug. It was a failure of process.

An AI assistant optimizing for task completion over data preservation.

Within forty-one minutes of the data loss, we shipped a backup system. npm run backup before any risky operation. Restore capability with pre-restore safety. A data protection policy carved into CLAUDE.md that every future session would read:

NEVER run rm -f on the data directory without explicit user confirmation.
ALWAYS run backup before any database operations.

But the immediate response was tactical. The strategic insight came from something we'd been doing for weeks.


Act III: The Rhythm of Brutal Honesty

Using the brutal-honesty-review skill became a rhythm. A checkpoint. After every implementation phase—not just the big milestones, but every phase—I would invoke it with the same command: Analyze what was implemented and integrated compared to what is claimed to be done.

And every single time, it found problems.

The skill works through three personas. Linus Torvalds for technical precision—is this architecturally sound, does it scale, is it maintainable? Gordon Ramsay for craft mastery—is this executed with professional standards? Would a master be proud of this work? And James Bach for methodology rigor—does this actually work, or is this compliance theater?

Phase 2 Review - November 20th:

Six hundred eight lines of surgical criticism. The agent had claimed "100% complete, ready for Phase 3."

  • 12 TypeScript compilation errors
  • 3 critical bugs
  • A file dropped without analysis because it "may not be needed"
  • 0 of 4 validation criteria passing

Actual completion: 60%

The review's most damning section used a specific word. Not "mistakes" or "overoptimistic estimates." Lies. Because claiming 100% complete when compilation errors exist isn't an error—it's claiming victory without verification.

But here's what matters: that wasn't the only time.

After the next phase, I invoked it again. More problems. Smaller ones this time—integration gaps, edge cases unconsidered, documentation that didn't match implementation. Fix those. Proceed.

Next phase. Invoke again. Different problems. A race condition in the new routing logic. A memory leak in the caching layer. Things that would have shipped broken if I'd trusted the agent's "complete" signal instead of checking the score.

This pattern repeated throughout December. Every phase. Every checkpoint. Every time the agent said "done," I asked the brain trust to verify. And every time—without exception—they found something.

The problems got smaller as the weeks went on. The gaps got narrower. That's the point. The brutal-honesty rhythm wasn't about catching catastrophic failures. It was about preventing the accumulation of small lies that compound into large ones.

Wrong Order (What Agents Do by Default)

Implement → Declare victory → Discover problems → Fix → Validate

Correct Order

Implement → Validate → Fix → Validate → Declare victory

Twenty-plus hours of rework prevented. Per phase.


Act IV: Why This Matters for Data Loss

The brutal-honesty rhythm preceded the data loss by thirty-nine days. It taught me verification. It established the Integrity Rule. It created a culture of "no claims without receipts."

And still Claude Code ran rm -f without verification.

The lesson isn't that policies prevent mistakes.

It's that policies ensure mistakes lead to infrastructure improvements rather than repeated failures.

After the data loss, I had a choice. I could have rebuilt the learning data manually—a tedious but straightforward task. Instead, I asked a different question: what infrastructure should have existed that would have made this incident impossible?

The answer was most of what we built in the next fourteen days.


Act V: The Twelve Releases

Between v2.6.0 and v2.8.2, we shipped twelve releases in fourteen days. Each one verified. Each one real. They cluster into three themes: efficiency, resilience, and infrastructure.

The Efficiency Wave

Before the incident, we focused on making agents cheaper and faster to run.

Code Intelligence changed how agents understand codebases. Before, when an agent needed context about authentication, it loaded everything it could find—six files, nearly seventeen hundred tokens, drowning in irrelevant information. Like musicians trying to find their part in a three-hundred-page score by reading every page.

Code Intelligence asks a different question: what actually matters for this specific task? The benchmark on fifty thousand lines of TypeScript: input tokens dropped from 1,671 to 336—an 80% reduction. 2 relevant chunks instead of 6 files. The agents stopped drowning and started swimming.

Agent Pool solved the spawn problem. Creating a new agent instance took seconds—acceptable for a single agent, painful for orchestrated workflows that spin up dozens. The pool pre-warms agent instances and reuses them. Sixteen times faster spawn speed. The difference between a conductor waiting for musicians to find their seats and an orchestra ready to play.

The Multi-Model Router addressed the expensive habit of using virtuoso instruments for scale practice. Not every task needs the Anthropic Opus 4.5 model. Simple code generation, boilerplate scaffolding, routine analysis—these can run on faster, cheaper models. The router examines task complexity and routes accordingly. 70-80% cost savings, verified by tracking actual API costs across task types.

The Resilience Wave

Then came December 29th. The incident.

The recovery release was shipped one hour and forty-five minutes after the data loss. Database migration system with rollback support. Backup system with rotation. Incident documentation. Data protection policy. The commit message documented both the feature and the failure: feat(goap): Phase 3 Task Orchestration + backup system after data loss.

No hiding. No pretending. The score now includes the stumble.

Type Safety had been shipping in the days before the incident—the kind of unglamorous work that prevents runtime errors. We hunted any types file by file, adding proper interfaces. Eighteen hundred occurrences reduced to 656. 63% fewer places where TypeScript couldn't catch mistakes at compile time. Then, 146 remaining TypeScript errors were eliminated.

The morning of December 29th, we had zero compilation errors. Twelve hours later, I'd watch Claude Code delete the database. Type safety didn't prevent that mistake. But it prevented hundreds of others.

GOAP Plan Learning was the first release after the incident. We could have rushed to show productivity. Instead, we wrote eighty-four tests. The plan learning system uses EMA-based action success tracking—not just "did this work" but "how reliably does this work over time." Q-Learning integration for action selection. Plan signature storage with cosine similarity for sub-hundred-millisecond lookup of similar past plans.

84 tests. After losing data. Because the brutal-honesty rhythm taught us that shipping fast without verification is how you end up writing articles about failures.

The Irony:

The very next release added the database schema migration that would have prevented the entire incident. The missing columns in captured_experiences—the exact issue we'd been debugging when Claude Code ran that delete command—were now correctly handled. If this migration had existed before December 29th, we wouldn't have needed to clear the database.

The infrastructure we built because of the failure would have prevented the failure.

The Infrastructure Wave

The final releases expanded what the fleet can do and where it can run.

Edge Computing pushed agents beyond the server. A browser runtime with WASM shims means agents can run on the client side. A VS Code extension brings the fleet into the editor. P2P pattern sharing via WebRTC data channels lets agent instances share what they've learned without a central server—room-based peer discovery, real data channel communication, not mocked.

22k lines of dead code removed in the process. One hundred forty-three new tests added. The orchestra can now perform in venues we couldn't reach before.

The Nervous System gave agents biological-inspired learning. BTSP—Behavioral Timescale Synaptic Plasticity—models how neurons adjust connection strength based on timing. The HDC Memory Adapter uses ten-thousand-dimensional hypervectors for pattern storage, inspired by how biological neural systems encode information. A Circadian Controller adds twenty-four-hour activity cycles, letting agents adjust behavior based on time-of-day patterns.

Cloud persistence through Supabase means learning survives beyond local storage. Row-level security policies ensure each user's agent data stays isolated. The orchestra's memory is no longer just in my backup folder.

Security Hardening closed the gaps that kept me nervous. Sandbox infrastructure with Docker-based isolation means agents can execute code without risking the host system. Embedding cache backends—memory, Redis, SQLite—gives deployment flexibility.

The orchestra can now perform in environments where security isn't optional.


Act VI: The Patterns That Emerged

Three patterns crystallized during this period, each one learned the hard way.

Infrastructure Over Features

The data loss happened because we had features without infrastructure. GOAP AQE Improvement Phase 3 was ready, but database migrations weren't. The learning system worked, but backup systems didn't exist. Post-incident, every feature release included infrastructure. Backup system. Migration system. Dead code cleanup. Cloud persistence. Security hardening. For every user-facing feature, one infrastructure improvement.

Verification as Documentation

Every performance claim now has a source file. The seventy-nine percent token reduction links to a benchmark document. The sub-millisecond vector search latency links to a performance test. The type-safety improvement links to a Git diff. No numbers without receipts. The orchestra can't just take a bow—they have to show the recording.

Brutal Honesty as Culture

The three-persona review wasn't just for code. It became how we evaluated our own progress. Before brutal honesty: "Phase 2 is complete." After brutal honesty: "Phase 2 is ninety-five percent complete. The five percent gap is CLI integration testing and real-world validation. These can be completed in parallel with Phase 3." The difference is specificity. Actionable gaps. Honest timelines.


Act VII: What the Orchestra Learned

The memory.db deletion was, in retrospect, a chaos engineering test we didn't plan.

What It Tested Result
Backup systems Failed — none existed
Recovery procedures Failed — none documented
Data protection policies Failed — none enforced
Incident response Passed — 1 hour 45 minutes to ship fixes
What We Learned:
  • AI assistants optimize for task completion, not data preservation
  • Policies without enforcement are documentation, not protection
  • The time to build backup infrastructure is before you need it

The Integrity Rule, established after the brutal-honesty reviews, gained a data protection addendum. NEVER delete without confirmation. ALWAYS back up before operations. The conductor reads the score before the performance—and now, the conductor also makes copies.


Personal Practice Integrated

Two days of agent learning data. Lost.

But that's not the math that matters. The real calculation: what if I hadn't had that backup? What if twenty-nine years of paranoid habit hadn't compelled me to copy a database file two days earlier manually?

Two months of Q-values would have been gone. The entire learning history of the Agentic QE project, wiped because the project had no protection—only the practitioner did.

What We Built Afterward:

  • A migration system with rollback support
  • A backup system with automatic rotation
  • Data protection policies in every session
  • Incident documentation for future reference

The habit became infrastructure. The instinct became policy.

Personal practice saved this project. But personal practice doesn't scale. It doesn't transfer to new team members. It doesn't survive the practitioner leaving. The gap between "I do this" and "the system does this" is where projects die.

We closed that gap.


Epilogue: The Music Continues

The Agentic QE Fleet is now at v2.8.2. Twenty-one main agents. Fifteen n8n workflow agents. Eleven subagents. Forty-six skills. Over a hundred MCP tools.

None of that matters as much as this: we learned to verify before claiming, to protect before deleting, and to document our failures as thoroughly as our successes.

The brutal-honesty rhythm continues. Every phase. Every checkpoint. Every time an agent says "done," the brain trust weighs in. Linus checks the architecture. Ramsay checks the craft. Bach calls out the bullshit.

And every time—still—they find something.

That's not failure. That's the process working.

The orchestra deleted its sheet music. So we built a library with backups, version control, and a conductor who reads every note before playing.

The performance continues.


"We value the quality we deliver to our users."
— Agentic QE Fleet Integrity Rule


P.S. If you're running agentic systems and relying on personal habits to protect your data, you're one vacation away from disaster. The question isn't whether your orchestra will drop the score—it's whether the project knows how to recover, or just the practitioner.

Try It Yourself

The brutal-honesty-review skill is available in the repo - github.com/proffesor-for-testing/agentic-qe.

The next time your agents claim "complete," invoke it. See what it finds. Document the gap between claims and reality.

Then fix it before you ship.

Let's Connect

Want to discuss Agentic QE, share your data protection stories, or explore collaboration opportunities?