This is a fantastic question, and context overload is definitely the final boss of agentic systems and its part of my focus when thinking in agentic platform engineering design.
To answer your question: the flat-file approach has held up surprisingly well, and hasn't hit a ceiling yet. The main reason is lazy loading and the fact that directory scoping acts as a highly accurate proxy for "task context".
When the agent is in a directory, the AGENTS.md layer doesn't inject the entire content of all available skills into the context window. It only injects the index (the skill names and a one-line
description). The agent only reads the actual step-by-step execution file when the skill is explicitly invoked. Because of the directory scoping, a single layer rarely exposes more than 5-10 highly relevant skills anyway.
However, the reason I actively avoid a database for agent instructions comes down to core Platform Engineering principles: GitOps and Determinism.
Agent behavior, safety constraints, and standard operating procedures are essentially Infrastructure as Code. If a team's agent misbehaves or executes a destructive action, I need to be able to look at a Git commit history, review a PR, and perform a deterministic rollback. DB-backed RAG systems are fantastic for dynamic retrieval, but they lose that strict version control and peer-reviewability. It's hard to PR a vector database update.
That said, I completely agree with your approach for a different tier of context, and I think the
hybrid model is the ultimate sweet spot.
In my roadmap, this hybrid model is achieved via MCP (Model Context Protocol):
Behavior & Rules (How to act): Stays in Git-backed flat files (Layers & Skills) to guarantee determinism and auditability.
Domain Knowledge (What to know): Handled by DB-backed RAG/Graphs (like your setup), exposed to the agent via MCP servers.
So instead of the agent trying to load a massive API spec or relationship tree from a file, the
flat-file skill simply instructs: "Use your internal knowledge MCP tool to query the database for relationships and summaries before writing the code."
By the way, and talking about MCP, have you considered wrapping your DB-backed system into an MCP server? It feels like it would be the perfect bridge between deterministic agent instructions and dynamic knowledge retrieval.
Thanks for your comment! it gave me a lot to think about :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a fantastic question, and context overload is definitely the final boss of agentic systems and its part of my focus when thinking in agentic platform engineering design.
To answer your question: the flat-file approach has held up surprisingly well, and hasn't hit a ceiling yet. The main reason is lazy loading and the fact that directory scoping acts as a highly accurate proxy for "task context".
When the agent is in a directory, the AGENTS.md layer doesn't inject the entire content of all available skills into the context window. It only injects the index (the skill names and a one-line
description). The agent only reads the actual step-by-step execution file when the skill is explicitly invoked. Because of the directory scoping, a single layer rarely exposes more than 5-10 highly relevant skills anyway.
However, the reason I actively avoid a database for agent instructions comes down to core Platform Engineering principles: GitOps and Determinism.
Agent behavior, safety constraints, and standard operating procedures are essentially Infrastructure as Code. If a team's agent misbehaves or executes a destructive action, I need to be able to look at a Git commit history, review a PR, and perform a deterministic rollback. DB-backed RAG systems are fantastic for dynamic retrieval, but they lose that strict version control and peer-reviewability. It's hard to PR a vector database update.
That said, I completely agree with your approach for a different tier of context, and I think the
hybrid model is the ultimate sweet spot.
In my roadmap, this hybrid model is achieved via MCP (Model Context Protocol):
So instead of the agent trying to load a massive API spec or relationship tree from a file, the
flat-file skill simply instructs: "Use your internal knowledge MCP tool to query the database for relationships and summaries before writing the code."
By the way, and talking about MCP, have you considered wrapping your DB-backed system into an MCP server? It feels like it would be the perfect bridge between deterministic agent instructions and dynamic knowledge retrieval.
Thanks for your comment! it gave me a lot to think about :)