DEV Community: VAAS-X

I wired my memory SDK into a live drone control loop. It found a real, honest limitation.

VAAS-X — Tue, 04 Aug 2026 18:08:01 +0000

Every other test I'd run on vaas-x validates retrieval against a fixed dataset: ingest, then query, then check the answer. This one asks a harder question: can it sit inside a real-time decision loop, where every query result immediately becomes an action that changes the world, which changes the next query? I built a simulated drone — 2D position and altitude, raycast obstacle sensing, wind, battery drain, walls it can actually crash into — and wired vaas-x into its control loop directly.

What the SDK actually does here

from vaasx import Bootstrap

brain = Bootstrap(api_key="YOUR_API_KEY", device_id="drone_01")

hits = brain.query("Drone navigation state. goal_dist=6.0m yaw_err=0.2rad hazard=clear ...", k=7)

brain.ingest([{
    "state": {"text": "Drone navigation state. goal_dist=6.0m ..."},
    "action": {"text": "Control: thrust=0.72 yaw_rate=0.31 (left) climb=-0.20 (down)"},
    "outcome": {"text": "Outcome: success no_collision dist_to_goal=1.9 energy=0.013 arrived", "success": True},
}])

brain.outcome(hits[0]["id"], success=True, delta=0.12)

Same three calls as everything else — ingest, query, outcome — just applied to a real-time control problem instead of a dataset.

The architecture: memory suggests, deterministic rules decide

Every control step: canonicalize the drone's state to text, query memory for similar past situations, and add the recalled action to a candidate pool alongside a local heuristic controller, a few purpose-built maneuvers (settle near the goal, brake, escape a close obstacle), and small perturbations. Every candidate is scored by simulating it forward a few steps and penalizing collisions, close clearance, and wasted energy. A hard-coded veto function rejects any candidate — retrieved or not — that violates a safety rule. Probabilistic retrieval proposes; deterministic rules and simulated rollout decide.

The ablation: does memory actually change the outcome?

A fair test needs a controlled comparison, not a summary number. I ran the identical 10-episode run, twice, on the same wall layout and the same random draws — once with the memory candidate allowed to compete for the decision, once with it excluded entirely from an otherwise identical candidate pool and scoring pipeline.

First attempt: both arms produced byte-identical trajectories. The cause turned out to be in how I'd seeded memory — entirely from the same local heuristic controller it was competing against, so retrieval had nothing genuinely different to offer. I fixed that (24% of seed episodes now come from a distinct exploration policy, not the heuristic) and reran.

The honest result

Both arms still finished at 4 wins out of 10 — and were still episode-for-episode identical. Across 20 full episodes (232 total control steps combined), the memory candidate won the internal decision exactly once.

The reason: the scoring bonus meant to favor a recalled action is a small, fixed number, while the rollout cost function it competes against has a much larger dynamic range — a single collision alone costs 400 points in that scoring. A recalled action transplanted onto a new state essentially never beats a controller purpose-built for that exact state by less than the bonus, so the discount rarely if ever changes which candidate wins.

This is a faithful port of the original prototype's own scoring formula, not something I introduced while porting it — which means it's a genuine, previously-unmeasured property of this specific design, not a flaw in retrieval itself. I can't even say whether what memory recalled was good; it essentially never got the chance to be chosen.

The generalizable lesson

In any "propose from memory, then score by simulation" pattern, the bonus that's supposed to let memory override a local controller has to be calibrated against the actual scale of the scoring function it's competing inside, or memory will structurally never participate no matter how good retrieval is. That's a real, useful thing to know before building this pattern into a production autonomy stack — and it's the kind of finding that only shows up when you run a real ablation instead of taking a demo's summary numbers at face value.

What this does and doesn't show

What it validates: the ingest/query/outcome path runs unmodified inside a real-time control loop against a resolver over the network, retrieval and safety-veto logic compose cleanly, and a controlled, reproducible ablation methodology can isolate exactly what a memory-augmented decision system is and isn't doing. What it does not show: that retrieval-augmented control outperforms a well-tuned local controller in this environment — on this evidence, it didn't get the chance to. This is a simulated drone, not flight-tested hardware, and the scoring-calibration issue found here is specific to this rollout-scoring design, not a general claim about memory-augmented control.

Full runnable steps, including how to reproduce the ablation yourself: reproduction guide. Technical writeup: whitepaper PDF.

I pointed my memory SDK at physics simulations instead of sensors — it worked once, and failed informatively twice

VAAS-X — Tue, 04 Aug 2026 18:04:51 +0000

Every other test I'd run on vaas-x so far was telemetry: industrial sensors, wearable IMUs, agent session logs. That left an open question — does outcome-grounded retrieval transfer to a domain with no sensor stream at all, where the "state" is a scientific simulation's own parameters? I ran three independent physics/computing systems through it to find out, held to the same bar as everything else: a ground truth computed independently of the SDK for every test point, and the honest result reported whether or not it flattered the product.

Same three calls, applied to simulation output

from vaasx import Bootstrap

brain = Bootstrap(api_key="YOUR_API_KEY", device_id="physics_qec")

brain.ingest([{
    "state": {"text": "Syndrome: 1000000100010001010010011011000000..."},
    "action": {"text": "correction=000000000011111100000000..."},
    "outcome": {"text": "learned recurring burst fault pattern", "success": True},
}])

hits = brain.query("Syndrome: 1000000100010001010010011011000000...", k=1)
print(hits[0]["score"], hits[0]["text"])

Win #1: a quantum error-correction decoder learning one fault, cleanly

A 64-bit random linear code (n=64, k=32) mathematically cannot correct an arbitrary weight-6 error — it's past the code's guaranteed correction distance. But real hardware often produces the same high-weight fault repeatedly: a stuck line, a recurring burst on the same physical bits. I queried a specific weight-6 burst syndrome before vaas-x had ever seen it (no match, exactly as expected — the code genuinely can't solve this algebraically), ingested exactly one episode describing that syndrome and its correction, then queried the identical syndrome again.

The correct correction came back — and I didn't just check that a hit came back, I ran the recalled bits through the code's own check_correction() to confirm it actually fixes the error. To be clear about what this does and doesn't show: it's a recall test, not a generalization test. Memory remembers a specific pattern it's been shown once; it doesn't predict corrections for syndromes it's never seen.

The harder question: two continuous-parameter systems

The QEC case is categorical — a syndrome either matches something seen before or it doesn't. The harder test is continuous interpolation: given a physics simulation's continuous input parameter (a coupling constant, a field ratio), can a text-embedding query predict the correct phase for a value memory's never been shown? I tested this against two independent ground truths: a real Metropolis Monte Carlo lattice simulation (13 kappa values ingested, averaged across 3 independent MC chains per point to smooth out genuine sampling noise near the transition) for a lattice φ⁴ scalar field theory, and real exact diagonalization (20 h/J ratios ingested) for a transverse-field Ising model's quantum phase transition. Both ground truths were recomputed fresh for every held-out query.

Lattice φ⁴: 5 of 8 held-out kappa values correctly classified. Transverse-field Ising: 4 of 10 held-out h/J ratios correctly classified.

The fix I tried that didn't work — and why that's the useful part

In both systems, every miss had the same shape: memory defaulted toward whichever phase had more representation in what was ingested (7 of 13 φ4 episodes were "ordered"; 7 of 20 TFIM episodes were "critical"), instead of discriminating finely near the actual phase boundary. Before publishing this, I tried a legitimate fix: k=7 retrieval with a score-weighted majority vote instead of trusting a single top-1 hit — standard practice, not a way of engineering the answer.

It changed nothing. The TFIM run predicted "critical" for every single query, identical before and after the fix, down to the query. That rules out top-1 noise as the explanation — the retrieved neighbourhood itself is dominated by the majority class regardless of the query value.

My read: this is a real, useful limitation, not a bug. A short, numerically-dense query string like "h/J=0.350" differs from a training example by only a few characters in an otherwise near-identical string — a general-purpose sentence embedding model has little reason to weight that span heavily, and it shows up exactly like this. Retrieval does coarse region classification correctly (every miss landed on the wrong side of a real, close decision boundary, not a wildly wrong one), but it's not a substitute for a numerical model when the question is "exactly where is the line."

What this does and doesn't show

Categorical or recurring-pattern memory — QEC's syndrome recall, or industrial/wearable channel classification, where the signal dominates the description — is where this SDK is validated to work well. Fine interpolation across a continuous parameter from a bare numeric label in the query text is not, at least not without more deliberate encoding work than a raw f-string. If you're evaluating memory-augmented retrieval for a scientific-computing use case, match the shape of your problem to what's actually proven here.

Full runnable code for all three systems, plus the exact numbers: reproduction guide. Technical writeup: whitepaper PDF.

I nearly fooled myself validating a wearable IMU classifier — here's the bug and the fix

VAAS-X — Tue, 04 Aug 2026 18:02:22 +0000

Most of the validation work on vaas-x so far had been industrial sensor data — turbofans, machine telemetry. I wanted to know if the same zero-config channel classifier actually transfers to a completely different domain: a wearable IMU strapped to a moving human. No feature engineering, no per-sport tuning, no hints about what any channel means.

I'm writing this one up slightly differently than my other posts, because the first version of this test gave me a wrong answer, and I think the reason it was wrong is more useful than the result itself.

The dataset

UCI's Daily and Sports Activities set (Altun, Barshan & Tunçel, 2010): 8 subjects, each wearing five Xsens IMU units — torso, both arms, both legs — 9 axes per unit (accelerometer, gyroscope, magnetometer × x/y/z), sampled at 25Hz. 45 channels total. It includes both a sedentary activity (sitting) and dynamic sport activities (basketball, rowing), which gives a clean, checkable question: does a classifier that's never seen this data correctly tell apart "person sitting still" from "person playing basketball," using channel statistics alone?

import pandas as pd

# Mirrored subset: github.com/AniMadurkar/Daily-Activities-and-Sports-Biomechanics-Analysis
df = pd.read_csv("sports_science_dataset_subset.csv")
channels = [c for c in df.columns if c not in ("subject", "activity", "timestamp")]
print(len(channels), "channels")  # 45

First attempt — and the mistake

My first pass pooled all 8 subjects together per activity and ran it through the profiler in one shot. The result came back backwards: sitting showed up with more "significant" channels than basketball. That's not just unexpected, it's physically nonsensical — a person sitting still should be one of the lowest-variance activities in the entire dataset.

The bug wasn't in the classifier. It was in the test. Pooling subjects together means each subject's own sensor baseline and IMU orientation differences get mixed into the between-subject variance for every channel — including sitting, where there's no real movement to swamp that noise. For basketball, the actual movement signal is large enough to dominate regardless. Pool the data and you're accidentally measuring "how different are these 8 people's resting sensor baselines" more than "how much does this channel move during this activity."

# Wrong: pools all subjects, cross-subject baseline noise contaminates
# the low-motion activity's variance more than the high-motion one
df_sitting_pooled = df[df["activity"] == "sitting"][channels]

The fix: one continuous stream per subject, per activity

That's also just what a real deployment looks like — one wearable, one athlete, one continuous stream. So I reran it that way: for each of the 8 subjects independently, feed their sitting stream and their basketball (or rowing) stream through the profiler as two separate single-device sessions.

from vaasx.bootstrap import StatisticalProfiler, SchemaClassifier

def profile_subject_activity(df, subject_id, activity):
    subset = df[(df["subject"] == subject_id) & (df["activity"] == activity)]
    profiler = StatisticalProfiler(device_id=f"subject_{subject_id}_{activity}")
    for _, row in subset[channels].iterrows():
        profiler.observe(row.to_dict())
    return SchemaClassifier().classify(profiler.snapshot())

results = {}
for subject_id in df["subject"].unique():
    for activity in ["sitting", "basketball", "rowing"]:
        results[(subject_id, activity)] = profile_subject_activity(df, subject_id, activity)

The result, once the methodology was fixed

Across all 8 subjects, sitting left an average of 14.8 of 45 channels classified stable, 22.4 flagged significant. Basketball and rowing collapsed to zero stable channels in every single subject, with 40–44 of 45 flagged significant every time. Consistent, in the right direction, in all 8 people — with no channel labels or activity hints ever given to the classifier.

Check it against something outside the SDK entirely

import numpy as np

def independent_variance(df, subject_id, activity):
    subset = df[(df["subject"] == subject_id) & (df["activity"] == activity)][channels]
    return subset.var().mean()

sitting_var = np.mean([independent_variance(df, s, "sitting") for s in df["subject"].unique()])
basketball_var = np.mean([independent_variance(df, s, "basketball") for s in df["subject"].unique()])
rowing_var = np.mean([independent_variance(df, s, "rowing") for s in df["subject"].unique()])

print(f"basketball / sitting: {basketball_var / sitting_var:.0f}x")
print(f"rowing / sitting: {rowing_var / sitting_var:.0f}x")

Plain pandas .var(), nothing from the SDK. Basketball came out roughly 154x higher variance than sitting, rowing roughly 27x — computed completely independently of whatever the classifier decided. The classifier's "significant vs. stable" split is tracking a real, independently measurable physical signal, not an artifact of how it happens to score things.

What this doesn't show

I want to be as clear about this here as the whitepaper is: this validates that zero-config channel profiling correctly separates a sedentary activity from a dynamic one, on real wearable data, in a domain the classifier was never tuned for. It does not validate injury prediction, movement-quality scoring, or that a flagged pattern means anything clinically. That's a much harder, differently-evidenced claim, needs labelled injury-outcome data specific to a sport and population, and I haven't tested it — so I'm not claiming it.

The mistake in my first pass is the part I'd actually want another engineer to take away from this: pooling data across subjects/devices/sessions before checking a per-entity classification claim is an easy way to quietly validate the wrong thing, and get a plausible-looking wrong answer out the other end.

Full runnable steps, same code as above, against the real UCI zip (not a mirror): reproduction guide. Technical writeup with the full 8-subject numbers: whitepaper PDF. If anyone reproduces this against activities I didn't test, I'd like to know if the pattern holds outside basketball and rowing.

I beat CartPole's random baseline with 5-line memory queries, no training, no download

VAAS-X — Tue, 04 Aug 2026 17:57:37 +0000

No dataset to download for this one — just pip install gymnasium and a deterministic simulation you can run yourself in a few minutes. I wanted a test of vaas-x's outcome-grounded retrieval that had nothing to do with sensors or IoT, so I picked the most over-used toy environment in RL: CartPole.

The question isn't "can this beat a trained RL policy" — it can't, and that's not the point. The question is whether biasing action choice toward what previously kept the pole up, using nothing but similarity retrieval over logged episodes, beats picking actions at random.

Baseline first

import gymnasium as gym

env = gym.make("CartPole-v1")

def random_episode():
    obs, _ = env.reset()
    steps = 0
    while True:
        action = env.action_space.sample()
        obs, _, terminated, truncated, _ = env.step(action)
        steps += 1
        if terminated or truncated:
            return steps

baseline = [random_episode() for _ in range(50)]
print("random policy, mean steps:", sum(baseline) / len(baseline))

Log episodes as memory, not training data

Each observation gets bucketed by sign into a short state description, and the action taken goes into source_text so it comes back out of retrieval later:

from vaasx import Bootstrap

brain = Bootstrap(api_key="YOUR_API_KEY", device_id="cartpole")

def bucket(obs):
    labels = ["cart_left", "cart_right"], ["cart_still", "cart_moving_right"], \
              ["pole_left", "pole_right"], ["pole_falling_left", "pole_falling_right"]
    return " ".join(labels[i][int(v > 0)] for i, v in enumerate(obs))

log = []  # kept locally too, for the independent check later
for _ in range(200):
    obs, _ = env.reset()
    ep_items, ep_states, ep_actions = [], [], []
    while True:
        action = env.action_space.sample()
        state_text = bucket(obs)
        ep_items.append({
            "payload": {f"obs_{i}": float(v) for i, v in enumerate(obs)},
            "source_text": f"{state_text}; action_taken={action}",
        })
        ep_states.append(state_text)
        ep_actions.append(action)
        obs, _, terminated, truncated, _ = env.step(action)
        if terminated or truncated:
            break
    resp = brain.ingest(ep_items)
    for i, episode_id in enumerate(resp["episode_ids"]):
        if episode_id is None:
            continue
        # every step kept the pole up except the last one in the episode
        success = i < len(resp["episode_ids"]) - 1
        brain.outcome(episode_id, success=success)
        log.append({"state": ep_states[i], "action": ep_actions[i], "success": success})

200 episodes of a random policy, logged with the one honest signal available: did this step precede the pole falling, or not.

Recall an action instead of choosing one blind

import re

def recall_action(obs, k=5):
    hits = brain.query(bucket(obs), k=k, prefer_success=True)
    votes = [int(m.group(1)) for h in hits if (m := re.search(r"action_taken=(\d)", h["text"]))]
    if len(votes) < 2:
        return env.action_space.sample()
    return max(set(votes), key=votes.count)

Five lines. Query for similar past states, weight toward the ones that succeeded, take a majority vote over what action was taken in those.

Does it actually help?

def memory_episode():
    obs, _ = env.reset()
    steps = 0
    while True:
        action = recall_action(obs)
        obs, _, terminated, truncated, _ = env.step(action)
        steps += 1
        if terminated or truncated:
            return steps

memory_run = [memory_episode() for _ in range(50)]
print("memory-augmented, mean steps:", sum(memory_run) / len(memory_run))

Being honest about this: CartPole is noisy over 50 episodes. The gap over random should be visible, but if it isn't obvious on your run, bump the episode count before concluding anything either way — I'd rather say that up front than let a lucky/unlucky seed do the talking.

Check retrieval against a plain nearest-neighbor computed locally

import pandas as pd

local = pd.DataFrame(log)
local_pref = local.groupby("state").apply(lambda g: g.loc[g["success"], "action"].mode())
print(local_pref)

For a handful of states, compare local_pref — a majority vote computed with nothing but pandas over your own local log — against what recall_action actually returns from the API. They're answering the same question two different ways; they should agree.

Run it yourself

Full guide here — zero downloads, free-tier key at vaasx.com/pricing. If you try it, I'm curious whether the gap over random held up on your seed, and by how much.

Does CO2 actually predict room occupancy more than temperature? I checked against ground truth instead of assuming.

VAAS-X — Sun, 02 Aug 2026 17:33:13 +0000

Most "smart" claims in IoT are unfalsifiable in practice — a vendor says their system "learned what matters," and you have no real way to check it against anything. I wanted to see what happens when you can.

I'm building vaas-x, a memory layer that profiles a data stream and classifies which channels carry real signal, with no schema and no domain knowledge supplied up front. So I ran it against UCI's Occupancy Detection dataset, which has something most sensor data doesn't: a real, human-verified ground-truth label on every single row.

The dataset

Five environmental channels — Temperature, Humidity, Light, CO2, HumidityRatio — sampled about once a minute in a single office, with a column called Occupancy (0 or 1) recording whether someone was actually in the room. 8,143 rows.

import pandas as pd

df = pd.read_csv("datatraining.txt", index_col=0, parse_dates=["date"])
channels = ["Temperature", "Humidity", "Light", "CO2", "HumidityRatio"]

Occupancy doesn't go into the ingest payload. It's held back — used afterward to tag outcomes and to check the classifier's answer.

Ingest, then tell it what actually happened

from vaasx import Bootstrap

brain = Bootstrap(api_key="YOUR_API_KEY", device_id="office_occupancy")

records = df[channels].to_dict(orient="records")
timestamps = df.index.astype(str).tolist()

ids = []
for i in range(0, len(records), 500):
    batch = [{"payload": r, "timestamp": t} for r, t in zip(records[i:i+500], timestamps[i:i+500])]
    resp = brain.ingest(batch)
    ids.extend(resp["episode_ids"])

occupied = df["Occupancy"].tolist()
for episode_id, is_occupied in zip(ids, occupied):
    if episode_id is None:
        continue
    brain.outcome(episode_id, success=bool(is_occupied))

The outcome() call is the part that's easy to skip and shouldn't be: it's what lets retrieval later distinguish "looks similar" from "looks similar and actually was an occupied room."

Query it

hits = brain.query("occupied room, motion detected, elevated CO2 and light", k=5, prefer_success=True)
for h in hits:
    print(h["timestamp"], h["outcome"]["success"], h["score"])

Since outcomes were tagged straight from the real Occupancy column, every hit here should read success: True when prefer_success=True is set. If one doesn't, that's a real, checkable discrepancy — go look up that timestamp in the dataframe directly.

The actual question: does the classifier agree with reality?

from vaasx.bootstrap import StatisticalProfiler, SchemaClassifier

profiler = StatisticalProfiler(device_id="office_occupancy")
for r in records:
    profiler.observe(r)

result = SchemaClassifier().classify(profiler.snapshot())
print("significant channels:", sorted(result["significant_channels"]))

Now check that against the actual correlation with the real label — no SDK involved in this step at all, just pandas:

correlations = df[channels + ["Occupancy"]].corr()["Occupancy"].drop("Occupancy").abs().sort_values(ascending=False)
print(correlations)

Light and CO2 correlate with Occupancy far more strongly than Temperature, Humidity, or HumidityRatio — which matches intuition (a room fills with exhaled CO2 and someone usually turns the lights on). The question isn't whether that's surprising, it's whether the classifier's significant_channels list matches that ranking, computed independently, on the same public data anyone can download.

Two labeled test sets you can run this against yourself

datatest.txt and datatest2.txt cover different date ranges under the same schema and are also labeled — ingest either as a second device_id and repeat the correlation check against its own ground truth rather than trusting a single run.

Full steps in the reproduction guide. Free-tier API key at vaasx.com/pricing, no card required. If you've got sensor data with any kind of real label attached — a failure flag, a conversion event, anything — that's the actual test worth running: not "does this look smart," but "does it agree with something you can independently check."

I gave my memory system 24 unlabeled NASA sensor channels and zero configuration

VAAS-X — Sun, 02 Aug 2026 17:00:48 +0000

I've been building a persistent memory layer for AI agents and connected devices — vaas-x, pip install vaas-x — and the claim I make about it that's easiest to be skeptical of is "zero configuration." No schema, no field mapping, no telling it what the data means. It just looks at a stream and figures out what's actually carrying information.

So instead of demoing it on my own data, I pointed it at something I had no hand in designing: NASA's CMAPSS turbofan degradation dataset, with every column identifier stripped out first.

The setup

CMAPSS FD001 is a public benchmark — 100 turbofan engines run to failure under one operating condition, logged as one row per engine-cycle. Each row has 3 operating-condition settings and 21 sensor readings. I know which three columns are the operating settings and which 21 are sensors. The classifier doesn't — I renamed everything to channel_00 through channel_23 before it ever saw the data.

import pandas as pd

columns = ["unit", "cycle", "op_setting_1", "op_setting_2", "op_setting_3"] + [f"sensor_{i}" for i in range(1, 22)]
df = pd.read_csv("CMAPSSData/train_FD001.txt", sep=r"\s+", header=None, names=columns)

measurement_cols = [c for c in columns if c not in ("unit", "cycle")]
df_blind = df[measurement_cols].rename(columns={c: f"channel_{i:02d}" for i, c in enumerate(measurement_cols)})

24 anonymous channels. No sensor names, no units, no hint that this is even turbofan.

Feed it in

from vaasx import Bootstrap

brain = Bootstrap(api_key="YOUR_API_KEY", device_id="cmapss_fd001")

records = df_blind.to_dict(orient="records")
for i in range(0, len(records), 1000):
    batch = records[i:i+1000]
    brain.ingest([{"payload": r} for r in batch])

Ask it what it found

from vaasx.bootstrap import StatisticalProfiler, SchemaClassifier

profiler = StatisticalProfiler(device_id="cmapss_fd001")
for row in records:
    profiler.observe(row)

result = SchemaClassifier().classify(profiler.snapshot())
print("stable channels:", sorted(result["stable_channels"]))
print("significant channels:", sorted(result["significant_channels"]))

Compute the ground truth straight from the data with plain pandas, independent of anything the SDK told you, and compare the two sets directly. When I ran this, they matched — the classifier correctly separated the 3 near-constant operating columns from the 21 channels actually carrying signal, having never been told which was which.

I want to be precise about what this does and doesn't show: it's not "the system understood this is an engine." It's "the system correctly told apart columns that carry real information from columns that don't, on data it had never seen a schema for, and an independent variance check agrees." For a zero-config claim, that's the actual bar to clear.

Try it on your own data

The whole thing — data, code, verification step — is a public reproduction guide, same steps as above, runnable against your own free-tier API key (vaasx.com/pricing, no card required, 10,000 episodes free). If you've got a sensor stream, a log file, or anything structured you've been meaning to give some form of memory to, I'd genuinely like to know what you find when you point it at your own data instead of mine.

Persistent, Outcome-Grounded Memory for AI Agents — No GPU, No Vector DB

VAAS-X — Fri, 24 Jul 2026 18:18:57 +0000

https://vaasx.com

Why I built this

Every AI agent I worked with forgot everything between sessions, and every
"add memory to your agent" tool I found either needed a GPU, billed per
query, or both.

pip install vaas-x gives any device or agent a persistent, queryable
record of what it's seen — what happened, what it did, what the outcome
was — and retrieves the closest matching past episode in milliseconds, on
CPU, with no cloud round-trip required.

What it does

Point a structured data stream at it (sensor readings, agent actions, API events — anything JSON-shaped) and it profiles the stream automatically, no schema design.
Query it and get back the most similar past episodes, ranked by what actually worked, not just what's nearest in vector space.
Runs identically on a £30 ESP32 microcontroller and an EC2 instance — same codebase, no domain-specific build.

Wiring it into an agent loop

This is the part most people ask about, so here it is up front:

from vaasx import Bootstrap

brain = Bootstrap(api_key="...", device_id="my_agent")

def agent_step(observation, act_fn):
    action = act_fn(observation)
    result = execute(action)

    # Agent already knows the outcome the moment it acts, so log the whole
    # episode in one call instead of ingest-then-tag-later
    resp = brain.ingest([{
        "state": {"observation": observation},
        "action": {"taken": action},
        "outcome": {"success": result.success},
    }])
    episode_id = resp["episode_ids"][0]  # server-assigned, no UUID plumbing needed

    # Recall similar past situations before the *next* decision
    past = brain.query(observation, k=3, prefer_success=True)
    return action, episode_id, past

Three calls, no vector DB to stand up, no embedding model to host yourself.
prefer_success=True is doing the actual work — it's not just
nearest-neighbour, it's ranked toward what worked last time in a similar
situation.

The numbers

Metric	Result
Mean retrieval, 1.18M episodes, AWS m7i-flex.large CPU	14ms
Mean retrieval, desktop i5, same dataset	1.1ms
NASA CMAPSS FD001 blind trial (24 channels, identifiers stripped)	24/24 correctly classified, zero prior knowledge
Live ESP32 edge deployment	Offline shard, syncing IMU episodes in real time
Longest-running live agent deployment	35,000+ episodes, continuous operation

No GPU, no AVX-512, for any of the above.

Pricing

Free tier gets you an API key instantly, no card required. Developer is
£19/mo, Professional £99/mo, both self-serve. Enterprise is contract-based
for teams wanting on-prem/air-gapped deployment.

The honest caveat

The SDK ships as a compiled wheel, not source-available — the retrieval and indexing internals are proprietary and protected as a trade secret rather than through a patent filing. What is open: full API docs, working examples, and the
wire format, so you can see exactly what goes in and comes back even
without reading the internals. Multimodal (vision/audio/depth) support is
real but still early — encoder models are in active training, flagged as
such wherever it's mentioned.

Happy to answer anything about the benchmark methodology, the architecture
at a high level, or why CPU-only mattered enough to build around.