Every VAAS-X device is its own isolated memory shard by default — nothing written on one is reachable from another. HiveMind is the one line of code that changes that on purpose: name the devices, and a single query fans out across all of them and comes back merged, ranked, and deduplicated.
from vaasx import HiveMind
fleet = HiveMind(api_key="YOUR_API_KEY")
fleet.add_shard("device_1")
fleet.add_shard("device_2")
hits = fleet.query("your query", k=10)Free tier runs on one device, on purpose — HiveMind is what turns a device into a fleet.
HiveMind isn't automatic merging, and it isn't magic — it's a thin, documented client loop over the same query endpoint every device already exposes. That's deliberate: what it does should be easy to reason about when a query is about to cross a device boundary.
Nothing crosses a device boundary by accident
Episodes are scoped per device_id. Querying one device never surfaces what was written to another — that isolation holds whether you're on the Free tier with one device or an Enterprise fleet with hundreds.
One query, every named device, one ranked answer
HiveMind calls the standard query endpoint once per registered device and merges client-side: de-duplicated by episode ID (keeping the higher-scoring copy if the same episode surfaces from more than one device), sorted by score, then truncated to k.
fleet.devices to confirm what's currently registeredquery() before adding any devices falls back to your account's default deviceHiveMind is where it starts working together
One device is enough to evaluate VAAS-X end to end. It isn't enough to run a fleet, a team, or an agent that follows you across sessions — that's the line HiveMind sits on, unlocked from Developer tier up.
HiveMind's fleet.query() is a pull — you ask, every named device answers. The MCP connector's three-tool loop is the other direction: leave an episode unresolved, and it becomes a decision-grade job queue across your devices — with idempotent completion, not a hopeful convention.
remember(outcome="pending")Writes the episode with outcome.result: "pending" instead of a known result — work for another session, or another device, to pick up.
await_pending()Long-polls a device and blocks until a pending episode shows up, or the timeout elapses. Call it in a loop from an otherwise-idle session to turn it into a live worker instead of one more thing querying the fleet.
record_outcome(expected_prior_result="pending")Compare-and-swap completion: the write only applies if the episode is still exactly what you expect. Two workers racing for the same item don't silently clobber each other — the loser gets a clean 409 outcome_conflict with the real current value.
Live-verified, not just documented: closing an already-closed episode with the same guard returns {"error": true, "status_code": 409, "detail": {"error": "outcome_conflict", "expected_prior_result": "pending", "actual_result": "..."}} — the real conflicting value, not a silent overwrite. Full tool reference on the MCP connector page.
Three real recall() calls against three real device shards, same query string, run shortly before this page was published — a small, self-run illustration of the mechanism above, not a customer case study.
| Device queried | Result | Score |
|---|---|---|
| deviceA | Own episode found | 0.61 |
| deviceB | Own episode found | 0.64 |
| unrelated third device | No relevant match | 0.17 |
Querying the unrelated device directly for the exact same string returns a genuinely low score against unrelated content — not a filtered zero. Naming deviceA and deviceB together in one HiveMind call merges both hits into a single ranked answer instead of two separate ones you'd have to reconcile yourself.
independent episodes, cross-session HiveMind recall validated at p≈0.0002
episodes accumulated in a live autonomous agent loop running continuous HiveMind fan-out
substrate logic in the client — fan-out and merge are a documented, testable loop, not hidden magic
3,586-episode and 35,000-episode figures as published in VAAS-X's technical whitepapers — see the Whitepapers page for full methodology.
A laptop session and a CI session are two different devices with two different memories, until you federate them. HiveMind is how one agent's history stays available to the next session that picks up the same work.
Each unit keeps its own on-device shard — no cloud dependency for local operation. HiveMind is the fleet-wide read: what one machine learned becomes queryable across all of them, on demand.
Every teammate's device stays private by default. Naming a shared set of devices is an explicit choice, not a default you have to opt out of.
HiveMind is live today on Developer tier and above — no separate onboarding, no migration. Add a device ID, and query.
Email: hello@vaasx.com
Sales: sales@vaasx.com
Support: support@vaasx.com