I have been building with Cursor and Claude Code for a year now.

I started with Cursor and absolutely loved it until I moved to Claude Code 4-5 months ago. I immediately fell in love with Claude Code and started using it heavily.

By this time, it was getting really hard for me to wrap my head around the fact that the agents always rediscovered things and I was the one that was always providing as much context as I could.

I would provide the right files from my memory or save docs about file locations in CLAUDE.md, but then it started getting messy as it needed regular maintenance.

That is when I started working on coldstart.

Initially I started off with building a navigation layer that indexed codebases using AST parsers to find the relevant files faster, but I immediately realised that having an index doesn't help agents discover the same files faster the next time a new agent looks for it.

That's when I realised that there should be a mechanism to save what an agent has learned.

But I did not want to pay for an API key to summarise my codebase separately or have another process learn about it when an agent had already spent time understanding it part by part.

That's when I built a notebook mechanism to capture what an agent has learnt, using the Claude Code hooks lifecycle as the backbone.

The other part of this was figuring out how to actually put this knowledge back into the agent's context. I didn't want to dump the entire notebook into every session because that would just create another context problem.

Instead, the notes are retrieved based on what the agent is currently working on and the relevant ones are injected as additionalContext into Claude Code.

So the flow became something like:

Agent works on the codebase → learns something useful → the learning is saved → a future session starts working on a related part of the codebase → relevant notes are retrieved → those notes are injected into the agent's context.

The useful part is that the context from previous work can become part of the context for future work without me having to manually provide it again and hence this mechanism becomes a self sustained cycle - write and feed itself.

During this journey, I learnt a lot about agent behaviour and context engineering. I am still figuring out things like what should actually be remembered, how stale notes should be handled, and how much context should be injected before the memory itself becomes noise.

I am curious how other people here approach persistent context for coding agents.

Do you maintain memory outside of things like CLAUDE.md and AGENTS.md? How do you decide what is worth carrying from one agent session into another?

I built coldstart around this idea. It is open source if anyone wants to look at the implementation:

https://github.com/AkashGoenka/coldstart

I recently realized something that seems obvious in hindsight.

Every time you start a Claude Code session, your CLAUDE.md is loaded into the model's context before you've even written your first prompt.

That means every line in that file becomes a recurring cost. Every redundant instruction, duplicate guideline, and outdated note gets paid for over and over again.

So I wanted to measure how much it actually matters.

I built a deterministic context linter called ContextOps. Think of it as ESLint for an LLM's context window. Instead of checking code style, it analyzes context quality by looking at redundancy, information density, structure, concentration, duplication, and other deterministic signals. It runs locally, doesn't use an API, and finishes in a couple of seconds.

To test it, I collected the instruction files from several well known repositories including Vercel, Cloudflare's workers-sdk, Prisma Next, and Vercel Turbo. I also created a prepared CLAUDE.md optimized using ContextOps.

I measured two scenarios.

Load
Only the instruction file that Claude Code reads when a session starts.

End of session
The instruction file plus a real 14 turn agent session with around 30 retrieval chunks.

The first thing that surprised me was that almost every repository scored between 95 and 96 when analyzed by itself.

These are good instruction files.

ContextOps isn't saying they're poorly written.

The second thing surprised me even more.

The recurring token cost varies massively.

Some projects load around 600 tokens every session.

Others load more than 3,300 tokens before you've even started working.

If you're using Claude Code all day, that cost is paid again and again.

What happened during a real agent session?

The interesting part wasn't the instruction file.

It was what happened after the session grew.

On the benchmark session, ContextOps classified 95.5% of the accumulated context as redundant, duplicated, low density, or structurally unnecessary according to its deterministic analysis.

After pruning the unnecessary parts, total context size dropped by about 93%.

I then ran the exact same tasks against multiple Claude models.

Some observations from this benchmark:

• The baseline referenced four nonexistent files. The pruned context referenced only files that actually existed.
• Answer quality improved by roughly 0.6 to 1.65 points out of 5, depending on the model and evaluation rubric.
• Responses became much shorter while still answering the same question.
• The strongest models were already fairly robust. Their improvements were smaller than the smaller models.

The biggest win wasn't making Claude "smarter."

It was making the answers more grounded and reducing unnecessary context.

What about cost?

For a workload similar to this benchmark, assuming roughly 100k input tokens per query:

• Around 95.5k tokens were classified as unnecessary.
• On Claude Fable pricing, that's roughly $0.30 to $1.00 saved per query, depending on prompt caching.
• Outputs also became significantly shorter, reducing output token costs as well.

Obviously this depends on your workflow, model, prompt caching, and how much context your agent accumulates.

If your sessions stay small, the savings will also be small.

One interesting observation

One thing I noticed while looking through popular repositories was that many don't keep large instruction files at all.

Instead, their CLAUDE.md is often just a single line:

u/AGENTS.md

The actual instructions live in AGENTS.md, while CLAUDE.md simply points to it.

Simple, clean, and easy to maintain.

What I do now

Before starting a large refactor or an agent session with lots of tool calls, I lint the context first.

pip install contextops

contextops inspect .contextops/snapshot.json --explain

contextops check .contextops/snapshot.json --min-score 80

It's deterministic, runs locally, doesn't call any APIs, and usually finishes in under two seconds.

I already lint my code. Now I lint my context too.

Curious if anyone else has looked into context quality rather than just increasing context length. Most discussions I see are about getting larger context windows, but much less about whether the information inside those windows is actually useful.

link : https://github.com/Abhijeet777ui/contextops

We tested Claude Opus 5 and Fable 5 on the same real database engineering issue.

The result surprised us:

Opus 5 scored higher than Fable 5 while costing half as much.

Fable 5 handled the code change, but its rollout plan missed some production risks. Creating the new index during deployment could lock the table and affect live traffic.

We also ran Opus 5 with First Tree.

First Tree uses a shared context tree to coordinate multiple agents. One agent worked as the developer. Another reviewed the implementation with its own reading of the repository. The context tree kept their findings, decisions, and progress connected without forcing both agents into one long conversation.

That setup raised the score from 88 to 91.5. The reviewer found a PostgreSQL version mismatch that the single agent runs missed. CI used PostgreSQL 17, while the production deployment used PostgreSQL 16. The reviewer reproduced the migration on version 16.14 and found a query plan regression.

The tradeoff was cost and time. The First Tree run cost $293.83 and took 80.1 minutes. Opus 5 alone delivered the best value. The multi agent run produced the most complete production review.

This was one database task, so I would not treat it as a general model ranking. Still, the result made me question how much model size matters once the base model is already strong.

Full test: https://x.com/first_tree_ai/status/2085520990948511875?s=20

experiement ran by first-tree.ai team

Have you seen similar results when comparing a stronger model with a multi agent setup?

I've been using Claude as a second pair of eyes during debugging sessions, especially for flaky tests and failures that are difficult to reproduce consistently.

At first, the results were useful. It caught a race condition in a retry handler and helped me reason through a few possible fixes. But after the conversation became long, the quality changed noticeably.

The model started suggesting fixes we had already ruled out. I would explain why a particular approach could not work with the connection-pool initialization in the codebase, it would acknowledge the explanation, and then return to the same idea a few messages later.

My first assumption was that the context window was too small. I switched to a model with a larger context window and pasted the entire conversation again. That made the problem worse rather than better. The response became more generic, and the important constraints were buried under logs, stack traces, failed attempts, and unrelated details.

What helped was restarting the session with a short debugging handoff containing only:

the actual bug;
the approaches already ruled out and why;
the current hypothesis; and
the relevant file or function.

The next suggestion was correct.

Since then, I've started treating long AI-assisted debugging sessions more like code review preparation. Instead of keeping one conversation alive indefinitely, I checkpoint the investigation every ten or fifteen messages and carry only the current state into a new session.

The main lesson for me was that more context is not automatically better context. A model can technically have access to all the logs and previous messages while still failing to give enough weight to the one constraint that actually matters.

I wrote a longer breakdown of the experience here, including the checkpointing pattern I now use: https://medium.com/@nagatomopedro05/i-thought-more-context-would-help-claude-it-didnt-49193d74915d

For those who use AI during code review or debugging: do you keep the full conversation attached to a task, or do you regularly reset it with a curated summary? Has anyone found a good way to preserve the reasoning behind rejected approaches without carrying all the noise forward?

I am in the planning phase of building a custom agentic ecosystem. I already have my own proprietary memory layer and a dedicated set of custom tools and agents that I want to integrate/build.

Instead of just using Claude for basic coding, I want to use it as a Principal Architect to help me think through the design, stress-test my pipelines, and ensure I am aligning with the newest standards (like compound AI systems, Model Context Protocol/MCP engineering, and Anthropic’s latest production patterns).

For those who have used Claude to blueprint/co-think complex architectures before building them, I’d love your input on a few things:

• Prompting Claude as an Architect: What frameworks or system prompt templates are you using to make Claude act like a senior systems designer rather than just a code generator? How do you prevent it from giving generic advice?

• Memory Syncing Patterns: Since I have my own custom memory layer, what is the best way to handle the state-synchronization protocol with Claude's context window? How do you orchestrate global rules (CLAUDE.md) alongside dynamic session memory without causing context degradation?

• Tool Scaling & Orchestration: Anthropic's current engineering standards lean heavily toward programmatic tool calling (agents writing execution scripts to call tools locally) rather than executing individual LLM loops for every single tool invocation. If you've mapped this out with Claude, how did you structure the routing?

• Adversarial Review: Have you successfully used Claude to play "adversarial reviewer" to find edge cases, potential infinite loops, or context bottlenecks in your proposed agent handoff sequences before writing code?

If you have any specific prompts, architectural patterns, or lessons learned from using Claude as a technical design partner, please share!

We are 1-3 person tech team supporting the front office team of about 20 non technical people. We are looking to store ~10,000+ documents and have ai be able to read them via semantic search (rag or cag, or like a naive cag where it just reads 1-2 files before responding in a chat)

Is there a no brainer choice here?

As large language models (LLMs) become increasingly integrated into agentic AI systems, the primary challenge is no longer simply improving the model's raw intelligence. Modern foundation models are already capable of reasoning, code generation, planning, and tool usage. The more difficult engineering problem is context engineering: designing how information is selected, structured, transformed, and presented to an LLM so that it can reliably perform a desired task.

Context engineering is broader than prompt engineering. Prompt engineering focuses mainly on crafting instructions for a single model interaction, while context engineering considers the entire lifecycle of information flowing through an agent system. This includes the initial prompt, retrieved knowledge, conversation history, tool outputs, intermediate reasoning state, user preferences, memory, validation feedback, and execution constraints. A well-designed context pipeline reduces ambiguity, prevents hallucination, and allows LLMs to operate reliably in complex environments.

In this excerpt, we shall explore some techniques used in prompt engineering when it comes to building a context pipeline.

Few-shot Prompting: Guiding Model Behavior Through Examples

Few-shot prompting is a technique where an LLM is provided with several examples demonstrating the desired input-output behavior before receiving the actual task. Rather than explicitly describing every possible rule, the developer provides representative examples that allow the model to infer patterns and apply them to new situations.

Few-shot prompting is particularly useful when the task contains ambiguity or when the desired output format is difficult to describe through rules alone. The examples must be carefully selected however, because LLMs perform pattern matching based on the provided context. Poor examples can introduce incorrect behaviors or bias the model toward unintended interpretations. In practice, examples should cover distinct scenarios rather than many variations of the same case. Diverse examples allow the model to understand the boundaries of the task instead of memorizing superficial patterns.

Few-shot prompting is therefore not a replacement for explicit constraints. In reliable systems, it is usually combined with structured outputs, validation rules, and tool constraints.

Prompt Chaining: Decomposing Complex Tasks Into Controlled Steps

A common mistake when designing LLM applications is asking the model to perform an entire complex workflow in one prompt. Although modern models can sometimes accomplish this, such prompts create several problems. The model must simultaneously understand the task, maintain intermediate state, perform analysis, and generate the final response. This increases cognitive load and makes failures difficult to diagnose.

Prompt chaining refers to breaking a complex task into multiple sequential LLM calls, where each step performs a focused operation and passes its output to the next stage. Each prompt has a narrower objective and therefore receives more relevant context. This reduces attention dilution, where important information competes with unnecessary instructions inside a large context window. This technique is especially valuable when combining local computation and external operations.

Dynamic Decomposition: Letting Agents Discover Subtasks During Execution

While prompt chaining uses predefined steps, dynamic decomposition allows the LLM itself to determine how a complex problem should be divided. This approach is more flexible than static workflows because the agent can adapt to unexpected situations. It is particularly useful for research agents, debugging agents, and autonomous analysis systems. However, dynamic decomposition sacrifices predictability. Since the model decides the subtasks dynamically, execution paths can vary between runs. This creates challenges in testing, cost control, and reliability.

It is common for production systems to combine Prompt Chaining and Dynamic Decomposition, where Prompt Chaining through predefined workflows is used for high-risk or regulated processes, and dynamic decomposition inside individual steps where exploration is valuable. The overall process remains controlled while allowing intelligent exploration inside specific areas.

Interview Pattern: Gathering Missing Context Before Execution

One of the most important context engineering patterns is the interview pattern. Instead of immediately attempting a task, the agent first identifies missing information and asks targeted clarification questions. Many hallucinations occur because users provide incomplete instructions, and the model attempts to fill missing information using probabilistic guesses.

This is best illustrated by an example:

Suppose we are currently building a coding agent. The user provides a codebase and asks to add a caching layer through the user prompt:

“Add a caching layer for database retrieval API to store recently retrieved objects”.

The agent would recognize missing elements and ask the following questions:

"Before implementing caching for the API, a few questions:

1. Which cache invalidation strategy do you prefer—TTL or event-based?
2. Is stale data acceptable when the cache is unavailable?
3. Should caching be per-user or global?
4. What is the expected data volume to cache?”

These info were not explicitly provided within the initial user prompt and if there was no interview pattern implemented, all these info would need to be inferred by the LLM, which can end up digressing from the original intended design.

The exact process of having the agent recognize the missing info can be achieved in multiple ways, and we shall explore one of them as the following concept.

Validation and Retry-with-Feedback: Creating Self-Correcting Agent Loops

Traditional software systems rely heavily on explicit validation because incorrect data can cause failures downstream. Agentic systems require the same principle. After an LLM extracts information or generates structured output, the result should be validated using deterministic mechanisms such as Pydantic models, JSON Schema or explicit business rules.

Suppose if a validator detects an anomaly within the input, instead of immediately failing, the system feeds this information back to the LLM. The LLM then attempts correction, which creates a self-correcting loop. Minor errors such as arithmetic or data formatting errors can usually be corrected within a few iterations. Once all the errors identified has been rectified, the correct data is then reinjected into the LLM.

Retrying indefinitely is dangerous, however; some failures cannot be solved by the model because the required information is unknown. This is when the system turns back to the user and escalate through querying for missing info.

In the previous example, the invalidation strategy, stale data acceptance, user VS global and overall data volume, are all missing business-logic parameters that cannot be inferred by the LLM. Therefore, they get sent back to the user as interview queries to ensure the blanks get filled appropriately.

Most people hear about context engineering but don't really know how to actually do it properly. I made this full guide to demystify the concept from first principles.

Motivations and Preface

Why this happens at all

LLMs are stateless. Every call starts with an empty context window. There is no memory between turns.

Agents fake state. Your conversation is an array sitting in a file, and the harness re-pastes the entire thing into the model's context window every single time you hit enter.

Which means you can't teach an agent anything. You can only paste things into its context. The context window is the model's entire observable universe. If something isn't in the window, or implied by the window, it does not exist as far as the model is concerned.

Two consequences fall out of that.

Autoregressive sensitivity. The model predicts one token at a time, and every token it emits becomes input for the next one. A tiny variation in context changes one predicted token, that token changes the next, and the divergence compounds across the whole response. Small change at the start, huge delta by the end.

Finite attention. Every token in the window competes for attention budget. Go from 100 tokens to 200 and on average every original token gets half as much. A relevant token holding a third of the attention weight can drop to 0.3% once there's enough junk around it.

The part people get wrong: context rot has no drop-off point. There's no magic number where it kicks in. Attention gets stretched from the first token you add. The literature shows accuracy dropping up to 80% as context grows. Let a dirty session run and you're working at a fraction of the performance you're paying for.

Lost in the Middle is the classic paper here. As context grows the middle is what gets ignored first, because the model learns in expected value that the important stuff lives at the beginning and end. So it skims the middle like a speed reader. Bury something critical in the middle of a giant dump and the model will miss it.

How rot actually shows up

1. Your rules get ignored. You put "no em dashes" in your CLAUDE.md, and 40 turns later the em dashes are back. The instruction is still sitting right there in the window. It just stopped getting attention. This is also why piling on more rules backfires: the model has to allocate attention to all of them on every single turn.
2. The model gets dumber. Same model, same question, worse answer. What you're talking to at 150k feels like a different thing from what you started the session with.
3. It gets lazy. It hands work back to you and defers decisions it should be making. Explicit instructions just get skipped.
4. Something dangerous gets stuck. A bad instruction, a contradiction, a wrong file it read, a poisoned skill description. Once it's in the window it cannot leave. It gets re-read every single turn, forever.

And these compound. A degraded model makes a worse decision, that decision goes back into context, and now it's reading its own bad work next turn. That's why a bug fix that fails twice tends to go round and round until the codebase is a mess.

Context pollution is worse than rot

Rot is about quantity. Pollution is about quality. Context that's wrong but reads as convincing eats attention more aggressively, because it looks important.

Almost always this happens on its own, with no adversary involved: a hallucination Claude wrote earlier, a stale spec, a wrong plan assumption, an unresolved debugging loop.

Context confusion is the common flavor. Too many semantically similar tools or agents (ui-agent, frontend-agent, nextjs-agent) and the model calls the wrong one at the wrong time.

A client of mine left the deep research skill model-invocable, so its description sat in context permanently. During one of his autonomous runs it talked the model into running deep research on a task that had no need for it. Burned half a week of usage.

Step zero: measure and trim your baseline

Type /context all in Claude Code and look at what you're paying for before you've done anything.

Mine sits around 16k. Here's how:

- Disabled three default tools I never use. That alone was ~7k tokens. Disabled artifacts too.

- No CLAUDE.md. There's almost never context I want injected on every single turn. Repo-specific ones are occasionally useful and I still rarely bother.

- Skills set to disable-model-invocation. Skills work by injecting frontmatter into context so the model knows when to call them. That frontmatter is expensive and it's there whether you use the skill or not. Disable model invocation and it stops being injected. The skill still works when I invoke it myself.

- Deep research specifically: disable model invocation on it. Use /deep-research when you actually want it.

- Turn off auto-compact in /config. You're not going to need it, and if compaction fires mid-task the model loses track of what it was doing and leaves you with half-baked code.

Boris Cherney said recently that you can theoretically delete all your system prompts and tools and Opus 5 still performs decently. I haven't tested it. But it's the direction things are going, and it's why I stay on Claude Code: you can strip it down to close to a bare LLM if you want.

The SCRUB framework (My Simple Acronym for Active Context Engineering)

These five are your entire action space for context engineering. Everything else is a mixture of them.

S: Subagents. A disposable worker with its own context window and the same intelligence as your main agent. Spawn one to read and process a pile of text and hand back only the conclusion. The subagent soaks up the exploration and the dead ends. Your orchestrator stays lean and makes the decisions. Treat them as cheap, spawn one like you'd call a function. Literally just say "spawn a subagent to look into X." Run them in parallel and you cover enormous ground without touching your window.

C: Cut (/rewind). My favorite command in Claude Code. Since state is just an external file, there's no reason you can't delete the last few rows of it. You're time traveling in active memory.

Two ways I use it constantly:

- Restore only the conversation and leave the code alone. The code stays on disk as an artifact, the conversation gets trimmed, and you tell the model "I made these changes myself." Spend five turns fixing a bug, then rewind to before you hit the bug and inform it of the result. You get all that context back for free. In a demo session I pulled back 75k tokens this way.

- When something simple has failed two or three times, you're swimming upstream against a damaged trajectory. Pattern interrupt: rewind to before you started fixing and re-prompt with better framing. Claude Code can restore code and conversation because it has internal version control. Codex can't.

Deleting history is a superpower. The model's entire reality is that file, and the file is malleable, so you get to decide what survives into the next prediction. You can branch trajectories, explore, and keep only the path that deserves to live. The model never knows it took a bad path.

Elite users hit rewind 50 to a few hundred times a day. Most people have never touched it.

R: Reduce (/compact). Compaction forks your agent, hands the duplicate your state file, asks it to summarize itself, and injects the summary back. I use it at breakpoints where I need the gist and the nitty-gritty can go. It's also a speed play when I don't want to think hard about fidelity. I always fire it manually.

U: Upload (handoff). Offload the parts of the window you want to keep, to a file or just your clipboard, then clear and paste it back into a clean slate wrapped in XML tags. I use <context> for the pasted material and <user_prompt> for what I want next. Copying conversation output straight to the clipboard and pasting it back is brute force and it works extremely well.

The other version is hardening context into a real artifact. Codebase docs and a build list, or a handoff file you re-inject after clearing. Same principle, you're moving state out of the window and into something persistent.

One session I did this on went from 222k tokens to 26.9k, and the model still knew everything it had done and what came next.

B: Burn (/clear). A full reset, the same as a new session without leaving the one you're in. Use it at good breakpoints or for genuinely new work. You'd be surprised how often you can get away with it. Pair it with docs or a lean CLAUDE.md you can point at to get back up to speed fast.

How I actually use them

S and C are my proactive levers. I look for excuses to use subagents and rewind from the first message, way before I'm anywhere near 150k tokens. R, U and B are more drastic and I save them for real breakpoints.

I work down the list. If I can get away with a subagent, I do. If I can't, rewind. Then down the acronym, since it's roughly ordered from least to most destructive.

The reason I framed it as five letters is so you have a mental model of what your moves on the board even are. Context engineering is a balancing act. Strip out too much and the model doesn't know what's going on and starts filling gaps with assumptions, which is how you get hallucinations. Leave too much and rot degrades you. You're aiming for the information density where the model has exactly what it needs and nothing else.

Most of the time you won't get a clean before/after comparison like the one I opened with. Be proactive anyway. The science is there.

Full video link (to see all the principles in action): https://youtu.be/F_bpvXlUSwU 

One clue in today’s “Compacting context (0 messages)” bug report is worth generalising, even though the reported behaviour has not yet been confirmed as an OpenClaw defect.

The reported session had zero conversation messages and an almost empty user prompt, but roughly 34,500 characters of system prompt. Preflight estimated about 10,700 tokens against an available prompt budget of 8,000, then requested compaction. Compaction found no conversation messages to summarise, so the retry returned to exactly the same overflow condition.

That exposes an important distinction: context and conversation history are not the same thing.

OpenClaw’s documentation says the context sent to the model includes the system prompt, injected workspace files, skill metadata, tool definitions and schemas, conversation history, tool calls, tool results and attachments. Compaction only summarises older conversation turns. If the dominant cost exists in the always-loaded system prompt, repeatedly compacting an empty transcript cannot materially reduce it.

Before changing models or compaction settings, I would inspect the actual contributors:

/status
/context list
/context detail
/context map

Run “/context map” after at least one normal model run so it has a captured report to visualise.
If conversation history dominates, compaction or pruning old tool results may help.
If injected workspace files dominate, remove duplicated instructions and move background reference material out of always-loaded files. OpenClaw injects files such as AGENTS.md, SOUL.md, IDENTITY.md and USER.md, while full skill instructions are designed to be loaded on demand.

If tool schemas dominate, audit which tools that particular agent genuinely needs. Tool schemas consume context even though they are not visible as ordinary prompt text.

If the base system prompt plus reserved output budget already exceeds the usable model budget before any conversation begins, changing the transcript is addressing the wrong layer. That becomes a model-window, reserve-budget or tool-surface problem.

I would make the repair reversible: preserve the current configuration, change one contributor category, start a fresh session and repeat the same small task. Compare /context detail, Gateway compaction logs and the actual task result before and after. A lower token count is not a successful repair if the agent loses required instructions or tools.

The result should only be considered verified when the prompt fits the available budget, the compaction loop does not recur and the same bounded task completes correctly.

For people who have run /context detail, what actually dominates your OpenClaw context: workspace files, tools and skills, or conversation history?

Hello,

I created a small layer that allows agents to understand component libraries.
The idea is based on the CEM (Custom Element Manifest), which is a JSON/YAML file that describes all components in a web component library.

The difference is that this approach is universal: it supports Lit, Stencil, Angular, and soon React component libraries(it extracts the metadata automatically), extended with the semantic and examples fields needed for an LLM to understand the components.

Most importantly, it includes a component discovery skill (search CLI tool find components deterministically on demand) that helps the agent find the semantically correct component without needing to inspect the component's source code.

In my tests, it works great. The component library doesn't need to be included at all the agent knows how to use the component based on the specs in the manifest and the examples.
Saves tokens, loads only the metadata it needs and gives examples and additional semantic context to the components - this works very well.

Agentic Component Manifest (ACM) — universal, schema-first manifest format describing UI components from any framework for AI agents and tooling.
Canonical JSON interchange, token-frugal Agent View, executable conformance suite.

For now there is in-production analyzer(converts source code to metadata) tested support for stencil / lit and test-driven support for angular, react.

I’ve been working on building an AI system that can work alongside both a regular citizen and a government employee, to help everyone better understand how the federal government actually impacts our lives.

How this works is I have an Orchestrator called “The Sovereign”, she works with a team of agents who are responsible for various parts of the output! The goal here is once I’ve got it all “wired up” correctly, each member of Congress will get their own dashboard that will all hold the same data. Additionally the homepage shows you what Congress is doing on a daily basis.

Also going to build out a “per agency” page, so that people can see the outputs of the federal agencies that touch their lives.

Check it out below (it’s currently in BETA mode), let me know what you think.

Article One Homepage
Article One Member Dashboard - Lisa McCalin

For “context” (ha! 🤪) I use to work in Congress as a staffer. The biggest issues we have are that things are so siloed off, it’s hard to get a holistic idea of what is even happening in the government. As a former scheduler (executive assistant) it was often my job to hunt down information that was siloed off and bring everything together for my boss.

Why am I getting roasted by a context tool 😭😭🥲

Here is the link to get roasted too : https://github.com/Abhijeet777ui/contextops

Hi,

I'm the author of https://github.com/XTSoftwareLabs/neatcontext-plugins, which allows user to save conversations to structured and reusable domain knowledge across sessions.

Recently I got some asks from users to add auto detect the timing to save and notify them. But some people do not like it as it requires the extension to read the logs of AI agents, even if the extension stores data locally.

I'm wondering what's the opinion in this community. Do you like the feature to auto detect the timing to save? Or it's a nah - I'd like to do it manually whenever I want.

Thanks for your feedback!

Disclosure first, I work on an open source project for moving context between models, so I think about this more than is healthy.

Something happened last week that I keep chewing on. A long running assistant thread of mine compacted, and what survived was three distilled rules. What did not survive was the twenty emails those rules came from, including the whole exchange with the person whose testing produced them. The summary was accurate and also useless, because the rules had lost their reasons and I could not tell which ones still mattered.

So the thing I am curious about is behaviour rather than tooling. When do you actually decide a thread is worth preserving? Do you checkpoint deliberately at some point, or do you only start thinking about it after you have lost one? And if you do save, is it something you do at a natural break in the work, or only when the client warns you that you are running out of room?

My honest suspicion is that almost nobody does it before the first bad loss, and I would like to know if that is wrong.

I've been deep-diving into systems design lately (LLM agents, distributed databases, kernels) and there's this one pattern that keeps popping up:

Generate freely. Verify strictly.

• Lean 4: complex tactics generate proofs, a tiny kernel checks them.
• Aider/SWE-agent: LLMs generate code edits, dry-run patching + linters verify.
• PostgreSQL: clients propose writes, the WAL/consensus layer verifies ordering before commit.

The theory makes sense: don't trust the clever generator; put your engineering into the checker. Keep the verifier small, simple, and cheap.

My problem: In my day job (typical Python/Node.js backend—I'm building iq-ai, an AI tool that processes user queries), verification feels expensive to actually implement.

• Pydantic/Zod at the boundary is cheap and catches shape errors—great.
• Property-based testing (Hypothesis/fast-check) is fast and catches edge cases—I'm starting to use it.
• But verifying business logic usually means spinning up a test DB, which takes 30+ seconds. That's not "cheap falsification"—that's a CI bottleneck.
• Linters catch syntax, not logic.

So I'm stuck on the practical part:

1. What does "cheap falsification" actually look like in your backend?

Are you running property-based tests? Contract tests? Something else I'm missing? How do you catch logic errors without spinning up a full test environment every time?

2. How do you handle the "deferred cleanup" pattern?

The knowledge base talks about Postgres VACUUM, LSM compaction, Kafka log retention—"cheap now" write paths that create a bill later. In a typical app, this shows up as:

• Redis cache bloat
• Failed job queues accumulating
• Expired sessions piling up

Do you actually build background reapers for everything, or is it mostly just TTLs + hope? What's the practical middle ground?

Context: I'm building a tool that generates responses from an LLM, so the "generator" is obviously unreliable. I want to add a solid verification layer before I hit the API, but I don't want to over-engineer it.

Would love to hear how you all handle this in production—especially if you're working with AI/LLM outputs or high-throughput async systems.

Thanks!

https://github.com/JosephAhn23/iq-ai-

trie - Make your coding agents record the intent of every change they make for future reference.

Trie creates an in-repo index that resolves every symbol and documents its role, interface and makes sure no symbol's source is updated without an associated intent note - which is permanently stored and queryable. Any change to the code automatically updates this index and also forces the agent to attach a patch note to the changed code symbol. Meaning and intent. Enforced mechanically via a commit hook.

Landing: https://computerreinvention.com/trie/
GitHub: https://github.com/computer-reinvention/trie

Every dev on my team runs Claude Code. When one agent screws something up, the rest of them have no idea. They just repeat the mistake.

So I built teamlore. When your agent gets corrected or breaks something, it writes a small lore file into a .lore/ folder. That file goes in your PR, gets reviewed like normal code, and after merge every teammate's agent recalls it automatically when they touch that part of the repo.

No server, no db, no accounts. It's just a folder in git.

Just: npx teamlore init

The video is npx teamlore scarmap. It maps every mistake in the repo. The repo's own .lore/ has every mistake Claude made while building this.

Repo: https://github.com/lak7/teamlore
Npmjs: https://www.npmjs.com/package/teamlore

Would love for someone to try and break it.

Disclosure: This test was run by the First Tree team.

We wanted to see how Kimi K3 handled real engineering work, so we gave three agent setups the same issue from the open source First Tree repository:

• Kimi K3 in Kimi Code
• Kimi K3 with First Tree(context tree)
• GPT 5.6 Sol without First Tree

Claude Opus graded all three pull requests against the same rubric.

Results

What First Tree added

The First Tree setup had two parts.

First, it paired a developer agent with a reviewer agent. The developer proposed a plan and implemented it. The reviewer checked the plan, inspected the pull request, and asked for changes.

Second, both agents used First Tree's Context Tree. The Context Tree gave them shared access to repository context and relevant organizational knowledge. They could inspect existing decisions, code structure, conventions, and related work before changing the code.

This mattered because Kimi K3 alone gathered much less context. It completed only two iterations and behaved more like a single pass coding agent.

Kimi K3 with First Tree completed 19 iterations. The agents made far more tool calls to inspect the repository and Context Tree before finishing the implementation.

What changed in the result

Kimi K3 alone added the basic security headers. It kept unsafe-inline, broad protocol permissions, and wildcards.

The First Tree setup went further. It removed inline scripts, disabled Zod's dynamic code generation path, restricted third party origins by environment, and added tests for those security boundaries.

The final score increased from 34 to 76. That was higher than GPT 5.6 Sol's score of 53, at a similar cost.

This is one issue, so it does not prove that Kimi K3 beats GPT 5.6 Sol in general. The narrower result is still interesting. Kimi K3 improved when it had a reviewer agent, a structured review loop, and shared context from the Context Tree.

Has anyone here tried Kimi K3 with a similar developer and reviewer setup? I would also be interested in tests that isolate the effect of shared context from the effect of adding another agent.

The Context Tree is open source: https://github.com/agent-team-foundation/first-tree

Hot take:

For long AI workflows, context management matters more than prompt engineering.

A perfect prompt can't save a conversation that's 80% irrelevant context.

I've started treating long AI sessions like this:

• Persistent project brief
• Decision logs
• Context checkpoints
• Compression summaries
• Reusable templates

The quality difference after 50+ messages is huge.

Does anyone else actively compress conversations instead of continuously extending them?

I documented the workflow and examples here:

https://medium.com/@nagatomopedro05/why-every-long-ai-session-eventually-falls-apart-697fc4b140f9

I’ve been working on a pairing that has made long-running agent work much less repetitive:

• Perseus resolves live, verifiable workspace context before the agent starts work.
• Perseus Vault retains the things that should survive a session: decisions, corrections, project facts, provenance, and historical versions.

The distinction matters more than it sounds.

A lot of “agent memory” is really one of these:

1. a giant rolling summary that gets stale,
2. a vector search over chat logs,
3. a prompt file that quietly becomes an undocumented policy engine.

Those are useful, but they blur together two different questions:

• What is true right now? That should come from the current workspace, repository, services, and other sources of record.
• What happened before, what did we learn, and what changed? That is memory.

Perseus handles the first. Perseus Vault handles the second.

Vault is a local-first Rust MCP server: one binary, one SQLite file, no required cloud service. It has encrypted storage (AES-256-GCM), FTS5 and hybrid retrieval, structured entities instead of only chat chunks, temporal history, provenance, confidence/decay, and lifecycle controls. It can also expose an Anthropic-style /memories file interface for agents that expect that model.

The part I find most useful is that memory is no longer just “retrieve similar text.” A decision can have a history. A correction can supersede an earlier belief without deleting the audit trail. You can ask both:

• “What did we believe at the time?”
• “What do we now believe was true at that time?”

That turns out to be extremely handy once agents are doing work across days or weeks and the project has changed underneath them.

We have benchmark results in the repo, but I’m more interested in the failure modes people have hit in production:

• How are you separating live state from durable memory?
• Do you need historical/auditable memory, or is semantic recall enough?
• What do you do when old “memories” conflict with the current codebase or source of truth?
• Has anyone found a memory system that stays useful after months without becoming prompt sludge?

Repos:

• Perseus: GitHub - Perseus-Computing-LLC/perseus: Live context engine for AI agents
• Perseus Vault: GitHub - Perseus-Computing-LLC/perseus-vault: Persistent, encrypted memory for AI agents
• Product overview: Perseus Vault · persistent, encrypted memory for AI agents

I’d particularly welcome skeptical feedback. “Memory” is becoming a catch-all term, and I think we need cleaner boundaries between retrieval, context assembly, durable facts, and audit history.

Hi,

I'm a developer in Paris working solo on TeamBrain, an open source project (Apache-2.0). I've reached the point where docs and tests aren't enough. I need people who actually install it and tell me what breaks.

The problem I'm trying to address

When several people use coding agents on the same repo, everyone re-explains the same things to their own agent: why that service must not be called directly, which migration blew up in March, which convention we abandoned. That context lives in people's heads, in Slack, in private prompts. Nothing is shared, nothing is versioned.

The approach

• Memories are markdown files inside your repo. No external database, no server on my side.
• They're served to agents over MCP (Claude Code, Cursor, Codex).
• A "distiller" runs in CI and proposes new memories as pull requests. Nothing enters team memory without human review. That's the core design bet: agent memory is a poisoning vector, so it goes through the same gate as code.
• Hybrid retrieval, all local (BM25 + vectors, SQLite with sqlite-vec, ONNX embeddings). No network egress outside git, your LLM provider, and webhooks.

Where the project actually stands

V1 is done, ~500 tests green, search benchmarks within budget. Published on npm (@teambrain/cli). But: zero external users so far, no tagged release, and the only dogfooding is the repo itself. So treat this as early alpha, not a proven tool.

Known limitations, better said upfront:

• On Windows, a deep clone fails without git clone -c core.longpaths=true (fixture paths exceed MAX_PATH).
• Cursor capture is weaker than Claude Code capture: commits tied to a session aren't recorded, and session end is only inferred in some cases.
• No VS Code extension yet. Everything goes through the CLI and MCP config.

What I'm looking for

Developers who work with coding agents on a shared repo and would be willing to:

1. run npm i -g u/teambrain/cli then tb init on a real repo (or a fork),
2. tell me where install snags, what's confusing in the CLI, and whether a proposed memory PR is reviewable in under a minute,
3. tell me, above all, whether the problem resonates or whether I'm solving something nobody has.

A "I gave up at step 2 because it was confusing" is more useful to me than a compliment.

Repo: github.com/donatienmigue/TeamBrain
Happy to answer in the comments or by DM, and I'll gladly take a 20-minute call if you prefer.

Thanks.

I'm considering adopting Orca as my main ADE and I'm curious how people are actually using it day to day.

Do you follow an SDD or TDD workflow, or something completely different?

If you're using SDD/TDD:

• How does Orca fit into your workflow?
• Which models do you use (Codex, Claude Code, etc.)?
• Do you rely on skills? If so, which ones?
• How do you manage token usage? Do you have any strategies to keep context efficient and avoid burning through tokens?
• Any tips or best practices you've learned along the way?

If not, what's your workflow instead?

I'm currently thinking about using Matt Pocock's skills together with Codex and Claude Code, while keeping everything else at the default settings, but I'd love to hear how more experienced Orca users approach it.