r/agenticAI

I’ve been working on Curion, a memory system for AI agents built around a simple idea:

The main agent should not have to manage memory manually.

Most AI agents are useful inside a single session, but they still lose important context between sessions. Project decisions, implementation history, constraints, unresolved tasks, and previous reasoning often disappear unless I manually write long handoff notes.

At first, the obvious solution seems to be giving the agent memory tools: save, search, update, delete, edit.

But that creates a second problem.

If the main agent has to manage memory by itself, it can easily receive too many raw memories. Some are relevant, some are stale, some are only partially related, and some may conflict with newer information. The agent then has to spend context and attention deciding what matters.

That creates context bloat.

Curion takes a different approach.

I think of Curion as a librarian for AI agents.

A good librarian does not just throw every possibly related book at you. They understand the question, know how information is organized, filter what matters, notice conflicts, ask clarifying questions when needed, and return the most useful context.

That is what Curion is meant to do for agent memory.

The main agent only needs to say:

“I want to remember this.”

or

“I need to recall something about this.”

Curion handles the rest.

When saving memory, Curion can decide how information should be stored, whether it relates to existing records, whether something should be updated, and whether a conflict requires clarification.

When recalling memory, Curion does not just dump raw search results into the agent’s context. It retrieves relevant records, evaluates what is useful for the current task, synthesizes the context, and clearly says when nothing relevant was found.

The analogy I use is human memory. When we want to remember something, we do not consciously search through billions of memories. We ask for what we need, and the relevant memory appears automatically beneath the surface.

Curion is built around that same interface idea for AI agents.

It is project-first: Curion focuses on the project the agent is currently working in. It can also use cross-project recall when information from another project is actually relevant.

Curion is not just a save/search tool. It is a collaborative memory layer: a specialized memory librarian that helps agents remember responsibly, reduces context bloat, and gives the main agent only the context it actually needs.

GitHub: https://github.com/geanatz/curion

NPM: https://www.npmjs.com/package/@geanatz/curion

Portfolio: https://geanatz.com

I just open-sourced Context Warp Drive, a continuity engine for LLM agents.

Repo: https://github.com/dogtorjonah/context-warp-drive

Right now, the industry has two bad ways of dealing with long agent horizons:

1. Just ride the 1M-2M context window.
2. Use an LLM to summarize older messages ("compaction").

LLM summaries are inconsistent, they burn an extra model round-trip, they quietly drop the exact identifiers your agent needs (UUIDs, paths, hashes), and worst of all, they constantly rewrite the prefix—which trashes your provider prompt cache.

This library takes a different approach: deterministic folding.

As the agent works, older context is folded into deterministic skeletons. Instead of linearly bloating to the ceiling, the active context sawtooths—building up efficiently, then dropping back down to a clean floor without losing continuity.

Why not just use the 1M token window?

Because 95% of what an agent carries with it on a long task isn't needed right now. It's looking for the needle in the haystack, but massive context windows force it to carry all the hay.

A larger window raises the ceiling, but it doesn't move the floor where models reason best. Long-context evals keep showing the same thing—models do not use giant contexts as cleanly as the marketing numbers imply:

• Lost in the Middle — models degrade when needed information is buried in the middle of long context.
• RULER — large drops as context length and task complexity increase, even for models advertised as long-context.
• Context Length Alone Hurts LLM Performance Despite Perfect Retrieval — length itself hurts performance even when retrieval succeeds.
• Intelligence Degradation in Long-Context LLMs — models can collapse past critical context thresholds even when input remains relevant.

By keeping the agent deterministically folding with a warm cache and a low context band, you keep it snappy, cheap, and focused. You leave the hay behind until it's actually needed.

How Context Warp Drive works:

• The Rebirth Seed: The continuity package that makes the full reset possible. It carries the recent user and AI messages, what the agent was actively working on and editing, its execution plan state, preserved exact identifiers from the full trace, and episodic context from earlier work. It is not a vague summary—it is a structured, deterministic snapshot the agent can wake up from and continue seamlessly.
• Cache-Hot Appending: As the agent works, older turns fold into compact bands that append onto the rebirth seed. The context builds up over time, but because the seed stays byte-identical, you pay for cheap cache reads turn after turn instead of expensive fresh inputs.
• The Sawtooth Reset: You can't append forever. When measured input pressure hits your configured ceiling, the engine performs the full sawtooth—the context drops back to a fresh rebirth seed and the cycle continues from a low-context floor.
• Zero-LLM Folding: Raw chat history stays preserved as the source of truth, but the model sees a deterministic compact view. Tool calls, paths, receipts, retained reasoning, and exact identifiers are all preserved without asking another model to summarize anything.
• Episodic Recall: When the agent re-touches a path or concept from before the reset, the engine pages the relevant folded detail back in. The agent doesn't carry all the hay—it pulls it back when it matters.
• Task Rail: I also included a portable execution primitive called TaskRail. It keeps long-horizon plan state outside the prompt: steps, progress, acceptance criteria, and serializable checkpoints. Combined with folding and rebirth seeds, the agent stays low-context while still knowing exactly where it is in a multi-step workflow.

What's in the repo:

• Core folding engine, provider-agnostic across Anthropic content blocks, OpenAI-style tool_calls, and Gemini parts.
• Anthropic prompt-cache breakpoint helpers to maximize read-hits.
• Raw rebirth seed renderer.
• Model-aware context budget resolver.
• Fold recall and episodic recall (with an optional SQLite episode store).
• Portable Task Rail state machine.
• Gemini CLI and Codex CLI folding adapters.

There are a lot of knobs you can tune, but the core philosophy is the same: use the 1M window as safety headroom, not as the operating band.

(Not on npm yet—install from source for now.)

I've been running this in my own multi-agent orchestration stack for months and completely dropped LLM compaction. The difference is fundamental: the agent stops treating context as a giant backpack and starts treating it like a paged working set—small, hot, recoverable, and always grounded in the raw trace.

Been working on something which im deciding to call Dexi - a proactive agent to help you get stuff done. The problem it solves: you're juggling multiple clients or projects, and every context switch means re-checking calendars, todos, and notes scattered across your tools. Dexi now keeps a live picture per client/project deadlines, open tasks, recent changes and when something shifts (a cancellation, a new due date), it updates everything related and tells you what changed instead of you hunting for it. Switch contexts, everything's already current.

I've been running my own week on it daily through beta and it's the stickiest thing we've built. It's free to try right now, tryna get it out this sunday https://discord.com/invite/7VRZpSZGFN

All feedback welcome!!!

i wanted to see which ai harness was the best because there are a lot of them(pi, opencode, Hermes agent), so I(mostly Claude) made this benchmark because Claude told me there was no benchmark.

I set it up to test them while keeping the model constant (using Qwen 3.5 9B). I don’t know if it works or how viable it is but it is interesting.

Here is the repo if you want to look: https://github.com/ya5h-P/harnessbench

you can edit fork and change this because yo are probably more knowledgeable than m

19-year-old Chinese student Zhang Wei built an AI-powered traffic radar using Claude, spending only around $20 and one month to develop the system.

According to the story, the system connects to a camera and detects vehicle speed in real time. When a car exceeds the limit, the AI records a video clip, reads the license plate, identifies the owner, and automatically sends the fine through email.

What makes this interesting is not just the price tag, but what it represents. AI tools are making it possible for individuals to build products that once required full engineering teams, expensive hardware, and long development cycles.

I built a small free macOS tool for reviewing Codex sessions using the Codex desktop app. Are people here using anything similar to improve their AI coding workflows?

After longer Codex runs, I kept finding that the transcript was technically available, but hard to review.

The things I wanted to inspect were:

- What changed

- Which files were touched

- Where tokens went

- Which tool calls mattered

- Whether the prompt/context was good enough to reuse

- What context would be useful to share during code review

So I made BuildrAI, a local-first app that turns Codex session artifacts into timelines, token usage, prompt/session evaluation, changed-file context, and shareable reports.

I’m curious how other people are handling this.

Do you review Codex sessions after the fact, or do you mostly trust the final diff?

I have been working on a project called Pessoa, an agentic framework designed to run locally.

I first just wanted to learn how to add a memory layer (how to use the mem0 Python library) when using Ollama but decided to expand into something bigger.

So, I decided to build a modular system that acts as a "nervous system" for local LLMs.

By being modular, I separate the inference engine from memory, tools, and the frontend.

This way, if future users want to change Ollama for vLLM, change LLM, or change the frontend for something different from Streamlit, they can use it easily.

Key features:

- Frontend: Used Streamlit to make a ChatGPT like front end.

- Memory: Uses mem0 + Qdrant for long-term memory, independent of the model.

- Tools: Includes a FastAPI wrapper and an MCP (Model Context Protocol) server for tool calling.

- Skils: Uses a markdown-based pattern to inject system instructions (like Claude skills).

It is open-source, free to use, and designed as a blueprint rather than another bloated framework (<1200 lines of code).

GitHub: https://github.com/tiagomonteiro0715/pessoa

I used n8n to automate order status updates by connecting a webhook to Google Sheets and routing emails with Gmail - saves me a ton of time

More automations: Join our community: https://go.phonezait.de/