AI Agent Logs Blowing Up Your Context? Replace Markdown with a Rust Database

Title

AI Agent Logs Blowing Up Your Context? Replace Markdown with a Rust Database

Meta Description

AppSec engineer builds PentaCore in Rust, an MCP server using encrypted SQLite instead of Markdown as AI agent state storage, solving context window blowup from logs, with context recovery, progress queries, and sub-agent collaboration.

Article Content

When AI agents work on long tasks, log files pile up until even a 256k token context window can't hold them. An AppSec engineer built PentaCore for this — an MCP server written in Rust that uses encrypted SQLite instead of Markdown as the agent's state store.

The Problem: Limitations of Markdown as State Storage

The engineer uses AI agents for reconnaissance, attack surface mapping, and hypothesis testing in security work. After each project runs for a few weeks, the log folder is stuffed with files like recon.md, endpoints.md, attempts-auth.md, progress-subagent-3.md. Although the model has a 256k token context window, the accumulated logs eventually can't all fit.

To recall progress, the agent has to read the entire archive, leaving no room to do actual work. Specific symptoms include:

• Compaction erases progress: After context compaction, the agent re-reads progress.md, sees "invoices module - almost done," and starts over. What exactly "almost" means, no one can say.
• Repeated failed attempts: The agent tries certain hypotheses three times, each time as if for the first time.
• Sub-agents don't know main agent decisions: Scope constraints live in the main agent's context; sub-agents are unaware.
• No quick answer to "what's left?": Must read every file and manually reconstruct the global picture.

Markdown files are good for human reading, but fail as state storage for a running agent: no structure, inconsistent state semantics, and not queryable.

Context compaction is a mechanism commonly used in long-session agent systems: when conversation history approaches the model's context window limit, the system automatically summarizes or discards earlier content to free up space for continued reasoning. The problem is that this compaction is lossy and irreversible — original details disappear, and summaries often lose key qualifiers. For agents that store state in Markdown, compaction means that the next time it reads progress.md, it only sees a vague description and cannot reconstruct which specific step "almost done" refers to or which checks remain, resulting in duplicated work. Compaction itself is not a flaw; the flaw is that state storage relies on non-queryable natural language text, so post-compaction recovery can only rely on re-reading full text, further squeezing an already tight token budget.

Requirements: Six Key Requirements

The author lists a clear set of requirements:

1. Restore full context with minimal tokens — at the start of a new session or when spawning a sub-agent.
2. "What's left?" must be a query, not reading history.
3. Failed attempts are recorded and discovered before the agent repeats them.
4. Decisions made at the top level are communicated to every sub-agent without restating the entire conversation.
5. Completed work is folded into a summary — the next session reads the summary, not hundreds of notes.
6. Everything runs locally, no external services, project data stays on the machine.

Finding no suitable tool, the author built PentaCore: an MCP server written in Rust, a single binary, one encrypted SQLite file. It doesn't plan tasks or decide next steps; it only stores what it's given and returns what's requested.

Design: Dual Storage and Pyramid Structure

PentaCore has two stores:

Notes are narrative content: goals, steps, attempts and their results, facts, decisions, questions, lessons learned. Notes form a tree via parent and a graph via typed links. Search supports exact words and semantics (built-in all-MiniLM-L6-v2 embeddings).

Entities are multiple objects of the same type: hosts, endpoints, files, etc. Each entity has state, attributes, and named checks.

This separation matters. "Show all things that haven't passed check X" is a field filter, and its result should not depend on how the agent phrases the note.

The top level is the goal, below are steps, each step has a checklist. Each endpoint is an entity, marked when checked. Now, "what hasn't been checked" is just one call to query_entities, and the overall view is another call.

Restoring context after compaction

At the start of a new session, one call to resume returns: last checkpoint, work in progress, blockers, failed attempts, decisions made, and all outstanding checklist items. The response fits a configurable token budget and does not silently truncate.

Sub-agents get only the context they need

The main agent creates steps for sub-agents and links relevant decisions via uses. The sub-agent only gets the step ID; calling resume task=<id> returns the task assignment, scope decisions, and summaries of already-checked adjacent areas. No need to restate the main agent's entire conversation.

Summaries replace accumulated history

When a step completes, calling summarize records the work and result. task_summary returns a summary of the entire task in tree order — one call regardless of how many notes are beneath. Agents at any level of the hierarchy can get a focused summary of a region of the entire perimeter.

MCP (Model Context Protocol) is an open protocol that lets AI applications connect to external tools and data sources in a unified way. An MCP server exposes a set of tools, resources, and prompts that clients (such as Claude Code or other agent runtimes) call when needed. PentaCore as an MCP server means it is not embedded in the agent reasoning loop but provides capabilities like resume, summarize, query_entities through a standard interface, and the agent calls them on demand and retrieves structured state according to token budget. This decoupling lets the same state store be reused by different clients and sub-agents, and also makes security boundaries clearer: the server is only responsible for storage and retrieval, not decision-making.

all-MiniLM-L6-v2 is a lightweight sentence embedding model with about 22M parameters that maps text to 384-dimensional vectors, commonly used for semantic search and similarity matching. PentaCore embeds this model so note search supports both exact word matching (e.g., FTS5 full-text index) and semantic nearest-neighbor retrieval: the agent doesn't have to remember which word it used originally, as long as the meaning is similar it can find relevant notes. Running the embedding model locally also fits the "data doesn't leave the machine" requirement, with no external vectorization API. The cost is some startup overhead from first loading the model and building the index, and increased binary size.

Security: Memory Is a Prompt Injection Channel

The author emphasizes: memory is a prompt injection channel. Everything written to memory will later be read as context. Unauthorized writes become injected instructions.

Therefore the following measures are taken:

• stdio only by default: The server can only be called by the process that started it.
• HTTP is not accidentally exposed: Loopback addresses only; refuses to start without a token of at least 32 characters; requires exact Host header to prevent DNS rebinding; rejects any request with an Origin header.
• Boundary input validation: Every parameter is parsed into a type with length and character set constraints; unknown fields are rejected.
• User text never becomes SQL: Only bound parameters are used, FTS5 operators are escaped, and entity queries are assembled from a whitelist of fields and operators.
• Encryption at rest: SQLCipher, secure_delete, WAL cleanup after purging.

The author acknowledges limitations: the SQLCipher key is compiled into the binary. It protects files from those who only have the file, but not from those who have the binary or source code. All known limitations are listed in the README.

DNS rebinding is an attack against local HTTP services: a malicious web page first makes the browser resolve the attacker's domain to their server, then quickly switches DNS so it resolves to 127.0.0.1, thereby bypassing the same-origin policy and making requests to the local port. PentaCore's defense is to validate the exact Host header, ensuring the request actually targets the expected hostname rather than a rebound domain, and to reject requests with an Origin header to block cross-site calls initiated by browsers. Such hardening is necessary for any local agent service listening on a loopback address, because "binding only to 127.0.0.1" is not enough to prevent the browser from being used as a springboard.

When PentaCore Is Not Suitable

• Software development task tracking with dependencies: consider Beads or Claude Code's built-in tasks.
• Short tasks within a single session: model context is sufficient.
• Long-term memory about the user or their preferences: different problem, different tool.

PentaCore is suitable for scenarios where an agent handles many similar goals across multiple sessions, experiences compaction, and needs precise answers to "what's done, what's found, what's left."

Try It

Binaries for Linux, macOS, and Windows are available in Releases, with SHA256SUMS, SBOM, and build provenance attestation. Can be used via claude mcp add pentacore -- /path/to/pentacore or any MCP client configuration. Docker images are available with a read-only root filesystem and dropped capabilities.

Repository: https://github.com/DroBov1Tya/PentaCore

If you find a vulnerability, please use Security -> Report a vulnerability in the repository, not a public issue.

One-line Summary

AppSec engineer writes MCP server PentaCore in Rust, replacing Markdown with encrypted SQLite for agent state storage.

Paragraph Summary

The article introduces PentaCore, built by an AppSec engineer: an MCP server written in Rust that uses encrypted SQLite instead of Markdown as AI agent state storage. The author points out that Markdown logs blow up the 256k context window during long tasks, causing progress loss after compaction, repeated failed attempts, sub-agents disconnected from main agent decisions, and no quick answer to "what's left." PentaCore uses a dual-store design — a note tree carrying narrative and decisions, and an entity table for structured queries — and through tools like resume, summarize, and task_summary achieves low-cost post-compaction recovery, on-demand sub-agent context, and summaries replacing accumulated history. On security, it emphasizes that memory is a prompt injection channel and adopts default stdio, strict HTTP restrictions, input validation, parameterized queries, and SQLCipher encryption, while acknowledging limitations such as embedded keys.