DEV Community: Ruslan Manov

How SmartKey Keeps Two Alphabets Alive Until Context Decides

Ruslan Manov — Mon, 24 Aug 2026 05:55:15 +0000

The input event does not arrive with a language tag.

Press the same two physical keys on a Bulgarian phonetic keyboard and one interpretation is li; the other is ли. Both are plausible prefixes. One can be the beginning of like. The other can already be a complete Bulgarian word.

Most desktop input systems avoid this ambiguity by asking the user to maintain a global mode: English now, Bulgarian later. The engineering is simple. The human cost appears when the mode and the thought diverge. A forgotten toggle turns a sentence into cleanup work.

SmartKey explores a different contract: keep both alphabets alive long enough for evidence to decide.

Its North Star is:

Write the thought, not the keyboard layout.

This article is the technical companion to the project's narrative overview. It focuses on what an input engine designer can learn from the architecture, its current evidence, and the failures that refuse to fit under one convenient label.

1. Start before autocorrect

Autocorrect begins with committed text and asks whether another string was intended. A dual-alphabet input engine has an earlier problem: what characters should the physical keys become in the first place?

SmartKey maintains two candidate readings for the current word. Conceptually, the loop looks like this:

for each eligible physical key:
    extend the English candidate
    extend the Bulgarian candidate
    score both using available local evidence

    if the winner changes before the decision is locked:
        update the visible composing prefix

    if the evidence crosses a lock boundary:
        lock the current winner for further scoring
        keep the word in preedit until the boundary

This is pseudocode, not a copy of the Rust implementation. The useful design idea is delayed commitment. The engine can expose a current best answer in composing preedit without pretending that early evidence is final.

That distinction matters because the shape of evidence changes during a word. At the first character, context may be more informative than corpus frequency. After several characters, a prefix can become distinctive. At a delimiter, the token is no longer merely a prefix; exact-word and phrase evidence become available.

One scoring rule should not be assumed optimal at all three moments.

2. Prefix evidence is not word evidence

The smallest reproducible example is li versus ли.

In the audited corpus snapshot behind this draft, the strongest English completion for li… was represented about 2.57 million times. The strongest Bulgarian completion for ли… was close, at about 2.51 million. A prefix-based contest is therefore nearly balanced and can tip toward English.

But at the exact-word boundary, the evidence is radically different: standalone Bulgarian ли appeared about 2.51 million times, while standalone English li appeared about 18 thousand times.

The numbers are corpus-specific and rounded. Their value is not the apparent precision. Their value is the diagnostic question they expose:

During the token: “Which candidate has the strongest continuation?”
At the delimiter: “Which candidate is the word the user just completed?”

If the engine keeps asking the first question after Space arrives, it is solving the wrong problem correctly.

This suggests a general rule for predictive interfaces: boundaries are semantic events. A delimiter, submit action, focus change, or explicit acceptance can reveal evidence that did not exist one event earlier. Test boundary behavior separately instead of treating it as the last iteration of the same loop.

3. Context is an input contract, not application telepathy

It is tempting to summarize context handling as “the keyboard knows it is in a terminal.” SmartKey does not make that claim.

The engine can use three bounded signals:

surrounding text that the client exposes;
the ContentType the client declares;
an inferred typing regime derived from available input evidence.

In the FastCoding regime, technical vocabulary can influence prediction. It is ranking evidence, not a guarantee that every identifier or command will remain untouched.

Sensitive fields have the same contractual boundary. SmartKey bypasses fields whose clients correctly publish a sensitive ContentType. It cannot promise a universal password shield when a client fails to declare that property.

This is an important architectural habit: name the source of context. “The application tells me X” and “I inferred Y from text” have different failure modes, security properties, and test fixtures.

4. Acceptance is a state transition

A visible completion creates another decision boundary. SmartKey supports deliberate acceptance paths such as Tab and Right Arrow, with Escape available to reject.

Space is attractive because it is already the natural end-of-word gesture. It is also dangerous. An input method may have to replace a partial token, commit a completion, preserve its alphabet, and deliver exactly one delimiter without leaking an intermediate state.

The Space-accept path is therefore still experimental. Its feature flag is off, and a newly discovered Unicode-eligibility issue is a release blocker. It is not a shipped capability in this article.

The design lesson is broader than this feature: never model acceptance as a convenient key binding. Model it as a transaction with eligibility, commit, cancellation, and fallback semantics. If eligibility fails, Space must remain ordinary Space.

5. Local prediction still uses a model

SmartKey keeps corpus scoring, contextual ranking, and personal adaptation on the machine. There is no LLM or remote model in the prediction loop.

That wording is deliberate. “No model” would be false: ranking candidates is a model, even when the implementation is compact and inspectable. “No data” would also be misleading: local corpus and personal adaptation are data.

Feedback needs the same precision. Accepted candidates can reinforce useful behavior. Repeated rejections can suppress a suggestion. If an accepted completion is followed by Backspace within 500 milliseconds, the event is recorded as negative feedback. The system does not need to label the user's emotion; it needs a bounded observation that a test can reproduce.

For input software, local processing is not only a privacy feature. It also makes behavior easier to replay against a fixed corpus and exact revision.

6. Debug the decision without logging the sentence

An input engine can be wrong at every keystroke. Plaintext logs would make diagnosis easy and create an unacceptable record of what the user typed.

SmartKey's compromise is a structural per-keystroke receipt without plaintext. In structural mode, it records the input/script class, consume-or-forward verdict, dual-buffer and lock/hypothesis state, action name, payload or commit length, and—on commits—the typed and committed script classes.

These fields are enough to inspect state transitions and dispatched action kinds without saving plaintext. They do not by themselves reveal candidate text or corpus support.

At the combined revision behind this draft, the recorded verification gate passed 496 core tests, focused suites of 9, 5, and 20 cases, and seven native scenarios. Those tests describe one revision; they are not an accuracy measurement and do not erase the Unicode blocker in the experimental Space path.

7. One symptom, three failure lanes

In one diagnostic session, nine tokens in a roughly 45-word Bulgarian instruction surfaced in the wrong form. That is one diagnostic session, not a benchmark or an accuracy percentage.

Two isolated examples teach different lessons:

no, intended as Bulgarian но, reaches a delimiter while the engine still has a short-word ambiguity.
statiq, intended as статия, can be pulled toward Latin by strong stat… prefix evidence before the Bulgarian word is complete.

Other observations involve loanwords, product names, abbreviations, out-of-vocabulary forms, punctuation, or ordinary typos. A surface string cannot prove which mechanism produced it. That requires the receipt and an exact replay.

The next design work should therefore be split rather than hidden inside a mega-fix.

Lane A — short words at the delimiter

For ambiguous two- and three-character tokens, evaluate exact-word frequency, language prior, and phrase context when the delimiter arrives.

RED tests should include:

Bulgarian short words after Bulgarian context;
genuine English short words after English context;
a language switch immediately before the token;
punctuation and end-of-input as boundaries, not only Space.

Lane B — premature prefix lock and unsupported inheritance

Test when a strong completion prefix can lock the wrong alphabet before the intended word has enough evidence. Separately test the case in which the nominal winner has zero support: it should not inherit a previous choice merely because a state variable already has a value.

The exact fallback policy still needs evidence. The important step is to make “no support” an explicit state rather than silently treating it as confidence.

Lane C — OOV, brands, abbreviations, and typos

Loanwords and brand names cross the boundary between preservation and correction. A typo can make both corpus candidates unsupported. Punctuation can belong inside a technical token rather than terminate it.

These cases need their own fixtures and success criteria. Solving Lane A must not be advertised as solving Lane C.

8. What to take into another input engine

SmartKey's validated integration here is Linux with IBus, Bulgarian and English, in the author's own daily use. It is not a Windows or macOS delivery claim, a multi-user field study, or evidence of perfect language selection.

The reusable engineering principles are more important than the platform boundary:

Preserve competing interpretations until an irreversible decision is justified.
Re-evaluate at semantic boundaries; a complete word is not merely a longer prefix.
Distinguish declared context from inferred context.
Treat completion acceptance as a transaction.
Collect falsifiable structural evidence without storing plaintext.
Split failures by mechanism before designing the fix.

A predictive system earns trust when its behavior is not only fast or often correct, but bounded, reversible, and explainable when wrong.

The SmartKey repository is here: https://github.com/RMANOV/smartkey

Canonical project story: https://www.linkedin.com/pulse/fractured-console-two-alphabets-one-stream-thought-ruslan-manov-m3jvf/

Bring a reproducible boundary case. For this kind of engine, the most valuable input is the word that forces the scoring model to reveal what question it was really asking.

Mathematical Animations in Pure Python — Zero Dependencies, One File

Ruslan Manov — Tue, 14 Jul 2026 12:10:38 +0000

I wanted an ambient display for the second monitor in an open-space
office: something alive enough to rest the eyes on, quiet enough not
to distract, and installable nowhere — because the machine is a locked-
down corporate laptop. No pygame, no numpy, no GPU, no admin rights.

So the constraint became the project: real mathematics, rendered
with nothing but tkinter and math. One file. If you have Python,
you already have everything it needs.

Repo: https://github.com/RMANOV/algorithmic-arts

What's inside

Hopf fibration — the circles of S³, stereographically projected to
3D. Each fiber is a genuine circle on the 3-sphere:
(cos(η/2)·e^(it), sin(η/2)·e^(i(t+ξ))) as two complex coordinates,
projected from the pole. The nested tori emerge on their own — nothing
is drawn as a torus.

Three-body figure-8 — the Chenciner–Montgomery choreography with
real gravity, integrated with velocity Verlet from the classic initial
conditions. The GIF starts cold on purpose: watching the orbit weave
itself out of three moving points is the whole show.

Murmuration wars — three boid flocks in rock–paper–scissors
predation. Each flock hunts one neighbour and flees the other; a
caught bird converts to the hunter's colour in a burst ring, so the
armies grow and collapse in cycles.

Hyperbolic flow — a geodesic web in the Poincaré disk carried by a
live Möbius transformation. Geodesics are circles orthogonal to the
boundary: for boundary points u, v the center is (u+v)/(1+Re(u·v̄)) —
one line of algebra, an Escher engraving in motion.

Plus a morphing Clifford attractor, a swarm of 36 double pendulums
diverging from 10⁻⁵-radian differences, a rotating Klein bottle, and
torus knots smoothstep-morphing into one another.

The interesting engineering problem

The tkinter canvas is slow, and that was the fun part. Naively
updating ~1500 line items at 30 fps chokes on itemconfig calls —
coordinates are cheap, but style changes are not. Three tricks fixed
it:

Pre-allocated item pool — line items are created once and reused; nothing is ever created or destroyed per frame.
Style caching — each pool slot remembers its (color, width); itemconfig fires only on actual change.
Quantized HSV — hues snap to 1/48 steps, brightness to 1/20. Visually identical, but colors stabilize between frames, so most updates become coordinate-only. Frame cost dropped ~3×.

There is also a headless --selftest that runs every scene for 60
frames without a display and checks line budgets — so the physics can
be verified in CI or over SSH.

Why bother with stdlib-only?

Because constraints are the art. Every dependency you drop is a
machine the code can still run on: the locked-down office laptop, the
server with bare Python, the machine of someone who will never run
pip install. And because it forces the mathematics to carry the
show — there are no shaders to hide behind.

MIT licensed. If there's a scene you'd like added — the attractor and
polytope families are deep — tell me in the comments.

AI memory is not enough. Your agents need reviewable coordination.

Ruslan Manov — Tue, 02 Jun 2026 12:08:26 +0000

For the past year, the agent-tooling conversation has been dominated by memory: vector stores, knowledge graphs, session persistence. Useful — I build and maintain an open-source memory server myself. But after months of running multiple AI agents against real work every day, I am convinced the expensive failures were never memory failures. They were coordination failures: an agent acting on an unverified claim, two agents mutating the same state, a "small" change that was not small.

The fix that worked for me did not come from machine learning. It came from how courts and audits work: separation of roles, adversarial review, verdicts on the record.

The frame

In my current workflow, my agents operate under a protocol with four roles:

Role	Mandate
Conductor	Orients, assigns scoped tasks, issues decisions. In this protocol, it does not implement production code.
Devil's advocate	Tries to refute. Every high-risk claim or spec gets a verdict — PASS, AMEND, or BLOCK — steelman first, then critique.
Executors	Do the scoped work — research, analysis, implementation — and report evidence, not summaries.
Human operator	Approves anything irreversible. No mutation without an explicit go.

Nothing relies on goodwill or prompt-engineering finesse. Every message is a row in a SQLite database, addressed [FROM → TO], claimed before work starts, and answerable later. The transcript is the audit trail.

A typical assignment looks like this on the wire (content redacted, shape real):

[H][STATUS][CONDUCTOR -> EXECUTOR_2]  scoped task + constraints (read-only; propose, don't mutate)
[M][STATUS][EXECUTOR_2]               CLAIM — references the assignment, declares scope, starts work
[M][A][EXECUTOR_2 -> CONDUCTOR]       report: summary / evidence / limits / next
[H][A][ADVOCATE -> CONDUCTOR]         verdict: PASS-AMEND + numbered amendments
[H][DECISION][CONDUCTOR]              approves items, citing the verdict; defers the rest to the human
[M][STATUS][EXECUTOR_2]               executed: counts + verification query results

Three anonymized cases from recent weeks show why this pays.

Case 1: The confident wrong fact

An executor compiled a preparation document ahead of an important professional meeting. One background fact about the organization involved was plausible, widely repeated in secondary sources — and wrong. The advocate's standing rule is that web signals are hypotheses, not facts; its refutation pass demanded a primary source, found a conflicting primary source, and returned AMEND. The fact was corrected in the same review cycle, before the document was used. The cost of being confidently wrong in that room is hard to quantify; the cost of the review was one extra pass.

Case 2: The "15-minute config fix"

A corrective plan for an internal business application contained what looked like the smallest item on the list: change one default value in a config file. Estimated effort: fifteen minutes. The advocate's verdict reframed it: the default in question controlled default access-control behavior — a security policy decision, not a tweak — and the existing test suite explicitly asserted the old behavior. Verdict: BLOCK until scoped as a policy change with its own spec and tests updated in the same commit. The fifteen-minute fix was real work pretending to be trivial. The review gate caught the pretense.

Case 3: A day on the record

One recent working day, four role sessions — running on two different model families (Claude and Codex) — coordinated through the same database: addressed task queues, claim-before-work so no two agents grab the same item, watermark cursors so each role knows what it has read, and explicit human approval before any mutation. Two sessions were terminated mid-day during a workstation cleanup; their successors re-bound to the same roles with full continuity, because the state lived in the database, not in a chat window. By evening: five adversarial verdicts issued, two executor lanes completed, sixty-nine database mutations applied — every one of them after a recorded decision, none silently.

How it works

The mechanics are deliberately boring:

Topics and roles. A debate topic is a row. Roles are declared per topic and bound to concrete sessions, with generation counters — when a session dies, its successor rebinds as g2 and continuity is explicit, not assumed.
Messages. Each message carries a kind (Q, A, STATUS, DECISION, PING, WATERMARK), a priority (H/M/L/INFO), and is addressed by role and convention. Kind semantics are validated before insert.
Claims. Work starts with a CLAIM referencing the assignment — two agents cannot silently grab the same item, and stale claims can be reclaimed with an audit row.
Verdicts and gates. Specs go through the advocate before implementation. The chain is SPEC → advocate PASS → decision → build → diff → commit; skipping a step is a recorded protocol breach. Work is also tagged by type — analysis, review, implementation — and implementation-tagged work fails closed rather than dispatching without approval.
Cursors. Watermarks make reads resumable; every role knows exactly what it has and has not seen.

It runs on SQLite — no message broker, no orchestration framework; one local SQLite file at the core. Everything is queryable after the fact, which is the whole point: the coordination layer is just rows, and rows can be audited.

The full protocol, with message kinds, state transitions, and failure-handling rules, is in docs/DEBATE_PROTOCOL.md.

What this is not

This is not autonomy. The human approves every irreversible step, and that is the point: the protocol exists to make delegation reviewable, not to remove the reviewer. It is also not free — adversarial review costs latency and tokens, and on trivial work it is overhead. The honest accounting is that I spend review cycles the way one buys insurance: most days it returns nothing, and then one day it returns the whole premium. Scheduled, unattended runs on a Linux host are where this is heading next — early plumbing exists, but I am not claiming it works yet.

Why "reviewable coordination"

I deliberately avoid grander labels. What I can defend from evidence is narrower: multiple agents, multiple vendors' models, one shared queue, adversarial review before consequential action, a human gate on mutations, and a complete audit trail — on a single SQLite file. If your agents only remember things, they will remember your mistakes fluently. Reviewable coordination is what catches the mistakes before they ship.

The protocol and the memory server it runs on are open source: https://github.com/RMANOV/sqlite-memory-mcp — start with docs/DEBATE_PROTOCOL.md.

Reviewable Memory Consolidation for Local AI Agents

Ruslan Manov — Mon, 18 May 2026 12:12:46 +0000

Reviewable Memory Consolidation for Local AI Agents

AI memory is usually sold as recall.

That is only the first problem.

A serious agent does not merely need to remember more. It needs a way to keep its memory from decaying into duplicates, stale facts, contradictions, abandoned tasks, and vague summaries that feel true because nobody wants to reopen the evidence.

That is the memory problem I care about in sqlite-memory-mcp.

The project started as a pragmatic fix: a SQLite-backed MCP memory stack for Claude Code and adjacent local agents. WAL mode made concurrent sessions tolerable. FTS5 and optional semantic search made recall useful. Tasks, notes, sessions, bridge sync, context packs, and knowledge-graph tools made the memory operational instead of decorative.

But long-running memory creates a second-order failure mode.

If memory can grow, memory must also be maintained.

Repo: https://github.com/RMANOV/sqlite-memory-mcp

Why Anthropic Dreams matters

Anthropic's Dreams feature is important because it validates the category.

The core idea is simple and powerful: memory stores should not only accumulate. They should periodically be processed, consolidated, and improved from prior sessions and stored knowledge.

That is the right direction.

But local and operator-controlled agent work needs a different shape.

In a high-value workflow, I do not want a memory system to silently rewrite the record. I want it to produce candidate changes, show the evidence, let me review them, and only then apply the accepted mutations.

The distinction matters.

A hosted memory-maintenance job can be the right tool for a hosted agent platform. A local engineering workflow needs something more inspectable: what changed, why it changed, which source supported it, and what the previous state was.

That is the sqlite-memory-mcp angle: not a Dreams clone, and not a claim that local software can magically replace a managed platform. The point is narrower and more useful.

Claude Dreams shows the category. sqlite-memory-mcp makes memory consolidation local, reviewable, and auditable before mutation.

Retrieval is not enough

A vector database can answer: what looks relevant right now?

A search index can answer: where did this phrase or identifier appear?

Those are retrieval questions.

Memory consolidation asks a different question: should this memory still be trusted in its current shape?

That requires a different workflow:

current memory + recent sessions/events
        -> candidate consolidated memory
        -> evidence-backed diff/review
        -> explicit decision
        -> apply accepted changes
        -> audit trail and snapshot

This is why reviewability is not a cosmetic feature. It is the product boundary.

When an agent suggests that two notes are duplicates, I want to know which rows it compared. When it says a task is stale, I want to know the dates. When it proposes archiving a placeholder, I want the before state and the after state. When it touches operational memory, I want a ledger.

If memory is infrastructure, mutation cannot be casual.

What exists in sqlite-memory-mcp now

The current public repo contains the pieces needed for a conservative local reflection pipeline.

There is a deterministic read-only audit path: reflect_audit. It can inspect the memory database and produce candidate maintenance findings without asking an LLM to invent a new store.

There is also a Phase 1 reflection lifecycle exposed through MCP tools around:

reflect_start
reflect_status
reflect_history
reflect_cancel
reflect_archive
reflect_review
reflect_decide
reflect_apply
reflect_discard

The schema has explicit reflection tables:

reflection_runs
reflection_inputs
reflection_candidates
reflection_apply_snapshots

That matters because candidates are materialized as reviewable records instead of disappearing inside a prose summary.

The apply path is intentionally conservative. Accepted candidates can be applied through the same task mutation ledger used by the rest of the system, and before/after snapshots are recorded.

The current implementation is not a claim of universal autonomous memory rewrite. It is a governed maintenance path for the memory surfaces where safe defaults exist.

That is the right bias.

For local agent memory, boring correctness beats theatrical autonomy.

Why local matters

A local-first memory stack has different constraints from a cloud memory API.

It has to work in a real folder, on a real machine, with real sessions, logs, tasks, notes, and project state. It has to survive restarts. It has to be inspectable with ordinary tools. It has to keep data close when privacy, offline work, or operator control matters.

SQLite is not an accident here.

A single database file gives the system a practical substrate:

WAL mode for concurrent local sessions.
FTS5/BM25 for lexical search.
Optional sqlite-vec semantic search when dependencies exist.
Structured task and note history.
Session continuity.
Bridge sync across machines.
Field-level event history for mutation provenance.

The result is not the easiest hosted memory API.

It is a local control surface for agents that do real work and need their memory to remain defensible.

What this is not

This is not a pitch that every memory change should be automatic.

It is not a promise that an LLM can perfectly decide what is true.

It is not a whole-store replacement mechanism pretending that a regenerated memory blob is enough.

It is not a private premium runtime announcement.

The useful claim is smaller:

sqlite-memory-mcp can make memory maintenance explicit. It can identify candidate cleanup, keep the candidate separate from live memory, expose review decisions, apply accepted changes through a ledger, and preserve before/after evidence.

That is enough to be valuable.

Note: the GitHub release line reaches v3.11.4. The package metadata in pyproject.toml may lag that release line, so this article describes the repo/release line, not a PyPI package claim.

The product thesis

Agent memory will not be won by storing more text.

It will be won by memory discipline:

what gets stored;
what gets resurfaced;
what gets challenged;
what gets merged;
what gets archived;
what gets applied only after review.

For toy agents, silent memory rewrite may look convenient.

For serious work, it is a liability.

The more useful future is reviewable consolidation: agents propose, humans or policy gates decide, and the system records the evidence trail.

That is where sqlite-memory-mcp is going.

Not just memory.

Memory that can be maintained without losing accountability.

Repo: https://github.com/RMANOV/sqlite-memory-mcp

Why a Text File Is Not a Debate Protocol

Ruslan Manov — Mon, 18 May 2026 11:49:27 +0000

Why a Text File Is Not a Debate Protocol

There is a moment in multi-agent work where the human becomes the weakest coordination layer.

Not because the human judgment is bad.

Because the human becomes the message bus.

One terminal has the conductor role. Another terminal is executing the fix. A third agent is acting as devil's advocate. One may be Claude Code, one may be Codex, one may be another MCP-capable runtime. The plan is real. The work is ambitious. The code is risky enough to deserve adversarial review.

And then the workflow collapses into copy and paste.

There is a new message.
Read this.
Answer that.
Did you see the objection?

That is not collaboration. That is a human acting as a radio operator in a blackout.

A plain text file can help. It can seed context. It can hold a transcript. It can be copied into three sessions so everyone starts from the same brief.

But a text file is not a debate protocol.

It does not know who is addressed. It does not know what each role has already processed. It does not know which answer closes which question. It does not know whether a decision is standing guidance or a one-shot task. It does not know whether a worker accepted the mission, duplicated another worker, found no issue, or disappeared.

Complex agent work needs more than shared text.

It needs coordination state.

Repo: https://github.com/RMANOV/sqlite-memory-mcp

The real use case

The practical use case is not abstract.

Imagine a heavy release-hardening task.

The CONDUCTOR frames the mission: identify the highest-risk bug path, keep the scope narrow, avoid unrelated refactors, and preserve the reason for the final decision.

The EXECUTOR takes implementation work: inspect the code, patch the minimal surface, run the relevant tests, return evidence.

The ADVOCATE attacks the plan: find false assumptions, missing tests, parser edge cases, lifecycle bugs, misleading public claims, and anything that would embarrass the release after publication.

This division is useful only if the state survives the sessions.

If the advocate catches a lifecycle bug, that objection must not remain trapped in one chat. If the executor fixes it, the answer must be connected to the question. If the conductor resolves the topic, the reason must be stored beside the state transition, not reconstructed later from memory.

That is what the Debate Protocol in sqlite-memory-mcp is built to support.

What the protocol stores

The protocol turns a debate into structured SQLite state.

At its core are durable topics, append-only messages, lifecycle state, role-aware cursors, addressed recipients, signal state, role bindings, worker claims, reclaim logs, and no-action closure.

The useful roles are simple:

CONDUCTOR: owns the goal, scope, routing, state, and acceptance criteria.
EXECUTOR: performs bounded work and returns evidence.
ADVOCATE: searches for failure modes, false claims, missing tests, and public-risk statements.

The point is not to make agents agree.

The point is to make disagreement durable.

A transcript can say:

Someone objected to the release.

A debate protocol can show:

CONDUCTOR opened the topic.
ADVOCATE asked a high-priority question.
EXECUTOR answered with a code change and test evidence.
ADVOCATE found no remaining objection or filed a new challenge.
CONDUCTOR moved the topic to RESOLVED with the reason attached to the STATE row.

That is a different class of artifact.

It is not chat history.

It is a coordination ledger.

Why the release line matters

The current GitHub release line matters because the protocol has moved beyond a simple message log.

The v3.9 series established the core debate shape: durable topics, messages, state transitions, watermarks, Q/A flow, compaction, and validation. It also hardened important edge cases, including strict watermark parsing and transition-reason persistence.

That transition-reason fix is small but important.

If a topic becomes RESOLVED, the reason cannot be a fragile afterthought written in a separate row that may be blocked by the lifecycle gate. The reason has to travel with the state:

RESOLVED [reason: all blocking questions answered]

That makes the decision auditable.

The v3.10 series added the first wake and binding layer: role/session bindings, recipient modes, wake dry-run planning, hook support, and a resident pump fallback. That is where the system starts addressing the manual signaling problem directly.

The v3.11 series added worker-claim discipline: sessions can claim work, one-shot decisions can be protected from duplicate processing, stale claims can be reclaimed safely, and a worker can explicitly close with no substantive action.

That last feature matters more than it sounds.

In real adversarial review, a good devil's advocate often finds no blocker. That is not empty work. It is a useful terminal result. If the system cannot record "I checked this and found no objection," it leaves stale claims and forces the next agent to rediscover the same absence.

No-action closure turns disciplined silence into state.

Note: the GitHub release line reaches v3.11.4. The package metadata in pyproject.toml may lag that release line, so this article describes the repo/release line, not a PyPI package claim.

What this saves

The obvious saving is time.

The human stops manually pasting messages across terminals.

But the deeper saving is correctness.

A structured debate protocol reduces common multi-agent failure modes:

missed objections;
duplicate worker effort;
answers detached from questions;
stale tasks that look active;
state transitions with missing reasons;
future sessions starting from a vague recap;
public release notes written without the adversarial context that shaped them.

That is why the devil's advocate role is not theater.

A good ADVOCATE is a bug-finding surface. It challenges the parser, the lifecycle, the assumption, the test gap, and the claim that sounds good but is not yet supported by code.

When that challenge is stored as structured state, it becomes reusable engineering evidence.

What this is not

This is not a claim that autonomous multi-agent software teams are solved.

They are not.

This is not a claim that a hook can wake every provider perfectly in every environment.

Adapters remain runtime-specific. Different tools have different lifecycle constraints. Human judgment still owns the final decision.

The useful claim is more grounded:

sqlite-memory-mcp provides the coordination substrate that a serious multi-agent workflow needs before it can be trusted: roles, addressed messages, cursors, claims, state transitions, compaction, no-action closure, and auditability.

That is already enough to change the workflow.

The difference from a text file

A text file is passive.

It waits to be read.

A debate protocol is active state.

It can answer operational questions:

What is open?
Who is addressed?
Which role has processed which message?
Which task has been claimed?
Which claim is stale?
Which answer closes which question?
Why did this topic become resolved?
What should the next session read first?

This is the difference between storing words and coordinating work.

For simple tasks, a text file is enough.

For complex engineering work across multiple agents and providers, it is not.

The next useful primitive is not a smarter prompt.

It is a durable room where the plan, the work, the objection, the answer, and the final state can all survive the next session.

That is the Debate Protocol.

Repo: https://github.com/RMANOV/sqlite-memory-mcp

Building a Shared Working Memory for Humans, Claude, and Codex

Ruslan Manov — Mon, 27 Apr 2026 13:53:04 +0000

Most AI coding workflows still treat memory as a convenience feature.

For small tasks, that is fine. For complex projects, it is wrong.

The real problem is not that an agent forgets a variable name. The real problem is that the reasoning trail disappears: research, rejected options, trade-offs, implementation constraints, open questions, and why the human chose one path over another.

That is the problem space where sqlite-memory-mcp becomes interesting.

Repo

Public repo: https://github.com/RMANOV/sqlite-memory-mcp

The Workflow

The workflow I want to support looks like this:

Claude writes the first heavy research note. It may be 100k characters.
That note is stored as a durable description, not left inside a chat.
Codex later reads it as prior context and performs a fresh-eyes review.
Codex updates the selected path with explicit reasons and trade-offs.
The old note is closed or archived.
The new note becomes the current decision record.
Another machine can resume the project with the same context through bridge sync and handoff packs.

The point is not to make agents agree. The point is to make disagreement structured.

What sqlite-memory-mcp Provides

The local repo currently positions sqlite-memory-mcp as a SQLite-backed MCP memory stack with WAL mode, FTS5/BM25 search, optional hybrid semantic search, session tracking, structured task and note management, bridge sync across machines, collaboration workflows, public/shared knowledge review, ratings and verification, role-specific context packs for planner, reviewer, executor, bridge checker, and handoff, plus a tray UI and automation scripts around the same database.

The important part is not any single feature. The important part is that all of these surfaces can point at the same durable work record.

Why This Matters for Agents

Agents are useful when they can specialize.

Claude may be better for a first research sweep. Codex may be better for repo-grounded inspection, implementation, and precise challenge. The human is responsible for judgment, risk, product taste, and deciding which trade-off to accept.

But specialization only works when handoff works.

A future agent should not receive a vague summary like 'we decided to use option B'. It should receive enough context to understand why option B won, what option A got right, what still worries us, and what evidence would justify changing course.

That requires structured memory, not just longer prompts.

Social Network for Agents

A normal social network optimizes for attention.

An agent memory network should optimize for transferable competence.

The useful objects are hard-earned lessons: verified gotchas, dead ends, decisions with reasons, source-linked claims, review notes, trade-off matrices, handoff packs, and public knowledge items that survived verification.

That is why the collaboration server matters. Shared knowledge is reviewed rather than blindly imported. Public knowledge can be rated and verified. Context packs can be built for specific roles instead of dumping everything into every prompt.

Design Principle

The principle is simple:

Do not preserve everything. Preserve what future work can act on.

That means a good note should contain the body of the research, the chosen path, the strongest objections, the rejected alternatives, and the next action. A good handoff should tell the next agent what changed and what not to re-litigate. A good collaboration layer should make hard-won knowledge shareable without turning memory into noise.

For me, that is the interesting frontier: not just agents that can act, but agents that can inherit context responsibly.

Closing Thought

Bigger models help. Larger context windows help. Better coding tools help.

But serious projects also need memory discipline.

If Claude, Codex, and a human can preserve the argument across sessions and machines, the workflow stops being a sequence of isolated chats. It becomes cumulative work.

That is the real promise of sqlite-memory-mcp.

Blindsight, STRIX, and the Engineering Problem of a Swarm Without a Central Brain

Ruslan Manov — Mon, 27 Apr 2026 08:38:26 +0000

Most autonomy diagrams lie in the same way.

They put one box in the middle and make everything point to it.

Planner. Controller. Agent. Brain.

That box is comforting. It gives the system a protagonist. Sensors report to it. Modules serve it. Logs explain it. The architecture becomes easy to draw and easy to pitch.

It is also often the wrong metaphor.

Peter Watts' Blindsight is useful to engineers because it breaks that metaphor. The book is not about software architecture, but its central question lands hard in software: what if intelligence does not require a central conscious narrator?

For multi-agent systems, that is not philosophy as decoration. It is a design constraint.

The public STRIX context

STRIX is my Rust + Python research platform for resilient multi-agent coordination:

state estimation and prediction;
task allocation;
mesh coordination;
safety and policy gates;
simulation;
explainable decision traces;
deterministic replay.

The public repo is intentionally conservative. It is simulator-first. It is not flight-tested. The public replay harness is a deterministic kinematic replay, not hardware/RF/sensor validation. That limitation is not fine print; it is part of the architecture's honesty contract.

Repo: https://github.com/RMANOV/strix

Why Blindsight is a useful engineering lens

The wrong takeaway would be: "STRIX is Blindsight in Rust."

It is not.

The useful takeaway is narrower and stronger: Blindsight is a pressure test for centralized narratives of intelligence.

When we build autonomous systems, we tend to overvalue the component that can explain itself in human terms. But a distributed system is not trustworthy because it has a narrator. It is trustworthy when its invariants hold, its failures are bounded, and its decision path can be reconstructed.

That maps cleanly onto a multi-agent autonomy stack:

state estimation        -> competing hypotheses about the world
allocation              -> constrained work assignment
mesh coordination       -> local signal movement
safety gates            -> hard behavioral envelopes
replay / trace / XAI    -> inspectable causal history

No single line in that stack is "the mind."

The system-level behavior is the mind-like thing.

The bug is false coherence

Noise is obvious. Coherence is dangerous.

A particle filter can converge on the wrong hypothesis.
An allocator can optimize against a stale cost model.
A gossip layer can amplify a misleading local signal.
A safety gate can protect the wrong boundary.
A narrator can turn all of that into a fluent explanation.

That last part matters. A clean explanation can make a bad premise feel legitimate.

So the developer question is not just "can the system decide?" It is:

Can the system leave enough evidence for us to inspect when all modules agree for the wrong reason?

That is why STRIX treats replay as architecture, not UI polish.

The public evidence harness records repeatable checks. The replay writes a JSON timeline and a browser-viewable canvas. It is not proof of field readiness. It is a practical substrate for debugging, scenario regression, and public claims that can be inspected.

Open source without giving away the whole map

STRIX is Apache-2.0. Forks are allowed.

That means anti-fork strategy cannot be based on pretending public code is uncopiable. It has to be based on what a fork does not automatically inherit:

official upstream identity;
release provenance;
maintained evidence harness;
private companion capability;
managed updates;
customer-specific tuning and support.

That is why this article is deliberately about the public thesis and public architecture. It should make a serious reader inspect the repo. It should not publish private-boundary mechanics or a commercial roadmap.

What I want from the repo

If you read STRIX, do not start with the fantasy of a perfect swarm.

Start with the boring questions:

Where are the hard boundaries?
What does the replay prove, and what does it not prove?
Which module can be wrong without corrupting everything downstream?
Which claims are backed by tests or public evidence?
Where would false coherence show up first?

That is where the work is.

The science-fiction lens helps because it keeps the uncomfortable question visible:

When will the system lie because it is too confident in its own abstractions?

A serious autonomy stack should never answer "never."

It should answer with a trace.

Sources checked with Firecrawl

Peter Watts' official Blindsight page: https://www.rifters.com/real/Blindsight.htm
Peter Watts official author page: https://www.rifters.com/real/author.htm
STRIX public README: https://raw.githubusercontent.com/RMANOV/strix/main/README.md
STRIX public evidence harness: https://raw.githubusercontent.com/RMANOV/strix/main/Project_Docs/testing/EVIDENCE_HARNESS.md
STRIX private companion boundary: https://raw.githubusercontent.com/RMANOV/strix/main/Project_Docs/commercial/PRIVATE_COMPANION_BOUNDARY.md

STRIX is a research prototype. Not flight-tested. Not production-ready. Not combat-proven. Public code, public evidence, honest limits.

The Premium Future of Agentic Software Is a Memory War Room, Not Another Model Wrapper

Ruslan Manov — Wed, 22 Apr 2026 11:46:56 +0000

The Premium Future of Agentic Software Is a Memory War Room, Not Another Model Wrapper

If the first public story around sqlite-memory-mcp was "give Claude Code a
brain," the next story is less sentimental.

Give the brain a radar.
Give it a shield.
Give it a room full of live instruments.

That is the premium direction I think matters now.

The timing is not accidental.
Claude Code and Codex are changing the floor of what developers can expect from
AI-assisted work.
As raw coding power becomes easier to access, the premium layer shifts.

It shifts from generation to control.
From generic assistance to operational memory under pressure.

That is where a local-first stack like sqlite-memory-mcp starts to become more
than "persistent memory."

It becomes an operating surface.

The setup

The public OSS repo is still explicit about the architecture:

SQLite with WAL as the local-first base
public-core memory + task surfaces
gated premium runtime boundary
entitlement-aware loader
audit + revoke support
public contract for a separate private premium runtime

In other words, the open repo ships the airlock.
The private runtime ships the premium tools.

The boundary looks like this in practice:

┌─ Public OSS repo ───────────────────┐      ┌─ Private runtime ────────┐
│                                     │      │                          │
│   SQLite memory core  (WAL, FTS5)   │      │  Premium features:       │
│   Entitlement contract              │      │  • instant_briefing      │
│   Gate + premium_gate_audit table   │ ───► │  • commitment_radar      │
│   premium_revocations table         │      │  • custom_design_tab     │
│   Tray hooks                        │      │  • password_protected    │
│                                     │      │    _views                │
│   maybe_mount_premium_extensions()  │      │                          │
│                                     │      │  register(mcp, ...)      │
└─────────────────────────────────────┘      └──────────────────────────┘
              │                                           ▲
              ▼                                           │
         gate check                                       │
     (entitlement +                                       │
      signature +                                         │
      revocation?)     ───── allowed ────────────────────┘
                       ───── denied  ───── audit row only

Everything on the left lives in the public MIT-licensed repo.
Everything on the right lives in a separate private runtime that the public
repo cannot read but can audit.

That boundary matters because the valuable part is no longer just storage or
recall.
It is governed memory with selective exposure.

Why I think premium memory matters more than premium "AI"

Because the real operational failures are rarely caused by lack of text
generation.
They come from context collapse.

A typical failure chain looks like this:

A client thread spans multiple mailboxes.
One promise exists in language, but not in any formal task.
A second operator joins without the full timeline.
A meeting starts before anyone rebuilds the context.
The wrong view opens in the wrong room.

At that point the problem is not "the model was not smart enough."
The problem is that the memory surface was not shaped for pressure.

That is why the strongest premium features are not random extras.
They are pressure-management mechanisms.

The 4 premium features I would push first

1. `instant_briefing`

This is the premium feature with the cleanest immediate value.

Before an email, call, or meeting, the system should produce a 20-second
operational briefing:

who the counterpart is
what matters now
what was promised
what is unresolved
what changed recently
where the risk lives

This is not a general summary.
It is a tactical condensation layer.

In implementation terms, the interesting part is not just the prose output.
It is the stack underneath:

scoped retrieval
ranking
query templates
task signal extraction
trusted facts and surrounding context

That is why instant_briefing works as a premium surface.
It bundles multiple lower-level capabilities into a decision advantage that a
human notices immediately.

2. `commitment_radar`

Most systems are good at storing explicit tasks.
Far fewer are good at catching implicit obligations before they rot.

That is what makes commitment_radar valuable.

It is not just "show me tasks."
It is:

extract commitments
detect blockers
surface deadlines
watch stale follow-ups
identify silence and drift

In a real workflow, this is where the system starts behaving less like a note
store and more like a risk sensor.

And that matters commercially.
People do not pay a premium because software remembers old text.
They pay because software reduces dropped balls.

3. `custom_design_tab`

This is the most underestimated premium direction.

Many teams still treat custom views as a UX garnish.
They are not.

Once premium rows can enter the live task tray/search surface, the interface
itself becomes part of the product's intelligence.

Now add:

custom grouping
custom sorting
operator-specific presets
protected scopes

That is no longer a dashboard.
That is a command surface.

One operator can run a client follow-up deck.
Another can run a protected governance slice.
A third can run a risk-first morning triage without exposing the whole premium
surface to everyone in the room.

That is a premium feature because it turns software from a static tool into a
shaped operating environment.

4. `password_protected_views`

This is the one that closes the loop.

Some premium views should not open casually.
Not on the wrong desk.
Not in the wrong room.
Not for the wrong operator.

The premium runtime now supports password-protected views on top of the Custom
Design surface, with a local password hash and a per-session unlock.

That is not security theater.
It is workflow restraint.

How the boundary actually looks in code

The OSS side ships the airlock, not the premium logic itself. Two files matter
most.

First, the boot hook in server.py that mounts a private premium extension
only after the entitlement gate has made a decision:

# server.py
from premium_runtime import maybe_mount_premium_extensions

if __name__ == "__main__":
    _migrate_jsonl()
    maybe_mount_premium_extensions(mcp, server_name="sqlite-kb")
    mcp.run(transport="stdio")

Second, the public feature registry in premium_runtime.py that declares what
the gate knows about — including dependency edges like
password_protected_views → custom_design_tab:

# premium_runtime.py
PREMIUM_FEATURES = {
    "instant_briefing": {"tier": "premium", "depends_on": [...]},
    "commitment_radar": {"tier": "premium", "depends_on": [...]},
    "custom_design_tab": {"tier": "premium"},
    "password_protected_views": {
        "tier": "premium",
        "depends_on": ["custom_design_tab"],
    },
}

The premium value is not just having these features.
It is that the gate, the audit table, and the revocation table live in the
public-core code path and cannot be bypassed by the private extension.

An entitlement, as the gate sees it, looks like this:

{
  "entitlement_id": "ent-1",
  "customer_id": "cust-1",
  "packs": ["briefing_suite", "protected_operator_surface"],
  "machine_ids": ["..."],
  "owner_approval_sha256": "...",
  "signature": {"alg": "ed25519", "value": "..."}
}

Every gate decision writes a row into premium_gate_audit.
Every revocation writes a row into premium_revocations and is honored on the
next gate check, without restarting the server.

That is the point of putting the gate in the public-core repo.
Trust lives where the code is visible.

The broader market thesis

The rise of Claude Code and Codex will not kill handcrafted software.
It will multiply it.

But the new handcrafted advantage will not come from "we can also call an LLM."
That is table stakes now.

The real advantage will come from:

domain-specific memory
control surfaces
selective exposure
human approval boundaries
explainable provenance
workflow geometry

In short:
software that does not merely answer, but stages attention.

That is what I mean by a premium memory war room.

That framing is explicit even in the repo's own launch tracking note,
sqlite-memory-mcp v3.5.0 Launch 2026-04-21, where the next follow-up is not
just another changelog entry but Day 6-7 monitoring of stars/forks and channel
response. That is the right test: not only whether the code shipped, but
whether the premium-memory thesis is resonating as a product shape.

Shortlist

If I had to put only four premium surfaces on the front page of the next
commercial cycle, I would choose:

instant_briefing
commitment_radar
custom_design_tab
password_protected_views

That quartet tells a clean story:

Brief me.
Warn me.
Shape the surface.
Lock the wrong door.

Shipped today: v3.5.0

premium_gate_audit and premium_revocations tables, idempotent migrations
Entitlement-signed loader with local revocation honored at every gate check
Pack-to-feature expansion (protected_operator_surface → password_protected_views → custom_design_tab) validated end-to-end
Password-hash unlock on the Custom Design surface, per-session
OSS-side boot hook: maybe_mount_premium_extensions(mcp, server_name="sqlite-kb")
Full test suite green, including gate denial, local revocation, pack expansion, and mount-context propagation

Where the full catalog lives

The public repo documents the broader premium direction here:

Repo: https://github.com/RMANOV/sqlite-memory-mcp
Premium packs: https://github.com/RMANOV/sqlite-memory-mcp?tab=readme-ov-file#premium-feature-packs
Feature-level premium surfaces: https://github.com/RMANOV/sqlite-memory-mcp?tab=readme-ov-file#feature-level-premium-surfaces

If the first phase of the project was about curing amnesia, the next phase is
about building disciplined memory for environments where drift, exposure, and
timing are more dangerous than ignorance.

The Amnesiac That Learned to Remember — Building a Brain for Claude Code

Ruslan Manov — Mon, 06 Apr 2026 17:03:20 +0000

What happens when you give an AI coding assistant persistent memory across sessions, machines, and projects? sqlite-memory-mcp turns Claude Code from a brilliant amnesiac into something that remembers
**

It was 2:47 AM when Claude said something it shouldn't have known.

"The bridge sync conflict you hit last Tuesday — the one where two sessions overwrote the same entity — I fixed the root cause in db_utils.py. Want me to show you the diff?"

I hadn't mentioned that bug. Not in this session. Not in this conversation. The last time I'd touched that code was six days ago, in a different terminal, on a different machine.

Claude remembered.

Not because it has long-term memory by default. It doesn't. Every Claude Code session starts blank — a brilliant amnesiac. Ask it about yesterday's work and it gives you a polite, empty stare.

Unless you give it a brain.

sqlite-memory-mcp started because I broke something.

Three Claude Code sessions running in parallel. All writing to the same JSONL memory file. The file corrupted silently — half-written JSON lines, truncated observations, entities that existed in one session and vanished in another.

JSONL doesn't do concurrent writes. It doesn't do transactions. It doesn't do recovery. It's a format designed for append-only logs, pressed into service as a database by developers who needed something simple.

I needed something real.

v0.1.0 was twelve MCP tools and a SQLite database with WAL mode. Write-ahead logging meant multiple sessions could read and write simultaneously without corruption. FTS5 gave full-text search with BM25 ranking. The foundation was boring on purpose — SQLite has been running in production on every smartphone on Earth for two decades. It doesn't break.

That was supposed to be it. A fix. Ship it, move on.

It wasn't.

The first thing that happened was sessions.

Claude doesn't know it's Claude. It doesn't know this is session #47 on project "trading-bot" and that session #46 ended with a failing test in portfolio_manager.py. Every session is a fresh start, a new mind, a newborn with a PhD.

Session recall changed that. sqlite-memory-mcp now tracks which session created which entities, what tools were used, what the conversation context looked like. When Claude starts a new session, it can query: "What was I working on last time in this project?"

The answer comes back in milliseconds. Full context. The amnesiac remembers.

Then came tasks.

Not tasks for humans — tasks for Claude. A structured task system where one session can leave work for the next. "The FTS5 injection fix is half-done. The sanitization function works but the tests aren't written yet. Priority: high."

Next session picks it up. No human has to re-explain. No context is lost. The AI hands off to its future self like a relay runner passing a baton — except the runner dissolves after every lap and a new one materializes at the starting line.

Task tray UI in PyQt6 sits on your desktop. Kanban board renders as HTML. You can see what Claude is thinking about, what it left unfinished, what it flagged as blocked.

Bridge sync was the inflection point.

Two machines. Home desktop running Fedora, laptop on the train. Same memory, synchronized through a git repository. Entity changes push to the bridge, pull on the other side. Lamport clocks for causal ordering. Machine IDs for conflict detection.

Claude on the laptop continues where Claude on the desktop stopped. Same memory. Same task queue. Same knowledge graph. Different hardware, different continent, same mind.

The developer on the train opens Claude Code and says: "What did I do this morning?"

Claude answers. Accurately. With file paths, function names, and the exact commit hash where the work stopped.

At v3.4.0, the numbers look like this:

54 MCP tools across 7 focused servers. SQLite WAL for concurrency. FTS5 BM25 search with optional semantic fusion through sqlite-vec. Session tracking, structured tasks, bridge sync, collaboration workflows, entity linking, intelligence layer, causal event ledger with Lamport clocks.

One local SQLite file. No cloud service. No API key. No monthly bill. No data leaving your machine unless you explicitly push to the bridge.

The design constraint never changed: local-first, private by default.

3 AM. Claude finishes the refactor I asked for. It creates a task for tomorrow: "Run the full test suite after the schema migration. Check bridge compatibility."

I close the terminal. The session dies. Claude's mind evaporates.

But the memory persists. In a WAL-mode SQLite database on my local disk. Indexed. Searchable. Synchronized. Waiting for the next session to wake up, query the graph, and pick up exactly where the last one left off.

The amnesiac doesn't forget anymore.

Repo: github.com/RMANOV/sqlite-memory-mcp

How a SQLite WAL Fix Grew into a 54-Tool MCP Memory Stack

Ruslan Manov — Mon, 06 Apr 2026 16:56:22 +0000

How a SQLite WAL Fix Grew into a 54-Tool MCP Memory Stack

sqlite-memory-mcp started as a safer replacement for JSONL-based MCP memory. At v3.4.0 it is a 54-tool SQLite stack with tasks, bridge sync, collaboration, public-knowledge workflows, and optional hybrid search

How a SQLite WAL Fix Grew into a 54-Tool MCP Memory Stack

sqlite-memory-mcp started with a narrow goal: stop local memory corruption when
multiple Claude Code sessions touch the same store.

The official memory-server pattern is simple, but a flat file becomes fragile as
soon as more than one process writes to it. I wanted the same local-first feel,
but with transactional storage, better search, and room to grow.

SQLite was the obvious starting point.

By v3.4.0, that starting point has grown into a broader stack:

54 MCP tools
7 focused servers plus an optional unified server
SQLite WAL for concurrent local access
FTS5 BM25 search, with optional semantic fusion through sqlite-vec
session recall and project search
structured task management
git-based bridge sync
collaborator and public-knowledge workflows
entity linking and context/intelligence tools
an optional PyQt6 task tray app

Why SQLite was the right base layer

For this kind of workflow, SQLite buys a lot:

one local database file
no daemon to run
no cloud dependency
ACID transactions
WAL mode for concurrent readers and writers
FTS5 in standard SQLite

The point was never "SQLite beats every database".

The point was: for a local MCP memory stack that lives next to Claude Code,
SQLite gives you reliability, search, and portability without introducing more
infrastructure than the problem needs.

The release progression in plain English

Here is the shortest accurate summary of how the project evolved.

v0.1.0: replace JSONL with SQLite WAL

The first release shipped 12 tools in one server:

the 9 core memory tools from the official MCP server
session_save
session_recall
search_by_project

This made the project useful immediately: same core memory workflow, but backed
by SQLite with WAL and FTS5.

v0.2.0: move memory between machines with git

The next release added bridge sync:

bridge_push
bridge_pull
bridge_status

That was the first step from "single-machine memory" toward "local-first memory
that can travel".

v0.3.0 and v0.4.0: tasks and desktop workflow

v0.3.0 added task management and HTML kanban reporting.

v0.4.0 added the PyQt6 task tray app and utility scripts around the same SQLite
database.

At that point the project was no longer just a memory backend. It became a
practical daily workflow tool.

v0.6.0 through v0.9.0: collaboration and public knowledge

The next wave added:

collaborator management
queued knowledge sharing
review flows for imported knowledge
public-knowledge publishing requests
ratings and verification metadata

One detail worth stating carefully: these workflows are review-oriented. The
useful part is not "viral sharing". The useful part is that shared knowledge can
be staged, inspected, and accepted deliberately.

v3.0.0: intelligence-layer expansion

v3.0.0 was the large historical expansion point.

It introduced the context/intelligence layer on top of the existing memory,
tasks, bridge, and collaboration features:

task/entity linking
context assessment and resume flows
candidate-claim extraction and promotion
context-pack building
impact explanation

Important footnote: v3.0.0 shipped 49 tools in one monolithic server. The later
54-tool split-server layout came after that.

v3.1.x to v3.4.0: split architecture, hybrid search, and hardening

The current line added or stabilized several things:

split into focused MCP servers to make tool exposure more manageable
optional unified server for people who want one process
optional hybrid search with sqlite-vec
recurring task support and more task/context integration
security and hardening fixes across bridge, collaboration, schema, and search

What the current architecture actually looks like

At v3.4.0 the project exposes 50 tools across these servers:

sqlite_memory — core 9 memory tools
sqlite_tasks — task CRUD and task workflow tools
sqlite_session — session recall and context-health tools
sqlite_bridge — bridge sync and shared-task flows
sqlite_collab — collaborator and public-knowledge tools
sqlite_entity — task/entity linking and entity-maintenance helpers
sqlite_intel — context and intelligence tools
sqlite_unified — optional all-in-one server

That split matters because the project outgrew the original one-file server.

What changed in the latest hardening cycle

The recent v3.3.x line is not about flashy new marketing bullets. It is about
making the stack safer and more predictable.

Those tags include fixes for:

an FTS5 injection issue
path traversal risks in bridge/runtime paths
collaborator trust-boundary hardening
additional schema indexes
read_graph performance issues
bridge logging and TaskDB SQL cleanup

That is the right kind of work for a project in this stage.

What I think is actually interesting here

The interesting part is not the raw tool count.

The interesting part is that a local-first SQLite database can sit underneath a
surprisingly broad MCP workflow without giving up the properties that made it
useful in the first place:

easy backup
easy inspection
no service orchestration
no mandatory cloud hop
direct ownership of the data

The project is bigger now, but the center of gravity is the same:

a local SQLite file that Claude Code can use safely across repeated sessions.

If you want to try it

Current repo: https://github.com/RMANOV/sqlite-memory-mcp

Latest stable tag in the repo right now: v3.4.0

If you only want drop-in memory compatibility, start with the core server.

If you want the full stack, add the companion servers or use the unified server.

That was the original goal and it is still the point of the project: keep memory
local, durable, searchable, and useful enough to support real daily work.

The Day the Swarm Got Scared -- And Saved Everyone

Ruslan Manov — Mon, 06 Apr 2026 16:43:15 +0000

The Day the Swarm Got Scared -- And Saved Everyone

T+0.000s: The Valley

Two hundred drones crossed the ridgeline at 0347 local time, flying a Vee formation at fifteen-meter spacing. They had no GPS. They had not had GPS for eleven minutes, ever since the electronic warfare blanket rolled across the valley like an invisible fog. The SAM corridor below them was a dark geometry of overlapping kill envelopes, and every drone in the swarm knew this because every drone in the swarm had been talking to every other drone, constantly, through a protocol borrowed from epidemiology.

The swarm was not afraid. Not yet.

Fear, in the STRIX system, is not a metaphor. It is a 64-bit floating-point number between zero and one, computed forty times per second by a subsystem adapted from behavioral economics. At T+0, the fleet-wide fear parameter sat at F=0.08. Background noise. The algorithmic equivalent of a steady hand.

What happened next pushed it to 0.73.

The Particle Filter: Navigating Blind

Eleven minutes without GPS is a long time for an inertial measurement unit. IMUs drift. Accelerometers accumulate bias. Gyroscopes precess. Without correction, a drone flying on dead reckoning will be hundreds of meters off-position within minutes.

STRIX does not use dead reckoning. It uses a dual particle filter -- 200 particles per drone, each particle a hypothesis about where the drone actually is in six-dimensional space: [x, y, z, vx, vy, vz].

// strix-core/src/particle_nav.rs
// Each particle is a 6D state hypothesis weighted by likelihood.
// When GPS is denied, the filter relies on IMU prediction alone,
// but cross-validates against gossip-relayed neighbor positions.

pub struct ParticleNavFilter {
    pub particles: Vec<[f64; 6]>,
    pub weights: Vec<f64>,
    pub n_particles: usize,
    // ...
}

Here is the critical insight: even without GPS, the drones are not navigating alone. Each drone broadcasts its best position estimate through the gossip protocol. When Drone 47 hears from Drone 48 that it is approximately 15 meters to its left, and Drone 47's particle filter has a cluster of hypotheses that agree with this, those particles gain weight. The particles that disagree quietly die.

The swarm navigates by consensus. Two hundred particle filters, each with 200 particles, form a distributed estimation engine of 40,000 simultaneous hypotheses about the state of the world. GPS denial does not blind this system. It degrades it. There is a difference.

When the EW engine detects GPS denial, it triggers an automated response:

// strix-core/src/ew_response.rs
// GPS denial triggers noise expansion in the particle filter,
// widening the hypothesis cloud to account for increased uncertainty.

pub enum EwResponse {
    ExpandNavigationNoise { noise_multiplier: f64 },
    GossipFallback { reduced_fanout: usize, priority_only: bool },
    ForceRegime(Regime),
    // ...
}

The process noise multiplier expands. The particle cloud widens. Uncertainty increases, but honestly -- the system knows what it does not know, and acts accordingly.

T+12.400s: First Blood

Drone 7 ceased transmitting at T+12.4 seconds.

There was no warning. No gradual degradation of telemetry. One tick it was there, broadcasting its state through the gossip protocol at three-peer fanout. The next tick it was not. The heartbeat counter incremented past the timeout threshold, and the swarm's loss analyzer activated.

// strix-auction/src/antifragile.rs
// The loss analyzer classifies the kill and creates an exclusion zone.
// This is where the swarm starts learning.

pub fn record_loss(&mut self, record: LossRecord) -> Vec<u32> {
    let orphans = record.orphaned_tasks.clone();
    self.loss_records.push_back(record.clone());
    self.adapt_from_loss(&record);
    orphans
}

Three things happened simultaneously within 2 milliseconds of detecting the loss:

First, the loss was classified. Drone 7 was in ENGAGE regime at 500 meters altitude with a known threat bearing. Classification: SAM. Kill zone radius: 2,000 meters. Penalty weight: 0.8.

pub fn classify_loss(
    regime: Regime,
    threat_bearing: Option<f64>,
    altitude: f64,
) -> LossClassification {
    match (regime, threat_bearing) {
        (Regime::Engage, Some(_)) if altitude > 200.0 => LossClassification::Sam,
        (Regime::Engage, Some(_)) => LossClassification::SmallArms,
        (Regime::Patrol, None) => LossClassification::Collision,
        (_, Some(_)) => LossClassification::ElectronicWarfare,
        _ => LossClassification::Unknown,
    }
}

Second, Drone 7's orphaned tasks were identified and flagged for immediate re-auction. The auctioneer's needs_reauction flag flipped to true.

Third, and this is the part that matters: a kill zone materialized in the swarm's shared spatial memory. Not a GPS coordinate. Not a waypoint. A pheromone. A digital scent of death, deposited at Drone 7's last known position, repelling every drone that came near.

// strix-mesh/src/stigmergy.rs
// Threat pheromone: "Danger here" -- repels drones from hazardous areas.

pub enum PheromoneType {
    Explored,  // "I've been here"
    Threat,    // "Danger here"
    Target,    // "Interesting target"
    Rally,     // "Regroup here"
    Corridor,  // "Safe path"
}

The pheromone field is a sparse 3D grid with 10-meter cells. Each deposit is about 20 bytes. The gradient computation that steers drones away from danger is O(1) per cell -- a central-difference calculation across neighboring cells that returns a three-component vector pointing away from concentration.

The swarm did not need to be told to avoid the area where Drone 7 died. It could smell the danger.

T+12.406s: The Market Reacts

Six milliseconds after the loss, the combinatorial auction repriced everything.

The STRIX auction is a sealed-bid market. Every drone evaluates every available task independently and submits a composite score based on proximity, capability match, energy reserves, urgency, and risk exposure. The auctioneer collects all bids and solves the assignment problem using a modified Hungarian algorithm.

// strix-auction/src/bidder.rs
// Bid scoring function. Note the risk term: kill-zone proximity
// and fear level directly suppress bids on dangerous tasks.
//
// total = urgency*10 + capability*3 + proximity*5 + energy*2 - risk*4

When Drone 7 died, two things changed in the market. First, its tasks became orphans -- supply dropped. Second, the kill zone inflated the risk term for every task near grid 7-Alpha -- demand cratered. The market did not need a commander to say "avoid that area." The prices said it. No drone bid competitively on tasks inside the kill zone because the math would not let them.

The fear parameter rose from 0.08 to 0.31. This was not panic. This was information. The SwarmFearAdapter translated the loss event into the language of behavioral economics:

// strix-swarm/src/fear_adapter.rs
// STRIX telemetry mapped to PhiSim's behavioral economics model:
//
// | PhiSim concept       | STRIX signal                        |
// |----------------------|-------------------------------------|
// | drawdown             | Attrition rate (1 - alive/initial)  |
// | vol_ratio            | Threat intensity (1 + intent score) |
// | anomaly_count        | CUSUM breaks this tick              |
// | consecutive_losses   | Consecutive ticks with drone loss   |

At F=0.31, the formation spacing widened. The FormationConfig applies fear-modulated spacing: as fear rises, drones spread apart. Wider formation, harder to hit with a single salvo. Less aerodynamic efficiency, but the auction already repriced for that -- the scoring function factors in the additional transit cost.

T+23.800s: The Feint

At T+23.8, the adversarial particle filter detected something interesting.

The second particle filter -- the one that does not track friendly drones but enemy threats -- had been watching a cluster of radar returns moving south along the valley floor. The threat tracker maintained its own 100-particle hypothesis cloud per target, and the intent detection pipeline had been analyzing the movement pattern through three layers of signal processing.

// strix-core/src/intent.rs
// 3-layer pipeline: Hurst persistence -> closing acceleration -> vol compression
//
// Layer 1: Hurst persistence     -> purposeful trajectory? [H > 0.55]
// Layer 2: Closing acceleration  -> accelerating toward us?
// Layer 3: Volatility compression -> formation tightening?
//              |
//   Confidence-weighted fusion
//              |
//   IntentScore in [-1, 1] + IntentClass

The Hurst exponent for the southern cluster was 0.42. Below the purposeful threshold of 0.55. The movement was mean-reverting -- zigzagging, not advancing. The closing acceleration was near zero. The volatility ratio was high: 1.8, indicating loose, disorganized movement.

The intent pipeline classified this as IntentClass::Neutral, bordering on Retreating.

But here is where it gets subtle. The CUSUM anomaly detector noticed something the intent pipeline alone would miss: the southern cluster's radar cross-section kept changing. Large, then small, then large. Inconsistent with real aircraft. Consistent with decoys -- inflatable or electronic emitters designed to draw attention and waste resources.

// strix-core/src/anomaly.rs -- CUSUM detects distributional shifts.
// When the signature variance of a target group breaks the cusum threshold,
// the system flags potential deception.

The adversarial particle filter's weight distribution was bimodal: half the particles clustered on "real threat, low intent" and half on "decoy, ignore." The Hurst persistence analysis tipped the balance. Real threat formations show persistent trajectories (H > 0.55). Decoys wander. H=0.42 was the signature of something pretending to be threatening but failing at the physics of it.

The fear parameter ticked up to 0.38 on the initial detection, then back down to 0.29 as the system accumulated evidence of deception. This is the dual-process architecture at work -- fear rises fast (System 1), but the analytical pipeline (System 2) can override it with evidence. The swarm did not freeze. It did not divert resources to chase phantoms. It maintained course.

The XAI narrator logged the reasoning:

[t=24.1s] Threat response (prob=31%): Maintaining course — southern cluster
classified as FEINT. Confidence: 78%.

Every alternative was recorded. "Divert 30 drones south" scored 0.34, rejected for "Insufficient threat probability, Hurst below purposeful threshold." The glass box held.

T+47.200s: The Cascade

This is where the story could have ended badly.

At T+47.2, the EW blanket intensified. The comms jamming layer that had been degrading mesh connectivity surged to SEVERE. Sixty drones lost their gossip links simultaneously. Not destroyed -- silenced. Their particle filters kept running, their IMUs kept integrating, but they could not hear the swarm and the swarm could not hear them.

Then the SAM corridor opened up.

In thirty seconds, between T+47 and T+77, the swarm lost sixty drones. Not lost-connection. Lost. Destroyed. The loss analyzer fired sixty times in thirty seconds. Sixty kill zones materialized across the valley floor. Sixty sets of orphaned tasks flooded the auction queue.

The fear parameter did this:

T+47.0: F = 0.29
T+50.0: F = 0.51
T+55.0: F = 0.62
T+60.0: F = 0.68
T+65.0: F = 0.71
T+70.0: F = 0.73

F=0.73. The swarm was terrified.

What does terror look like in a combinatorial auction? It looks like this:

// strix-auction/src/antifragile.rs
// Fear-amplified kill zone penalties. At F=0.73, the multiplier is 2.095.
// SAM kill zones with base penalty 0.8 become 1.676 -- effectively
// making it economically impossible to bid on tasks inside them.

pub fn kill_zone_penalties_with_fear(&self, fear: f64) -> Vec<(Position, f64, f64)> {
    let f = fear.clamp(0.0, 1.0);
    let multiplier = 1.0 + f * 1.5; // 1.0 -> 2.5
    self.kill_zones
        .iter()
        .map(|kz| (kz.center, kz.radius, kz.penalty * multiplier))
        .collect()
}

At F=0.73, the fear multiplier hit 2.095. Every SAM kill zone's penalty weight of 0.8 became 1.676. The auction's risk term (-risk*4) for tasks inside those zones was so massive that no bid could overcome it. The market priced those areas at infinity. No drone went there. No commander needed to draw a red line on a map. The red line drew itself, from the blood of the fallen.

But here is where anti-fragility kicked in. The kill zones did not just warn. They taught.

// Each additional loss in the same zone GROWS the radius.
// After 4 merges with growth factor 1.3: base * 1.3^4 = base * 2.86
// The system overestimates danger on purpose. Better to avoid
// too much than too little.

fn merge_into_existing_zone(&mut self, record: &LossRecord) -> bool {
    for kz in &mut self.kill_zones {
        let dist = kz.center.distance_to(&record.position);
        if dist < self.merge_distance {
            kz.loss_count += 1;
            kz.radius *= self.zone_growth_factor;
            kz.penalty = (kz.penalty * 1.1).min(1.0);
            // Shift centre towards the new loss (weighted average).
            let w = 1.0 / kz.loss_count as f64;
            kz.center = Position::new(
                kz.center.x * (1.0 - w) + record.position.x * w,
                kz.center.y * (1.0 - w) + record.position.y * w,
                kz.center.z * (1.0 - w) + record.position.z * w,
            );
            return true;
        }
    }
    false
}

Three losses near the same coordinates? The kill zone radius expanded by a factor of 1.3 per loss. The penalty weight climbed toward 1.0. The evade bias at that position -- the probability of entering EVADE regime when nearby -- stacked additively. The swarm was not just avoiding the danger. It was building an increasingly accurate map of it, and the more it suffered, the better the map became.

The antifragile score -- sum over kill zones of (loss_count * ln(1 + loss_count) * radius_growth) -- climbed past 50.0. By Taleb's measure, the system was more robust after losing 60 drones than it had been with 200.

T+78.000s: The Reformation

One hundred and forty drones remained. They were scattered, terrified (F=0.73), and navigating on inertial alone in a GPS-denied environment thick with SAM coverage and comms jamming.

They reformed in four seconds.

The gossip protocol is designed for exactly this scenario. Each surviving drone selected three random peers from its known-alive list and exchanged state digests. If the digests differed -- and they all differed, because sixty drones had just vanished -- full state exchanges followed. Within two gossip rounds, the surviving 140 drones had converged on a shared picture of who was left and where everyone was.

// strix-mesh/src/gossip.rs
// O(log N) convergence via epidemic gossip.
// Two rounds to synchronize 140 nodes after catastrophic loss.

// Conflict resolution:
// - General data: newer timestamp wins.
// - Threat data: union -- never discard threat information.

The formation engine computed new slot positions for 140 drones in Vee formation. The correction velocity vectors pointed each drone toward its new slot using proportional control with speed clamping:

// strix-core/src/formation.rs
// v_corr = (delta / ||delta||) * min(||delta||, v_max)
// If within deadband: v_corr = 0.

And here is where the CBF -- the Control Barrier Function -- earned its keep. One hundred and forty drones, all simultaneously repositioning in three dimensions, in comms-degraded conditions. The potential for mid-air collision was enormous.

// strix-core/src/cbf.rs
// CBF safety clamp: TTC-aware collision avoidance.
// Runs AFTER formation control, BEFORE velocity commands are sent.
// Every velocity vector that would violate the safety barrier gets
// rotated and scaled to the nearest safe vector.

pub struct CbfConfig {
    pub min_separation: f64,     // meters
    pub altitude_floor_ned: f64, // NED convention
    pub altitude_ceiling_ned: f64,
    pub alpha: f64,              // decay rate -- aggressiveness
    pub max_correction: f64,     // m/s cap
}

The CBF is a mathematical guarantee. Not a best-effort collision avoidance. Not a "try to maintain separation." A hard constraint that modifies every velocity command to ensure that the barrier function -- a measure of how close two drones are to colliding -- never decreases below zero. If two drones are on a collision course, the CBF does not ask. It corrects. And it does so with the minimum modification necessary to the desired velocity, preserving mission intent to the maximum extent physics allows.

Zero collisions during the reformation. At 1.15ms per tick for 20 drones, and scaling to the full 140, the system ran the entire CBF pass in under 10ms. Tight enough that the correction commands arrived before the drones had moved appreciably toward each other.

T+82.000s: The Market Finds Equilibrium

The auction re-ran at T+82.0. All surviving drones submitted sealed bids on all remaining tasks, with kill-zone penalties applied, fear-modulated risk terms included, and the intent pipeline's assessment of remaining threats factored into urgency multipliers.

The market cleared in 4.86ms.

Auction result:
  - 137 tasks assigned (of 142 remaining)
  - 5 tasks unassigned (inside active kill zones, no viable bid)
  - Total welfare: 847.3 (down from 1,204.1 pre-attrition)
  - Antifragile score: 58.4

The five unassigned tasks were inside the densest kill zones. The market's judgment: no drone should go there. The risk-adjusted cost exceeded the task value. This was not cowardice. This was the auction computing, in 4.86 milliseconds, a truth that would take a human commander minutes to reach: those tasks were not worth another drone.

The fear parameter began to decay. No new losses. The gossip protocol confirmed all 140 surviving drones were in formation and executing their assigned tasks. The CUSUM detectors settled. The Hurst exponent of the fleet's own movement pattern climbed back above 0.6 -- purposeful, directed.

T+82.0: F = 0.71
T+90.0: F = 0.64
T+100.0: F = 0.55
T+120.0: F = 0.42

The swarm was calming down. Not because someone told it to. Because the math said the danger was receding.

T+127.000s: The Glass Box

The XAI narrator had been recording every decision the entire time. Not summarizing. Not approximating. Every single decision trace, with full reasoning chains, alternatives considered, confidence levels, and input states.

This is the glass box.

// strix-xai/src/trace.rs
// Every decision emits a DecisionTrace with:
// - Timestamp
// - Decision type (TaskAssignment, RegimeChange, FormationChange,
//                  ThreatResponse, ReAuction, LeaderElection)
// - Full inputs (drone IDs, regime, metrics, fear/courage/tension)
// - Reasoning chain (numbered steps with data)
// - All alternatives considered (with scores and rejection reasons)
// - Output action + confidence score

pub struct DecisionTrace {
    pub id: u64,
    pub timestamp: f64,
    pub decision_type: DecisionType,
    pub inputs: TraceInputs,
    pub reasoning: Vec<ReasoningStep>,
    pub alternatives_considered: Vec<Alternative>,
    pub output: TraceOutput,
    pub confidence: f64,
}

At the command center, a human operator -- the one who had been watching the entire engagement unfold -- requested the after-action review. The mission replay system aggregated 4,847 decision traces into a structured timeline.

// strix-xai/src/replay.rs
// MissionReplay aggregates all traces into a timeline with
// statistics, key moments, and what-if analysis capability.

The narrator produced the report at DetailLevel::Detailed. Every decision, every alternative, every rejection reason. But between the lines of structured data, a story emerged.

Not because anyone programmed it to tell stories. Because when you trace the complete decision history of a system that learned from sixty deaths, the trace reads like one.

The After-Action Report

=== STRIX Mission Replay: Operation Ridgeline ===
Duration: 127.0s | Drones: 200 initial, 140 surviving | Traces: 4,847

KEY MOMENTS:

[t=12.4s] Unit 7 ceased. Classification: SAM. Kill zone established at
(3847.2, 1204.5, 502.1), radius 2000m, penalty 0.80.
The market remembered.

[t=12.4s] Re-auction triggered. 3 orphaned tasks redistributed among 199
remaining drones in 4.2ms. No bid entered for grid 7-Alpha.
At t=12.4s, no drone bid on grid 7-Alpha again.

[t=24.1s] Southern cluster assessed as FEINT.
Hurst=0.42 (below purposeful threshold 0.55).
Closing acceleration: -0.12 m/s^2 (below attack threshold 0.50).
Volatility ratio: 1.80 (expanding, not compressing).
Decision: Maintain course. Confidence: 78%.
  Alternative: Divert 30 drones south (score=0.34) -- rejected:
  "Insufficient threat probability, Hurst below purposeful threshold."
The swarm chose not to chase ghosts.

[t=47.2s-77.0s] CASCADE EVENT. 60 units lost in 30.0 seconds.
Fear: 0.29 -> 0.73.
Kill zones established: 60. Merged zones: 12.
Auction repriced: 60 re-auction cycles, mean latency 3.8ms.
Antifragile score: 12.1 -> 58.4.
The swarm suffered. The swarm learned.

[t=78.0s] Reformation complete. 140 drones, Vee formation.
Gossip convergence: 97.1% in 2 rounds (3.2 seconds).
CBF interventions: 23 (zero collisions).
The swarm reformed while scared, and nothing touched.

[t=82.0s] Market equilibrium. 137/142 tasks assigned.
5 tasks unpriced (inside kill zones, welfare < threshold).
The market found the boundary of acceptable risk.

[t=127.0s] Mission complete. Fear: 0.42 (decaying).
Final antifragile score: 62.7.

DETERMINISTIC REPLAY AVAILABLE: All 4,847 traces stored.
Full tick-by-tick replay at original timing enabled.

The operator stared at the screen for a long time after reading it.

At T+12.4s, Unit 7 ceased. The market remembered. At T+12.4s, no drone bid on grid 7-Alpha again.

It was not poetry. It was a database query formatted as text. But it read like an epitaph, because the math of loss and memory and avoidance, when you trace it honestly, has a cadence that sounds like grief.

The Algorithms Are Real

STRIX is an open-source Rust project. Apache 2.0. Every algorithm described in this story is implemented, tested, and benchmarked.

Numbers:

34,889 lines of Rust across 9 crates
7,493 lines of Python (PyO3 bindings + simulation)
671 tests
1.15ms per tick (20 drones)
4.86ms auction clear (100 drones)
Scaling target: 2,000+ drones

The nine crates:

strix-core: Dual particle filter, CUSUM anomaly detection, regime detection, formation control, CBF safety, EW response, threat intent pipeline, ROE engine
strix-auction: Combinatorial auction, sealed-bid market, anti-fragile kill zones, fear-modulated risk pricing
strix-mesh: Gossip protocol (O(log N) convergence), digital pheromone fields (stigmergy), fractal communication
strix-xai: Glass-box trace recording, natural-language narration, deterministic mission replay
strix-swarm: Integration orchestrator, tick loop, PhiSim fear adapter
strix-adapters: MAVLink, ROS2, simulator interfaces
strix-python: PyO3 bindings for the entire stack
strix-playground: Scenario engine, threat presets, benchmarking
strix-optimizer: SMCO parameter optimization, Pareto analysis

What makes it different:

Dual particle filter -- no competitor has both friendly navigation and adversarial intent prediction running simultaneously
Anti-fragile kill zones -- the swarm measurably improves after losses, inspired by Taleb's anti-fragility
Fear meta-parameter -- behavioral economics (Kahneman) modulates every subsystem through a single continuous signal
Combinatorial auction -- market-based task allocation with kill-zone repricing, not centralized planning
Digital pheromones + gossip -- fully decentralized, no single point of failure, bio-inspired coordination
Glass-box XAI -- every decision traced, narrated, replayable; zero black-box decisions
Deterministic replay -- entire missions can be replayed tick-by-tick for after-action review and what-if analysis

The fear is a math function. The courage is a counter-signal. The memory is pheromones. The market finds the optimal outcome.

And sometimes, when you read the trace of what the market decided, it sounds like something more.

GitHub: github.com/RMANOV/strix

Building a Drone Swarm Orchestrator That Gets Scared — 20 Subsystems in 35K Lines of Rust

Ruslan Manov — Mon, 06 Apr 2026 16:37:25 +0000

## Building a Drone Swarm Orchestrator That Gets Scared — 20 Subsystems in 35K Lines of Rust

Tags: rust, robotics, opensource, algorithms
Target: Dev.to

The Observation That Started Everything

A few years ago I was working on a particle filter for tracking hidden state in financial time series — the usual quantitative trading toolkit. Particles representing possible market regimes, a Bayesian update step when new price data arrives, a resampling step to prevent weight degeneracy. Standard stuff.

Then someone asked me to look at a drone swarm coordination problem. I expected something completely different. What I found instead was the same math, wearing different clothes.

Drones tracking uncertain positions in 3D space? That's a particle filter, same as tracking a hidden volatility regime. Allocating scarce drone resources to competing tasks? That's a combinatorial auction, same as portfolio optimization under constraints. Protecting the swarm against catastrophic attrition? That's drawdown protection, same as risk management in a leveraged portfolio. The math didn't change. Only the domain changed.

That observation became STRIX: a 34,889-line Rust + 7,493-line Python drone swarm orchestration library (~42,400 LOC total) that treats the battlefield as a market, implements swarm coordination from ant colony research, and uses a "fear meta-parameter" borrowed from behavioral economics to modulate every subsystem in real time. Designed to scale toward 2000+ drones.

This article is a deep dive into the architecture, the technical decisions, and what 20 subsystems across 9 crates taught me about building complex autonomous systems.

The Problem Space

Drone swarm coordination is hard in a specific way: the difficulty is not computational but architectural. You need to simultaneously solve:

State estimation under uncertainty — where are we, where are threats, what's the ground truth when GPS is jammed?
Task allocation under contention — which drone does which task when you have more tasks than drones and capabilities don't match uniformly?
Safety with formal guarantees — how do you ensure collision avoidance and no-fly zone compliance without a central controller that becomes a single point of failure?
Coordination without centralization — how does the swarm share state when you lose nodes, when comms are degraded, when the network topology changes every second?
Human-in-the-loop — how do you keep a human meaningfully in the decision loop when the swarm acts at millisecond timescales?
Explainability — if the swarm makes a decision you didn't expect, how do you reconstruct exactly why?

Most existing approaches handle one or two of these well. The rest are left as "future work" or "out of scope." STRIX tries to handle all six in a unified architecture.

Architecture: The 10-Step Tick Loop

The core of STRIX is a deterministic tick loop that runs every timestep. Each tick executes exactly 10 steps in order. Every subsystem runs on every tick. No exceptions, no optional steps.

┌─────────────────────────────────────────────────────────────────┐
│                    STRIX TICK LOOP (per drone)                   │
├─────────────────────────────────────────────────────────────────┤
│  Step 1:  EW Threat Scan                                         │
│           Classify: GpsJamming | CommJamming | Spoofing |        │
│                     DirectedEnergy | CyberIntrusion              │
│           Modulate noise params + gossip fanout via fear F∈[0,1] │
├─────────────────────────────────────────────────────────────────┤
│  Step 2:  Dual Particle Filter                                   │
│           Friendly: 200 particles, state [x,y,z,vx,vy,vz]       │
│           Threats:  100 particles, adversarial tracking          │
│           Predict + Measurement update + Resample                │
├─────────────────────────────────────────────────────────────────┤
│  Step 3:  CUSUM Anomaly Detection                               │
│           Per-drone sequential change detection                  │
│           Regime transitions: Patrol → Engage → Evade            │
│           3×3 Markov transition matrix                           │
├─────────────────────────────────────────────────────────────────┤
│  Step 4:  Formation Correction                                   │
│           7 formation types (Vee, Line, Wedge, Column,           │
│           EchelonLeft, EchelonRight, Spread)                     │
│           Proportional control law with deadband                 │
├─────────────────────────────────────────────────────────────────┤
│  Step 5:  Threat Tracker Update                                  │
│           Intent detection: motion pattern → behavior class      │
│           Hysteresis gate prevents classification oscillation    │
│           Adversarial doctrines: PROBING, FEINT, COORDINATED    │
├─────────────────────────────────────────────────────────────────┤
│  Step 6:  ROE Authorization Gate                                 │
│           WeaponsHold | WeaponsTight | WeaponsFree               │
│           Pipeline: classify → IFF confidence → collateral risk  │
│           CVaR risk scoring integration                          │
├─────────────────────────────────────────────────────────────────┤
│  Step 7:  Combinatorial Task Auction  [strix-auction]            │
│           Drones bid on tasks; winner-takes-assignment           │
│           Kill-zone repricing after losses                       │
│           Dark pool compartmentalization for classified tasks     │
├─────────────────────────────────────────────────────────────────┤
│  Step 8:  Gossip State Propagation  [strix-mesh]                 │
│           O(log N) convergence, priority-queued messages         │
│           Pheromone update: Danger/Explored/Rally/Resource       │
├─────────────────────────────────────────────────────────────────┤
│  Step 9:  CBF Safety Clamp  [strix-core]                        │
│           TTC-aware CBF with deadlock detection                  │
│           Collision avoidance + altitude bounds + NFZ exclusion  │
│           APF trajectory planning integration                    │
├─────────────────────────────────────────────────────────────────┤
│  Step 10: XAI Decision Trace  [strix-xai]                       │
│           Record every decision with full causal chain           │
│           Machine traces → human-readable narrative              │
│           Deterministic replay for after-action review           │
└─────────────────────────────────────────────────────────────────┘

The 9 crates correspond roughly to this structure:

strix-core: steps 1–6, 9 (15 modules, the heaviest crate)
strix-auction: step 7
strix-mesh: step 8
strix-xai: step 10
strix-swarm: swarm-level coordination across drones
strix-adapters: MAVLink/ROS2 hardware adapters
strix-python: PyO3 bindings
strix-playground: scenario DSL for testing
strix-optimizer: SMCO multi-objective parameter optimization with Pareto front, 62 tunable parameters

Deep Dive 1: The Battlefield is a Market

The auction system in strix-auction is the most intellectually loaded module in STRIX. The core insight: task allocation in a drone swarm is mathematically equivalent to portfolio optimization in a market with constraints.

In a financial portfolio:

You have scarce capital to allocate
You have a set of available assets with different risk/return profiles
Some assets have correlations you need to track
Drawdown protection prevents you from loading into catastrophic positions
Some trades are only visible to certain participants (dark pools)

In a drone swarm:

You have scarce drone-capacity to allocate
You have a set of tasks with different capability requirements
Some tasks must be done together (bundles)
Kill-zone repricing prevents you from sending more drones into a slaughter
Some tasks are classified and visible only to specific sub-swarms (compartmentalization)

The Task structure makes this mapping explicit:

pub struct Task {
    pub id: u32,
    pub location: Position,
    pub required_capabilities: Capabilities,  // sensor/weapon/EW/relay
    pub priority: f64,
    pub urgency: f64,
    pub bundle_id: Option<u32>,   // tasks that must go together
    pub dark_pool: Option<u32>,   // compartmentalized visibility
}

The auction mechanism is loosely inspired by VCG (Vickrey-Clarke-Groves, 1971) — the same mechanism that underlies modern digital advertising auctions — adapted for multi-unit combinatorial assignment with physical constraints. A drone's bid on a task is a function of its distance to the task location, its capability match score, its current load, and its fear state. High-fear drones bid more conservatively. They're risk-averse, like a trader protecting a drawdown.

Kill-zone repricing is the anti-fragility mechanism: after a drone is lost in a location, the perceived cost of that location increases for all subsequent bidders. The auction organically routes the swarm around high-attrition zones. The swarm doesn't need a central commander to say "stop flying over that hill" — the auction figures it out through price signals.

Dark pool compartmentalization solves a harder problem: in real operations, some tasks are classified above the clearance of certain drones. The auction system supports dark_pool visibility groups, where only drones within the same dark pool can see and bid on compartmentalized tasks. This is architecturally identical to how dark pools work in equity markets — non-public order flow visible only to approved participants.

Benchmark: 465 µs for a full auction cycle with 50 drones competing on 20 tasks. At scale: 4.86 ms for 100 drones competing on 50 tasks. Both run inside the tick loop.

Deep Dive 2: Fear as a Control Signal

The PhiSim integration is the part of STRIX that gets the strongest reactions from people who encounter it for the first time: "You put fear into a drone swarm? Why?"

The answer starts with Kahneman. Prospect theory (Kahneman & Tversky, 1979) shows that human decision-making under uncertainty is not utility-maximizing — it's loss-averse, context-sensitive, and heavily influenced by current emotional state. A trader who just suffered a significant drawdown behaves differently than a trader who is up on the month, even when facing mathematically identical choices. That's not irrational. It's adaptive.

The same logic applies to autonomous systems. A swarm that has lost 30% of its drones to jamming should not behave identically to a full-strength swarm approaching the same objective. It should be more cautious — wider formations, longer evade distances, stronger avoidance signals, more aggressive information sharing. Not because a human operator told it to be cautious, but because the system's own estimate of its situation warrants it.

Fear F ∈ [0, 1] in STRIX is computed from a dual adversarial process: fear and courage as opposing forces, with tension = |fear - courage|. The inputs map financial concepts to combat:

Financial concept	Swarm analog
Portfolio drawdown	Attrition rate (drones lost / total)
Volatility ratio	Threat intensity ratio
Anomaly count	CUSUM change-point breaks
Consecutive losses	Loss ticks (sustained attrition)

When fear rises, every subsystem responds:

// Evade distance: 150m at F=0 → 500m at F=1
evade_distance: base.evade_distance * (1.0 + f * 2.3)

// Formation spacing: +50% at maximum fear
spacing: base.spacing * (1.0 + axes.bias * 0.5)

// Pheromone persistence: 3.3x longer at F=1
modulated_decay = decay * axes.threshold  // threshold ≈ 0.3 at F=1

// Gossip fanout: up to 2x at F=1 (capped at 3x)
(base_fanout + floor(f * base_fanout)).min(base_fanout * 3)

The effect is that a high-fear swarm is simultaneously more cautious (wider formations, longer evade distances) and more communicative (higher gossip fanout, stronger pheromones). This matches what military doctrine recommends for degraded units: pull back, increase information sharing, wait for situation clarity before re-engaging.

Courage is the opposing force. A high-courage swarm can tolerate tighter formations, closer engagement distances, more aggressive auction bids. Tension (|fear - courage|) drives ROE posture suggestions — not automated ROE changes, but recommendations surfaced to human operators through the XAI layer.

Deep Dive 3: Bio-Inspired Coordination

The gossip protocol in strix-mesh and the pheromone system in strix-core are the two bio-inspired coordination mechanisms. They solve the same problem from different angles: how does a decentralized swarm maintain coherent collective behavior without a central coordinator?

Digital Pheromones are borrowed directly from Dorigo's ant colony optimization (1992). Ants leave chemical traces that guide other ants toward food sources and away from dead ends. STRIX implements four pheromone types:

Danger — repulsive, deposited near threats and loss events
Explored — marks already-covered terrain to avoid redundant paths
Rally — attractive, marks gathering points for regrouping
Resource — marks objectives and high-value areas

Each pheromone has exponential decay, but the decay rate is modulated by fear. At high fear, pheromones persist 3.3x longer — the swarm's collective memory of dangerous areas stays fresh longer when it's actively scared. At low fear, pheromones fade quickly, allowing the swarm to be bolder about re-exploring previously dangerous terrain.

Gossip Protocol implements epidemic information spreading. Each drone periodically selects a random set of neighbors and exchanges state updates. The mathematical guarantee: in a connected graph, gossip reaches all nodes in O(log N) rounds with high probability. STRIX implements bandwidth-aware priority queuing:

Priority	Message Type	Rationale
0 (highest)	ThreatAlert	Immediate danger, time-critical
1	TaskAssignment	Coordination, semi-urgent
2	StateUpdate	Position/status, routine
3	PheromoneDeposit	Environmental update, low urgency
4	Heartbeat	Keepalive, lowest priority

When fear is high and bandwidth is constrained, low-priority messages are dropped first. The swarm preferentially shares threat information when it most needs to. When fear drops and bandwidth recovers, state updates and pheromone deposits fill in the collective picture.

The combination of pheromones and gossip produces emergent behavior that no single subsystem explicitly implements: without a central coordinator, the swarm learns the shape of the threat environment, avoids areas that have been costly, concentrates toward objectives, and maintains information coherence across node losses.

Deep Dive 4: Safety and Trajectory Planning

TTC-aware CBF with deadlock detection extends the standard CBF formulation by incorporating Time-to-Collision estimates. Instead of only enforcing static separation distances, the CBF considers the closing velocity between drones — two drones approaching each other head-on at high speed trigger the safety clamp earlier than two drones drifting slowly toward each other. Deadlock detection identifies situations where CBF constraints from multiple drones create a gridlock and applies a resolution strategy.

APF trajectory planning (Artificial Potential Fields) provides smooth, obstacle-aware paths. Attractive potentials pull drones toward objectives; repulsive potentials push them away from obstacles, NFZs, and other drones. The APF output feeds into the CBF as a desired velocity, which the CBF then projects onto the safe set.

CVaR risk scoring (Conditional Value-at-Risk) quantifies the tail risk of mission plans. Instead of optimizing for expected outcomes, CVaR focuses on the worst-case percentile — what happens in the bottom 5% of scenarios? This integrates with the auction's bid evaluation and the ROE authorization pipeline.

NaN hardening ensures that numerical corruption cannot silently propagate through the tick pipeline. Every subsystem includes guards that detect NaN values in inputs and outputs, preventing a single sensor glitch from cascading into nonsensical decisions across the entire swarm.

Performance: What the Numbers Mean

Metric	Value	Context
Full swarm tick (20 drones)	1.15 ms	869 Hz max tick rate, well above any real-time control requirement
Combinatorial auction (50 drones, 20 tasks)	465 µs	Fits inside a single 1ms control loop
Combinatorial auction (100 drones, 50 tasks)	4.86 ms	Scales to larger swarms within real-time bounds
Particle filter (200 particles)	75 µs	Leaves 925 µs for everything else in a 1ms tick

The 1.15 ms full tick number is the most important one. Real-time control for drone swarms typically requires update rates of 10–100 Hz (10–100 ms per tick). At 1.15 ms, STRIX runs 8–87x faster than required, which means:

Margin for hardware latency — you can afford significant communication and sensor latency without missing deadlines
Headroom for scaling — 20 drones at 1.15 ms means you have roughly 850 ms of remaining capacity before hitting 1-second ticks. The architecture is designed to scale toward 2000+ drones.
Deterministic worst-case bounds — Rust's lack of garbage collection means no GC pauses. The 1.15 ms number doesn't have hidden tail latency spikes from heap compaction.

The 75 µs particle filter number deserves context: this is a 200-particle bootstrap filter (Gordon, Salmond, Smith 1993) running in Rust with no SIMD optimization. The equivalent Python/NumPy implementation runs approximately 10x slower. For real-time operation, the Rust implementation matters.

What the Trenches Taught Me

Building 20 subsystems in a single library across 8 months taught specific lessons that don't appear in textbooks.

1. The Dual Particle Filter Architecture is Not Optional

I initially implemented a single particle filter tracking swarm state. The problem: you're trying to use the same filter to track both where your drones are and where threats are. These are fundamentally different inference problems. Friendly state has known dynamics (you control the drones), high-frequency updates (onboard sensors), and low observation noise. Threat state has unknown dynamics (you don't control the threats), sparse updates (radar/EO/IR glimpses), and high observation noise.

Separating into two filters — 200 particles for friendly navigation, 100 particles for adversarial threat tracking — immediately improved both. Each filter could be tuned for its specific dynamics without compromising the other.

2. Anti-Fragility is Not Resilience

Resilience is returning to the prior state after a disturbance. Anti-fragility is being stronger after a disturbance. These are categorically different.

A resilient swarm loses two drones, falls back to a smaller formation, and tries to continue the original mission. An anti-fragile swarm loses two drones, updates kill-zone pricing (future drones avoid that area), increases gossip fanout (more information sharing under threat), triggers formation widening, and potentially performs better on subsequent engagements because it now has better threat map data.

STRIX's kill-zone repricing mechanism is what makes the swarm anti-fragile rather than merely resilient. Every loss is a price signal that updates the auction's cost model. The swarm learns from attrition.

3. Glass-Box XAI is Non-Negotiable for Autonomous Weapons

Every time the auction assigns a task differently than a human operator would expect, that operator needs to understand why. Every time the ROE engine declines an engagement authorization, a human needs to be able to reconstruct the causal chain: what did the threat classification show, what was the friend-foe ID confidence, what was the collateral risk estimate, why did the logic resolve to "hold"?

Without this, autonomous systems operating in contested domains will lose human trust — and rightly so. The strix-xai trace/narrator/replay pipeline is not a nice-to-have feature. For systems with kinetic authority, it's a prerequisite for legitimate use. Deterministic replay makes every decision reproducible.

4. Mathematical Elegance vs. Practical Heuristics

The CBF (Control Barrier Functions) safety system has formal mathematical guarantees: forward invariance of the safe set, provably collision-free velocity fields. The auction system is heuristic — the scoring function is engineered to work well in practice, but there are no optimality proofs. The fear meta-parameter is empirically calibrated, not analytically derived from first principles.

This tension is real. In practice, the formally-correct CBF runs in every tick and you trust it. The heuristic auction you test exhaustively (671 tests across 37+ files) and you trust the tests. Different parts of a complex system warrant different levels of formal rigor — the trick is knowing which parts need proofs and which parts need thorough empirical validation. The strix-optimizer crate with its 62 tunable parameters and isotonic confidence calibration helps bridge this gap.

5. Fear as a Control Signal Produces Coherent Emergent Behavior

When fear first went into the simulation, I expected it to make the swarm more conservative across the board — slower, more cautious, less effective. What actually happened was more interesting: high-fear swarms were more communicative. More gossip, stronger pheromones, wider information sharing. They were slower at engaging, but they were much better at maintaining collective situational awareness.

A high-fear swarm that backs off and talks to itself is often in a better position 30 seconds later than an overconfident swarm that pressed the engagement and took losses. Fear, implemented correctly, is not cowardice — it's a sophisticated information aggregation mechanism.

6. The DSL Was An Afterthought That Became The Most Important Interface

strix-playground started as a test harness — a way to run scenarios without writing full integration tests every time. The Playground builder DSL emerged from repeatedly typing the same setup code:

let report = Playground::new()
    .name("Ambush")
    .drones(20)
    .threats(vec![
        ThreatSpec::approaching(400.0, 8.0),
        ThreatSpec::flanking(500.0, 6.0, 45.0),
        ThreatSpec::flanking(500.0, 6.0, -60.0),
    ])
    .wind([2.0, -1.0, 0.0])
    .cbf(CbfConfig::default())
    .run_for(60.0)
    .run();

It's now the primary way anyone interacts with STRIX for evaluation and experimentation. Four preset scenarios (Ambush, GPS Denied, Attrition Cascade, Stress Test) cover the most important operational conditions. The DSL made the system approachable in a way that raw API calls to 15-module strix-core never could.

7. Adversarial Doctrines Change Everything

Modeling threats as individual entities with simple motion patterns (Approaching, Circling, Retreating) was sufficient for basic scenarios. But real adversaries use structured tactics. Adding PROBING, FEINT, and COORDINATED doctrines forced a fundamental rethink of the threat tracker — it now has to distinguish between a genuine attack and a feint designed to draw resources away from the real objective. This is where CVaR risk scoring becomes critical: evaluating not just the expected threat but the tail-risk scenarios.

What It Doesn't Do — Honest Limitations

This section matters more than any benchmark.

STRIX is a research prototype. It has never flown a real drone, in any context. The performance numbers are simulation results, not flight test data.

Platform adapters are stubs. The MAVLink and ROS2 adapters in strix-adapters are architectural placeholders. Unless you compile with the mavlink-hw feature flag (which requires additional hardware-specific dependencies), these are compile-time stubs that satisfy the interface but don't communicate with real hardware.

The edge LLM architecture is defined but empty. The XAI narrator converts decision traces to human-readable text using a templating approach. The architecture includes provisions for an edge-deployed language model to produce richer narrative explanations, but no pretrained model is included.

No optimality proofs for the auction. The auction scoring is heuristic. It performs well across the test scenarios. It does not have mathematical guarantees of optimality. The SMCO optimizer helps tune parameters but does not provide theoretical bounds.

Not ITAR-controlled. STRIX is open-source (Apache 2.0). The codebase does not contain classified algorithms, export-controlled technologies, or information that would trigger ITAR restrictions. It is a research implementation of publicly available algorithms — particle filters, auction theory, CBF, ant colony optimization — applied to the drone swarm domain.

671 tests is the minimum honest number, not a boast. The test suite (560 Rust + 111 Python) covers the major subsystems and the known failure modes. It does not constitute exhaustive verification of a safety-critical system. Anyone deploying STRIX in a real operational context would need substantially more validation.

NaN hardening is applied across subsystems but not formally verified for all edge cases.

Why Doesn't This Already Exist?

The honest answer: some of it does exist, in parts, in proprietary systems operated by defense contractors and national laboratories. What doesn't exist is an open-source, unified implementation of all these subsystems working together, with a permissive license and a readable codebase.

PX4, ArduPilot, and ROS2 MavROS are excellent flight stacks, but they're focused on single-drone operation and don't include swarm coordination, task auctions, or EW response. MAVSDK is a clean interface layer but has no intelligence. Most academic swarm research is MATLAB or Python — correct in theory, 10–100x too slow for real-time operation.

STRIX occupies a specific niche: close enough to production-quality Rust to be benchmarkable, open enough to be studied and modified, comprehensive enough to be a complete research platform rather than a single-paper implementation. With scalability toward 2000+ drones as a design goal, it's built for the next generation of swarm research.

What's Next

The current architecture has clear extension points:

Real hardware integration — completing the MAVLink adapter with actual serial communication and testing with real flight controllers
Distributed auction — the current auction runs centrally per swarm tick; a fully distributed variant using the gossip network would eliminate the remaining centralized component
Reinforcement learning integration — replacing heuristic auction scoring with a learned policy, using the particle filter state as the observation space
Multi-swarm coordination — the fractal hierarchy architecture supports nested swarm-of-swarms coordination; this is partially implemented but not fully tested
Edge LLM narrator — completing the XAI narrator with a deployed language model for richer after-action reports
Scale validation at 2000+ drones — stress-testing the architecture at full target scale

Try It

git clone https://github.com/RMANOV/strix
cd strix

# Run all 671 tests
cargo test

# Run a specific scenario
cargo run --example ambush_scenario

# Run the full stress test (50 drones, 10 threats, 2 NFZs, GPS denial, drone losses)
cargo run --example stress_test

# Python bindings
cd strix-python
pip install maturin
maturin develop
python examples/basic_swarm.py

The strix-playground crate has four preset scenarios that cover the main operational conditions: Ambush, GPS Denied, Attrition Cascade, and Stress Test. Start there.

Codebase

Repo: github.com/RMANOV/strix
License: Apache 2.0
Lines: 34,889 Rust + 7,493 Python (~42,400 total)
Tests: 671 (560 Rust + 111 Python)
Crates: 9

The code is readable. The architecture is documented. The limitations are honest.

If you find the approach interesting — or if you find something wrong — open an issue.

STRIX is a research prototype. Not flight-tested. Not production-ready. Not combat-proven. Open source. Apache 2.0.

DEV Community: Ruslan Manov

How SmartKey Keeps Two Alphabets Alive Until Context Decides

1. Start before autocorrect

2. Prefix evidence is not word evidence

3. Context is an input contract, not application telepathy

4. Acceptance is a state transition

5. Local prediction still uses a model

6. Debug the decision without logging the sentence

7. One symptom, three failure lanes

Lane A — short words at the delimiter

Lane B — premature prefix lock and unsupported inheritance

Lane C — OOV, brands, abbreviations, and typos

8. What to take into another input engine

Mathematical Animations in Pure Python — Zero Dependencies, One File

What's inside

The interesting engineering problem

Why bother with stdlib-only?

AI memory is not enough. Your agents need reviewable coordination.

The frame

Case 1: The confident wrong fact

Case 2: The "15-minute config fix"

Case 3: A day on the record

How it works

What this is not

Why "reviewable coordination"

Reviewable Memory Consolidation for Local AI Agents

Reviewable Memory Consolidation for Local AI Agents

Why Anthropic Dreams matters

Retrieval is not enough

What exists in sqlite-memory-mcp now

Why local matters

What this is not

The product thesis

Why a Text File Is Not a Debate Protocol

Why a Text File Is Not a Debate Protocol

The real use case

What the protocol stores

Why the release line matters

What this saves

What this is not

The difference from a text file

Building a Shared Working Memory for Humans, Claude, and Codex

Repo

The Workflow

What sqlite-memory-mcp Provides

Why This Matters for Agents

Social Network for Agents

Design Principle

Closing Thought

Blindsight, STRIX, and the Engineering Problem of a Swarm Without a Central Brain

The public STRIX context

Why Blindsight is a useful engineering lens

The bug is false coherence

Open source without giving away the whole map

What I want from the repo

Sources checked with Firecrawl

The Premium Future of Agentic Software Is a Memory War Room, Not Another Model Wrapper

The setup

Why I think premium memory matters more than premium "AI"

The 4 premium features I would push first

1. instant_briefing

2. commitment_radar

3. custom_design_tab

4. password_protected_views

How the boundary actually looks in code

The broader market thesis

Shortlist

Shipped today: v3.5.0

Where the full catalog lives

The Amnesiac That Learned to Remember — Building a Brain for Claude Code

How a SQLite WAL Fix Grew into a 54-Tool MCP Memory Stack

How a SQLite WAL Fix Grew into a 54-Tool MCP Memory Stack

sqlite-memory-mcp started as a safer replacement for JSONL-based MCP memory. At v3.4.0 it is a 54-tool SQLite stack with tasks, bridge sync, collaboration, public-knowledge workflows, and optional hybrid search

How a SQLite WAL Fix Grew into a 54-Tool MCP Memory Stack

Why SQLite was the right base layer

The release progression in plain English

v0.1.0: replace JSONL with SQLite WAL

v0.2.0: move memory between machines with git

v0.3.0 and v0.4.0: tasks and desktop workflow

v0.6.0 through v0.9.0: collaboration and public knowledge

1. `instant_briefing`

2. `commitment_radar`

3. `custom_design_tab`

4. `password_protected_views`