Tensegrity

Post 4 of the Nexus series: why a runtime library of saved query plans beats cold-start LLM replanning on every query.

---

The plan you already wrote

Point of view is worth 80 IQ points. (Alan Kay)

The previous post, Decisions as indexed data, was about refusing to let design decisions evaporate into chat history. This post is about refusing to let query plans evaporate as well. We cache them, persist them, reach for them again rather than re-deriving from scratch every time. At least, that’s the theory; ideally the practice too.

A common pattern in LLM agentic retrieval is to cold-start on every query. The agent reads the question, reasons about what it means, picks a strategy, executes the strategy, stitches the results into an answer, and then throws the plan away the moment it returns. The next query does it all over again. Same shape of problem, fresh derivation, possibly different answer. The system isn’t learning anything across queries; the agent meets every analytical question as if for the first time. Every trace of what worked (or didn’t) the last time has been discarded along with the plan.

That’s the problem the AgenticScholar paper addresses, and it’s the reason plan-centric retrieval was in Nexus from the start. I read the paper early on while working out what shape Nexus should take, felt that the framing was excellent, and built the loop in.

The AgenticScholar paper

AgenticScholar: Agentic Data Management with Pipeline Orchestration for Scholarly Corpora (arXiv:2603.13774) describes a four-layer architecture for analytical querying over a scholarly corpus: a taxonomy-anchored knowledge graph, an LLM-driven query planner that compiles natural-language questions into operator DAGs, a composable operator library of about fifteen typed operators, and structured ingestion. Recall the four layer architecture from our first post.

Downstream of the planner sits a predefined plans pool: a library of saved plans matched to incoming queries by confidence threshold. If a stored plan clears the threshold, it runs. Otherwise the query is treated as ad-hoc and handed back to the planner.

Their benchmarks run that architecture against Elicit, Gemini Deep Research, SmolAgent, and naive RAG, reporting NDCG@3 of 0.606 against naive RAG’s 0.411 on analytical queries, with an ablation attributing part of that lift to predefined-plan selection specifically. I took the pattern seriously on the strength of the argument rather than the number. The queries were LLM-generated from the same 25-document synthetic corpus they were scored against, the ground truth was LLM-labeled, and two of the baselines are proprietary systems with their own training corpora. The design is worth borrowing; the benchmark is not evidence I can check.

Nexus takes two ideas from the paper directly: the operator-DAG model for analytical retrieval, and the predefined-plans-pool loop. The rest of this post is about where the implementation diverges:

• Storage lives in T2 as structured records (shape, DAG, outcome, tags) in PostgreSQL, sitting alongside memory and the catalog taxonomy. Plans participate in the same query and search machinery as everything else in the project. Which is nice and uniform.
• Matching stacks three signals where the paper uses one: dimension filter for structural matches against plan shape, embedding-based semantic rerank (cached and low latency), and keyword fallback when the shape metadata is sparse. The mixed corpus makes any single signal too brittle on its own.
• Promotion is empirical, not (only) author-curated: every plan carries match_count, success signals, and cost-and-latency profiles, and those numbers decide what stays in the library and what gets retired.
• Corpus is mixed-kind, not single-kind: code, prose, RDRs, and papers all sit in one substrate, so plan dimensions can route queries across content types rather than within a single kind.

What a plan carries

A Nexus plan follows the shape the paper lays out. The first time you encounter a class of query, you pick the operators, arrange the DAG, tune the dimensions on which the plan should match. That arrangement is saved. Every subsequent invocation runs the saved arrangement instead of re-deriving it.

Each plan carries three kinds of information:

• Shape is the set of dimensions that identify when the plan applies: question type, corpus scope, intent, whatever the matcher should key on.
• Procedure is the DAG of operators to run: search, traverse, extract, rank, generate, and so on.
• Metrics are the empirical record: match_count, success signals, latency, cost. How this plan has actually performed in the wild.

Twelve plans are seeded automatically at nx init. Your own plans land in the same library as you author them. The library grows by capture rather than by re-derivation: each plan is a specific shape of question you’ve worked through and chosen to keep.

How a query finds a plan

plan_match is a short, direct lookup with three signal sources layered on top of each other. It filters the library by dimensions (structural match), re-ranks the filtered set semantically against the incoming query’s embedding, and falls back to keyword search when dimension metadata is sparse. If a plan clears the threshold, it runs. If nothing does, the agent falls through to dynamic planning. Plan-first means try the library first, not library or nothing.

The three layers each catch a kind of miss the others don’t:

• Dimension filter is fast and precise, but only as good as the plan’s shape metadata.
• Semantic rerank handles the cases where dimensions underspecify, matching on concept similarity when the vocabulary has shifted.
• Keyword fallback (PostgreSQL full-text, ranked by ts_rank) catches the tail where neither dimensions nor semantics land a clean hit but the keyword surface exists. Typically when a plan’s description names the specific tools or corpus it works on.

It’s the same defense-in-depth shape Decisions as indexed data described for the cumulative-design corpus. No single mode is authoritative; they stack.

A walk through the decision-retrieval plan

The worked example from Decisions as indexed data was nx_answer("what did we decide about plan matching and why?"). Here is the shape a plan for that class of question takes. Its dimensions key on question-type decision-history, intent explanation, corpus scope rdr. Its DAG: search rdr__* collections, traverse the implements and cites links from the top results in parallel, rank the merged set, summarize the reasoning recorded in each linked RDR, cite back to chash:<sha256> spans. Six operators, arranged once and stored once, running again every time a similar question arrives.

I am describing a shape rather than pointing at a row in my library, and the reason is itself the lesson. The nearest real question in my logs — how does the plan-match-first gate decide between executing a matched plan and dispatching a planner? — ran three times and matched a saved plan on two of them. That plan is not in the library any more. Of 146 lifetime plan matches on this install, only 29 belong to plans that still exist. The library turns over, and naming a specific row in a blog post would be describing something that may already be gone.

Scoping and bridging across corpora

The decision-retrieval plan is the simple case: one question-type, one corpus (RDRs). The more interesting case is where plans route across corpora that depend on each other, and stay out of corpora that don’t.

Three projects, three corpora, all indexed here. Delos is a distributed-systems framework. Luciferase depends on it for membership, partitioning, and consensus primitives. ART depends on neither and has no relationship to either.

Ask a question about Luciferase internals and a naive retrieval hits Luciferase’s collection and stops. But Luciferase traces into Delos for those primitives, so the right answer bridges into both. A Delos-only question, on the other hand, should not pull from ART.

Plans can encode that routing as a first-class dimension: a corpus scope that names which collections a question is allowed to reach. A Luciferase deep-dive would bridge Luciferase, Delos, and the Delos papers. A Delos-internals plan would scope to Delos and stay isolated from the rest. plan_match routes an incoming query by detecting which project the question is about, and the matched plan’s scope decides which collections get searched.

I should be straight about the status of that, because the mechanism and the practice have not met yet. The dimension exists, the scope field exists, and the topology above is real. The plans are not: my library holds 19 plans and none of them encode cross-project routing. The four with real traffic are all single-corpus research shapes over one collection. This is the widest gap I know of between what the design supports and what I actually use, and writing this post is what made me notice it.

Promotion discipline

This is Nexus’s own minor addition to the pattern. The paper’s plans pool is curated by its authors; Nexus attaches empirical evidence to every plan and uses it to decide what stays.

Every plan accumulates match_count (how often it fires), success signals (whether the answer landed), and cost-and-latency profiles per run. Plans that match often and perform well stay. Plans that never match, or match poorly, get retired.

Here is what that looks like in practice, which is less tidy than the principle. My install has 214 recorded nx_answer runs, 98 of which retained their question text rather than redacting it. Splitting those 98 by whether the question had ever been asked before is what makes the mechanism legible:

	ran a saved plan	fell through to the planner
first time a question is asked	18	44
every subsequent ask	33	3

A question asked for the first time mostly has no plan specific enough to run, so it falls through by construction. The planner builds one and it is saved. Nearly every repeat after that hits it. That is the design working, and it is the strongest evidence I have that the idea holds.

It also falsifies the tidier version of my own claim. I have been saying that most analytical questions are variations on a handful of shapes. Across 62 distinct questions, 54 were asked exactly once, and only 8 ever recurred. Reuse is real where it happens, and repeat asks account for 36 of those 98 runs, but “a handful of shapes” describes about a third of my traffic rather than most of it.

That reframes the number I found most alarming. The library holds 19 plans and 14 have never executed, which reads as an indictment until you separate the two things the library counts. match_count records every time the matcher returned a plan as a candidate; use_count records the times one actually ran. The shipped defaults are wide nets: the review default has been returned as a candidate 362 times and has never once been the plan that ran. Six plans have never been returned at all.

The pattern underneath that was not what I expected. The four plans carrying real traffic are all ones I wrote for my own questions, and they account for 28 of the 29 executions on record; the twelve that ship with Nexus have executed once between them, in April. A generic plan gets squeezed from both sides. When a specific plan exists it wins on confidence. When none exists, the question is usually novel enough that the planner takes it and deposits a specific plan for next time. The middle ground a general-purpose plan occupies turns out to be narrow, and that is an argument for capture over curation: the plans that actually run are the ones a real question left behind.

So promotion discipline is real in the sense that the counters exist and the library does turn over. It is not yet real in the sense of a library that prunes itself: nothing retires the six plans that have never been returned as candidates, and I have never removed one by hand.

This is closer to the discipline RDRs use than to a pure cache. What makes a plan worth keeping isn’t that it’s stored; it’s that it solves a recurring query-shape well. The match counts are the evidence. Promotion is a judgment call informed by the numbers, the same way RDR acceptance is a judgment call informed by the research findings.

The corollary is that adding a plan isn’t a no-cost action. A plan that overlaps poorly with an existing one, matching queries the older plan already handles or handling them worse, makes the library noisier. A small library of plans that each carry their weight is more useful than an ever-growing pile that slowly dilutes the matcher’s precision.

When replanning is still the right call

Plan-first isn’t plan-only. The ad-hoc fallback comes directly from the paper: when plan_match returns nothing above threshold, the agent falls through to dynamic planning. That’s the right behavior for novel query shapes, for one-off questions, for cases where the library genuinely doesn’t have the right tool.

The point isn’t to replace the planner. It’s to route the common shapes away from the planner, so replanning is reserved for the questions that genuinely need it. Some analytical queries in a long-lived project turn out to be variations on a shape you have already worked through; by my own numbers, about a third of them. Those are where saved plans pay for themselves, and where semantic matching across surface variations does the work of recognizing the shape. The long tail still gets the full LLM planner. And when a tail query turns out to be the first instance of a new recurring shape, it’s often worth capturing the resulting plan for next time. That’s actually how the library grows: from the moments where the planner worked from scratch and the result turned out to be worth saving.

Going deeper

• AgenticScholar paper (arXiv:2603.13774): the four-layer architecture Nexus builds on.
• Plan-centric retrieval: the overview.
• Plan-authoring guide: what’s seeded, how to author, how promotion works.
• plan_save / plan_match: MCP tool reference.
• RDR-042: AgenticScholar-Inspired Enhancements and RDR-080: Retrieval Layer Consolidation: the design arc in the Nexus repo.

What’s next

Up next: Operators as building blocks. Plans are DAGs; DAGs are composed of operators. That post unpacks what an operator actually is, why they’re kept small and single-purpose, and what composition unlocks when you start stacking them.

Follow along: Post 00: Installing Nexus is the install + first-tour walkthrough. The builtin plans are seeded for you at nx init; nx plan list shows what is in the library and how often each has matched.