Questioning the Agent Stack: Vector Stores, Hypergraphs and Coding Jobs

The pull toward adding more

Read through this year's coverage of AI agents and one thing stands out ahead of any individual claim: the advice nearly always says to bolt something on. A memory layer. A graph. An orchestration framework. A retrieval pipeline with three reranking passes. More agents to watch the agents you've got. Underneath is a quiet belief that sophistication means progress, and that a system doing nothing fancier than six months ago is falling behind.

A fair amount of that stack has probably been built and defended by anyone reading this. So it's worth pausing on a small cluster of pieces that argue the reverse: the sophisticated thing you added likely hasn't earned its place. Most contrarian tech writing is hype in reverse, equally confident and equally thin on evidence. These three cases are different because each rests on something checkable, whether a benchmark result, a structural proof or a plain account of how someone's workday goes. That standard applies below, and it applies to any stack, including your own.

Each case is a spot where the field reached for more structure although the real problem sat somewhere duller.

Case one: agent memory and vector stores

Agent memory on a vector store is usually settled in about half a minute. Somebody notes that the agent should keep things across sessions, and the reflex follows: embed, store, retrieve by similarity. Tutorials all work that way, so it became the default, and nobody tested it against anything simpler.

One write-up this year ran that test. On the LoCoMo benchmark, a baseline consisting of a folder of plain text files and grep scored higher than several funded, purpose-built memory products. The comparison wasn't staged. Systems with embeddings, similarity search and sometimes graph memory layered on top lost to a setup that takes an afternoon to put together.

Thinking it over, the explanation seems clear. Similarity search finds; it doesn't reason. It does well at pulling text that's close in meaning to a query. It does badly at what memory needs, like recognizing that a fact from three weeks ago was replaced by yesterday's, or that two saved memories conflict and one must win. An index has no sense of time or of corrections, so it returns the nearest vectors and leaves the model to notice that two of the top five contradict each other.

A second mismatch concerns familiarity, not ability. Models have been trained on enormous volumes of material about working with files: opening, searching, editing, listing folders, tracing imports. Files are close to the native material of their training data, and a grep plus file-read loop uses that directly. By contrast, a vendor's vector query API is something the model has to learn to use well inside your own context window, with little earlier exposure. The trade swaps a skill it already has for one it must pick up mid-task, and adds embedding and retrieval delay.

A decision guide for the two options, laid out side by side, looks like this.

WHEN A FILESYSTEM + GREP BASELINE IS ENOUGH        WHEN YOU ACTUALLY NEED A VECTOR STORE
------------------------------------------------   ------------------------------------------------
Single-agent or small-team memory                  Retrieval across a corpus too large to
                                                    fit or scan in context at all
Facts that change over time and need               Cross-document semantic search where
correction, not just accumulation                  keyword overlap is genuinely weak
Memory the model itself writes,                    Centralized memory shared by many agents
manages, and re-reads in its own loop               that needs access control and auditing
Debuggable state, plain text you can                Multi-hop or relational reasoning across
open, diff, and edit by hand                        thousands of entities where similarity
                                                     search is doing real narrowing work

What the file-based loop looks like

"Just use files" sounds hand-wavy until it's code. This version needs no hosted service.

import os
import subprocess
from datetime import datetime
MEMORY_DIR = "agent_memory"
def write_memory(topic: str, content: str) -> str:
    os.makedirs(MEMORY_DIR, exist_ok=True)
    path = os.path.join(MEMORY_DIR, f"{topic}.md")
    timestamp = datetime.utcnow().isoformat()
    with open(path, "a", encoding="utf-8") as f:
        f.write(f"\n## {timestamp}\n{content}\n")
    return path
def recall(query: str) -> str:
    # ripgrep if you have it, grep -r works fine too
    result = subprocess.run(
        ["rg", "-i", "-C", "2", query, MEMORY_DIR],
        capture_output=True, text=True
    )
    return result.stdout or "no matches"
def list_topics() -> list[str]:
    if not os.path.isdir(MEMORY_DIR):
        return []
    return [f[:-3] for f in os.listdir(MEMORY_DIR) if f.endswith(".md")]

Hand the model those three functions as tools and let it decide when to save, when to search and when to load an entire short topic file. The outcome is memory without embedding costs, without a database to host or pay for, and with state you can open in any editor when something misbehaves. When the approach eventually runs out, the reason will be concrete, such as a corpus too big to grep quickly or a multi-hop question that keyword search can't answer. That justifies a vector store far better than copying a tutorial.

None of this says vector databases shouldn't exist. It says don't reach for one before benchmarking the boring baseline. Try full context and filesystem plus grep first, and adopt a paid memory product only if it beats that baseline by enough to cover its cost and the loss of debuggability. Most agent memory never needs to clear that bar.

Case two: hypergraphs in RAG

Last year's default was the vector database. This year's is graph-based RAG, and hypergraphs enter when a team feels an ordinary knowledge graph can't express enough. The case sounds reasonable. A regular edge links two nodes, but lots of facts have more participants. Take an expense approval: one person signs off on a colleague's report, charged to a quarterly marketing budget, on behalf of a finance team. That's five parties in a single fact. Squeezed into pairs, it either stops being one atomic event or splits across several binary edges that queries must stitch back together. A hyperedge connects any number of nodes at once, so it looks like the faithful way to store such facts, and teams build hypergraph RAG expecting the faithfulness to improve retrieval.

A different write-up checked that expectation against the working code of a hypergraph RAG paper instead of its abstract, and found something almost comic. HyperGraphRAG, built to promote native hyperedges, stores everything in a regular graph database with binary edges. Its own authors demonstrate that turning each hyperedge into a few binary edges around a reified node for the event loses nothing, so each form can be rebuilt precisely from the other.

That detail carries the entire argument. Say a native hyperedge and a reified cluster of binary edges hold exactly the same incidence structure, and either one regenerates the other without effort. Then the choice between them has no modeling consequences and amounts to picking a storage format. One commenter summed up the math tersely: the two forms are the same incidence structure, and hypertree width changes by a constant only when arity is bounded. Hypertree width is what determines how expensive a query is. Hop count doesn't, and neither does the number of participants packed into one edge. Convert your representation, shift that figure by a constant, keep each fact to a bounded number of participants (five people approving an expense, not five hundred), and query difficulty stays the same.

Why this catches people out

It's an easy mistake to make. Hop count feels natural, since more nodes between question and answer seems like a harder query. Hypertree width is far less intuitive: it belongs to constraint-satisfaction and query-complexity theory and diverges from hop count in ways you won't see until you look. You can add structure that cuts hops for one sample query while doing nothing, or slightly harm, the complexity class the query belongs to. Worked examples in a paper can look impressive and still reveal nothing about the measure that governs the general case.

Before settling on a plain graph, a reified graph or a native hypergraph store, this comparison helps.

REPRESENTATION          WHAT IT ADDS                     WHAT IT ACTUALLY CHANGES
---------------------   -------------------------------  --------------------------------
Plain binary graph       Simplest to build and query      Baseline; loses atomicity of
                         with standard graph tooling      multi-participant facts
Reified binary graph     Recovers atomicity via an        Same incidence structure as a
(event node + roles)     explicit "event" node             hyperedge; hypertree width
                                                            shifts by a constant only
Native hypergraph        Hyperedges as first-class         No reduction in query
store                    objects, arguably cleaner          complexity class over a
                         to write against                   reified graph; new storage
                                                             engine to run and maintain

That doesn't make graph structure pointless for RAG. Multi-hop relational retrieval does gain from graphs over flat vector search, and no one argues otherwise. The argument concerns the extra jump from graph to hypergraph. Once the proof replaces the pitch, that jump yields neater-looking data models, adds a new kind of infrastructure to operate, and leaves untouched the figure that decides if queries are quick or slow. If retrieval is weak, the remedy with evidence behind it is usually better graph construction or a smarter retrieval strategy over the graph already built, not a more exotic edge type.

Case three: what a senior engineer's job actually is

Both earlier cases deal with retrieval architecture. The last one differs, since it isn't a choice of tool but a question of what senior engineering work is made of.

A tech lead running a five-person team within a company of more than a thousand wrote that AI can't do 95% of his job. He begins with what sounds like a concession: writing code takes up the smallest share of his time, by a wide margin. His team operates on "you build it, you run it," which puts on-call for its systems on his own engineers and not on a separate operations group free to treat production as someone else's concern. His morning starts at 8:30 with pull request review. The code arriving, much of it typed by AI agents, is clearly stronger than what he reviewed two years before. He doesn't question that AI writes good code. He accepts that completely, and then notes how little it changes the work he actually does.

This challenges a premise common in thinking about agent stacks, namely that capability sets the pace of automation. If a model produces correct code, the logic goes, coding stops needing a person, and automation of the job tracks the part of it spent producing code. The tech lead says that equation never held, and AI just makes the flaw visible. His job was not mostly code. It was mostly coordination: choosing what to build and in which order, negotiating scope with people whose priorities clash, reviewing and standing behind decisions others made, carrying the pager, mentoring younger engineers, and mediating between a stakeholder's request and what the system can safely support. No part of that is a coding task.

That may be the most overlooked point of the year in agent debates, more than any benchmark, because it explains why dramatically better coding scores and a dramatically easier job haven't moved together for many senior engineers, even enthusiastic daily users. SWE-bench scores climbing from single digits into the seventies within a couple of years is a real and large step. It doesn't turn into 70% less work, because code production was never 70% of the job, certainly not once the role includes the on-call rotation and the roadmap along with pull requests.

One caveat: the third point carries over to other settings less neatly than the first two did. Claims about vector databases and hypergraphs can be checked against a benchmark or a proof. The coordination-versus-code split in a senior engineer's week varies with company size, team maturity, whether the overhead is dysfunction or something load-bearing, and the person's own seniority. A five-person team in a thousand-person firm with a build-it-run-it policy is one kind of job and doesn't represent every engineering role. The direction of the correction still looks broadly right. Agent capability limits how much of the code-writing slice could be automated, and it says almost nothing about the coordination slice, which never depended on typing speed or code quality.

The shared pattern

Lay the three cases next to one another and the lesson isn't specifically about vector databases, hypergraphs or AI capability. It's about the gap between where a field believed the bottleneck was and where it really sat.

CASE                WHERE COMPLEXITY WAS ADDED         WHERE THE REAL BOTTLENECK WAS
------------------  ----------------------------------  --------------------------------
Agent memory         Vector embeddings, similarity       Whether the model can use a
                     search, sometimes a graph layer      retrieval method it already
                     on top of that                        has deep fluency with
RAG structure         Native hyperedges, a new             The complexity class governing
                      storage engine, more                  query cost, which the fancier
                      elaborate graph modeling               structure barely touches
"How much of the      An assumption that model             Whether the job was ever
job gets automated"   capability alone predicts             mostly about the thing the
                       the automatable fraction              model is good at

None of the sophisticated options was wrong to exist. Vector databases have genuine uses, hypergraphs may help somewhere nobody has located yet, and AI agents do take real drudgery out of engineering work, which the tech lead acknowledges. The error was skipping the question of whether the extra sophistication targets the real bottleneck or just the one that's easiest to wrap an elaborate solution around.

The habit extends far beyond agent engineering. Adding a layer is easier than asking whether the plain baseline was ever measured fairly against it. A new abstraction counts as visible progress that you can point to and call an upgrade. Verifying that grep already does the job, that query complexity actually improved, or that the thing swallowing your week was the thing you assumed, takes longer, feels worse, and sometimes ends in a decision to stop building.

A checklist before the next layer

A short list worth running against any stack before another layer goes in:

1. Have I benchmarked the boring baseline, not just assumed it loses?
   (full-context, grep, a plain graph, a human doing the coordination)
2. Does the new structure change the metric that actually governs cost
   or quality, or does it just look more sophisticated on a diagram?
3. Am I reaching for this because a benchmark or proof told me to,
   or because it's what the tutorials and the funded products default to?
4. If I strip this layer back out, what specifically breaks?
   If I can't name it precisely, I probably don't need the layer yet.
5. Am I solving the bottleneck I actually have, or the bottleneck
   that's most interesting to build a sophisticated solution for?

None of this argues for less engineering. It argues for spending engineering effort on finding where the bottleneck lives before building the elaborate thing that assumes the answer is known. The three pieces weren't contrarian for sport. They did the unglamorous checking, and the checking disagreed with the default. That's a much higher bar than a hot take with a loud headline, and it's the one any stack should be held to.