Resume Builder
Paste a job description, click Tailor, get a polished PDF in under a minute. Behind the curtain: a single-stage Opus call constrained by a strict JSON schema, a Redis-backed job queue, Memory Archive context lookup for past-job detail, and a non-negotiable rule that the JSON pipeline is never overwritten with markdown.
Generation pipeline
One Opus call, four boundaries. Each boundary fails loud.
Why single-stage Opus
Earlier iterations chained: Sonnet draft → Opus polish → Sonnet shrink. Cheaper per call, more retries, more drift, more places for the JSON contract to slip into markdown. The single-stage Opus version trades dollars for determinism — one prompt, one schema, one pass, one PDF.
The cost ledger says it's worth it: median spend per resume is well below the value of getting a clean output every time.
Components
summary, experience[], skills[], education[]. No prose escapes. If the response doesn't validate, retry — never silently coerce.**bold** meant a dozen broken PDFs in production. Now it's an explicit guardrail.Hard-won rules
More of the system
Resume Builder is one of 11 services. Memory Archive holds the past-job memories it depends on; the agentic-framework provides the Opus client; the deployment pipeline ships changes safely.