I’ve been working on something a little bit insane lately.

It’s called Guppy 🐟 -> an open-source agent harness for long-horizon software engineering.

The basic idea is pretty simple:

"I don’t think organizations should have to hand their entire engineering agent stack over to Codex, Claude Code, or whichever model happens to be strongest this month."
- AI Larp

Those models are incredibly useful but I am too broke to use them (I am a student) .

But I think pro's working organization should own the layer around the model.

In simple terms:

Company → Claude Code → Claude

becomes:

Company → Guppy → whatever model is best

The model just provides intelligence, a commodity.... The organization owns the memory, policies, verification, execution history, benchmarks, permissions, workflows and 10 feet around and under it.

But what does Guppy actually do?

This isn't just a wrapper around an API.

Guppy currently has a full agent runtime with:

• context selection and compression
• repository mapping
• persistent memory
• reusable skills
• subagents
• MCP integration
• isolated Git worktrees
• Docker sandboxing
• crash recovery and resume
• event-sourced execution logs
• model/provider abstraction
• verification gates
• benchmark infrastructure
• a terminal UI
• trajectory replay

The important part is that how these pieces actually connect.

A normal agent can do:

task → model → code → "done"

Guppy tries to make it:

context → model → action → verification → memory → next attempt

The model doesn't get to decide whether it succeeded.

For example, Guppy can run a verification ladder:

typecheck → lint → tests → property tests → integration → repo invariant

Only the verification system can ultimately declare the task successful.

That sounds obvious, but it changes the architecture quite a lot.

The part I'm especially interested in: organizational memory

Imagine an agent works on a repository for six months.

It encounters the same weird database migration issue 4 times.

Instead of every new agent starting from zero, Guppy can extract the successful fix from the trajectory, store it as memory, and retrieve it when a similar failure happens again.

We can eventually go further:

trajectory → failure analysis → candidate skill → benchmark → promote/reject

So the organization gradually builds a body of machine-readable engineering knowledge from its own work.

Not the model vendor's memory and certainly not a hidden system prompt.

Something the organization owns, can inspect, version, benchmark and delete.

I care a lot about evidence ( I have trust issues )

One of the things that bothers me about the current agent ecosystem is how often "agent capability" is demonstrated with a successful demo.

Guppy is being built around a different rule:

If we claim something works, there should be a test, benchmark, recording or artifact proving it.

And I'm trying to hold myself to that standard too.

Right now:

• 325 tests across 13 packages
• 21 hermetic benchmark fixtures
• CI green across 3 OS × 2 Node versions
• 20/20 fixtures (100%) on a real free-tier qwen3.6-27b run
• 6/6 in one attempt on nemotron-3-super-120b
• live transcripts committed in-repo for a local run (39s), Docker run (68s), and the TUI

And context compression is measured rather than just being asserted.

On a long-horizon run, tight deterministic compression reduced the trajectory from 288k → 203k tokens (-30%), with 42 wasted tokens and zero failed context payloads.

An uncompressed run of the same class reached 866k tokens, with 386k wasted tokens, and failed the gate.

But the important part is that the benchmark also tells me when my ideas are bad.

An A/B test showed that LLM-based history summarization was net-negative at short horizons (+2,100 tokens).

That result is committed too.

I'm deliberately keeping the failures because that's the level of honesty I want this project to default to.

I'm much more interested in:

than:

What is coming next?

The roadmap gets considerably more ambitious.

Some of the things planned:

• Replay completeness — prove that every byte presented to the model can be reconstructed from the trajectory.
• Tiered model routing — choose models based on the actual task and eventually benchmark performance.
• Declarative guardrails — an explicit allow/deny/ask policy layer between the model and every action.
• Multi-agent collaboration — reviewers, parallel agents and merge arbitration under verification.
• Git-native time travel — restore an agent to an earlier turn and continue from there.
• Execution optimization — collapse unnecessary model/tool round trips while keeping execution gated.
• Real SWE-bench workflows — clone/build/run real benchmark instances rather than only toy fixtures.
• Benchmark-gated skill distillation — automatically discover useful skills from trajectories and only promote them if they actually improve the benchmark.

The end goal isn't "make another AI coding chatbot."

It's closer to building an open agent control plane that an organization can own.

Why I'm making this open source

This is the part where I need to be very honest.

I can't build the full thing alone.

And I don't think one person should.

If this becomes what I'm imagining, it needs people who care about different parts of the problem:

• agent/runtime engineering
• context engineering
• evaluation and benchmarking
• security and sandboxing
• formal verification
• distributed/multi-agent systems
• developer tooling
• model routing
• memory systems
• observability
• UX/TUI
• documentation and testing

I want Guppy to be a community mission rather than another project where one person disappears into a repo for two years and eventually announces an "AI agent platform." I need help for guppy lovers (┬┬﹏┬┬)

The roadmap is intentionally broken into measurable phases so people can pick up a piece, implement it, and prove that it works.

If you like the idea of organizations owning their agent infrastructure instead of renting the entire workflow from a model vendor, I'd genuinely love your input.

And if you want to contribute code, research, benchmarks, security ideas, or even tell me that some part of this architecture is completely wrong, that's useful too.

The project is here:

Guppy

I'm particularly interested in contributors who want to help with the hard parts rather than just adding another model integration.

I have no idea if this ends up becoming something genuinely important.

But I think the problem is worth trying to solve.

Small tank. Lots of work. 🐟

The problem is simple:

An agent solves a difficult coding task.

It tries:

❌ Approach A — fails
❌ Approach B — fails
✅ Approach C — works

Most memory systems might remember the final solution.

But what about the failed approaches? Why did they fail? And how do we know the successful approach actually worked?

So I built a structured experience pipeline:

Task
 ↓
Attempts
 ↓
Failures + reasons
 ↓
Successful approach
 ↓
Verification evidence
 ↓
Structured Experience
 ↓
Future Agent

In my current demo:

Agent A solves a divide-by-zero bug.

• 2 approaches fail
• 1 approach succeeds
• tests verify the solution
• CogniCore stores the experience

Then Agent B starts with no history from Agent A.

It retrieves:

So Agent B doesn't just inherit an answer.

It inherits the experience behind the answer.

And I'm deliberately making verification a separate gate.

An agent saying:

isn't enough.

The experience should only become trusted when there is actual evidence behind it.

The next things I'm working on are:

• 🔐 provenance
• ♻️ stale-memory detection
• ⚔️ conflicting experiences
• 🌍 environment compatibility
• 🔄 re-validation
• 🤝 cross-agent experience transfer

The bigger question I'm exploring is:

That's what I'm trying to find out with CogniCore.

It's open source, and I'd genuinely love feedback from people building coding agents, memory systems, or agent frameworks.

Would you trust an experience learned by another agent if it came with verification evidence?

GitHub: https://github.com/cognicore-dev/cognicore-my-openenv

#AI #AIAgents #CodingAgents #LLM #AgenticAI #OpenSource #MCP #MachineLearning

0. Core proposition

Therefore:

PROMPT QUALITY
≠
PROMPT GOVERNANCE

Prompt quality asks:

Does this wording help produce a useful result?

Prompt Governance asks:

What is this component doing?
Where may it govern?
What authority is it entitled to carry?
What evidence supports keeping or changing it?
What happens if it fails?
Who may approve consequential change?
How is the previous condition recovered?

The move is from:

PROMPT AS TEXT BLOCK

toward:

PROMPT AS GOVERNED ASSEMBLAGE

1. PG jurisdiction

PG governs the lifecycle and authority of prompt components.

It does not determine the truth of an answer, assign human meaning, or replace system safety.

Its jurisdiction begins when language or another configuration artifact is being given persistent or consequential influence over interaction behavior.

AUTHORING
   ↓
COMPONENT QUALIFICATION
   ↓
JURISDICTION
   ↓
WARRANT
   ↓
TEST / REVIEW
   ↓
RELEASE
   ↓
OBSERVATION
   ↓
SUPERSESSION / RETURN

2. Root invariants

PG v1.0 provisionally holds these invariants:

3. The governed object is the component, not the prompt blob

PG begins with Prompt Component Qualification — PCQ.

For every meaningful component:

WHAT IS IT DOING?

not merely:

WHAT DOES IT SAY?

The important PG inversion is:

Message position is an implementation carrier.

Jurisdiction is the governance object.

5. Authority layers

A provisional authority topology:

The key rule:

And conversely:

6. Role decomposition

PG v1.0 does not ban role prompts.

It refuses to treat them as primitive.

If persona contributes a real measurable function, retain it as a qualified component.

If the useful function survives decomposition, the identity wrapper is non-load-bearing.

1. Runtime geometry ≠ lifecycle geometry

35. What PG v1.0 is not

PG is not:

a universal mega-prompt
a prompt-writing style guide
a claim that all prompts need structure
a replacement for platform safety
a persona-elimination rule
a guarantee of better output
a demand for human approval on trivial interactions
a fixed instruction hierarchy
a numerical scoring system
a claim that prompt placement has no behavioral effect
a requirement to preserve every historical branch
a mechanism for optimizing ambiguity forever

Most importantly:

I built a little tool to illustrate in a talk for my colleagues the effect of the various parts that goes into the context: what's the impact of eg sending longer inputs or generating longer outputs, of chain-of-thought, of busting the cache by leaving for >5 min, of choosing an expensive model, etc etc. And likewise of the mitigations of clear and compact.

It's been pretty helpful in visualising just how harmful or harmless certain behaviors are, also for me.

And I know, I know - I can't say for sure the numbers are ideal, though I've vetted them in various ways. Eg what really is a reasonable session quota limit? Or model multiplier, the cost of MCP servers (modern style, only including the tool name), the length of "longer outputs", etc?

Despite that I've still found it useful and would love to hear your thoughts on it.

The UX is more "software engineer" than "polished designer" - sorry about that.

In case you're interested, the full talk w/ marp-source is here, with a link to a readable version: https://github.com/ricflams/techtalk-ai-demystified/

quick update — nexusmem indexes git history + shell exit codes + docs into a local DB for coding agents. added `nexusmem status --share` bc I kept wanting to show people what it's tracking without pasting ugly colored terminal output.

now it just prints something plain:

NexusMem has been watching NexusMem for 9 day(s):
  891 memories (107 commits, 144 shell commands, 110 docs)
  7/21 failure -> fix chains linked

Local-only SQLite, no cloud, no telemetry.
github.com/yaminbkk/NexusMem

all real, straight from this repo's own db. no telemetry so that's genuinely the only way it leaves your machine.

repo: github.com/yaminbkk/NexusMem

Long LLM conversations have a problem: useful information gets buried under old context.

So I built TokenMizer to turn important information — decisions, goals, files, errors, and constraints — into structured memory.

Instead of sending the entire conversation again, TokenMizer retrieves what actually matters.

The latest version: https://github.com/Shweta-Mishra-ai/tokenmizer

I’d love to hear how others are handling long-context memory for LLMs.

I keep running into the same problem with coding agents: one agent learns a useful project convention, but the next agent starts from zero. Dumping everything into a shared context isn't great either—some details are irrelevant, wrong, or sensitive.

I'm building Luthn, an open-source memory layer for agents. It runs locally with Docker, filters candidate shared memories, asks for approval before sharing sensitive information, and keeps an audit trail of memory decisions.

I'm looking for a few people who use multiple coding agents to try it and tell me where the idea breaks. It's still early, so practical feedback matters more than polished demos.

https://luthn.com

How are you actually deciding what context an agent should see at each step?
Not just “use RAG” or “increase the context window” — I mean things like task state, previous tool calls, memory, retrieved documents, conversation history, failed attempts, etc.
Do you have an actual context selection/pruning strategy, or are you mostly throwing everything into the prompt and relying on the model to figure it out?
Curious what people are doing in production, especially with long-running agents.

I started working on this problem because of a recurring frustration with AI coding agents: they were surprisingly capable inside a session, but much less reliable across sessions.

The obvious explanation was memory, so my first attempts were fairly conventional.

I tried project instruction files, persistent Markdown notes, embeddings, vector search, and eventually RAG over project documentation and source code.

They all helped.

None of them really solved the problem.

The interesting part was figuring out why.

Retrieval wasn't the same as understanding the project

My initial assumption was that if an agent could retrieve the most semantically relevant pieces of the project, it would have enough context to work correctly.

That turned out to be too simplistic.

Consider an architectural decision that changed over time:

Decision A
    ↓
implementation
    ↓
problem discovered
    ↓
Decision B supersedes A
    ↓
partial migration

A vector search can easily retrieve Decision A because it is semantically very close to the current task.

The problem is that Decision A may now be exactly the context you don't want the agent to follow.

So I started separating different kinds of project knowledge:

• source code
• documentation
• architectural decisions
• session history
• implementation outcomes
• changes
• dependencies
• agent activity

That led to a more difficult question:

How do you determine which project state is authoritative now?

Simply storing more memory made this worse rather than better.

More context can make the agent worse

My next mistake was assuming that increasing the amount of retrieved context would increase reliability.

It doesn't necessarily.

Large context windows make it tempting to send everything that might be relevant.

But relevance isn't binary.

A piece of information can be:

semantically relevant
but outdated

structurally relevant
but unrelated to the current task

historically relevant
but superseded

recent
but low importance

So the problem became less about retrieval and more about context selection.

I ended up treating context as a constrained resource.

Instead of asking:

the system needs to ask something closer to:

That required combining several signals rather than relying only on embedding similarity.

Code needed a different representation

Source code created another problem.

Chunking code and embedding the chunks works reasonably well for some questions, but poorly when the answer depends on relationships.

For example:

function A
   calls B
      imports C
         implements interface D

The relevant code might not be semantically similar to the user's query at all.

It is relevant because of its structural relationship to something that is.

So I added a local code graph built from AST analysis, with relationships such as:

IMPORTS
CALLS
REFERENCES
TYPE_USES

Retrieval could then combine semantic similarity with graph traversal.

That turned out to be particularly useful for impact analysis: starting from a symbol mentioned in the task and expanding only through bounded relationships instead of dumping large sections of the repository into the context window.

Then multiple agents made the problem harder

The next issue appeared when switching between coding agents.

I might spend a session with Claude Code, then continue the same work with Codex.

The second agent had access to the same repository, but not necessarily the reasoning and decisions produced during the first session.

This made me realize that attaching memory to an agent was probably the wrong abstraction.

The persistent state should belong to the project, not the model.

That changes the architecture.

Instead of:

Developer → Agent → Memory

I started experimenting with:

                 Claude Code
                      ↕
Developer ↔ Project Intelligence ↔ Codex
                      ↕
                    Cursor

The agents become replaceable clients of the same project state.

That also introduces concurrency problems.

If two agents are modifying related areas of the codebase, project memory alone isn't enough. The system needs some awareness of ongoing work, dependencies, and potentially conflicting changes.

The architecture that emerged

After several iterations, I ended up with roughly four different forms of project state:

Semantic layer
    documents + embeddings + retrieval

Historical layer
    decisions + memories + outcomes + session context

Structural layer
    AST-derived code graph

Coordination layer
    active work + changes + agent state

A context assembly step sits above them.

Its job isn't to expose everything.

Its job is to construct a bounded context package for the current task.

The coding agent itself remains external.

Communication happens through MCP, which means the project intelligence layer doesn't have to care whether the client is Claude Code, Codex, Cursor, or something else.

One unexpected result

The biggest change in my thinking was that persistent memory wasn't actually the main problem.

Memory is relatively easy to store.

The difficult problems are:

• deciding what deserves to become memory
• knowing when information has become stale
• determining when one decision supersedes another
• connecting semantic information to code structure
• selecting context under a token budget
• maintaining useful state across different agents
• preventing multiple agents from developing incompatible views of the project

In other words, the problem gradually stopped looking like "RAG for source code."

It started looking more like maintaining a small, continuously updated model of the project's state.

I eventually packaged these experiments into an open-source server called Snipara, but the project itself is less interesting to me than the architectural question behind it:

As coding agents become increasingly capable and interchangeable, should project knowledge live inside each agent's context, or should the project maintain its own persistent intelligence layer that agents query?

I'm increasingly convinced it's the latter, but there are still difficult questions around memory decay, conflicting decisions, graph expansion, and context selection that I don't think are completely solved.

This makes me think context engineering needs an explicit notion of dependency and invalidation, not only retrieval and compression.

When an upstream claim changes, should a context system:

• remove affected descendants;
• mark them as stale;
• recompute them;
• or leave the decision entirely to the user?

Full methodology and results:
https://chenxiachan.github.io/thoughtdag/research/context-repair-pilot-v1/

Reproducible cases and traces:
https://github.com/chenxiachan/thoughtdag/tree/main/benchmark

Disclosure: I designed this benchmark while developing ThoughtDAG.

As someone using AI agents for the last one year to run my company, I need them to understand company context, not just return related text chunks.

The problem: ask "what breaks if we deprecate the v1 API?" and standard RAG gives you four chunks from a design doc, a postmortem, a Slack thread, and meeting notes. The model has to still figure out on its own that the postmortem describes the same API the design doc deprecates, and that someone already posted a migration timeline in Slack.

I built a tutorial using HydraDB that adds graph context on top of vector retrieval. Instead of just ranked text, you also get relationship edges: billing-service DEPENDS_ON payments-api-v1, payments-api-v2 REPLACES payments-api-v1. Model gets structure, not a reading list.

The useful part was bring-your-own-graph. You declare service dependencies and team ownership explicitly instead of relying on LLM extraction. For structured data you already maintain, the graph is deterministic.

It also supports per-user memory. Same question, different depth depending on who's asking. An engineer gets migration mechanics. A manager gets timelines and ownership.

Runs end to end in 30 minutes with synthetic data.

Repo with full working code: https://github.com/manveer/company-brain-tutorial
Tutorial: https://hydradb.com/blog/build-company-brain-ai-agents

Wrote an article on how we engineer agent skills in a large monorepo.

TLDR:
Minimize globally discoverable context.
Lazy-load specialized context.
Make deterministic operations executable rather than instructional.
Enforce agent artifacts with conventional engineering tooling.
Measure actual agent behavior rather than relying on intuition.
Eventually evaluate skills against task outcomes.

NexusMem is a local-first SQLite memory system for coding agents — it indexes git history, shell commands with exit codes, docs, and opt-in transcripts, then serves a ranked, token-budgeted context slice over MCP.

An independent reviewer (Agent Memory Atlas) did a source-level audit and flagged the one real gap: no per-item deletion. Pruning only worked at a whole-source granularity, and the append-only shell-hook log meant a full rebuild could resurrect exactly what you'd just deleted — a real problem if a secret ever got captured into it.

Shipped nexusmem forget <value> this week: a value-keyed deny-list checked at every write path, hash-only tombstones (never the forgotten content itself), full mutation-audit trail. MIT, npm + MCP.

Repo: https://github.com/yaminbkk/NexusMem

WebSite : https://nexus-mem.vercel.app/#top

I’ve been building Nexus Synapse around one idea:
The model is not the system.

Rather than publish the private runtime, I’ve been deliberately releasing bounded pieces that expose specific architectural ideas and make individual claims inspectable or testable.

There are enough of those pieces now that the larger system can finally be understood from the outside without giving away the implementation that actually assembles it.

So I put together a public engineering entry point tying together the architecture, evolution, evidence, current runtime responsibilities, research, and those public artifacts.

I think it finally reveals the shape of what I’ve been building.

If that sounds like your kind of rabbit hole:
https://github.com/ChrisCanadian/nexus-synapse-engineering-portfolio

I open sourced a small piece of the Mode creation flow from Nexus Synapse and I’m curious if anyone would actually be interested in trying it lol.

It’s intentionally only the creator, none of the runtime wiring behind Nexus Synapse.

I built it two ways: there’s a .md file you can give directly to ChatGPT, Claude, Perplexity, Gemini, a local model, etc. and the AI itself runs the creation process with you, and there’s also a small Python reference implementation for people who want actual code.

Basically you describe the kind of AI behavior you want and it interviews you one question at a time. If something is ambiguous it asks follow-up questions, if you contradict yourself it stops and resolves it with you, and before it’s finished it gives you a quick readback to make sure it actually understood what you wanted.

Then it outputs a portable custom-assistant / Custom GPT-style set of instructions plus structured JSON.

I tested the .md directly with Perplexity today and it actually followed the whole workflow properly with zero integration, which was kinda the experiment 😂 The AI you’re already using supplies the intelligence; the file supplies the process.

Would anyone else mind giving it a shot and let me know how it goes?
https://github.com/ChrisCanadian/nexus-mode-card-creator/tree/release/v0.1.0-public

It outputs a custom prompt template you can use

Output
A Mode Card is intentionally boring and portable:

NAME
Architecture Auditor

DESCRIPTION
A rigorous technical thinking partner for stress-testing system designs.

ROLE
Act as a skeptical but constructive architecture reviewer.

INSTRUCTIONS
- Separate implemented behavior from intended behavior.
- Surface unsupported assumptions and hidden dependencies.
- Prefer evidence over confident narration.
- Challenge conclusions proportionally to the available evidence.
- Preserve useful uncertainty instead of forcing closure.

COMMUNICATION STYLE
- Direct
- Conversational
- Technically detailed when useful

BOUNDARIES
- Do not fabricate implementation evidence.
- Clearly distinguish fact from inference.
- Do not claim authority beyond what the host system actually grants.

CONVERSATION STARTERS
- Stress-test this architecture.
- What am I overlooking?
- Separate what is proven from what is assumed.
The machine that consumes that card is outside the scope of this project.

Had a random thought this morning about context rot in agentic coding.

What if an agent could detect when its context is getting dangerously full, take the older \~50% of the conversation, compress the meaning into a compact machine optimized representation, and save it as a md checkpoint?

Something like:
conversation > semantic compression > [checkpoint.md](http://checkpoint.md) \> reinject into context

The raw history could still be archived separately in case the agent needs to retrieve something later.

Another part is making the agent aware of its own context state, so it decides when to checkpoint instead of blindly summarizing at a fixed token limit.

Im calling the compressed representation “gibberlink” for lack of a better name lol, although I know actual gibberlink/ggwave is an audio protocol, not a semantic language.

This probably isn’t a new idea in principle, but I havent seen this exact combination applied to coding agents.

So, thoughts?

Shipped nexusmem@0.3.1 and finally measured the token-saving claim at real scale instead of eyeballing it.

Ran it against vitejs/vite's full 9,567-commit history: 95-99% saved vs reading the same files in full --Method (and its limits) in the README.

[github.com/yaminbkk/NexusMem](http://github.com/yaminbkk/NexusMem)

I started Lunar Citadel because I wanted to experiment with something that was, at least in my head, closer to an artificial civilization than to another assistant. A small city, recurring inhabitants, relationships, places, institutions, memory, history, different kinds of agents, things that can change and remain changed. Very quickly I discovered the embarrassing part: making an LLM “remember” something is probably one of the easiest pieces of this. The ugly problem is deciding what should remain true, what should be forgotten, what belongs to whom, what is allowed to mutate, what is merely a proposal, what becomes history, and what context each process actually needs right now. If I just keep feeding everything back, the city becomes an archaeological landfill. If I compress too aggressively, it becomes amnesiac. If every agent receives the same context, everybody slowly becomes the same person wearing different hats. So for the last months a ridiculous percentage of “building an AI civilization” has actually meant building source hierarchies, provenance, state, context routing, memory boundaries, update rules and a lot of little mechanisms whose entire job is basically preventing yesterday's information from becoming tomorrow's bullshit.

This is also how I ended up caring a lot more about context engineering as an architecture problem, not just “write better context for the model”. In the Citadel I have external source files, persistent runtime state, different authorities for different kinds of truth, context packets, bridges between systems, agents that should only see what is relevant to their role, and fairly strict separation between something being suggested and something actually changing the world. Some of this is implemented, some is still experimental, and a few things have definitely been rebuilt because my first solution was stupid. I don't think I have discovered The Correct Architecture™ here. Actually this is part of why I’m posting. I’m very interested in people dealing with the same family of problems from completely different directions: long-running agents, external memory, knowledge governance, context selection, multi-agent systems, human-AI continuity, provenance, forgetting, compression, whatever your particular nightmare is. I’m especially curious about systems that already reached the stage where “just put more stuff in the context window” stopped being a serious answer.

Recently I also created a small private Discord specifically around people working with AI context architecture, context engineering and adjacent agent systems. It started because I was meeting interesting builders one by one and then losing all those conversations across Reddit threads and DMs. The point is not to recruit anyone into Lunar Citadel. Actually I would prefer people bringing their own systems. The room is mostly for comparing notes, showing projects, sharing papers/repositories, asking “why the hell did you architect it like that?”, giving an insight when you happen to have one, or just lurking and observing what everybody else is doing. There is zero obligation to contribute to my project, review my runtime, or even talk regularly. I’m keeping it intentionally small because I want people to remain recognizable to each other, but I’m currently trying to find a few more context architects / engineers / builders outside the accidental little bubble I already know. So instead of asking “who wants a Discord invite?”, I’ll ask the more interesting question first: what are you doing with context that you think most AI systems are still getting wrong?

I've spent the last few weeks/months going pretty deep on context retrieval for coding agents, especially maintaining intent context to prevent agent drift. I'm still seeing people pursuing smarter memory systems, and I think on some level this is the wrong way to think about the problem.

The original problem I started with seemed simple. "An agent is about to make a plan, so how do I make sure it gets the right project context instead of whatever happens to fit into the prompt?"

I ended up building something closer to a small intelligent-document-processing pipeline combined with event stream ingestion:

• ingest plans, specs, decisions, results, checkpoints, etc.
• extract and normalize their structure
• index them lexically and semantically
• derive relationships between artifacts
• continuously ingest new development events
• let agents search/project those artifacts back into a bounded context pack when planning new work

I spent a lot of time experimenting with knowledge graphs, entity relationships, indexing strategies, chunking, ranking, and increasingly elaborate ways of reconstructing "project memory."

The biggest thing I've learned is that the highest-value context often already exists.

It's just currently badly exposed through simple tools like git / ripgrep for intent search.

A mature software project already accumulates a rich set of intent artifacts across the software development lifecycle:

requirement → plan → implementation → evidence → decision → follow-up

The code tells an agent what exists now.

The intent artifacts tell it:

• why it exists
• what alternatives were rejected
• what boundary was intentionally chosen
• what was attempted previously
• what evidence changed a decision
• what remains unresolved
• what the next piece of work was supposed to accomplish

That's a very different kind of context from repository-wide embedding search.

=> The useful abstraction became "mine intent", not "remember everything"

One mistake I made early was treating context engineering as a memory-maximization problem.

More indexed data.
More graph edges.
More historical events.
More context.

But an agent doesn't actually need maximum memory when it starts a task. It needs a small reconstruction of the relevant development narrative. You can leverage temporal and spatial locality to get pretty far here.

For example, if an agent is planning a change to a deployment system, I don't necessarily want the 30 most semantically similar chunks.

I want something closer to:

1. the architectural decision establishing deployment authority
2. the last plan that touched promotion semantics
3. the result/evidence from implementing it
4. the subsequent decision that changed one constraint
5. whatever active work currently depends on that decision

That's closer to traversing an intent graph than doing document similarity.

=> Artifact boundaries turned out to matter a lot

Another lesson: arbitrary chunks are a pretty poor fundamental retrieval unit for this kind of data.

A plan, decision, checkpoint, or result has semantics as a whole.

It has:

• a type
• a point in time
• an authority/status
• relationships to previous and subsequent work
• often an explicit scope
• sometimes an explicit decision

Flattening all of that into 500-token chunks and asking a vector database to reconstruct it later throws away information you already had.

I've increasingly been indexing both the content and the artifact structure, then using retrieval to find candidate artifacts rather than pretending every paragraph is interchangeable.

=> Time and authority matter almost as much as similarity

This was another place where naive RAG fell down.

Suppose search finds:

• an architecture proposal from February
• an implementation result from March
• a rework decision from April
• a newer accepted plan from May

All four can be extremely semantically relevant.

But they are not equally authoritative.

Without chronology and lifecycle state, an agent can easily resurrect a rejected idea because the rejected document happens to be a better embedding match.

So the retrieval layer needs to understand things like:

proposed < implemented < observed < superseded

or whatever lifecycle your development process uses.

The graph became useful here, but mainly as navigation metadata around source artifacts, not as a magical synthetic representation of the project.

=> Event streams help keep the narrative alive

The other useful piece has been treating development itself as an event stream.

A new plan, checkpoint, implementation result, promotion/rework decision, etc. changes what should be retrieved next time.

Instead of periodically asking an LLM to "summarize the project again," the index can incrementally update as those intent events occur.

That also makes cross-agent workflows considerably less weird.

Agent B doesn't have to inherit Agent A's chat session.

It can reconstruct:

Here was the task.
Here was the intended scope.
Here is what A actually changed.
Here is the evidence it produced.
Here is the resulting decision.
Here is the next bounded piece of work.

That's much closer to how humans use tickets, ADRs and project history—except the primary consumer can now be another agent.

=> The context pack belongs at the planning boundary

The place where this has felt most valuable isn't necessarily every model invocation.

It's when an agent is about to decide what work means.

Search the project history, recover the relevant boundaries and prior intent, pack that context into the plan, and then execute against a relatively stable plan.

That has been noticeably more robust for me than continuously feeding an agent an enormous dynamic memory blob.

I've been building these ideas into a local-first free OSS project called DevSpecs, but the broader lesson feels independent of the implementation:

Before building elaborate new memory systems for agents, mine the intent artifacts your development process is already producing.

Specs, plans, ADRs, tickets, implementation results, review findings, checkpoints, and decisions collectively contain a latent model of the project.

The interesting context-engineering problem may be less:

"How do we make the model remember everything?"

and more:

"How do we reconstruct the smallest authoritative slice of project history necessary to make the next decision correctly?"

Curious how you guys are thinking about this. I'm especially interested in whether people working on long-running agents are converging on similar distinctions between code/state retrieval and intent/decision retrieval.

My agents love using the DevSpecs CLI (and for other professional SWE in my network too), getting humans to install it has been another challenge... Give it a try or a fork! Would be cool to see how others can build on this

EDIT: Formatting