Breathe-memory takes a different approach: associative injection. Before each LLM call, it extracts anchors from the user's message (entities, temporal references, emotional signals), traverses a concept graph via BFS, runs optional vector search, and injects only what's relevant — typically in <60ms.

When context fills up, instead of summarizing, it extracts a structured graph: topics, decisions, open questions, artifacts. This preserves the semantic structure that summaries destroy.

The whole thing is ~1500 lines of Python, interface-based, zero mandatory deps. Plug in any database, any LLM, any vector store. Reference implementation uses PostgreSQL + pgvector.

https://github.com/tkenaz/breathe-memory

We've been running this in production for several months. Open-sourcing because we think the approach (injection over retrieval) is underexplored and worth more attention.

We've also posted an article about memory injections in a more human-readable form, if you want to see the thinking under the hood: https://medium.com/towards-artificial-intelligence/beyond-ra...

Comments URL: https://news.ycombinator.com/item?id=47530306

Points: 6

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=46780342

Points: 2

# Comments: 6

How do you handle false positives from mutation strategies like Base64 or token smuggling? In my experience, a lot of "successful" jailbreaks from automated fuzzing don't actually produce harmful outputs — the model just gets confused and outputs gibberish that technically matches a keyword filter.

Also curious about your payload curation — are these tested against specific model families, or generic? The attack surface differs quite a bit between Claude, GPT-4, and open-source models.

The local-first angle is smart. Most enterprises I've talked to won't send their system prompts to a third-party SaaS for obvious reasons.

The Memory Problem: Three Layers Beat One Anthropic's solution is a progress.txt file plus git history. It works, but it's flat. We use three layers instead: Layer 1: Model actualization. A semantic memory system that helps the orchestrating agent understand "what are we building and why." This is the soft layer. Layer 2: Think Jira meets Git, but for AI agents. Structured storage of tasks with metadata: blockers, decision paths, dependencies, progress state. The agent doesn't just know what to do next — it understands the logic of how we got here and where we're going. Layer 3: Git. Non-rotting charm of the classic version control. The key insight: separating "understanding" from "tracking" from "versioning" reduces cognitive load on the agent.

On Premature Victory: Prompt Engineering > Programmatic Constraints Anthropic's approach to the "agent declares victory too early" problem is a JSON file with passes: true/false flags and strongly-worded instructions not to edit it. Our approach: make the supervising agent responsible for proper task breakdown into what we call atomic structures — concrete enough to be unambiguous, but not so detailed that they micromanage the implementation. Completion criteria live in the sub-agent's prompt, not in the task definition. The sub-agent knows: tests must pass, lint must be clean, migrations applied. The supervising agent doesn't repeat this for every task — it's baked into how the sub-agent operates. Yes, this requires better prompts. But it also produces more robust behavior. The agent develops something closer to judgment rather than just following rules it's been told not to break.

The Multi-Agent Question: Minimum Viable Agents Anthropic asks whether a single general-purpose agent or multi-agent architecture works better. Our answer: use as few agents as possible. Every handoff between agents is a potential break in reasoning continuity. For small projects or clean microservice architectures: two agents. A strategic orchestrator and a coding agent. For complex systems: add a code reviewer. Three agents maximum.

What Anthropic Missed: Human-in-the-Loop as Synchronization The Anthropic piece treats human involvement as bookends — you provide the prompt, you review the result. We built in a different way: the user can intervene at any point, the sub-agent's completion report doesn't reach the orchestrator until the user validates it. This started as a bug. It became our favorite feature. Why it matters: We do not limit autonomy. It's more about synchronizing understanding between human and AI at critical checkpoints.

What We Haven't Solved Yet Honesty time: end-to-end testing is still manual for us. Lint passes, unit tests run, but visual verification happens in a separate session with a human watching. Anthropic's Puppeteer integration for browser testing is genuinely useful. We haven't automated that layer yet. It's on the roadmap, right after "pay rent" and "sleep occasionally."

The Takeaway Long-running agents are hard. Anthropic's solutions work. Ours work differently. The philosophical difference: they lean toward programmatic constraints (JSON files, explicit flags, structured formats the model "can't" edit). We lean toward better task decomposition and human checkpoints. Neither approach is wrong — different contexts, different constraints. We're sharing what worked in ours. If you're building something similar, maybe it saves you a few iterations.

Comments URL: https://news.ycombinator.com/item?id=46097759

Points: 1

# Comments: 0

Generic summaries or RAG results often feel useless because models optimize for "what would be useful to explain to anyone" rather than "what was significant in this specific context."

What worked for me: separate semantic context (the "why are we here" layer) from structured tracking (decisions, blockers, dependencies). The semantic layer captures salience — what mattered emotionally or strategically — and the tracking layer handles facts or even snapshots of the latest state of the process.

The model does not have to guess what was important. The memory architecture can encode it.