Vectr 1.1.0: Team Mode, and the Seven-Agent Test That Gated It

Vectr v1.0 solved a single-person problem. An AI code editor re-reads the same files every session, forgets everything the moment the conversation is compacted, and burns its context window re-discovering things it already worked out an hour ago. Semantic search plus persistent working memory fixed that, and Part 2 of this series is the long version of how. The catch is right there in the framing: one person, one machine.

Software isn't built by one person. Put ten engineers on the same repository and every one of their agents re-discovers the same architecture, re-learns the same gotchas, re-derives the same decisions — ten private caches of the identical knowledge, none of them shared. The working memory that makes a single agent effective is trapped per-machine. The obvious move is to put it on a shared server. The obvious move opens three holes v1.0 had no answer for.

First, a network-reachable daemon needs authentication. Localhost trust — the assumption that anything talking to the port is you — doesn't survive contact with a LAN. Second, notes are the single most sensitive thing an agent produces: not raw source, but distilled findings about your codebase, the parts an attacker would most want. Sitting at rest on a shared box, they need encryption. Third, a shared store needs accountability. Who stored what, who queried what, how long is any of it kept, and — the question that actually matters when someone asks — how do you delete it, completely, and prove you did.

Set VECTR_API_KEY and it guards both the REST routes and the MCP endpoint that the editor's model actually talks to. One route stays open on purpose: /v1/health, so a load balancer or a supervisor can check that the daemon is alive without holding the key. Everything else is closed.

The part worth dwelling on is how the key gets checked. The pre-existing comparison — written back when there was no key and nothing to compare — used a plain !=. That is a timing side channel. String inequality short-circuits at the first differing byte, so a key that is wrong on byte one comes back a hair faster than one wrong on byte ten, and an attacker who can measure that difference over enough requests can walk the key out one character at a time. The fix is hmac.compare_digest, which compares in constant time regardless of where the mismatch is.

Measuring byte-scale timing across a network is genuinely hard, and I'm not going to pretend someone was about to pull it off against a LAN daemon. But the correct comparison costs nothing, and shipping a known side channel because it's "probably not exploitable" is exactly the reasoning that ages badly.

# before — plain != short-circuits, leaking key length/position via timing
if provided_key != VECTR_API_KEY:
    return unauthorized()

# after — constant-time compare, no early exit to measure
import hmac
if not hmac.compare_digest(provided_key, VECTR_API_KEY):
    return unauthorized()

A new vectr key command generates a high-entropy key and — deliberately — never persists it. The key goes to stdout so KEY=$(vectr key) captures it in a shell variable; the human-facing guidance goes to stderr so it doesn't pollute the captured value. And when a key is set, the editor MCP configs that vectr writes include the auth header automatically. That last part comes with a warning printed in the CLI and the docs, in plain language: those config files now contain the key in plaintext, so they belong out of shared version control. I would rather say that loudly than let someone commit their key to a repo because the tool was too polite to mention it.

vectr start --host <addr> binds the daemon beyond loopback so other machines can reach it. Here is the load-bearing detail: a non-loopback bind refuses to start without an API key. You cannot, through any combination of flags, stand up a network-reachable index that serves notes to anonymous clients. It isn't a warning you can click past; the daemon exits. A shared index is authenticated by construction or it doesn't run.

On each teammate's machine, vectr connect points the editor at the central instance instead of spawning a local daemon:

# on the shared host
KEY=$(vectr key)                         # high-entropy, never persisted
VECTR_API_KEY=$KEY vectr start --host 0.0.0.0

# on each teammate's machine — note the --api-key=<key> form
vectr connect --url=<url> --api-key=$KEY --label=you

The --label is what makes shared memory legible. A note one agent stores is instantly recallable by every other agent on the instance, and it comes back rendered with an @label tag — so when the recall surfaces "the parser treats revert commits as a no-op," you can see it was @coder-parser who learned that, not a disembodied fact of unknown provenance. Attribution turns a shared pile of notes into something you can reason about: who found this, and do I trust that source for this kind of claim.

Concurrency is the other thing a shared store has to get right, because the whole point is that several agents write at once. Vectr leans on an SQLite busy timeout so simultaneous writers queue for a beat instead of colliding. I tested that with 24 concurrent stores hammering the same instance: 24 unique IDs, zero loss. That number matters less than what it predicts, which is what the seven-agent test then showed under messier, more realistic load — but I wanted a clean synthetic floor under it first.

One more piece connects this to the rest of the series. The orchestrator-and-subagents pattern I described in the context-relief post — a subagent finishes an investigation, writes its findings as notes, and the parent recalls them instead of re-reading the whole transcript — is exactly the pattern team mode generalizes. The only difference between "my subagents share a bus" and "my teammates share a bus" is that the second one crosses a network, which is the entire reason the auth and encryption work had to happen first.

Set VECTR_ENCRYPT_KEY — or stash a passphrase in the OS keychain — and vectr encrypts note content, note titles, and snapshot payloads before they touch disk. The primitive is Fernet — AES-128-CBC for confidentiality, HMAC-SHA256 for integrity, with the key derived through PBKDF2-SHA256 at 480,000 iterations. The iteration count is the brute-force tax: every guess an attacker makes against your passphrase costs them 480,000 hashes, not one.

Building this flushed out three real data-leak bugs, and they are worth naming because each one is the kind of leak you only find by asking "where does the plaintext actually go":

• Note titles were derived from the first line of the content and stored in the clear — so encrypting the body while leaving the title plaintext leaked the body's opening line anyway.
• Snapshot payloads embedded fully-decrypted note text, which meant a snapshot quietly bypassed note encryption entirely. You could encrypt every note and still have a plaintext copy of all of them sitting inside a checkpoint.
• There was no purge path for snapshots, so a note you "deleted" lived on inside any snapshot that had captured it. Delete didn't mean gone.

All three are fixed. But the more important part of this section is the boundary I chose not to hide.

There is one more turn of the screw for the strictest posture. By default, notes also carry an embedding vector so recall can match on meaning — and that vector is a lossy plaintext projection of the note's text, which is itself a small leak. Set VECTR_ENCRYPT_DISABLE_NOTE_VECTORS=1 and vectr omits those vectors entirely; recall then falls back to exact-text matching. You trade fuzzy semantic recall for a strictly smaller plaintext footprint. Most people won't want that trade. The people who do, need it to exist. The demo below lets you flip the whole thing on and off so the boundary is a picture instead of a paragraph.

The change here I'm least comfortable admitting is the one I'm most glad I caught. The audit log — the record of every recall query — used to default on. Which means earlier versions were quietly recording every question an agent asked its memory, undisclosed, on by default. That's wrong, and I'm not going to soften it: it was a privacy default that shouldn't have shipped the way it did. In 1.1.0 it is strictly opt-in. Unset VECTR_AUDIT_LOG and nothing is recorded. If you want the accountability trail — and on a shared instance you probably do — you turn it on, on purpose, and now you know it's on.

The rest of the data-handling story is about making "delete" mean delete:

• Retention. VECTR_NOTES_TTL_DAYS expires notes automatically after a set age. Unset, notes are kept until you delete them. The TTL exists for teams that don't want an unbounded memory of a codebase accreting forever.
• Complete purge. Forget-all now deletes snapshots and note embedding vectors too, not just rows in the notes table. This is the fix for the third leak bug above: previously "deleted" data survived in places the delete didn't reach.
• Tight permissions. Cache and state directories are created 0700 on POSIX — owner-only, so another user on a shared host can't read them off the filesystem.
• One table that says it all. A new docs/data-handling.md states, in a single table, what is stored, where, what's plaintext versus encrypted, how long it's kept, and how to delete every trace of it. If you have to read the source to answer "what does this tool keep about my code," the docs have failed.

A unit suite can tell you the SQLite lock holds and the auth header is checked. It cannot tell you the thing I actually needed to know before merging: does team mode work when real agents use it the way a real team would? So I built a scenario to answer exactly that, and gated the merge on it.

The setup was an empty git repository containing one file — PRODUCT.md, a product brief — and a single shared vectr instance running in --memory-only team mode. Then I assigned seven agents, all Claude Sonnet 4.6, all working independently, to build a real product from scratch: a command-line tool called relnotes that reads a range of conventional commits, groups them by type, infers the semver bump, and renders release notes as markdown and plain text. Stdlib-only Python — no dependencies to hide behind.

The constraint is the whole test: the agents coordinate only through the shared vectr instance. They shared no conversation and no documents, and none of them could read another's transcript. The only channel between a thing one agent learns and the next agent who needs it is a note stored in working memory and recalled by someone else. If team mode's shared memory doesn't actually carry knowledge between independent clients, the three modules never fit together and the product doesn't integrate. Integration is the assertion.

Seven agents, four phases, one memory between them.

• Two researchers went first — one on the conventional-commits spec, one on the CLI design. Their job was to turn open questions into load-bearing notes: the interface contracts (exact dataclass fields, function signatures, output formats), the spec's nasty edge cases (the breaking-change OR-logic, the shapes a revert can take, the footer grammar), and the design decisions that the coders would otherwise each have to reinvent.
• Three coders — parser, render, CLI — each worked in its own git worktree on its own branch, each owning exactly one module. The protocol was strict: recall the contracts first, build against them, and store every gotcha and deviation back for whoever hits it next. They never saw each other's code.
• One integration pass: the CLI coder merged all three branches, ripped out the test fakes it had been developing against, and wired the end-to-end tests.
• Two reviewers closed it out. A black-box product reviewer judged behavior against the brief from fresh, adversarial git repos — it never read the source, only ran the tool. A white-box code reviewer went the other way: contract adherence, test honesty, bug hunting in the actual code. Both were told the same thing — verify every claim in shared memory against reality, don't trust it.

A few realism details matter, because they're the difference between a test and a demo. Every agent authenticated with the shared API key and its own attribution label. Every memory operation went over the real MCP wire — the same JSON-RPC surface an editor's agent sees, not a test double that would paper over the parts I most wanted to stress. And one orchestrator — a separate model — wrote the briefs and verified the results but did zero domain work. It never wrote a line of relnotes and never made a design call. It refereed.

Start with the mechanism, because that's what a release gate is actually gating. Across the whole test, the seven clients stored 52 attributed notes that stayed live, and the audit log recorded 76 operations — 53 stores and 23 recalls. Those two numbers reconcile exactly: 53 stores minus one deliberately deleted smoke-test note — a throwaway stored only to confirm the write path worked — leaves the 52 live notes in the store. Nothing lost, nothing double-counted, the ledger balances to the note.

And there were zero server-side failures. No timeouts, no server errors in the 5xx range, no malformed responses, across every agent for the full length of the test. The SQLite lock I stress-tested with 24 synthetic writers never once surfaced to a real client. The proof that the writers were genuinely concurrent — not politely taking turns — is in the note IDs: they interleave across agents, with one coder's IDs jumping from #19 to #29 because six other stores landed in between while it was working. That gap is the fingerprint of real concurrency, and every one of those interleaved writes survived.

The demo below is that ledger. Watch the attribution spread across the seven roles, then reconcile the audit log against the live store yourself.

None of these numbers are the point on their own. A daemon that logs cleanly can still be useless. What makes the ledger mean something is the story it enabled, which is the next section — but I wanted the mechanism on the table first, because if the mechanism had failed here, nothing after it would matter.

Here is the moment that proves the mechanism, and it still surprises me a little. Three coders, in three isolated worktrees, independently transcribed the same data model from one contract note, and once the branches were merged the test suite went green on the first run: 119 tests, zero functional mismatches. Three people who never saw each other's code, agreeing on the exact shape of a shared type, because the shape traveled through a note and each of them copied it faithfully.

It gets better. The CLI coder needed to test in isolation before the real render module existed, so it built a fake render module purely from the stored contract notes — a stand-in that produced what the notes said the real one would. When the actual render module arrived in the merge, the fake's output matched it byte-for-byte. Two independent implementations of the same interface, converging on identical output, with nothing connecting them but a note in shared memory. That is the single cleanest signal I got that the contract was precise enough to build against blind.

# kind: gotcha   priority: high   @coder-render
render treats `perf` commits as patch-triggering.
The interface docstring doesn't list perf; the conventional-commits
spec treats perf as a fix-adjacent, patch-level change.
Revert path: drop 'perf' from the patch-trigger set.

The integrator's own verdict on that moment, verbatim: reading the code cold, "I'd have either 'fixed' a deliberate decision or burned time reconstructing intent — notes turned a judgment call into a lookup." That sentence is the entire value proposition of shared working memory in one line, and I didn't write it — the agent did, after the fact, when asked whether the memory had helped.

The reviewers were the honesty check

A shared memory full of confident notes is worthless if the notes lie. So the white-box reviewer's job was to verify every claim in memory against the actual code, and it did: the data model diffed byte-identical to the contract note, the test-fake removal was real, the 119-test claim reproduced exactly. No note lied. Recall-first, the reviewer said, turned what would have been a byte-identity check into a diff, and told it exactly which claims to verify rather than trust.

And the reviews were not rubber stamps, which is the other thing I needed to know. The black-box reviewer found a genuine release blocker in the product the agents built: a spec-conforming BREAKING CHANGE: footer got silently dropped when it was followed by a blank line and then another trailer — which means the tool inferred the wrong semver bump, in the exact core of what relnotes is for. It also caught a silent no-op in the python -m invocation path. Six more defects came out of the white-box pass, all of them in error paths the coders' happy-path tests never exercised. Eight real defects, in a product that had just merged clean.

I said the reviews found eight defects. Here is the number that keeps the previous section honest: none of those eight defects were in any of the 52 notes. Not one. The notes told the reviewers what to verify and where to look, but the bugs lived in code paths, and finding them required running the code, not recalling a note. Shared memory turned discovery into faster verification. It did not do the finding. If you take away one caveat from this whole post, take that one — memory is not a substitute for reproduction, and any pitch that implies otherwise is selling you something.

Three more limits, none of them hidden:

• The "byte-identical" story wasn't quite. All three coders added their own differently-worded module docstrings on top of the transcribed contract, which produced textual merge conflicts at the git level that the contract note had explicitly assumed were impossible ("byte-identical copies cannot conflict"). The assumption was wrong — the transcribed bodies matched, but the added prose didn't. The lesson got recorded for next time: a contract has to say "no additions — not even docstrings," or agents will each add prose in good faith and collide.
• One recall missed on the first try. A coder's first recall query didn't surface the most relevant contract note; a second, more targeted query did. One data point, and I logged it as a ranking follow-up rather than pretending recall is perfect. It isn't.
• Recall returns overlapping pages. Across related queries in a well-populated store, recall handed back overlapping ten-note pages — no misses, but redundant tokens the caller pays for twice. Logged as a follow-up. It's the same family of efficiency concern the v1.0 gate post ended on: the tool works, and it still has token fat to trim.

The release gate passed not because nothing broke, but because the things that broke were in the product being built and in fixable vectr ergonomics — never in the shared-memory mechanism itself. That distinction is the whole verdict, and I'll come back to it.

The point of dogfooding at this scale is that the tool gets used hard enough to break in ways you didn't script — and it did. vectr key could generate a key that started with a -. That breaks the documented vectr connect --api-key <key> form, because argparse reads a leading dash as a flag, fails to find it, and exits with code 2. Two agents hit it independently — which is exactly how you know it wasn't a fluke of one prompt.

It's fixed: vectr key now regenerates until the first character is safe, the docs show the always-safe --api-key=<key> form, and there's a regression test pinning it. That's the whole reason to run a gate like this. A key that occasionally starts with a dash is invisible in a code review and obvious the second a real client tries to connect with one.

Four smaller observations became tracked follow-ups rather than release blockers: the first-recall ranking miss and the recall-page overlap from the limits section, plus two ergonomic ones — documenting the note-ID interleaving so it doesn't read as a bug, and tightening the file-list printout that vectr connect emits. None of them held the release. All of them are written down, which is the point: a gate that finds nothing isn't a gate, and a gate whose findings evaporate into the chat log isn't one either.

At the end, I asked each of the seven agents the same question: did the shared memory actually beat reading the repo cold? And I told each of them, explicitly, that "no" was an acceptable answer — because a verdict you're only allowed to give one way isn't a verdict. All seven said yes, and the reason I trust the "yes" is that they backed it with specifics, not sentiment.

• The integrator called it decisive on three concrete counts, the sharpest being the perf-deviation lookup — the judgment call that shared memory turned into a two-second recall instead of an afternoon of reverse-engineering intent.
• The white-box reviewer said recall-first turned a byte-identity check into a diff, and told it precisely which claims to verify rather than trust — so its verification time went where the risk actually was.
• The black-box reviewer said a single stored note — "contract gaps filled by inference" — pointed it at two of its major findings before it ran a single test, in its words "turning discovery into verification."

Notice that every one of those endorsements is the same shape: not "memory found the bug," but "memory told me where to point my own verification." That's the honest version of the value, and it happens to be exactly the boundary the limits section drew. The agents and the defect count agree with each other, which is the most reassuring thing that can happen when you're deciding whether to trust your own test.

Three claims, each with its evidence, and I'll try not to inflate any of them.

The mechanism works under real concurrency. Seven clients, 76 operations, zero server-side failures, an audit log that reconciles exactly against the live store. That's not a stress benchmark I tuned until it passed; it's what fell out of seven agents using the thing for real work over the length of a build.

The knowledge-sharing effect is real and specific. Independent implementations converged on identical output through a note. A deliberate deviation became a lookup instead of an investigation. Reviews started from verified context instead of a cold read. These aren't vibes — each one is a concrete event with a number or a quote attached.

And the boundary is just as real. Memory doesn't find bugs; verification does. Ranking has room to improve, and I logged where. The release gate passed because the failures it surfaced were in the product being built and in fixable vectr ergonomics — the - key, the page overlap, the ranking miss — and not in the shared-memory mechanism the release is actually about. A gate that only ever confirms the thing works isn't a gate. This one told me where the edges were, and the edges were survivable. That's the difference between "I hope this works" and "I tagged it."

pip install vectr gets you 1.1.0 from PyPI; the source is on github.com/swapnanil/vectr, MIT-licensed. Everything in this release is opt-in, so a solo laptop install behaves exactly as it did before — you have to reach for team mode to get team mode.

When you do, it's three commands: generate a key on the shared host, start the instance behind it, point each client at it.

# shared host
KEY=$(vectr key)
VECTR_API_KEY=$KEY vectr start --host <addr>

# each client
vectr connect --url=<url> --api-key=$KEY --label=you

# optional: encrypt notes at rest
export VECTR_ENCRYPT_KEY=...
# strictest posture: omit note embedding vectors entirely
export VECTR_ENCRYPT_DISABLE_NOTE_VECTORS=1

The full policy on what's stored, what's encrypted, how long it's kept, and how to delete all of it lives in docs/data-handling.md in the repo. If you're evaluating this for a team, read that table before you read anything else I've written — it's the document I'd want if the codebase on the line were mine.