Agentic Purchase Pipeline

A staged process for buying things properly, with an AI agent doing the research.

I run this for any purchase over roughly $50. It looks tedious written down. It is much less tedious than owning the wrong object, and the hit rate has been good enough that I now reach for it by default rather than as a special occasion.

The core claim is narrow and, I think, defensible:

Most bad purchases are not caused by picking the wrong product from a correct shortlist. They are caused by a shortlist built against a specification that was never written down, and that would have changed if it had been.

This pipeline exists to make the specification an artifact, and then to let research attack it.

The pipeline

flowchart TB
    A([Something is needed]) --> S0
    S0["**0 · CAPTURE**<br/>Voice note → written spec<br/>tagged stated / measured / assumed"] --> S1
    S1["**1 · LOAD-BEARING REQUIREMENT**<br/>Find the one criterion<br/>no vendor publishes"] --> S2
    S2["**2 · LANDSCAPE**<br/>Classify the market by<br/>*how each class fails*"] --> S3
    S3["**3 · CANDIDATES**<br/>Resolve every marketing<br/>adjective to a number"] --> S4
    S4["**4 · REVISE THE SPEC**<br/>Research changes what<br/>you want. Let it."]
    S4 -->|new constraint| S2
    S4 --> S5
    S5["**5 · CHANNEL**<br/>Landed cost, not list price.<br/>Verify stock in the real catalogue"] --> S6
    S6["**6 · EXECUTE**<br/>Human today.<br/>Agent tomorrow."] --> S7
    S7["**7 · VERIFY & CAPTURE**<br/>Write back what the thing<br/>actually does"] --> Z([Done])

The loop from 4 back to 2 is the part that matters and the part most "AI shopping assistant" framings leave out. In the worked example, the spec changed four times, and every change was caused by something the research turned up. Two of those changes reversed an earlier decision outright.

The stages

#	Stage	What it produces
0	Capture the spec	A spec document with every claim tagged by where it came from
1	Find the load-bearing requirement	The one criterion that will silently make the purchase fail
2	Map the landscape	The market split into classes, each with its characteristic failure
3	Evaluate candidates	A table where every cell is a number or an explicit "unknown"
4	Revise the spec	An updated spec, and an honest record of what changed and why
5	Choose the channel	Landed cost per vendor, and confirmed availability
6	Execute	An order — and the current boundary of what an agent may do
7	Verify and capture	What the object actually does, written down for next time

The principles that do the work

The spec is a loop, not a gate. Writing it first is necessary and not sufficient. You do not know what you want until you have seen what exists, and a process that freezes the spec before research is just a slower way to buy the wrong thing.

Find the requirement no vendor publishes. Every category has one. In the worked example it was "does the pedal hold the key down while depressed, or does it fire a keystroke and let go?" — which decides whether push-to-talk works at all, is on no spec sheet anywhere, and fails silently when wrong. Identify it in stage 1 and every later stage gets easier.

Tag evidence tiers, and resolve adjectives to numbers. "Extra-wide", "ergonomic", "heavy-duty" are not data. Mark each claim verified (from a manufacturer spec page), reported (retailer or marketing copy), inferred, or unknown. An honest "unknown" in the deciding column is worth more than a confident adjective.

Arithmetic beats adjectives. One line of division eliminated an entire product category in the worked example: three pedals across a 210 mm body averages 70 mm each, against a 100 mm foot. No amount of "extra-wide" survives that.

Be willing to reverse. The recommendation in the worked example changed four times. Each reversal was caused by evidence, and each was stated as a reversal rather than quietly edited. An agent that never contradicts its earlier answer is not being consistent, it is being useless.

Landed cost, not list price. This is the one that actually cost money to learn. See stage 5.

Ask whether the software layer collapses the hardware requirement. Half the "is it programmable enough?" question in the worked example evaporated once the mapping layer was understood properly. Sometimes the expensive feature is one you can supply for free.

Drive the real catalogue, not a search engine. Web search will tell you a product exists. Only the vendor's actual storefront tells you whether the specific variant you need is buyable today. Agent-driving a logged-in session answered that in the worked example and changed the channel decision.

Worked example

example/ walks the whole thing end to end for a real purchase — a USB foot pedal for a dictation workflow — including the wrong turns, the four spec revisions and the two reversals. Details are sanitised and the delivery address is fictional.

It is deliberately not a tidy success story. The interesting parts are where the process caught something: an arithmetic check that killed a category, a vendor document that revealed a configuration trap, and a shipping quote that overturned the recommendation on the last day.

Relationship to my other repos

• Research-Decide-Implement — the same shape applied to software work rather than purchasing, with rdi-template as its scaffold.
• Document-As-You-Go — stage 7 is an application of it.
• Spec-Led-Certification — the same spec-first shape applied to choosing a professional certification.
• Claude-Shopping-Eval-Demo (not currently published) — a complementary pattern: screenshot store catalogues, hand them to a multimodal agent, get a ranked PDF. Better when the constraint is price across many local stores. This repo is better when the constraint is fit, and when you expect the spec itself to move.

Indexed alongside the rest at Agent-Reference-Workflows.

Where this is going

Stage 6 is the only one still fully manual, and it is the one most obviously about to change. Browser automation can already drive a checkout flow end to end; what is missing is not capability but a trustworthy authorisation boundary — a way to say "you may spend up to this much, at this vendor, on this item" and have that be enforced rather than merely requested.

MCP-based wallet and payment implementations are the obvious shape of the answer. When they land, stages 0–5 do not change at all. That is rather the point of having written them down as stages: the research pipeline is already agent-driven and already produces a decision with a defined product, vendor and landed cost. Execution is the last mile, and it is a small one.

Licence

MIT. Take the stages, ignore the example.