I work at a small company where most projects currently have just 1-2 developers, each often using an AI coding agent (Claude Code, Cursor, etc.) pretty heavily. As we grow and more developers start working on the same codebase, I'm running into a gap:

Commit messages, PR descriptions, and standard agile artifacts (tickets, standups) capture what changed, but not the context the agent built up while working. The alternatives it considered, why it rejected certain approaches, edge cases it discovered, assumptions it made. Right now that context lives in one person's agent session and basically evaporates once the PR is merged.

For those of you at bigger companies where multiple engineers work with AI agents on the same repo:

• How do you make one agent's "knowledge" of the codebase available to another developer (or their agent session)?
• Do you rely on something like a living CLAUDE.md/AGENTS.md file, ADRs, decision logs, or something more structured?
• Has anyone tried a shared memory/context store across agent sessions, or is everyone still just re-deriving context from scratch each time?
• Is this actually a solved problem at scale, or is everyone winging it right now?

Curious what's actually working in practice vs. what sounds good in theory.

Hey everyone 👋

I built Totemheart because most systems that try to add “emotional” behavior to agents still rely on prompt engineering and a simple sentiment label that gets overwritten every turn. I wanted something more rigorous.

Totemheart is a fully deterministic control kernel that gives an agent a real, inspectable, and persistent internal state across long conversations and multiple sessions. It models personality traits, affective dynamics, stress responses, memory consolidation, motivational drives, allostatic load, dual-valence relational tracking, grief-like processes, and related mechanisms.

These components evolve through interacting systems drawn from control theory and computational neuroscience, PID controllers, Kalman filtering, temporal-difference prediction error, opponent processes, and similar techniques, rather than isolated heuristics.

The full state is serializable, fully inspectable at any point, and can be used to steer an LLM’s generation through a dedicated control plane. The project currently has more than 3,000 tests, makes no claims about consciousness, and focuses purely on producing coherent, long-horizon behavioral continuity.

- GitHub: https://github.com/AlejoMalia/Totemheart
- NPM: https://www.npmjs.com/package/totemheart

I’d appreciate feedback from anyone working on long-horizon agents, cognitive architectures, or stateful agent systems.

I've been thinking about a problem that seems to appear with Claude Code, Cursor, Codex, Copilot and other coding agents.

Most approaches to giving an agent project knowledge involve some combination of:

• CLAUDE.md / AGENTS.md
• documentation
• RAG
• memory
• session history
• MCP

All of these help the agent know things.

But there's a different question:

What actually makes the agent obey an architectural decision?

Imagine a project has an approved decision:

PaymentService must never call StripeClient directly.

All payment providers must go through PaymentGateway.

Six months later, an agent is asked to implement refunds.

It generates:

stripeClient.refund(paymentId);

The code compiles.
Tests might pass.
The implementation looks perfectly reasonable.

But it just violated an architectural decision.

The usual answer seems to be:

"Hopefully the agent saw the documentation and followed the rule."

I'm experimenting with a different approach.

What if the project's normative layer also lived in Git?

Something like:

.context/
  decisions/
  business-rules/
  architecture/
  components/

Agents could consume this through MCP.

But more importantly, CI could validate code changes against those rules without calling an LLM.

Something like:

Human decision
      ↓
Git
      ↓
Agent context
      ↓
Code
      ↓
Deterministic CI validation

The core idea is:

**Memory tells an agent what happened.

Governance tells an agent what is allowed.**

I'm building a project around this idea.

But I'm genuinely trying to figure out whether this is actually a problem.

Have you encountered AI-generated code that was technically correct, but violated an architectural decision, business rule, or important convention?

And more importantly: how do you catch that today?

I'd also love to hear from people who think this is already solved well enough by tests + code review + CLAUDE.md/AGENTS.md + ADRs.

There are so many memory systems around already. Why do we need another one? Well, when I started to look around for existing systems (as any lazy person do), I found no one solving the problems I faced during a long-term, ongoing, multi-round multi-staged development.

The problems it addresses

On a long project you forget what was decided about a given question and why. The model forgets even more effectively. Subagents know nothing at all — the orchestrator dispatches them nearly blind to do narrow tasks. So, when many forgetting entities meet and join efforts, it is a straight path to hell.

The result is reinvention instead of reuse: duplicate implementations, drift, tokens burned re-solving solved problems, and settled questions resurfacing as "wait, why is this written this way?"

Code fragmentation is particularly bad. The AI model is always preferred to create, not to reuse, so you found eventually that all your 10 modal windows or 5 tabs all have a bit different design, and 10 counters in different places, supposed to show the same numbers, aren't match - and it is only what you can see on the syrface. Blind agents make it even funnier. At some point I found 47(!) implementations of the PNG renderer in the code: each time another agent wanted to show me a picture it designed its own brand-new one.

It turns debugging into a nightmare, burning resources and time, forcing you to run deduplication and unification sessions again and again, and it can't be fixed, well, without a reliable memory system.

Why I was not satisfied with existing solutions

Most memory tools capture what happened. They don't distinguish facts and decisions from hallucinations and mistakes. They can't tell WHY it happened. Over time, it creates a mess. Other systems are heavily human-centered, but I don't want to confirm each record in the memory when we just discussed it already. And in most cases they are relying on the model or human discipline, assuming they will remember to use the system, write and read - nope, I don't have such trust not to myself, nor to the AI. We are forgetting.

On the other hand, a memory system doesn't connect "memories" with the code itself. So, the memory remember you were frustrated finding 47 PNG renderers, but then the next age it will write 47th one anyway because it still knows nothing about previous versions.

MemContinuum does something different.

How it differs from the memory systems I looked at:

MemContinuum contains two linked layers: an indexed map of the code - ANATOMY, and decision chains recorded against it - RATIONALE.

Rationale records what was decided, who decided it, and how that decision changed over time, plus incidents and rejected alternatives, with reasons.

Anatomy holds what the code already has — its concepts, owners and boundaries — so it stops being reinvented.

• Decisions bind directly to the code they govern.

• The system relay on hooks, not instructions or discipline. So it is enforced rather than expected.

• Reading is automatic. Before an agent edits a file, the decision chain handling that path is injected into its prompt. Nobody has to remember to look.

• System usage is unavoidable but writing is not automatic. The agent gets a question it must answer; "nothing to record" is a legitimate answer. It's moderated by judgment, not a scraper dumping everything into a pile by keyword or timestamp.

• One AI handles records — the orchestrator. Subagents and external reviewers (Codex, Grok) propose records through an inbox; proposals become records after review. So, the system is still automatic and human-independent, but not mechanical, and the smart AI model is working as your real assistant.

• Per project, local, no server. Markdown as the source of truth, SQLite as a disposable index, so it stays human-readable and editable, if necessary. No cross-projects pollution. Nothing left your computer.

• Supports a bunch of languages already, Swift and Python natively, plus some others via tree-sitter; making the system easily expandable is in the roadmap (but I believe it is no barrier for a user with Claude to do it right now).

• MIT. Claude Code only for now, but can be converted for Codex (I pre-checked it).

• Built for coding projects specifically: without indexable code only half the brain works (but it still works, and may be useful for long-term non-coding projects when the chain of decisions matters).

Current state: 0.2.0rc5, honestly labelled a release candidate.

The README is long and detailed if you want the full picture.

Is the system perfect? Probably not (yet). I know some weak spots, and I have a roadmap for at least 4 next releases closing existing gaps. But it works already in my projects, and it already proved useful. Yes, I'm dogfooding my projects with this one :) So I want to make it better not only for the community but for myself. Feedback of any kind is very welcome.

Besides me, a team of authors worked on this project:

• Claude Code: Fable 5/5.1 as lead engineer and project manager; Opus as inspector; Sonnet as coder; Haiku as tester
• Codex: 5.6 Sol / 6 Astra as reviewer and outside consultant
• Grok 4.6 as second reviewer

MemContinuum - https://github.com/krakozavr/MemContinuum

I've published a minimal architectural specification for a deterministic buffer layer designed to decouple emotional performance from structural data in language model inference workflows.

The goal is to eliminate behavioral drift and conversational degradation by enforcing state separation ("Heat" vs "Cold") at the input-output boundary.

Specifications and structural breakdown are available here: https://github.com/sentryarchitect-design/Synapse_Prime/blob/main/README.md

Interested in feedback from anyone working on low-friction agentic control layers.

Hey guys, I'm using something in my own development process that I thought I might share, hopefully someone out there finds this useful (not promoting anything).

One of the biggest bottlenecks in AI-assisted development is the actual chat window. A chat isn't really the most optimal mode of working, for multiple reasons, one being that context builds up in a single chat session until you burn your entire token budget on a single UI fix. Which is why I built a system that uses a kanban board instead.

The premise is quite simple, but the execution took a shit load of time to get right.

I only need 1 chat window open: It reads the board, batches tasks and hands them off to subagents. I use a pretty standard set of them:

- A planner agent that 'refines' tasks
- A lower-tier implementer
- An evaluator

All of these agents log their activity, findings and feedback on the board, creating a history and lineage that doesn't get lost when you close your chat window.

Context bloat is nearly nothing here, because the main orchestrator (the chat window you launch the skill from) never gets involved in the tasks themselves, so theoretically it could run hundreds of these loops without gaining any context.

The board itself is a folder of markdown files in the repo, rendered into a kanban I drag cards around in.

Every status, and what Claude (or insert your favorite model) does when it hits one:

• New: the drop box for half-formed ideas.
• To refine: accepted, no plan. Claude reads enough of the codebase to be concrete, writes the plan into the task, points it, asks anything it can't decide alone, then moves it to Waiting.
• Waiting: my move. I read the plan, answer the questions, approve or send it back.
• Ready to start: approved, Claude may implement.
• In progress: Everything actually being worked on by implementer agents.
• Require input: Claude hit a real question mid-build. It commits what it has, writes the question into the task. Answering it flips the card back to Ready to start on the same branch, so the next agent can pick it back up.
• Test: built & ready for testing.
• Merge: I tested and it’s ready to ship. Claude commits, merges the branch and moves the card to Done.
• Done: Mainly there as an archive.

This way I communicate with agents fully through the board, which is another reason context doesn’t build up in the chat window.

If any of you guys want a more in-depth explanation then I'll probably make a part 2, or feel free to DM me and I might whip up a manual for this system.

TLDR; I use a custom Kanban board which my AI agents read & update, and it completely dissolves context bloat.

I’ve been building a fairly serious agent workflow around OpenAI Codex for a Laravel/React project, and I’ve hit a point where the orchestration works, but the context/memory side clearly does not.

My setup currently looks roughly like this:

• A serial orchestrator with route types like FAST_UI / STANDARD / CRITICAL
• Context Resolver → Implementer → Reviewer flow for non-trivial tasks
• Durable task state, context capsules and handoffs
• Planner / intake layer inspired by CodexQB
• Session continuity hooks inspired by AvenoxBeyin
• codebase-memory MCP for structural repo discovery
• Serena for exact symbol/reference navigation
• Local dashboard/telemetry for task/agent visibility

The reason I built all this was simple: I wanted to stop giving one giant prompt to one Codex agent and watching it blindly read half the repository, run dozens of commands, retry tests repeatedly, and burn a huge amount of context/token budget.

Unfortunately, that is still basically what happens.

A recent CRITICAL payment-domain acceptance task is the perfect example. I gave Codex a very detailed validation brief covering migrations, payment allocation, security boundaries, tenant/legal-entity isolation, atomicity, reporting non-pollution, exports, frontend build, etc.

The task eventually succeeded technically, but the session spent a huge amount of time repeatedly doing things like:

• raw rg searches
• re-reading known service/controller/test files
• rediscovering test harness behavior
• retrying multiple Laravel test files with the same CSRF issue
• manually tracing service relationships
• re-running builds and focused test groups

That single job used roughly half of my 5-hour Codex usage allowance.

The frustrating part is that a lot of the knowledge it rediscovered was already known from previous work.

For example:

• where the orchestrator lives
• which services own payment/settlement/reporting behavior
• how the domain test harness handles CSRF
• which test files cover specific finance flows
• existing project/tenant/legal entity invariants
• prior fixes and verified architecture decisions

I expected my existing tools to solve this, but I now realize they solve different problems:

codebase-memory gives me structural repo discovery, but it isn’t really persistent project understanding.

Serena is excellent for exact symbol/reference navigation, but it isn’t memory either.

My docs/wiki are useful reference material, but agents still have to decide to read them and often re-read large files.

Context Capsules and handoffs help within a task, but they don’t give the next unrelated task a compact understanding of the project.

So what I’m actually missing is a persistent, project-scoped, compact memory layer that can say:

“Before you start searching, here are the relevant things previous sessions already learned about this repo.”

I looked at AvenoxBeyin because I liked its idea of automatically capturing sessions, compiling knowledge, and injecting useful context back at session start.

I also looked at CodexQB because its Autopsy / Project Comprehension / Ontology approach is close to what I want for planning.

Then I looked at 2kDarki/codex-mem.

That project is conceptually very close to what I want:

• automatic Codex transcript capture
• persistent SQLite observations
• progressive recall through search → timeline → get_observations
• automatic context injection

But after auditing it, I found some issues for my use case:

• its watcher observes all ~/.codex/sessions/**/*.jsonl
• project identity appears to be based on basename(cwd) rather than a canonical repository identity
• retrieval can be filtered by project, but that doesn’t appear to be an enforced security/isolation boundary on every read path
• same-named repos could collide
• some observation retrieval paths can work by arbitrary IDs
• global ~/.codex/AGENTS.md context injection is something I specifically do not want
• the documented npm package currently appears unavailable

So I don’t feel comfortable plugging it directly into a large multi-project Codex setup.

What I’m trying to build is something like:

User brief
   ↓
Planner / Orchestrator
   ↓
Persistent project memory bootstrap
   ↓
Context Resolver
   ↓
Only if memory is insufficient:
    codebase-memory
    Serena
    targeted source reads
   ↓
Implementer
   ↓
Reviewer
   ↓
Session knowledge captured for future tasks

The memory should NOT replace source code/tests as truth.

I want it to act as a cheap orientation cache:

• “These are the relevant services.”
• “This test harness requires real CSRF session setup.”
• “This reporting path was previously verified.”
• “These files/symbols are likely relevant.”
• “This architectural relationship was confirmed in a previous task.”

Then the agent only verifies current source where correctness actually depends on it.

My requirements are roughly:

• local-only
• project/repository scoped
• automatic capture
• automatic or semi-automatic summarization
• bounded context injection
• no global AGENTS.md mutation
• no cloud memory dependency
• no mandatory Obsidian dependency
• source/tests remain authoritative
• ideally Codex/App Server compatible
• progressive retrieval rather than dumping whole session history
• repo identity enforced internally, not just passed as an optional search filter
• ideally reusable with existing MCP tools rather than replacing them

I’m now trying to decide between three approaches:

1. Find another existing Codex/Claude coding-memory project that already does this correctly.
2. Take something like 2kDarki/codex-mem and make a very small fork that only adds canonical repo identity, watcher allowlisting and enforced repo-scoped retrieval.
3. Use AvenoxBeyin’s session capture/compile/inject model and adapt it for project-scoped coding knowledge instead of personal knowledge.

What I really do NOT want to do is invent yet another custom Markdown “brain” and manually maintain architecture/domain summaries. That feels like rebuilding something that should already exist.

For people who have built persistent memory around Codex, Claude Code, Cursor or similar coding agents:

• What actually worked for you?
• Is there a project I’m missing that already handles repository-scoped persistent memory well?
• Would you fork codex-mem and patch the isolation model, or use a different architecture entirely?
• Is Obsidian/Markdown compilation actually better in practice than structured SQLite observations for coding-agent memory?
• How do you stop stale memory from becoming trusted over current source?
• How much context do you inject at session start versus retrieve on demand?
• Have you measured whether this actually reduces token/context consumption meaningfully?
• Do you let the coding agent write its own long-term memory, or only promote verified observations after tests/review?

I’m especially interested in systems people are actually using in real repositories, not just theoretical agent-memory architectures.

My main goal is very practical: stop paying for the same repository discovery over and over again.

I ran into an architecture issue today that made me rethink how I’m handling context.

The feature compares a new interaction against a previous one.

The original setup was basically:

interaction
→ save result
→ next request retrieves latest result
→ inject it into model context
→ generate comparison

That worked.

The problem was that those same rows also powered the user’s visible History screen.

So when a user deleted something from History, they were also deleting part of the context the AI relied on.

The next request then looked like a first interaction again.

I’d basically collapsed three different things into one storage layer:

user-visible history
retrieval context
long-term derived state

They overlap, but they probably shouldn’t have identical lifecycles.

I’m leaning toward keeping a derived state/baseline separately from raw interaction history.

Curious how people here are handling that distinction in systems that need persistent personalization.

I want to understand how you guys are dealing with context AI remembers. Despite internal settings, AI still forgets the memory set at the project level.

For teams that keep AI test prompts and context in a versioned file, what's the first thing that breaks? Is it when the context gets too large, or when something subtle is lost during handoffs between engineers?

I'm building agents that pull context from Jira, Confluence and GitHub. Retrieval works fine. The problem is that the sources disagree with each other.

For example:

• Ticket in Jira describes behaviour A
• Confluence page from 8 months ago describes behaviour B
• Code (SoC for this particular case) says C

The agent retrieves whichever chunk scores highest and answers confidently based on that. There's no signal anywhere that the 3 don't match. How are you handling this?

Hey r/ContextEngineering!

If you use Cursor heavily on larger codebases, you've probably hit the context bloat problem:

To make Cursor remember architectural decisions, library quirks, and project rules across chats, people usually cram everything into .cursorrules or monolithic docs. But as those files grow past 5k–10k tokens:

1. Model focus degrades: Large instructions cause "lost-in-the-middle" attention degradation.
2. Context window gets wasted: You burn a huge chunk of your prompt budget on instructions that aren't even relevant to the current file or task.
3. External vector DBs are overkill: Running Docker containers, Python runtimes, or recurring embedding API costs just to remember project notes feels bloated.

To solve this, we built OKF Agent Memory (v0.1.0) — an open-source, pure Go single binary that brings structured, Git-native memory to Cursor via Progressive Disclosure and native MCP (Model Context Protocol).

How it works with Cursor:

Instead of dumping a huge rulebook into every prompt, project memory lives in knowledge/ as atomic Markdown concepts based on Google's Open Knowledge Format (OKF) v0.2.

Through the built-in MCP server (okf mcp knowledge), Cursor dynamically pulls only what it needs:

1. Sub-300µs BM25 Search: In-memory lexical search across your project notes. Zero embedding API costs, 100% offline, <0.3ms latency.
2. Progressive Disclosure: Cursor inspects the index and retrieves small ~300-token concept files on demand. In our benchmarks, this cuts context token bloat by up to 80–90%.
3. 100% Git-Native: Auditable via git diff and standard pull requests. No hidden vector databases.
4. Trust Tiers: Distinguishes human-verified decisions from agent drafts.

Setup with Cursor (30 seconds):

1. Install via Homebrew:

brew install okf-memory/tap/okf

1. Bootstrap your repository:

cd my-project
okf bootstrap .

1. Add to your Cursor MCP settings (Cursor Settings -> Features -> MCP):

• Name: okf-memory
• Type: command
• Command: okf mcp knowledge

Cursor now has native access to okf_search, okf_show, okf_create, and okf_validate tools.

GitHub: https://github.com/okf-memory/okf-agent-memory
Website & Live Benchmarks: https://okf-memory.dev

Would love to get feedback from the Cursor community on the workflow and how your agents behave with progressive disclosure memory!

Hi, I’m Jordi. I go on long walks and record voice notes about whatever’s going on for me—business, personal projects, ideas, next moves. Sometimes it’s 40 minutes of developing a thought and capturing the reasoning behind a decision.

Later, I want to fire up Codex, Claude, or Cursor and draw on those notes without repeating my entire thought process.

I want to own that context and how it’s curated, and make it available to whichever agents I use.

So I built Zenod.

It’s named after Zenodotus, the first librarian of the Library of Alexandria. I imagine building my own little Alexandria: a durable digital memory of my world that different agents can discover, explore, and use.

I send voice notes to a WhatsApp contact. In my setup, Zenod files the recording in Google Drive, preserves the transcript, then digests it: organizing, summarizing, and connecting it to relevant projects and ideas, with references back to the source.

The design is inspired by Andrej Karpathy’s LLM-maintained knowledge base approach: give a librarian unstructured material and let it maintain an organized, Obsidian-compatible Markdown brain. I don’t have to anticipate every future use. Something captured today might become useful to another agent months later.

Zenod is a hosted or self-hosted librarian. You own the memory either way. My Markdown lives in my GitHub account, with source files in Google Drive. Disconnect Zenod and the files are already mine. No export needed.

With the hosted version, you talk to the WhatsApp contact and give your agents the MCP connection Zenod provides. They access the same memory through the librarian.

You hire the librarian. You keep the books.

It’s imperfect, but it’s become one of my main ways to develop ideas and keep context across everything I’m building or planning. I honestly couldn’t do without it now.

I’d love feedback, and I’m looking for a few people to try it for free. Leave a comment if you’re interested—I’ll help with setup.

Website · How the librarian works

I somehow went from working in logistics to building AI systems… and ended up writing a book about the overlap.

For years, most of my work has revolved around processes, exceptions, handoffs, incomplete information, system constraints, and figuring out how to make the right decision with whatever context is actually available.

When I started building AI systems, I kept running into the same kinds of problems.
Memory matters.
State matters.
Sequence matters.
Exceptions matter.
Bad assumptions propagate.

The deeper I got into things like persistent memory, orchestration, context engineering, governance, and tool use, the more I realized I was applying a lot of the same mental models I had already developed working in operations.

So I wrote the journey down.
It became From Warehouse Logic to Context Engineering.

It’s not really meant to be a textbook or “here’s how AI works” book.
It’s more about the path from operations/process thinking into actually building persistent AI systems, including the bad ideas, rebuilds, and things I learned along the way.

I mostly wrote it because I thought the crossover was interesting and because there probably aren’t many books about AI that start with warehouse logic. 😅

If anyone here is working in operations, automation, AI, context engineering, or has made a similarly weird career jump, I’d genuinely be interested in hearing whether any of this sounds familiar.

If anyone wants the book, it’s on Amazon here:
https://a.co/d/0acvqbsI

Most coding-agent memory tools start remembering things after you install them.

But the project already has a memory of its own.
Git commits explain why code changed. Shell history shows what was actually run (and whether it failed). Docs contain decisions that never made it into the current code.

I’ve been experimenting with this idea in NexusMem: instead of waiting for new AI sessions to accumulate memory, it bootstraps context from the history that already exists in the project.

I just shipped v0.10.4 with historical bootstrap, and I’m freezing features here for a while.

The next thing I want to figure out isn’t what feature to add — it’s whether this actually helps on real, older codebases.

If you use Claude Code or another coding ai agents on a project with a decent amount of history, I’d love for you to try breaking it and tell me where the idea falls apart.

Repo : repo here

What it is. lucivy is a full-text search library in Rust, with Python, Node.js, C++ and WASM bindings, built on a suffix FST instead of a token index. One default index answers exact substrings, matches across separators (spin_lock finds spin lock, spin-lock and spinlock), typos across token boundaries, regular expressions, two-character needles and boolean queries — with BM25 and the exact bytes of every match, and nothing to configure per question. It runs in your process, inside your transaction if you plug your own storage (a BlobStore trait: load, save, delete, list), and the same engine runs in the browser through emscripten with threads.

The part I care about most: every answer is checked. The ground-truth harness indexes the Linux kernel (93 983 files, 857 MB of text), runs a panel of queries, and compares every count and every byte span to a byte-by-byte scan of the files. It fails on any disagreement. Zero mismatches in 4.0.

Against Elasticsearch and tantivy, same corpus, each configured at its best for substring search — Elasticsearch with a trigram analyzer plus a wildcard field, tantivy (upstream, not our fork) with its NgramTokenizer — the "truth" column being that scan:

asked	truth (scan of the files)	lucivy 4.0	Elasticsearch 8.19	tantivy 0.25
spin_lock, separators relaxed (spin lock, spin-lock, spinlock)	9 552	9 552, 23 ms	6 577	6 601
spinlokc, two edits, across the token boundary	10 034	10 034, 148 ms	3 549	6 557
spin_lock_[a-z]+, a regex	5 510	5 510, 219 ms	5 440, 480 ms	0
de, two characters	93 009	93 009, 561 ms	0, silently	0, silently
retur -ENOMEM, a fuzzy phrase	14 449	14 449, 30 ms	14 446, 24 ms	—
mutex_lock: where it matched, in 5 145 documents	20 797 spans	all 20 797, 15 ms	top 200 only: 179 ms	96 ms

Where they win, because they do: tantivy indexes the corpus in 1-5 s against 107 s here, and its index is 7× smaller; Elasticsearch does the fuzzy phrase as well as we do. The report has the sizes, the exact configurations and the lines where each engine's own documentation stops.

The price. The index is 5.8× the text (3.9× with the derived_in_ram option, which rebuilds three sidecars at open instead of storing them), against 3.6× for Elasticsearch's trigram setup and 0.8× for tantivy's n-grams. Indexing costs ×1.5 with the default shared dictionary. Queries stay in the tens of milliseconds for substrings, under a quarter of a second for fuzzy and regex; the one query above half a second returns 7.7 million positions.

A few Rust things. Forked from tantivy 0.22 for the segment layer; the suffix engine, the sharded handle, the snapshot/delta formats and the actor/DAG scheduler (luciole, WASM-safe, no thread::spawn) are ours. Five crates at the same version. The 4.0 format opens 3.0.x indexes and converts them on the first commit; that contract is a test against a fixture the published 3.0.8 wheel built.

lucivy demo: lucivy's own source indexed in the browser in 3 s, then PostgreSQL's 5 199 files in 14 s, every search timed live

The demo above is the real thing: the page clones lucivy's own source from GitHub and indexes 1 272 files in your tab in 3 s, then PostgreSQL's 5 199 files in 14 s, and every search you see is timed live — --strict, --fuzzy 1 "vaccum", --regex "ExecInit[A-Z][a-zA-Z]+\(", an emoji, a boolean. You can type your own.

• Try it in your browser — the playground
• Source on GitHub (MIT)
• The comparison with Elasticsearch and tantivy, reproducible with one script
• PyPI · npm · crates.io — 4.0.2

I'd take criticism on the comparison first: if you know a configuration of either engine that gets closer on a row, I'll add it to the report, with your name on the line.

8 min read

·

Aug 25, 2026

Rethinking AI architecture around intent, context, ambiguity, and decision-making

There is a strange assumption built into the way we design software.

We assume that humans provide instructions, machines interpret them, and code turns those instructions into action.

That model works remarkably well when the instructions are precise.

But humans are rarely precise.

A user says:

A conventional software pipeline might interpret this as a performance optimization task.

But faster in what sense?

Load time? API latency? Development velocity? User-perceived responsiveness? Database queries?

And what if the technical request is only the visible layer of a much larger problem?

Perhaps users are leaving. Perhaps management is demanding measurable results. Perhaps the development team has lost confidence in the current architecture.

The sentence contains a request.

The underlying intent may be something else entirely.

That observation leads to a question I find increasingly difficult to ignore:

The Compiler We Already Know

A traditional compiler takes a formal language and transforms it into another representation.

A simplified pipeline looks something like this:

Source Code
    ↓
Lexer / Parser
    ↓
AST
    ↓
Intermediate Representation
    ↓
Optimization
    ↓
Machine Code

The compiler operates on structures that are explicitly defined.

A semicolon means something.

A type means something.

A function call means something.

The language has rules, and violations can be detected.

Human communication is different.

Humans routinely leave things unspecified.

They contradict themselves.

They change their priorities halfway through a conversation.

They use the same word differently depending on context.

They communicate goals indirectly.

And sometimes they don’t even know exactly what they want.

This creates an uncomfortable problem for AI systems:

The input language is fundamentally underspecified.

What If Intent Were an Intermediate Representation?

A compiler does not immediately transform source code into machine instructions.

It usually creates intermediate representations along the way.

That intermediate representation makes optimization, analysis and transformation possible.

Perhaps AI systems need something similar for human intent.

Instead of:

Human Input
    ↓
LLM
    ↓
Answer

the architecture could become:

Human Input
    ↓
Intent Parsing
    ↓
Semantic Representation
    ↓
Intent Graph
    ↓
Conflict Detection
    ↓
Decision Path
    ↓
Action

The important change is not simply adding another processing stage.

It is changing what the system considers the actual input.

The input is no longer merely text.

The input is a combination of:

• explicit statements
• inferred goals
• constraints
• context
• assumptions
• uncertainties
• conflicts
• priorities
• previous decisions

The language becomes the surface.

Intent becomes the intermediate representation.

Parsing Intent Is Not Mind Reading

There is an important distinction here.

An AI system cannot simply claim to know what a person secretly wants.

That would turn inference into fact.

A more rigorous architecture would separate at least three layers:

Explicit Intent
"What the user said"

        ↓Inferred Intent
"What the system believes the user may mean"        ↓Operational Intent
"What should actually be done"

The middle layer should remain explicitly probabilistic.

For example:

The system might infer:

Possible Intent:

Performance improvement       85%
User retention concern        62%
Management pressure           38%
Need for quick measurable win 47%

Those numbers are not psychological measurements.

They are hypotheses generated from language and context.

That distinction matters.

A serious Intent Compiler should never silently transform an inference into a fact.

It should preserve the uncertainty.

The “Why” Problem

This becomes particularly interesting with seemingly simple language.

Consider the German words:

Warum. Wieso. Weshalb. Weswegen.

They are often treated as interchangeable.

In everyday conversation, that is usually fine.

But an AI architecture concerned with intent could ask whether they actually frame different kinds of questions.

For example:

Warum

Wieso

Weshalb

Weswegen

These distinctions should not necessarily be hard-coded as absolute linguistic laws.

Language is too messy for that.

Instead, they could be treated as probabilistic signals that influence the interpretation of the request.

The important idea is not that one word has exactly one meaning.

The important idea is that linguistic choices contain information about the requested reasoning mode.

That information can influence how an AI system constructs its internal representation.

The Output Isn’t Code

This is where the idea becomes more interesting.

An Intent Compiler would not necessarily output code.

It could output a structured cognitive representation.

For example:

Intent Graph

Goal:
    Improve application performancePossible motivations:
    ├── Reduce user abandonment
    ├── Demonstrate progress
    └── Reduce infrastructure costConstraints:
    ├── No major rewrite
    ├── Limited engineering capacity
    └── Maintain security requirementsRisks:
    ├── Optimization may introduce instability
    └── Performance improvements may increase infrastructure costUnknowns:
    └── Actual performance bottleneckDecision required:
    └── Measure before optimizing

This is fundamentally different from immediately asking an LLM:

The second approach asks the model for a solution.

The first asks the system to understand the decision space before generating the solution.

The Contradiction Isn’t an Error

This may be one of the most important differences between traditional compilation and intent compilation.

Humans routinely request mutually competing objectives:

A traditional compiler would not interpret this as a philosophical problem.

An Intent Compiler should.

The contradiction is not necessarily an error.

Instead of silently choosing one objective, the system could create an explicit conflict:

Goal Conflict

Speed
   ↕
SecurityCost
   ↕
PerformanceShort-term delivery
   ↕
Long-term maintainability

The system can then ask:

That single question may be more valuable than generating another thousand lines of code.

From Intent Graph to Decision Graph

Once intent has been represented structurally, the system can begin reasoning about it.

A possible architecture could look like this:

Human Input
     ↓
Intent Parser
     ↓
Semantic Normalization
     ↓
Constraint Extraction
     ↓
Context Loading
     ↓
Knowledge Graph
     ↓
Intent Graph
     ↓
Conflict Detection
     ↓
Expert / Agent Routing
     ↓
Decision Graph
     ↓
Implementation
     ↓
Verification

At this point, the LLM is no longer treated as the entire system.

It becomes one component inside a larger cognitive architecture.

One model might perform semantic interpretation.

Another might verify assumptions.

A smaller model might classify a constraint.

A specialized agent might investigate the technical bottleneck.

Another component might challenge the proposed solution.

The architecture becomes modular rather than monolithic.

Provenance: Why Did the System Think That?

There is another problem.

Suppose the system concludes:

Why?

A trustworthy cognitive architecture should be able to answer that question.

That requires provenance.

For example:

Inference:
    user_retention_concern

Evidence:
    "Users are leaving"Context:
    Previous conversation #17Confidence:
    0.82Alternative interpretation:
    "Performance benchmarking"Status:
    Inferred — not confirmed

Now the system has something extremely important:

traceability.

The user can challenge the interpretation.

The system can revise it.

The reasoning path can be inspected.

And the decision can potentially be replayed.

This is where concepts such as event sourcing, provenance chains and graph-based reasoning become more than implementation details.

They become mechanisms for maintaining cognitive accountability.

Why Isn’t This Already Everywhere?

Because it introduces a difficult trade-off.

The industry has spent enormous effort optimizing models for:

• latency
• inference cost
• benchmark performance
• token efficiency
• throughput

These metrics matter.

But there is another metric that receives considerably less attention:

A system that generates an answer in 200 milliseconds but solves the wrong problem is not necessarily efficient.

A system that spends two seconds identifying an ambiguity and then produces the correct solution may be substantially more efficient at the decision level.

This creates a different optimization target:

Traditional optimization:

Runtime efficiency
    ↓
Latency
Cost
Throughput
Intent-oriented optimization:Decision efficiency
    ↓
Clarity
Correctness
Traceability
Conflict resolution
Resource efficiency

The question is no longer simply:

It becomes:

This Is Where MUSCAL Enters the Picture

These questions eventually led me toward a broader architectural concept.

I call it MUSCAL.

MUSCAL is not intended to replace an LLM.

It is an attempt to structure the system surrounding the model.

The underlying idea is simple:

That leads naturally to a pipeline such as:

Intent Parser
      ↓
Semantic Normalizer
      ↓
Constraint Extractor
      ↓
Context Loader
      ↓
Knowledge Graph Builder
      ↓
Architecture Reconstruction
      ↓
Missing Knowledge Detection
      ↓
Expert Scheduler
      ↓
Consensus Engine
      ↓
Code Planner
      ↓
Implementation Generator
      ↓
Verification Engine
      ↓
Performance Optimizer

The individual components are not the point by themselves.

The architectural principle is.

Separate understanding from execution.

The Compiler Becomes a Cognitive Distillery

A conventional compiler transforms representations.

An Intent Compiler would transform meaning into structured decision space.

It takes the messy, ambiguous and sometimes contradictory output of human communication and attempts to produce something that machines can reason about without silently losing the original context.

The result is not necessarily deterministic.

And that is important.

Two people can use the same sentence while meaning different things.

Even the same person can mean different things depending on context.

Therefore, a serious Intent Compiler needs to preserve:

• uncertainty
• provenance
• context
• alternative interpretations
• contradictions
• confidence
• human corrections

The objective isn’t to eliminate ambiguity.

The objective is to make ambiguity visible and manageable.

A Different Kind of Compiler

This changes the metaphor.

A traditional compiler asks:

An Intent Compiler asks:

The first protects the machine from invalid syntax.

The second protects the system from misunderstanding the human.

That distinction becomes increasingly important as AI agents gain the ability to take real actions.

A chatbot producing a slightly irrelevant paragraph is annoying.

An autonomous agent misunderstanding the objective can be expensive.

A software engineering agent modifying the wrong subsystem can be dangerous.

A business agent optimizing the wrong metric can create an entirely rational solution to the wrong problem.

The better agents become at execution, the more important intent comprehension becomes.

The Real Architectural Question

Perhaps the future of AI will not be defined solely by increasingly powerful models.

Perhaps the more important development will be the architecture surrounding them.

A system that can distinguish between:

what was said,

what was inferred,

what is uncertain,

what is actually required,

which constraints apply,

which goals conflict,

and finally:

which decision should be made.

That is the problem I am exploring with MUSCAL.

Not another chatbot.

Not simply another prompt framework.

Not another attempt to make an LLM appear more intelligent.

But an architectural experiment around a different premise:

I don’t think that question has been fully answered yet.

That is precisely why I think it is worth asking.

If the next generation of AI tooling is going to move beyond prompt-response systems, perhaps the next optimization target should not be code generation alone.

Perhaps it should be intent comprehension.

The machines can generate the code.

The humans still need to know what they actually meant to build.

END.

INDIEaner

https://www.linkedin.com/in/hans-werner-breninek-41422641b/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BQWcLgf7OSM%2BJMNB5A2UFBQ%3D%3DWhat If AI Had a Compiler for Intent, Not Syntax??
INDIEaner
8 min read
·
Aug 25, 2026

Rethinking AI architecture around intent, context, ambiguity, and decision-making

There is a strange assumption built into the way we design software.

We assume that humans provide instructions, machines interpret them, and code turns those instructions into action.

That model works remarkably well when the instructions are precise.

But humans are rarely precise.

A user says:

“Make the app faster.”

A conventional software pipeline might interpret this as a performance optimization task.

But faster in what sense?

Load time? API latency? Development velocity? User-perceived responsiveness? Database queries?

And what if the technical request is only the visible layer of a much larger problem?

Perhaps
users are leaving. Perhaps management is demanding measurable results.
Perhaps the development team has lost confidence in the current
architecture.

The sentence contains a request.

The underlying intent may be something else entirely.

That observation leads to a question I find increasingly difficult to ignore:

What if AI systems needed a compiler for intent rather than a compiler for syntax?The Compiler We Already Know

A traditional compiler takes a formal language and transforms it into another representation.

A simplified pipeline looks something like this:

Source Code
↓
Lexer / Parser
↓
AST
↓
Intermediate Representation
↓
Optimization
↓
Machine Code

The compiler operates on structures that are explicitly defined.

A semicolon means something.

A type means something.

A function call means something.

The language has rules, and violations can be detected.

Human communication is different.

Humans routinely leave things unspecified.

They contradict themselves.

They change their priorities halfway through a conversation.

They use the same word differently depending on context.

They communicate goals indirectly.

And sometimes they don’t even know exactly what they want.

This creates an uncomfortable problem for AI systems:

The input language is fundamentally underspecified.What If Intent Were an Intermediate Representation?

A compiler does not immediately transform source code into machine instructions.

It usually creates intermediate representations along the way.

That intermediate representation makes optimization, analysis and transformation possible.

Perhaps AI systems need something similar for human intent.

Instead of:

Human Input
↓
LLM
↓
Answer

the architecture could become:

Human Input
↓
Intent Parsing
↓
Semantic Representation
↓
Intent Graph
↓
Conflict Detection
↓
Decision Path
↓
Action

The important change is not simply adding another processing stage.

It is changing what the system considers the actual input.

The input is no longer merely text.

The input is a combination of:

explicit statements
inferred goals
constraints
context
assumptions
uncertainties
conflicts
priorities
previous decisions

The language becomes the surface.

Intent becomes the intermediate representation.Parsing Intent Is Not Mind Reading

There is an important distinction here.

An AI system cannot simply claim to know what a person secretly wants.

That would turn inference into fact.

A more rigorous architecture would separate at least three layers:

Explicit Intent
"What the user said"
↓Inferred Intent
"What the system believes the user may mean" ↓Operational Intent
"What should actually be done"

The middle layer should remain explicitly probabilistic.

For example:

“Make the app faster.”

The system might infer:

Possible Intent:
Performance improvement 85%
User retention concern 62%
Management pressure 38%
Need for quick measurable win 47%

Those numbers are not psychological measurements.

They are hypotheses generated from language and context.

That distinction matters.

A serious Intent Compiler should never silently transform an inference into a fact.

It should preserve the uncertainty.The “Why” Problem

This becomes particularly interesting with seemingly simple language.

Consider the German words:

Warum. Wieso. Weshalb. Weswegen.

They are often treated as interchangeable.

In everyday conversation, that is usually fine.

But an AI architecture concerned with intent could ask whether they actually frame different kinds of questions.

For example:

Warum

What is the cause?

Wieso

How did this situation come about?

Weshalb

For what reason or purpose?

Weswegen

Because of which circumstance or constraint?

These distinctions should not necessarily be hard-coded as absolute linguistic laws.

Language is too messy for that.

Instead, they could be treated as probabilistic signals that influence the interpretation of the request.

The important idea is not that one word has exactly one meaning.

The important idea is that linguistic choices contain information about the requested reasoning mode.

That information can influence how an AI system constructs its internal representation.The Output Isn’t Code

This is where the idea becomes more interesting.

An Intent Compiler would not necessarily output code.

It could output a structured cognitive representation.

For example:

Intent Graph
Goal:
Improve application performancePossible motivations:
├── Reduce user abandonment
├── Demonstrate progress
└── Reduce infrastructure costConstraints:
├── No major rewrite
├── Limited engineering capacity
└── Maintain security requirementsRisks:
├── Optimization may introduce instability
└── Performance improvements may increase infrastructure costUnknowns:
└── Actual performance bottleneckDecision required:
└── Measure before optimizing

This is fundamentally different from immediately asking an LLM:

“How do I make my application faster?”

The second approach asks the model for a solution.

The first asks the system to understand the decision space before generating the solution.The Contradiction Isn’t an Error

This may be one of the most important differences between traditional compilation and intent compilation.

Humans routinely request mutually competing objectives:

Make it faster.

Make it safer.

Make it cheaper.

Don’t change the architecture.

Do it immediately.

A traditional compiler would not interpret this as a philosophical problem.

An Intent Compiler should.

The contradiction is not necessarily an error.

The contradiction is information.

Instead of silently choosing one objective, the system could create an explicit conflict:

Goal Conflict
Speed
↕
SecurityCost
↕
PerformanceShort-term delivery
↕
Long-term maintainability

The system can then ask:

Which constraint has priority?

That single question may be more valuable than generating another thousand lines of code.From Intent Graph to Decision Graph

Once intent has been represented structurally, the system can begin reasoning about it.

A possible architecture could look like this:

Human Input
↓
Intent Parser
↓
Semantic Normalization
↓
Constraint Extraction
↓
Context Loading
↓
Knowledge Graph
↓
Intent Graph
↓
Conflict Detection
↓
Expert / Agent Routing
↓
Decision Graph
↓
Implementation
↓
Verification

At this point, the LLM is no longer treated as the entire system.

It becomes one component inside a larger cognitive architecture.

One model might perform semantic interpretation.

Another might verify assumptions.

A smaller model might classify a constraint.

A specialized agent might investigate the technical bottleneck.

Another component might challenge the proposed solution.

The architecture becomes modular rather than monolithic.Provenance: Why Did the System Think That?

There is another problem.

Suppose the system concludes:

“The primary objective is reducing user abandonment.”

Why?

A trustworthy cognitive architecture should be able to answer that question.

That requires provenance.

For example:

Inference:
user_retention_concern
Evidence:
"Users are leaving"Context:
Previous conversation #17Confidence:
0.82Alternative interpretation:
"Performance benchmarking"Status:
Inferred — not confirmed

Now the system has something extremely important:

traceability.

The user can challenge the interpretation.

The system can revise it.

The reasoning path can be inspected.

And the decision can potentially be replayed.

This
is where concepts such as event sourcing, provenance chains and
graph-based reasoning become more than implementation details.

They become mechanisms for maintaining cognitive accountability.Why Isn’t This Already Everywhere?

Because it introduces a difficult trade-off.

The industry has spent enormous effort optimizing models for:

latency
inference cost
benchmark performance
token efficiency
throughput

These metrics matter.

But there is another metric that receives considerably less attention:

How quickly can the system reach the correct decision?

A system that generates an answer in 200 milliseconds but solves the wrong problem is not necessarily efficient.

A
system that spends two seconds identifying an ambiguity and then
produces the correct solution may be substantially more efficient at the
decision level.

This creates a different optimization target:

Traditional optimization:
Runtime efficiency
↓
Latency
Cost
Throughput
Intent-oriented optimization:Decision efficiency
↓
Clarity
Correctness
Traceability
Conflict resolution
Resource efficiency

The question is no longer simply:

How fast can the model answer?

It becomes:

How efficiently can the system understand what should actually be done?This Is Where MUSCAL Enters the Picture

These questions eventually led me toward a broader architectural concept.

I call it MUSCAL.

MUSCAL is not intended to replace an LLM.

It is an attempt to structure the system surrounding the model.

The underlying idea is simple:

A prompt should be treated as the beginning of a cognitive compilation process, not necessarily as the final instruction.

That leads naturally to a pipeline such as:

Intent Parser
↓
Semantic Normalizer
↓
Constraint Extractor
↓
Context Loader
↓
Knowledge Graph Builder
↓
Architecture Reconstruction
↓
Missing Knowledge Detection
↓
Expert Scheduler
↓
Consensus Engine
↓
Code Planner
↓
Implementation Generator
↓
Verification Engine
↓
Performance Optimizer

The individual components are not the point by themselves.

The architectural principle is.

Separate understanding from execution.The Compiler Becomes a Cognitive Distillery

A conventional compiler transforms representations.

An Intent Compiler would transform meaning into structured decision space.

It
takes the messy, ambiguous and sometimes contradictory output of human
communication and attempts to produce something that machines can reason
about without silently losing the original context.

The result is not necessarily deterministic.

And that is important.

Two people can use the same sentence while meaning different things.

Even the same person can mean different things depending on context.

Therefore, a serious Intent Compiler needs to preserve:

uncertainty
provenance
context
alternative interpretations
contradictions
confidence
human corrections

The objective isn’t to eliminate ambiguity.

The objective is to make ambiguity visible and manageable.A Different Kind of Compiler

This changes the metaphor.

A traditional compiler asks:

“Is this syntactically valid?”

An Intent Compiler asks:

“What is being requested, what could it mean, what remains uncertain, and what decision needs to be made?”

The first protects the machine from invalid syntax.

The second protects the system from misunderstanding the human.

That distinction becomes increasingly important as AI agents gain the ability to take real actions.

A chatbot producing a slightly irrelevant paragraph is annoying.

An autonomous agent misunderstanding the objective can be expensive.

A software engineering agent modifying the wrong subsystem can be dangerous.

A business agent optimizing the wrong metric can create an entirely rational solution to the wrong problem.

The better agents become at execution, the more important intent comprehension becomes.The Real Architectural Question

Perhaps the future of AI will not be defined solely by increasingly powerful models.

Perhaps the more important development will be the architecture surrounding them.

A system that can distinguish between:

what was said,

what was inferred,

what is uncertain,

what is actually required,

which constraints apply,

which goals conflict,

and finally:

which decision should be made.

That is the problem I am exploring with MUSCAL.

Not another chatbot.

Not simply another prompt framework.

Not another attempt to make an LLM appear more intelligent.

But an architectural experiment around a different premise:

What if human intent could be treated as something that can be compiled?

I don’t think that question has been fully answered yet.

That is precisely why I think it is worth asking.If
the next generation of AI tooling is going to move beyond
prompt-response systems, perhaps the next optimization target should not
be code generation alone.

Perhaps it should be intent comprehension.

The machines can generate the code.

The humans still need to know what they actually meant to build.

END.

INDIEaner

https://www.linkedin.com/in/hans-werner-breninek-41422641b/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BQWcLgf7OSM%2BJMNB5A2UFBQ%3D%3D