Vital Few: compress a field, then stop

Most agent “research” does the same thing. It tours a field, writes a long report, and never tells you what you would work tomorrow. Stars get ranked. Vendors get taxonomied. Search never stops.

Give an agent a terse pointer, a name, a URL, “things like X”, and it produces a tour. Twenty siblings. A vendor taxonomy. A weighted score that hides the tradeoff. Then another search, because the last one did not feel done.

The useful output was never the tour. It was the cut: which objects actually distinguish the field, which hypotheses disagree, and which one item you would start tomorrow.

Juran had a name for that cut. He hung Pareto’s name on it, then spent a 1974 mea culpa walking it back: the vital few versus the useful many. The many are not junk. You name them once and leave them. You work the few.

Agents do the inverse. They expand the tail.

Vital Few is built for the opposite job: name an object, compress the field, compete, commit, stop. Two files, no runtime. You copy SKILL.md and LOOP.md into the agent’s skills directory and fire it whenever you want a field compressed, not toured. The spec is the loop. The runbook is the skill.

This post is the design: why a cut is trustworthy, the stop that makes it checkable, and one pass on a real field. The procedure itself lives in the repo. Pasting it here would be a worse README.

First principles of a trustworthy cut

A cut is trustworthy only if five properties hold. Each one forces a move in the loop. The names below are the sources of those moves, not a reading list to perform.

1. It is taken on the whole field. A cut from a partial view is premature, a conclusion dressed as analysis. So the first move ranks nothing: one extra sibling pass, one snowball, searching the job not the brand. Zwicky’s morphological box. Wohlin’s snowballing guidelines.

2. It keeps the few and names the many. Keep the non-dominated set on the load-bearing columns. Name the tail once, leave it. Juran 1974. The front is what you commit to.

3. It tolerates no contradiction. A cell that contradicts the instance, the first cut, or another cell cannot coexist with the field. Cross-consistency kills it: drop any idea that cannot live next to the instance you already named. Empty is allowed. Contradiction is not.

4. It ranks on disagreement, not on a score. A single weighted score at the collate step is a lie: the columns were the sweep, and the score hid the tradeoff. Rank on competing hypotheses that actually disagree. Each vote cites a published measurement. Star counts are not a witness. Chamberlin 1890. Platt 1964. Pugh +/−/S against a datum.

5. It commits, then stops. k is taken from the front. Simon 1955: satisficing. The stop condition is a check, not a feeling.

Those five properties are the spec. The last one is the load-bearing part: agents treat ranking as a warm-up for more ranking, and Vital Few makes that a fail.

What falls out of the spec

The pipeline is the principles in sequence:

name → instance → siblings → rank
    → ontology → frame → explode → cca
    → hypothesis-rank → top-k → extract loop

cca is cross-consistency: drop combinations the instance forbids, then merge. Empty cells stay empty.

In. A name, a URL, or “things like X”.

Out. A frame you can reuse, a top-k taken from the front, and a written answer to “would you start item 1 tomorrow?” SKILL.md lists what the agent must emit.

Fail-closed. No primary source for the instance? Stop after step 2 and say so. No sourced frame? Skip the explode and emit the sibling front only. Do not invent axes. The rules live in the loop, not in prose, because a model will not enforce a rule it only “understands”.

The aspiration check is property 5 made checkable:

1. A framing sentence exists and names the ontology.
2. Top-k is from the front. k is not N.
3. Item-1 witness: would you start work on item 1 tomorrow with only that sentence and this list? Written yes plus one line, or no.
4. No further search is queued.

If 3 is no, you get one recut of k or of item 1. Then you stop anyway. Recursion is bounded candidate generation, not a generational optimizer. Running the candidates is the work after this loop.

Is not. A Deep Research writer. A scanner. A product with a runtime. An implementation of the top-k. If you already know the API, or you are fixing one file, do not fire it.

One pass: “anthropic autonomous vulnerability patcher”

The worked example in the repo is the pointer I actually used. Here is the cut, not the tour.

The pointer sounds like a product. The object is not. After naming, it is anthropics/defending-code-reference-harness, and the class it sits in: a closed-loop cyber reasoning system. Job: autonomous recon → find → verify → patch, with a witness that is not a paragraph.

The instance is an unmaintained Apache-2.0 reference. C/C++ memory bugs, Docker plus ASAN, gVisor. The find agent emits a crashing input. A grader in a fresh container sees only PoC bytes. Patch ladder: build, PoC gone, tests, re-attack. A human still merges.

Not Claude Security (hosted). Not a general SAST wrapper. Mixing product, instance, and class in one noun is the step-1 fail. The loop forces the split.

Siblings got ranked on runnable OSS that closes find → prove → patch, not stars: FuzzingBrain / OSS-CRS, the Anthropic reference, google/mantis, Visa VVAH, Capital One VulnHunter, Hadrian OpenHack. Closed systems stay in the table and get marked closed (Claude Security, Microsoft MDASH, Big Sleep). They are not ranked as clones you can run.

First cut. Does a finding require an executable witness, and does a patch have to survive an independent check?

That question sorts the front. Three genera survive. The Anthropic reference and FuzzingBrain are closed-loop CRS. Mantis, VVAH, and VulnHunter are skill pipelines on a coding agent. OpenHack is the whitebox hunter: still runnable, different genus, so it stays on the front without pretending it is a CRS. Everything else is the tail, named once.

Entities. Target, threat model, witness, trust split, fix gate. If you can drop an entity and still tell two instances apart, it was never an entity.

The binding is a sentence, not a pipeline diagram: the threat model scopes the finder, which emits a witness; an independent grader may see only that witness; a unique bug goes to a patch agent; a fix gate; then a human.

The frame I imported is Stanford Symbolic Systems: philosophical analysis, formal methods, computational methods, empirical cognitive science. Sourced, not invented that afternoon. Under that frame a CRS is a hybrid: neural finder, symbolic grader, public language, second agent forbidden from the first agent’s inner story.

Five-by-four cells, then cross-consistency. Fifteen ideas remain. The ones that survive are about the interface between finder and grader, not about a better model.

Hypotheses that disagree (the useful ones, including the two that get demoted):

H5 is the frame. Rank projects by H1 ∧ H2 ∧ H3. H6 is vocabulary. H4 is how you would measure, not what you would build. That is the ranker doing work: hypotheses that agree are a manifesto, and the loop refuses them. Cells that cannot coexist with the instance get dropped before anything is numbered.

Top-k, from the front:

1. Witness as a checkable proof object
2. Threat model as compiled common ground
3. Public-language / bytes-only as the computational-level claim
4. Finding-as-communication (the merge bottleneck)
5. Patch as making the vulnerability uninhabited

Framing sentence, naming the ontology: autonomous vulnerability research is a symbolic system, a neural finder and a symbolic grader that may communicate only in public proof-like objects, under a compiled account of what the target considers a vuln, until a patch makes that object uninhabited. Then the remaining problem is saying that to a human who can merge.

Item-1 witness: yes. Tomorrow I would start by making the finding a proof object the grader can reject without reading the finder’s inner story.

Then extract the loop: strip the vuln nouns. What remains is Vital Few. That is step 11. Terminal. Do not recurse.

The full card is examples/worked-example.md.

What the loop refuses

The skill exists because agents do the same few things after a ranking.

They start building item 1 inside the ranking loop. That is the next loop. This one decides.

They search again after top-k, because stopping felt early. The four-check was the stop.

They write hypotheses that are all true together. That is a manifesto. The ranker only works if the hypotheses promote different work.

They rank by stars, or fold the columns into one score so the tradeoff disappears.

They skip the item-1 witness and call it done. “Looks done” is not a check.

The rest is the tail, named once: vendor taxonomies, expanding the useful many, a new eval used as a vote, breeding candidates after the rank, a frame with no source, keeping cells the instance forbids.

Why this sits next to Memori and Luffy

Memori stores what the agent learned. Luffy exports the loop so you can audit a review. Vital Few is the cut before you spend a week building the wrong sibling.

All three are the same thesis I keep writing down: probabilistic systems need a deterministic surround. Memory, constraints, traces, and now a stop condition that is a check, not a feeling.

The surround here is procedural, not a database. LOOP.md is the spec. SKILL.md is the runbook with YAML frontmatter name: vital-few. MIT. Clone it, copy two files, point the agent at a pointer.

git clone https://github.com/archit15singh/vital-few.git

Do not fire it to implement the top-k. That is the next loop. This one is finished when you would start item 1 tomorrow, and you have queued no further search.