query — is there an additional kind of memory that could be added to be highly impactful at increasing speed and reducing llm hits?
Related to
- Yes: add a project state/cache memory layer. You already have:
- pgv / codex-memory
Curated facts, decisions, preferences. - mwiki
Durable transcript/wiki archive. The missing high-impact layer is: 3. Project Intelligence Cache A fast, structured cache of expensive-to-rediscover project facts. Examples: project:
root: /ws
type: codex-runtime
important_files:- docker-compose.yml
- Dockerfile.codex
- Dockerfile.eco
- bootstrap/codex-bootstrap-loader.sh
entrypoints: - codex-agent.sh
- cdx-agent.sh test_commands: bootstrap:
- bash -n bootstrap/codex-bootstrap-loader.sh
- bash -n codex-agent.sh
services:
- codex-memory-db
- codex-embeddings
- memory-wiki
gotchas: - Do not touch host directly.
- Read ARCHITECTURE.md before auth changes.
“Known project map + command index + current operational facts.”
Why it would help
A lot of LLM/tool time is spent repeatedly answering:
- Where is the thing?
- What files matter?
- What commands verify this?
- What services exist?
- What docs must be updated?
- What should I not touch?
- Which Dockerfile owns which dependency?
- What is the launch path?
- What tests are relevant? Right now that information exists, but the assistant has to reread or infer it. A project intelligence cache could answer instantly. Highest-value subtypes A. File map memory Stores known important files and ownership: {
“file”: “Dockerfile.eco”,
“role”: “heavy ecosystem image”,
“edit_when”: [“OS packages”, “Android SDK”, “Gradle”, “browser tooling”]
} B. Command memory Stores validated commands by purpose: {
“purpose”: “verify bootstrap changes”,
“commands”: [
“bash -n bootstrap/codex-bootstrap-loader.sh”,
“bash -n codex-agent.sh”,
“bash -n cdx-agent.sh”
]
} C. Service topology memory Stores service graph: {
“service”: “memory-wiki”,
“depends_on”: [“codex-memory-db”, “codex-embeddings”],
“writes_to”: “data/memory-wiki”,
“search_rule”: “only explicit request”
} D. Decision ledger Not raw transcript, not just vector search — a concise chronological record: 2026-05-23: Decided memory-wiki is separate from codex-memory.
2026-05-24: Decided memory-wiki search is explicit only.
2026-05-30: Verified pgvector and memory-wiki are working. E. Error/fix cache Very high value. {
“error”: “column project does not exist”,
“cause”: “codex_memory schema uses project_name/project_key”,
“fix”: “query project_name instead”
} This directly reduces repeated debugging. Storage recommendation Use simple local files first: data/project-intel/
map.json
commands.json
services.json
gotchas.json
errors.json
decisions.md Then optionally index them into pgvector later. Why this may outperform another vector memory Vector search is good for fuzzy recall. But speed comes from structured answers. The biggest speedup would come from a deterministic layer the agent can read cheaply:
“Here is the known project map. Here are the relevant files. Here are the test commands. Here are known gotchas.”
Suggested name
- project-intel
- codex-project-index
- agent-situational-memory
- workspace-map
- ops-memory My preferred name:
Project Intelligence Cache
How it fits the stack
pgv / codex-memory
curated facts/preferences
memory-wiki
transcript/wiki archive
project-intel
structured project map, commands, services, known errors, verification recipes
Expected impact
Likely higher speed gains than adding another semantic memory layer.
Potential savings:
- Fewer rg/find/ls/cat commands
- Fewer rereads of docs
- Faster task planning
- Fewer wrong-file edits
- Faster verification selection
- Less need to ask the user for repeated context So yes — if the goal is speed and reduced LLM/tool hits, I’d add structured project intelligence memory next, not another freeform vector store.
Visited 1 times, 1 visit(s) today