The Beginning

The first cover-letter generator, back in May, was one undifferentiated move: job description plus context, into Claude, out comes a letter. By the time capability normalization, evidence scoring, personas, and retry-with-escalation all existed, that one move had become five, each with a name. Nobody planned that shape in advance across all three AI domains in this platform — cover letters, the photography assistant, and Ask Vikram all arrived at it independently, months apart, for the same underlying reason.

The First Solution

A single prompt call feels like the obvious unit of work because it maps directly onto how you'd describe the feature out loud: "take a job description, write a cover letter." One instruction, one call, one output. There's nothing wrong with that shape for a feature that only needs to produce plausible-sounding text. The trouble starts the moment the feature also needs to be right.

What Broke

A single call has no seam. Extraction, retrieval, and generation were smashed into one undifferentiated request, which meant there was no place to put a deterministic check on any of them — no place for scoreCandidateEvidence() to run before generation, no capped evidence pack to hand over, no gate to catch a citation to a photo that was never in evidence. By the time the model's output existed, every decision it made about relevance, inclusion, and truth had already happened invisibly, inside the one opaque call, with nothing to inspect and nothing to veto.

The Decision

The fix wasn't a smarter prompt. It was splitting the single call into named stages, each with one job and — critically — a place after it to put a gate:

Extraction — pull keywords and capability candidates out of a job description, or concepts out of a public question. Fully deterministic, no Claude involved yet.

Retrieval — score and rank what's actually relevant: scoreCandidateEvidence() for cover letters, searchPhotos() for the assistant, the six-stage hybrid retrieval for Ask Vikram. Authoritative, never overridden by the model that comes after it.

Planning — decide how to frame what was retrieved, without adding anything to it: persona selection and the rhetorical plan for cover letters, the Evidence Relationship Builder for photography. This stage can rearrange emphasis. It cannot invent content.

Generation — the one point where Claude actually writes, on a bounded, pre-selected input it cannot expand on its own.

Validation — the stage that's most different across all three domains, because "what needs checking" is genuinely domain-specific. Cover-letter generation re-prompts on banned-phrasing or opening-line violations, escalating with the exact offending text each retry, until it produces something clean or gives up. The photography assistant runs a Citation Gate that checks every cited photo ID against the pack it was actually given, then a Claim Validator that checks every structured relationship claim against the same evidence graph — and either one, on failure, discards the entire response and substitutes a fixed rejection message, no partial repair. Ask Vikram strips the internal retrieval graph before anything reaches the public caller. Three different failure responses — repair-and-retry versus reject-wholesale versus strip-and-forward — because a validation stage isn't one behavior, it's whatever behavior a given domain's specific risk actually calls for.

That last point mattered enough that I made it a deliberate choice rather than a default: retry-with-escalation costs latency and tokens every time a violation fires, but it gets the user a usable letter instead of a flat refusal. Discard-wholesale is cheaper to reason about and easier to prove correct — there's no partial-repair logic to get subtly wrong — but it hands the user nothing when a citation slips outside the pack, just a fixed rejection. I didn't try to make all three domains agree on which trade-off to take. Cover-letter prose is worth retrying for; a hallucinated citation isn't worth trying to salvage, it's worth refusing outright.

The New Architecture

Not this: Prompt → LLM → Output (no seam — every decision about relevance, inclusion, and truth happens invisibly, inside one opaque call) This: Extraction → Retrieval → Planning → Generation → Validation (deterministic) (authoritative) (framing only) (bounded input) (domain-specific gate) Cover letter: keywords/capabilities → scoreCandidateEvidence → persona/rhetoric → Claude → retry-on-violation Photo assistant: (via searchPhotos) → buildEvidencePack → relationship graph → Claude → citation gate + claim validator Ask Vikram: concept extraction → hybrid retrieval → (n/a) → Claude → strip internal graph

Three domains, five-stage shape, three different validation behaviors at the end — the stage exists everywhere, its response to failure doesn't have to.

Lessons Learned

I didn't design this shape and then apply it three times. Each domain reinvented it separately, under its own pressure, and only looking back across all three did the convergence become obvious. That's evidence the shape isn't a style choice — it's close to the only shape that survives contact with "don't let the model decide what's true," applied honestly, regardless of domain.

The other lesson cuts against tidiness: forcing all three domains' Validation stage to share one mechanism would have been the same mistake as forcing Engineering Behavior's retrieval into the shared src/lib/ai/ layer — a mistake I'd already made and reversed once before. A retry loop and a wholesale-reject gate solve the same category of problem, but they aren't the same code wearing different names; unifying them would have meant weakening one of them to fit the other's shape.

Looking Forward

A pipeline with named stages gives you something a single prompt call structurally cannot: intermediate values you can actually point to — a score, a capped pack, a citation set, a claim graph. That's not just an implementation detail. It's the difference between a system that produces an answer and a system that can show you why it produced that answer, which is the question the rest of this platform's guarantees actually rest on.

Takeaway

Pipelines don't beat prompts by being cleverer. They beat prompts by having seams — five of them, usually — and a seam is the only place you can ever put a gate. A single prompt call is a black box that happens to look confident. A pipeline is the same intelligence with checkpoints, and checkpoints are the entire reason any of this is trustworthy enough to ship.