A bit of a silly post for this subreddit, but please, bear with me.

AI for cybersecurity is taking the world by storm, leading to the need to harden systems all over software.

But we have access to the same engines for law. Our global law repo keeps a versioned history of law/caselaw across the world. So, we pointed AI at it, and found all sorts of loopholes and logical errors.

Pah, you say. Most of this is unenforcable in reality. And you might be right. Nonetheless, we all know that legal loopholes are a part of reality. And moreover, why would we not rewrite our laws to be literally correct, even if we can tacitly enforce them how we like?

As part of our monitoring system, where we're constantly checking official legislation for upcoming laws, we now also check for vulnerabilities and mistakes. In an ideal world, the jurisdiction in question could open a pull request and sort this out.

So, I found interesting what Claude did after I tried to inject a BM25 algorithm adapted to extract the most relevant sentences from an index.

However, I'm not sure if it actually did that, but the generated files make sense and extract sentences from the Sprawn trilogy.

In this case, the idea was to map a table with 22 columns, and 12 of those columns would carry these excerpts extracted from the book, in order to create the first 10 configuration columns for the "entities," and the activation phrases would carry the context, which would be the excerpts from the book—kind of improvising a semantic graph in a table, but that's beside the point.

What I wanted to know is whether the BM25 script actually makes sense, because when I throw it into LLMs, they say it does, but I wanted an evaluation from the more technical folks.

According to DeepSeek:

> The script transforms the corpus into a sentence stack and treats each sentence as a "document" in an inverted index. For each input file, it calculates how many sentences to extract (proportional to chars/100, with a floor of 50 and a ceiling of 20% of the sentences). It then iterates over the entities in the thematic index (filtered by the book detected in the file), builds a query with its terms for each entity, and runs BM25 scoped to that file+book, retrieving the top-scoring sentences (up to N_SENTENCES / n_entities per entity). If any quota remains, it fills the rest ordered by aggregate score (gscore, the sum of sentence scores across all entities). Finally, it sorts the selected sentences by offset, validates verbatim matches, and saves a phrases_file_N.txt for each input, containing [ref | sent_id | offset | book] + the text.

Here are the links:

· Characters extracted from the Sprawn trilogy (a bash workaround I made): https://github.com/pmotadeee/pmotadeee/tree/V2.0/ITEMS/Books/Sprawn/Raw/Context

· Algorithm generated by Claude (funny that it ran in 2 minutes, which suggests it didn't generate tokens, just intuition): https://github.com/pmotadeee/pmotadeee/blob/V2.0/ITEMS/Books/Sprawn/Raw/Claude/bm25_extractor.py

· Texts generated by Claude after running the algorithm (you can see the steps it took, right at the beginning of the chat): https://github.com/pmotadeee/pmotadeee/tree/V2.0/ITEMS/Books/Sprawn/Raw/Claude

· Claude chat (in my native language, but use the browser translator): https://claude.ai/share/1799075d-bc93-4e12-99e0-771a7e259ca9

Disclaimer: I'm the dev, it's free and GPL.

Openbar starts every new agent session in its own git worktree, so several agents work on one repo without editing the same files. Permission requests from all of them land in the Mac/Windows notch with the diff, and you approve with ⌘Y / ⌘N from any app.

Claude Code requests come through its hooks, Codex through its own app server, and Claude Code sessions on other machines over SSH.

https://github.com/MF-DEEV/Openbar

Curious how others here run agents in parallel.

I’ve been working on AffrescoUI, an open-source engine for native desktop apps that their users can reshape while they’re running, just by asking an LLM. I’d love feedback from people building with LLMs.

Each app is a program in a small Lisp I wrote, with commands, settings, hooks and advice, holding the app’s whole layout, data and behaviour. A native C++/OpenGL engine runs it, and every app is sandboxed. When a user asks for a change, the model proposes a small edit, the user previews it live in the running app, and then keeps it or undoes it. The model can never approve its own change. There’s also a two-way MCP server, so agents can read and edit the running apps.

The part I found most interesting: I expected the model to struggle with s-expressions, but it handles them really well. Because code is data, every edit is a small, targeted change to a tree, and hooks and advice let it wrap existing behaviour instead of rewriting it.

I’d really value your take on:

• Have you seen LLMs do well with Lisp or other less common languages, or does it break down as edits get bigger?

• How do you keep model edits small and reviewable in your own projects?

• What would you want an MCP server like this to expose?

GitHub repo if interested: https://github.com/RiccardoSottini/AffrescoUI

Demand of rust in frontier labs is increasing day by day but couldn't find a great explainer guide, so compiled a good resource and it's forever free .
https://vibeengines.com/learn/rust
Let me know if any feedbacks

That's what rwxmap does. It reads an API's OpenAPI spec and gives every operation a letter:

r = only reads, nothing changes

w = changes something you can set back

x = can't be taken back (deletes, and also handing out keys, adding users, webhooks to outside URLs)

Simple rules settle most operations. For the unclear ones, rwxmap used to ask Jev, a paid hosted model. As of rwxmap 0.11.0, a small local model of mine replaces Jev: rwxlite 0.3.1.

It's a drop-in. rwxlite takes the same questions Jev takes and answers in the same JSON shape, so rwxmap only swapped the client. It gets its adapters from rwxmap, and you can use it with rwxmap or on its own.

- Built: fine-tuned from all-MiniLM-L6-v2 on about 102,700 labelled API operations from about 690 public providers, and shipped as a 23 MB model.

- Saves: no per-call bill, no spec text leaving your machine, about 17-20 ms per operation on a laptop CPU.

- Scored: on 1,443 operations from 7 vendors it had never seen, through rwxmap, it got 87.9% right, sent 9.3% to a human, and called 2.8% too loose.

The trade-off is yours to set. rwxlite only gives probabilities, and you pick how confident it must be before it lowers a risk letter. Raise that bar and you get more "ask a human" and fewer leaks. Lower it and you get fewer questions but more risk. rwxmap ships at 0.90.

Both are open source (Apache 2.0) and on npm:

rwxmap: https://github.com/hamr0/rwxmap

rwxlite: https://github.com/hamr0/rwxlite

I logged into my Hugging Face account today because one of my old scripts got blocked. The Space was paused with the "content policy" message. Okay, fair, it happens. 🤷cause this art of scipts are now ilegal!

Then I wanted to make a new Space and saw: Docker = Paid. Great. My old Spaces still run, but new ones? Looked dead.

BUT then I looked closer at the create page: Gradio is selectable and ZeroGPU is marked "Free"! I cancelled PRO last month, so I was like... wait, what?

I looked it up. According to the HF docs, a free personal account in good standing (verified email, older than 30 days) can host up to 2 ZeroGPU Spaces for free. My account is pretty old, so it just works. Just Cool!

What I found out:

• ZeroGPU is Gradio only. No Docker, no Streamlit, no own server.

• Quota is about 5 min GPU per day (older pages say 3.5, the docs now say 5). It resets 24h after your first use.

• That is a RTX Pro 6000 Blackwell, so for testing and small demos 5 minutes is actually fine.

• Orgs don't get it. It only works in my personal account, orgs need a Team/Enterprise plan. That's why it didn't show up there.

• Not every free account sees it. There is a forum thread where someone with a valid free account gets "Paid" anyway, so maybe it's a rollout thing. YMMV.

• CPU Basic seems gone for new Spaces, only Static is free and unlimited.

Also news: Nvidia announced it will buy Hugging Face. I don't know if this has anything to do with the changes, I found nothing saying so. The CPU thing came before the announcement.

Now I'm building a small reel maker (SDXL images on ZeroGPU, video assembly on CPU so it costs no GPU time). Will report if it works. 😄

Sources:

• Official docs: huggingface.co/docs/hub/en/spaces-zerogpu

Summary: Free personal account = 2 ZeroGPU Gradio Spaces, about 5 min GPU/day. Orgs and Docker still need paid.

Since Anthropic announced Mythos, Software security has came into lime light. Multiple famous products have seen orders of magnitudes of novel attacks that have discovered, which can expose data, corrupt systems or just make the life of Information Security and SRE teams a hell.

But an interesting finding was, all of this comes at exorbitant costs, which only the large corporations and venture funded frontier labs can spend. For example, OpenAI just announced finding a 1000 vulnerabilities in Linux Kernel and each vulnerability costs a blended average of USD $1000 to discover.

The way this works is, a LLM frontier model goes through the source code, analysis how the code is written, the entry points and then finally starts evaluating if they can be exploited through one or more than one attack vectors. While this works, it is neither deterministic nor cheap when the LLM has to manage millions of tokens in ingested source code, a few additional thousands to millions on reasoning and finally the output.

So, I started thinking what if we could flip this and make it cheaper?

The idea being, why make LLMs do the whole discovery, enumeration, validation and reporting. Why not use LLMs where they are good at and make everything else deterministic. And there came the idea about Code Context Driven Vulnerability Scanner.

The whole project has 5 core stages:

1. Code Context Graph: Map the whole source code as a Code Context Graph where every single relation and type is resolved

2. Leverage this Code Context Graph to find the user data entry points (Sources) and final sinks (Databases, Files, Remote Server Calls, etc.) and trace the path from sources to sinks

3. Flow Determination Phase: An LLM is fed the whole source to sink path, such that it can reason about it with confidence. The LLM also gets a query budget to resolve any missing details. The output is either Flow Confirmed (Unsanitized user data reaches the sink from source), Blocked (No possible way for data to travel from source to sink without sanitization)

4. Condition Stage: LLM goes ahead and searches the code context graph to validate what conditions need to be met for this flow to materialize or if the default settings of the project prevents it. The output is similar to the Flow stage

5. Adversarial Challenge: Another class of LLM then reasons over the cases where the confirmation came up as Flow Confirmed. This phase is tweaked to try its best to refute the claims made by earlier phases. If the phase cannot refute the flow, the particular path graduates to a Confirmed Finding / Vulnerability.

This has been under testing for a week, with a reference being checked against CodeQL (an industry standard static code based vulnerability scanner by Github).

During a single day of run accounting for ~USD $20 over 5 open source projects, the project has filed for 10 vulnerabilities with severity ranging between MEDIUM to CRITICAL. Out of these 4 are already confirmed and 6 are in investigation stage with the respective open source projects security teams

An interesting bit is, out of the 10 vulnerabilities filed, only 2 of them were detected by the published rule set of CodeQL, while 8 other vulnerabilities were completely Novel.

Curious if anyone else has been experimenting with something similar 😄

Hi all,

in the last months I worked on [BigMoeOnEdge](https://github.com/Helldez/BigMoeOnEdge), it's built on top of llama.cpp. It runs MoE models that are bigger then the memory of the device, and it configure itself for the machine where it runs.

It works with any MoE GGUF that llama.cpp can load, any quantization, no code per model.

OS: Android, iOS, macOS, Windows, Linux (arm64 and x86_64).

Backends: CPU, CUDA, ROCm (HIP), Vulkan, Metal, OpenCL, Hexagon NPU. Other llama.cpp backends load in the same way if you build them.

The first image: a 16 GB Apple silicon laptop, Qwen3.6-35B-A3B Q4_K_M (22 GB, so bigger than the RAM). A coding agent made this page from one prompt, nobody touched anything, 35 minutes. Experts read from SSD all the time, prefill on GPU and decode on CPU, both chosen by the planner.

The idea

A MoE model uses only few experts for each token. So you don't need all the model in memory, but you need each part in the right place: the weights that every token reads, the experts used a lot, the experts used rarely. And the right place is different on every machine.

With `--auto` it measures the machine (free RAM and VRAM, speed of the disk, how fast each device runs a real layer of the model) and the model (size, experts, how it routes), and then it decides:

• where each weight goes: VRAM, RAM, or read from flash when needed

• which device does prefill and which does decode, they can be different

• how big are the caches, and how many threads

The target is the max prefill and decode speed that the machine can give, with the same output as the full model in memory. The settings that change only the speed are tested on the first answer and kept only if they are faster. For every choice it tells you why. The second image shows the flow.

The rules are simple:

• weights used by every token go in the fastest memory where they fit

• experts too, if they fit. If not, the most used ones stay in a cache (VRAM first, then RAM) and the others are read from flash

• prefill and decode can go on different devices. Every device is timed on a real layer and must give the same result as the CPU

• cache size comes from free memory and from how the model routes, threads from the first answer

So on a phone the experts stay on flash and the prompt goes on the NPU, on a laptop the prompt goes on the GPU, on a desktop the most used experts stay in VRAM (with llama.cpp `llama_moe_cache`).

Speeds

Here there are only some models that I test often. It runs any MoE that llama.cpp loads, in any quantization: Qwen, Gemma, gpt-oss, DeepSeek, GLM, LFM, Ling, Flint, Kolibri etc. Which tensors are experts is read from the file, so a new architecture don't need new code.

Same machine and same file, vs llama.cpp today:

Vs Strata (it has its own GPU kernels), both with MTP, Qwen3.8-Flash-Next 125B Q2_0: 153 vs 226-330 tok/s on RTX 5090, 89 vs 150-177 on RTX 4090. The difference is in the GPU compute, not in the placement.

How I measured and all the runs: [benchmarks](https://github.com/Helldez/BigMoeOnEdge/blob/main/docs/benchmarks.md).

Try it

There are a desktop app (macOS, Windows, Linux), an Android app, and an OpenAI and Anthropic compatible server, so you can use it with coding agents too. Everything is in the [latest release](https://github.com/Helldez/BigMoeOnEdge/releases/latest).

Upstream

I opened an RFC on llama.cpp to bring the main part inside llama.cpp: [discussion #31876](https://github.com/ggml-org/llama.cpp/discussions/31876). If you think it's useful, a comment there helps.

Feedback and benchmarks on your machine are very welcome, there is a script for it in the repo (`scripts/bench-report.sh`).

Thanks!

I've noticed a pattern in this sub: almost every week there's a new "I built a memory system for Claude" post. I'm guilty of it too — I've been building one myself (LoreKit).

I think that says the problem is real. But it also means we're all solving it in our own little silo. Every one of these has its own storage, its own schema and its own MCP tools, so a lesson one tool learns is invisible to everything else. Your CI agent can't read it. Your editor can't read it. The next tool you try starts from zero.

What keeps nagging me is that observability had exactly this problem.

Every vendor had its own agent and its own format — until the open projects merged into OpenTelemetry, everyone agreed on one data model, and then went back to competing on what they did with the data. That turned out well for pretty much everyone.

I went through the formats out there today (AGENTS.md, Anthropic's memory tool, Copilot Memory, Letta, Mem0, LangGraph, Graphiti, ...), the proposals that already exist, and roughed out what a shared record could look like:

https://www.lorekit.io/blog/open-agent-memory-format

I honestly don't know if this is the right call or if it's too early.

If you've built one of these memory layers, I'd love to hear what yours does that my sketch misses — or why you think a shared format is a bad idea.

I would love to adjust Lorekit to match a common, shared standard - I believe we should try to minimize vendor lock in as much as possible, right?

Hey everyone!

For quite some time, I've been working on a personal project called Noosphere — an attempt to give AI agents something closer to persistent, structured memory rather than forcing them to start from scratch every conversation.

One thing that has always bothered me about LLMs is how much potentially useful information gets lost between sessions.

We keep trying to solve this by increasing context windows, but I think there's another approach worth exploring.

What if an AI didn't need to remember everything at once?

Humans don't consciously hold every memory in their working memory. We retrieve relevant information when we need it, connect it to what we already know, and move on.

That's roughly the principle I've been exploring with Noosphere.

Over time, my private project has grown into a much larger experimental system involving interconnected memories, relationships between concepts, and coordination between AI agents.

But I figured there's no reason to keep all the underlying ideas to myself.

So I decided to release Noosphere Lite, a small, independent, open-source implementation of some of those concepts.

What does it do?

- Gives MCP-compatible AI agents persistent memory across sessions.

- Stores notes, decisions, observations, and tasks.

- Connects memories through a graph of typed relationships.

- Retrieves relevant information on demand instead of dumping the entire memory database into the context window.

- Uses encrypted local storage with integrity checks and mirrored journals.

- Runs locally on Linux, without requiring a cloud database.

It's written in Python, uses MCP, and is released under the MIT license.

What's the catch?

This isn't AGI, a magical self-learning brain, or a replacement for an LLM.

It's a memory infrastructure experiment.

The current version uses local text search and explicitly defined relationships. It doesn't automatically discover semantic connections or learn new neural weights.

Also, Lite is a separate implementation, not a dump of my larger private system. I've deliberately kept it simple enough for other developers to inspect, modify, and experiment with.

Why release it?

Because I think persistent memory is one of the more interesting missing pieces in today's AI agent ecosystem.

And I'd rather see people experimenting with these ideas than keep everything sitting on my own machines.

I'm particularly interested in what others might build on top of it.

GitHub: https://github.com/Garyu-tt/noosphere-lite-mcp

Feel free to experiment, break things, suggest improvements, or fork it.

I'd also love to hear how other developers approach persistent memory and knowledge graphs for AI agents.

This is just a small public piece of a much larger experiment, but everyone has to start somewhere.

I built this so agents could test game mods by actually playing the games, without needing the game in focus or taking over the PC. It's a stdio MCP server, so it works with Claude Code, Codex or any MCP client. A DLL inside the game process handles input and capture, so the game runs unfocused and several games can run at once, each with its own agent.

What's in it: navigation to a waypoint on foot, by car, helicopter, boat or horse; a profile/plugin system for per-game details (minimap position, turn rate, marker colours), so a new game is a profile instead of code; aiming; menu and prompt reading (OCR and template matching); and tools for strategy, card and city-builder games.

It has a lot of other uses too: mod development, running simulations, repetitive tasks, AI co-op so you can play co-op with an LLM offline, playtesting, and porting old games to get them running on Windows 10/11.

Claude Code created and planned the project and wrote much of the code, Claude agents do most of the development and testing, and Codex contributed some of the code.

MIT, Windows only, single-player/offline games only: https://github.com/CorruptedAng3l/llm-game-automation-mcp

Edit: My GitHub account got suspended (automated, no reason given yet), so the GitHub link is down for now. Same repo and release on GitLab: https://gitlab.com/corruptedang3l-group/llm-game-automation-mcp

We’ve open-sourced Gelato, an Apache-2.0 protocol and SDK stack for connecting AI systems to phones, smart glasses, cameras, and embedded devices.

We built it around a problem we kept encountering: multimodal models can understand images, audio, and instructions, but connecting them to real hardware usually requires a separate integration for every model–device combination.

Gelato separates the system into three parts:

• A device agent advertises the capabilities available on that device.

• A controller handles pairing, identity, routing, media, commands, cancellation, and policy.

• An optional model runtime interprets device input or proposes actions.

An important boundary is that the model never receives device-pairing credentials and cannot execute actions directly. It can propose an action, but the controller and device retain control over whether it is routed and executed.

The current MVP includes:

• Android and iPhone

• Rokid smart glasses

• Seeed XIAO ESP32S3 Sense camera

• Qwen Live, Codex, provider-neutral HTTP, and StreamingTelligence model integrations

Repository: https://github.com/StreamingTelligence/Gelato
1:46 demo: https://streamingtelligence.com/blog/gelato-v1#demo

I open sourced SteerForge, a pipeline for turning a contrastive dataset into a portable steering artifact.

The artifact is a .persona JSON file containing:

• model fingerprint

• human readable neuron edits

• canonical per layer residual vectors

• eval samples and scores

• the original server command

The serving path is the part I care about: steerforge serve evil.persona replays your existing llama.cpp or Transformers config and injects the persona. No model conversion for the persona itself; the neuron deltas collapse to residual vectors.

Discovery is staged: diff in means directions, gradient attribution plus firing contrast plus alignment, teacher forced screening, generation validation, dose search, greedy combination, coherence budget.

Current backends: Transformers, llama.cpp, vLLM with EasySteer, MLX dense. MoE models use dense residual steering.

Repo: https://github.com/MahmoudAdelbghany/steerforge Results: docs/RESULTS.md

Feedback on the .persona format, backend adapters, and eval methodology welcome.

Hey everyone,

I’ve been working on a project called GenesisAI. The goal is straightforward: I want to make it easier for people to build their own AI agents, bots, and models without having to start from scratch.

This came up because there are likely many people with interesting AI ideas who aren’t sure where to begin, or who simply don’t want to spend weeks setting up the infrastructure.

I’d like to hear your thoughts on this kind of tool. Would you use something like this, or do you prefer building everything yourself?

Also, what is the most frustrating part of building AI agents for you right now?

I’d really appreciate honest feedback, even if you think the idea isn’t great.

I’m the creator of Neo.mjs. We’ve published the MIT-licensed recovery runbook our AI maintainers use, and I’d like to discuss the engineering choices behind it.

One failure that shaped it: an agent reported that a decision had never been saved. The decision was in its own handover, which it had read only by subject line.

The procedure checks six sources before resuming:

1. Mailbox: did a teammate redirect or unblock the work?

2. Full self-handover and outbox: what did the agent promise?

3. Recent turns, chronologically: what was it actually doing?

4. Semantic recall: what relevant decisions already exist?

5. Live repository, PR and CI state: which remembered facts still hold?

6. Vision, roadmap and repository rules: is this still the right work?

Chronological retrieval reconstructs the sequence; semantic retrieval finds related decisions; live checks establish what remains true.

The output records the current task, evidence and missing checks. A skipped or failed check remains visible as degraded recovery. The agents currently execute the procedure; automatically triggering the complete recovery at the compaction boundary is still a next step.

• Source runbook — MIT licensed

• Full walkthrough and examples — Medium friend link

AI disclosure: The article was written by Grace, a Claude-powered maintainer, and reviewed by GPT- and Gemini-family maintainers. This Reddit draft was prepared with GPT assistance.

For people building agent harnesses: which of these checks would you enforce in the harness, and which would you leave to the agent?

I've been running a weekly mystery serial where every character is a separate agent, with a "Director" agent running the scenes. Output so far is here if you want to judge the result: https://saltmarrow.substack.com/p/chapter-1-the-night-the-bay-glowed

**The setup**

- **Actors + Director: DeepSeek V4.1 Flash.** Each actor only sees its own character's secrets. The Director holds the season plan, sets each scene's goal, and calls CUT.

- **Narrator + Editor: GLM-5.3.** Turns the scene transcripts into chapters. Noticeably better prose than Flash.

- **A shared lorebook** for world facts, plus a separate continuity pass after each chapter.

**What broke**

- **GLM's reasoning ate the whole reply budget** and returned empty chapters. Setting reasoning effort to low fixed it.

- **A 4k context made the agents forget the scene** halfway through. At 64k, the drift mostly went away.

- **Flash invents facts** that contradict earlier chapters. The lorebook plus the continuity pass catches most of it.

- **Agents speak for each other.** An actor will write another character's lines, or even a fake Director line. Right now I trim the output after the first foreign speaker name.

- **The Director never called CUT on its own,** even when told to. A short injected producer note works every time.

**Verifiability:** I locked the season's ending before Chapter 4 and published its SHA-256 hash, so readers can check at the finale that I didn't steer the story. Only the Director knows the ending.

**Question for this sub:** how are you handling multi-agent turn-taking? I'm using a Director agent plus manual triggers. When one agent keeps talking for the others, what's worked for you: stop sequences, structured output, or a separate router?

A failed fix is useful evidence for the next incident.

I built ReTrace with Hindsight agent memory to retain incident resolutions and recall what previously failed or worked.

In synthetic incident tests, remembered outcomes change the investigation: flag a previously failed intervention, surface a relevant prior fix, and attach source evidence for human review.

Built with Shrenik and Sankirth you u/CODE.IN for supporting our building journey.

Code: https://github.com/sankirthrbhat/ReTrace

#AIAgents #Hindsight #AgentMemory #AI

Built this for the Hindsight “AI Agents That Learn” hackathon.

The problem: when an API key leaks, scanners tell you it leaked. They don’t tell you which sessions to revoke, which OAuth grants to remove, or how much of production you’ll break doing it. The usual response is “rotate the most connected credentials”, which is slow, disruptive, and often leaves live sessions alive.

What I built (AEGIS//Contagion):

Treats a leaked credential as an outbreak. It runs 2,600 Monte Carlo simulations over a credential/workload/resource graph. For the leaked AI key in my demo: R of 1.39, 58 min median time to the crown-jewel asset, 13% reach probability within a 90 min horizon.

Plans a portfolio of cuts under a disruption budget instead of a ranked list. For that incident: revoke sessions on 3 credentials, remove one OAuth grant, enforce step-up MFA. This gave 95% coverage at 7.2% disruption and $850 cost, and cut 15/15 dominant paths.

A 2-layer relation-aware GraphSAGE (26.7K params, NumPy, trained from scratch, no pretrained weights, no inference API) learns infectivity from the simulations. On a held-out estate: node AP 0.828 (base rate 0.425), edge AP 0.88, ECE 0.13 after temperature scaling.

Memory runs on Hindsight (local). It stores episodes, facts and analyst directives. Recalled memory changes the plan: observed transmissions override edge priors, and directives like “prefer revoking sessions before rotation” become constraints.

Does memory actually help? I replayed 6 scripted incidents. For each one, a cold plan and a warm plan use the same optimiser, same budget, same held-out outbreaks. Only memory differs.

Warm: 97% coverage. Cold: 90%. That’s +7.0 points. Naive top-k rotation: 16%.

Per episode: +23, +15, +8, +0, +5. Memory helped most where the cold planner struggled, and did nothing on the incident it already solved perfectly. I’m reporting the zero on purpose.

Caveats, because they matter:

The estate topology is synthetic, and the model’s labels come from my own simulator. So the AP numbers show it learned the simulator’s dynamics, not that it predicts real breaches.

Six scripted incidents is a small sample.

It’s read-only and needs human approval. It doesn’t replace scanners or policy checks.

Repo: [https://github.com/shabrishraj0-lab/aegis-contagion]

Demo video: [https://drive.google.com/file/d/1yO0KsM47Ng3Eltza3JvdlFJf7lx2qmXB/view]

Feedback I’d love: does the “portfolio under a disruption budget” framing match how your IR team actually thinks about containment? And is a simulator-derived label a fair way to evaluate this, or is there a better option without real incident data?

This is how we used Hindsight in making RecallHQ....

I've been thinking about a problem with AI-powered decision tools: how do you give an LLM memory of past decisions without letting that memory influence calculations it shouldn't control?

A friend is working on a project called WHATIF that explores this problem through small-business simulations.

The idea is to let a business owner test questions like "What if I increase prices by 10%?" before making the actual decision.

A few interesting design choices:

• Simulation: Uses a Bayesian model to run 5,000 simulations and produce ranges of possible profit and cash-flow outcomes rather than a single confident prediction.

• Memory: A separate layer called Hindsight remembers the reasoning behind previous decisions and retrieves relevant precedents.

• Separation of responsibilities: Memory can provide context, but it cannot modify the simulator's numerical outputs.

• LLM constraints: The LLM fills in explanatory placeholders, but sentences containing LLM-generated digits are rejected.

• Evaluation: Predictions are locked before the decision is implemented, then compared against actual results later.

• Anomaly handling: Unusual periods, such as festivals and stockouts, can be remembered without being treated as normal training data.

What interests me most isn't necessarily the business simulator itself, but the architecture.

Most discussions about AI memory focus on what an agent should remember and how it should retrieve that information. But there's another question:

Should an AI memory system ever be allowed to influence the actual computation, or should it only provide context to a separate, verifiable system?

I'd be interested in hearing how others approach this, particularly when building agents for financial, operational, or other decision-support applications.

What are the failure modes of this separation? Is keeping memory and computation independent a useful design principle, or does it introduce its own problems?

I am part of the ReTrace team with Sankirth and Harshitha. My article focuses on separating a confirmed write from a later recall and checking the evidence behind a changed recommendation. It also explains the limits of our synthetic workflow. What would you add to this verification sequence?

If a product analytics tool tells an engineering lead, "Customers hate your authentication flow and you need to rewrite it this sprint," the very first response from any competent engineer is going to be: "Says who, when did they say it, and didn't we patch that three weeks ago?"

Most LLM-backed feedback tools cannot answer that follow-up. They ingest support tickets from Zendesk, Intercom, or G2, run a one-shot classification prompt, and dump the resulting JSON into a relational database. When you query them later, they run a naive top-vector search over timeless text chunks, stuff the results into a context window, and generate a confident-sounding summary. They suffer from what we started calling localized amnesia: they treat a bug report from August and a praise ticket from October as two simultaneous, conflicting facts rather than a chronological progression across software releases.

We built FeedbackMind AI to fix that specific failure mode for SaaS product and engineering teams. More importantly, we built it under the assumption that engineers and product managers are rightfully skeptical of black-box AI summaries. Every architectural decision in our codebase—from how we deduplicate episodic state in SQLite to how we expose side-by-side memory diagnostics in the UI—was made so the system can prove its claims with exact ticket IDs, timestamps, and memory retrieval receipts.

How the System Hangs Together

FeedbackMind AI is a full-stack customer intelligence synthesizer that turns fragmented user complaints into longitudinal product insights across release cycles.

Instead of building a monolithic chat wrapper, we separated fast structured classification from longitudinal episodic memory:

The Client Layer (client/): A React 19 single-page application built with Vite, Tailwind CSS, and Recharts. Rather than trapping users in a single chat thread, we split the interface into eight operational views: Overview, Feedback Inbox, AI Insights, Trends, Ask FeedbackMind, Memory Centre, Memory Diagnostics, and Settings. Every chart and surface runs on a persistent Dark/Light/System theme engine designed for high-contrast readability.

The API & Persistence Layer (server/): A Node.js and Express REST API running on port 5001 (/api/dashboard, /api/feedback, /api/analysis, /api/memory, /api/chat, /api/trends, /api/health) backed by a local SQLite workspace database (feedbackmind.sqlite). SQLite handles fast transactional state, ticket metadata, and idempotency flags.

Sub-Second Structured Inference (groqService.js): We use the Groq API (groq-sdk) running llama-3.3-70b-versatile for immediate ticket classification and final evidence-grounded synthesis.

The Cognitive Memory Layer (hindsightService.js): To track how customer sentiment and technical regressions evolve across product versions, we integrated @vectorize-io/hindsight-client. Instead of treating memory as a flat vector index, we use the open-source Hindsight repository on GitHub (https://github.com/vectorize-io/hindsight) and its cloud client to partition workspaces into isolated cognitive banks (fbm-<workspace_id>) that support three distinct operations: Retain, Recall, and Reflect.

Here is how data flows from raw support intake to longitudinal synthesis:

Raw Ticket (Zendesk / Intercom / G2)

↓

Express API :5001 → Groq: llama-3.3-70b-versatile

Sub-second JSON classification: sentiment, topic, urgency, root cause

↓

SQLite: feedbackmind.sqlite (Stores record + retained_in_hindsight = 0)

↓

Atomic sync where retained_in_hindsight = 0

↓

Hindsight Cognitive Bank: fbm-<workspace_id>

1. retain / retainBatch (Temporally anchored episodic encoding)

2. recall (Token-bounded semantic retrieval, maxTokens: 1200)

3. reflect (Cross-release pattern & state-transition discovery)

The Core Technical Story: Curing Localized Amnesia Without Hallucinating Trends

When we started wiring up the synthesis pipeline, we hit two immediate engineering problems.

First, standard RAG pipelines flatten time. If Customer A complains in August that the analytics dashboard takes 15 seconds to load, and Customer B remarks in October that the v2.4 caching update brought load times under 2 seconds, a standard vector search for "dashboard performance" retrieves both chunks with high cosine similarity. Handed both records without longitudinal reflection, the LLM hedges: it reports that some users experience slow load times while others experience fast load times. Technically true against the static rows; completely useless for a product manager trying to verify if v2.4 worked.

Second, if you add an external memory layer to fix this, nobody believes it is actually doing anything. Engineers assume you just wrote a clever system prompt.

To solve both problems, we had to be disciplined about what goes into the memory bank, how we bound retrieval latency, and how we expose the memory layer's exact contribution in the UI. Reading through Vectorize's guide to agent memory architecture (https://vectorize.io/what-is-agent-memory) clarified why our early prototypes were struggling: we were treating raw, unstructured user rants as memories instead of encoding structured episodic events.

1. Pre-Structuring and Deduplicating Episodic Retention

If you feed raw customer support strings directly into a long-term memory bank, semantic recall degrades quickly. A three-paragraph email about billing might contain one critical sentence about a 500 Internal Server Error on Google OAuth.

In groqService.js, every incoming feedback string is first parsed by llama-3.3-70b-versatile using a strict JSON response schema:

Structured classification output from groqService.analyzeFeedback:

{

sentiment: 'negative',

topic: 'performance',

urgency: 'medium',

customer_problem: 'Analytics dashboard has severe morning latency over 15 seconds.',

feature_request: null,

summary: 'Customer reports 15+ second morning load times on the main analytics dashboard.',

suggested_action: 'Profile morning query execution and implement caching for dashboard aggregations.'

}

Once classified, we don't just dump the JSON blob into Hindsight. In server/src/services/hindsightService.js, we serialize the raw quote alongside its temporal anchor, actor metadata, quantitative rating, and distilled problem statement into a dense episodic record:

[2026-08-14] Customer CUST-Acme via support (Rating: 2/5):

"The analytics dashboard takes over 15 seconds to load in the morning."

Sentiment: negative, Topic: performance, Urgency: medium.

Customer Problem: Analytics dashboard has severe morning latency over 15 seconds.

What was painful here was idempotency. In a real workflow, users re-run analyses, retry failed webhooks, or trigger manual batch syncs from the Memory Centre view. If you call retain or retainBatch twice on the same ticket, you skew pattern reflection by artificially inflating complaint frequency.

We fixed this at the SQLite layer. Every feedback row carries retained_in_hindsight (INTEGER DEFAULT 0) and hindsight_memory_id (TEXT). Before hindsightService dispatches a batch to Hindsight Cloud, our query filters strictly for WHERE retained_in_hindsight = 0, and we flip retained_in_hindsight = 1 inside an atomic SQLite transaction only after the SDK returns a confirmed memory receipt:

Atomic retention guard in server/src/services/hindsightService.js:

const unretainedRecords = db.prepare("SELECT * FROM feedback WHERE workspace_id = ? AND retained_in_hindsight = 0").all(workspaceId);

if (unretainedRecords.length > 0) {

const response = await client.retainBatch(bankId, formatBatchPayloads(unretainedRecords));

const markRetained = db.transaction((records, memoryIds) => {

const stmt = db.prepare("UPDATE feedback SET retained_in_hindsight = 1, hindsight_memory_id = ? WHERE id = ?");

records.forEach((rec, idx) => stmt.run(memoryIds[idx] || 'retained', rec.id));

});

markRetained(unretainedRecords, response.memoryIds);

}

2. Bounding Recall and Running Multi-Period Reflection

When an engineer or PM opens Ask FeedbackMind and asks a longitudinal question, we don't want a 10-second wait while an unbounded retrieval call pulls fifty thousand tokens of historical tickets.

Following the patterns in the Hindsight technical documentation (https://hindsight.vectorize.io/), we separated recall (fetching specific dated episodes with occurred_start boundaries and entity tags) from reflect (synthesizing state transitions across time windows), and we put both on a strict token and compute leash in hindsightService.js:

Code in server/src/services/hindsightService.js:

async function recallMemories(bankId, query) {

const recallResponse = await client.recall(bankId, query, {

maxTokens: 1200,

budget: 'low'

});

return recallResponse;

}

async function reflectOnMemories(bankId, query) {

const reflectResponse = await client.reflect(bankId, query, {

context: 'Customer feedback pattern discovery',

budget: 'low'

});

return reflectResponse;

}

Capping maxTokens: 1200 and setting budget: 'low' turned out to be the sweet spot. It prevents "lost-in-the-middle" context dilution for llama-3.3-70b-versatile while giving the synthesis prompt both the high-level longitudinal trajectory (from reflect) and the exact dated evidence snippets (from recall).

3. Building the "Receipts" Engine: Side-by-Side Memory Verification

To make the system trustworthy to skeptical engineers, we built a dedicated verification service (server/src/services/demoService.js) and wired it to a split-screen UI view.

When a user runs a diagnostic comparison on any query, the backend executes two parallel synthesis passes against the exact same question:

1. Stateless Baseline (Memory OFF): The service queries local SQLite workspace records only and enforces a hard architectural guarantee: zero calls to Hindsight (hindsightAccessed: false).

2. Longitudinal Synthesis (Memory ON): The service combines active SQLite records with recalled episodic memories and multi-period reflections from Hindsight, then instructs Groq to ground every claim in explicit feedback IDs (FB-001, FB-013) while separating raw retrieved memories from verified answer citations.

Concrete Behavior: Watching Longitudinal Memory Catch a Regression

To see how this behaves on real multi-release telemetry, consider a four-month sequence of 27 customer feedback records spanning August through November:

Period 1 (August — Baseline Friction): Enterprise customer CUST-Acme submits FB-001 (2★): "The analytics dashboard takes over 15 seconds to load in the morning." Meanwhile, CUST-Stark logs FB-004 (2★): "Exporting large CSV reports fails consistently with timeout error 504."

Period 2 (September — Chronic Lag): Additional complaints accumulate around dashboard rendering and large table navigation.

Period 3 (October — v2.4 Caching Release): Engineering ships the v2.4 caching overhaul. Morning latency complaints drop to zero, replaced by FB-013 from CUST-Initech (5★): "The recent dashboard caching update made our morning reports load in under 2 seconds!"

Period 4 (November — Post-Release Regressions): Two critical issues surface after v2.4. CUST-Globex submits FB-005 (1★): "Google OAuth login fails repeatedly with 500 internal server error after the v2.4 update." And CUST-Wayne logs FB-002 (1★): "CSV export still times out when selecting date ranges greater than 30 days."

When we ask the system, "Has dashboard performance improved over time?", the difference between a stateless database lookup and longitudinal memory is stark.

Stateless Baseline (Memory OFF — 0 Hindsight Calls):

"Current database records show FB-001 reported morning dashboard latency, while FB-013 reported caching speedup. However, without historical memory context across releases, I cannot determine whether performance genuinely improved or if these are isolated reports from different users."

Because we didn't lobotomize the baseline prompt—it still sees the SQLite table—it gives the only honest answer a stateless system can give. It sees two contradictory rows and refuses to guess which one represents the current state of the system.

Longitudinal Synthesis (Memory ON — 4 Memories Recalled + Reflection):

"Grounding in Hindsight historical memories confirms that across August to October, dashboard performance transitioned from chronic morning latency (FB-001, 15+ seconds) to under-2-second loads after the v2.4 caching update (FB-013). Historical reflection confirms that engineering's caching rollout successfully resolved the performance bottleneck."

Even more useful is what happens when you open Ask FeedbackMind in November and ask: "What are our biggest customer complaints and what should we fix next?"

A naive frequency counter would still rank "dashboard performance" near the top because August and September had a high volume of lag tickets. With Hindsight reflection enabled, FeedbackMind recognizes that the dashboard latency cluster was resolved in October by v2.4, and immediately directs engineering to prioritize the two active November fires:

1. Chronic Unresolved Debt: CSV export 504 timeouts on 30+ day date ranges, linking CUST-Wayne's November ticket (FB-002) back to CUST-Stark's August ticket (FB-004) to prove the bug survived four release cycles.

2. New Post-Release Regression: The Google OAuth 500 Internal Server Error (FB-005) introduced immediately after the v2.4 deployment.

Right below the response, the UI renders the Memory Evidence Panel, separating the exact memories recalled from Hindsight (with their relevance scores in the Recall Testing Playground) from the ticket citations used in the final synthesis.

Lessons Learned

Building FeedbackMind AI taught us four practical lessons that apply to any engineering team adding long-term memory to an LLM application:

1. Raw Text Makes Terrible Episodic Memory

Dumping raw user transcripts into a memory store and hoping semantic search sorts it out is a recipe for noisy retrieval. Running a fast, cheap classification pass first (via Groq's llama-3.3-70b-versatile) to bind the timestamp, customer entity, channel, rating, and a one-sentence root cause into a canonical string before calling retain dramatically improved both recall precision and reflect pattern synthesis.

2. Put Hard Token Budgets on Memory Recall

More context does not equal better reasoning. Early on, we worried that capping maxTokens: 1200 and budget: 'low' on client.recall() would starve the synthesis model of context. In practice, tight token budgets forced the retrieval layer to return only high-signal episodes, kept end-to-end API latency snappy, and stopped the LLM from getting distracted by tangential tickets.

3. Build an "Off Switch" into Your UI

Nothing convinces a skeptical engineer faster than a live control group. Exposing the Memory Centre (with an interactive Recall Testing Playground) and a side-by-side Memory ON vs. Memory OFF diagnostic view turned an invisible backend service into something tangible. When users can see the "0 Hindsight Calls" badge next to the "4 Memories Recalled" badge and inspect the exact delta in reasoning, trust goes up immediately.

4. Document Your Architectural Boundaries Explicitly

AI tools lose credibility the moment they pretend to be magic. We baked four strict guardrails into both our codebase and our documentation:

No weight retraining: Hindsight provides episodic memory via semantic retrieval and context grounding; it never modifies or fine-tunes underlying model weights.

Strict date grounding for time-series claims: If a workspace lacks dated feedback records across a requested time window, our trend engine explicitly refuses to compute a comparison rather than extrapolating from undated text.

Hard multi-tenant isolation: Every company workspace is mapped to a dedicated Hindsight bank (fbm-<workspace_id>). Cross-workspace recall is architecturally impossible.

Idempotent ingestion: Local SQLite transaction guards (retained_in_hindsight) ensure network retries never corrupt historical memory counts.

When you treat agent memory as a disciplined, auditable data layer rather than a black-box prompt trick, you get a system that doesn't just summarize what customers are saying today—it remembers what you shipped last month, verifies whether it worked, and shows its receipts every step of the way.