Four operational problems behind AI agents, and four public projects exploring them

Elzo Brito dos Santos Filho — Thu, 23 Jul 2026 14:51:03 +0000

AI agent demos tend to optimize for one thing: what the model can generate. Production systems fail somewhere else: at the boundaries around state, memory, retrieval, and authority.

Over the last months, I have been building a small public portfolio around those boundaries. This is not a claim that the projects form one integrated stack. They are independent tools connected by the same engineering question:

How can we give agents useful capabilities without giving them unrestricted authority over the system they modify?

I am the author and maintainer of the projects described below. The goal of this post is to explain the problems, the current design choices, and the limitations, not to ask for stars.

1. Unrestricted mutation: ESAA-Core

A coding agent can modify files, run commands, and declare success. But a transcript is not a state machine, and a log of messages does not prove that the resulting repository state followed an allowed workflow.

ESAA-Core explores a stricter model:

Agent proposes
  -> Orchestrator validates
    -> Event store records
      -> Deterministic projection rebuilds state

The agent emits an intention such as claim, complete, or review. A single writer validates the transition, applies workflow gates, records an append-only event, and rebuilds the read model.

This does not make an LLM truthful or eliminate bad code. It does make several classes of invalid transition observable and rejectable: completing work without a prior claim, applying file effects outside an allowed boundary, approving with the wrong role, or silently reopening terminal work.

The practical benefit is replayability. Instead of trusting the latest JSON file or chat message, the system can rebuild current state from the ordered event history and verify projection hashes.

2. Context loss between tools: Conversation ESAA

Governance state and conversational memory are different concerns. A task protocol should not become a dumping ground for every assistant message, but switching between Codex, Claude Code, Grok, or another runner should not erase the reasoning that led to a decision.

Conversation ESAA is an event-sourced memory layer for continuity and handoff across agents. It captures conversation events, derives topics and handoffs, and keeps the append-only history separate from the formal ESAA task store.

That separation matters:

governance answers: Which transition is valid?
memory answers: What context should the next agent recover?

Mixing them would make both harder to reason about. Conversation ESAA can support ESAA-governed work, but it is not a substitute for the governance protocol.

3. Retrieval overhead: rag-sqlite

Semantic search is useful for large conversation histories, but running embeddings inside a synchronous hook is a poor operational trade-off. An early pilot took roughly 16 minutes to build its first index. Putting that work in the critical path would increase hook latency and make the primary workflow depend on Ollama and an embedding model.

rag-sqlite packages deterministic local retrieval as a JSON CLI backed by one SQLite database. It supports local Ollama embeddings, an offline hash mode for tests, hybrid ranking, index generations, and a stable command surface for LLM tools.

Conversation ESAA consumes it as an optional external adapter:

activity.jsonl
  -> asynchronous export
    -> derived private corpus
      -> external rag-sqlite index
        -> search results rehydrated from canonical event IDs

The RAG projection is disposable and fail-open for the main conversation pipeline. Hooks mark the index dirty and schedule work; they do not execute embeddings while holding the main synchronization lock. If retrieval is unavailable, sync and verification still work.

This project is intentionally independent. It can also serve other local corpora without pretending that every use is an ESAA adoption. Its downloads and usage must remain separate from ESAA adoption metrics.

4. Unverifiable automated audits: ESAA-Security

Security agents introduce another authority problem. A model can produce plausible findings, but teams need to know which domains were examined, which boundaries applied, what evidence supported a classification, and whether a rerun reconstructs the same audit state.

ESAA-Security applies the ESAA architecture to structured automated auditing across 16 security domains. Findings, classifications, and audit transitions are governed through the same append-only and projection-oriented approach.

The ambition is not to replace human security review. It is to make automated audit work inspectable: explicit scope, repeatable tasks, recorded transitions, and findings that can be traced back to evidence.

A portfolio, not an integrated stack

The four projects currently align around a simple vocabulary:

Problem	Project	Current role
Agents mutate state without a control plane	ESAA-Core	Governance protocol and runtime
Context disappears between agents	Conversation ESAA	Event-sourced continuity and handoff
Local RAG requires too much infrastructure	rag-sqlite	Deterministic SQLite retrieval CLI
Automated audits are difficult to replay	ESAA-Security	Governed security-audit application

They should not be described as a seamless platform today. Integration needs contracts, examples, and tests before marketing language claims a stack.

Evidence and limits

As of July 23, 2026, the public adoption scan found four independent Tier 3 adopters across five public implementations of the ESAA pattern. ESAA-Core had 57 GitHub stars and 812 PyPI downloads in the previous 30 days; ESAA-Security had 200 stars. Stars and downloads are reach signals, not proof of operational adoption.

The more important limitations are technical:

ESAA-Core is still pre-release software.
Event sourcing rejects known invalid transitions; it does not prove that an agent's implementation is correct.
Conversation memory can preserve bad context as faithfully as good context.
Retrieval quality depends on the corpus, embedding model, and ranking settings.
Automated security findings still require validation and human judgment.
The projects are maintained by a small team and need more external reproduction.

Licensing

ESAA-Core, Conversation ESAA, and rag-sqlite are MIT-licensed. At publication time, GitHub does not detect an explicit license for ESAA-Security, so it should be treated as publicly readable code rather than assumed to grant open-source reuse rights. Clarifying that repository's licensing is a concrete follow-up item.

What I want to learn next

The next milestone is not a larger promotional number. It is better external evidence:

Can a new maintainer run the ESAA-Core quickstart without assistance?
Which workflow gates reject real mistakes rather than only synthetic tests?
Does Conversation ESAA improve a genuine cross-agent handoff?
At what corpus size does rag-sqlite stop being the right trade-off?
Which ESAA-Security domains produce findings that survive independent validation?

If you work on coding agents, agent memory, local RAG, or AppSec automation, I would value criticism of the boundaries and failure modes more than a generic endorsement.

Start with ESAA-Core, or inspect the full public repository list.

DEV Community: Elzo Brito dos Santos Filho