The problem
Several roles. Two languages. Eight variants per application.
I target multiple role families at once — four lanes, each with its own positioning and skill emphasis. Each needs a different CV framing. Each ships in German and English. Some need a cover letter, others need additional context.
Manually: four to six hours per role, copy-paste errors, stale facts, and a voice that drifts across documents.
8
PDF variants per application
~4 min
per pass, fully local
0
API tokens consumed
25
rules in the constitution
The setup
Local Claude Code. MCP. Thirteen agents.
The engine runs on a local Claude Code instance — no API tokens, no external calls, no data leaving the machine. Each tailoring pass takes four minutes instead of seconds. Privacy and cost are worth the wait.
MCP extends the tool surface so the model can read files, call scripts, and trigger renders within a single session. Thirteen specialised agents each own a bounded concern — no agent sees the full picture, each loads only the rules and sources it needs.
Rule 1 — loaded every session
Facts only. No invention. Ever.
Every claim must trace to a source. If a claim has no source, it does not appear. No exceptions.
Agentic architecture
Specialised agents, shared rules.
Each agent is scoped to one concern. It loads its own playbook, reads only the source files it needs, and hands off to the next agent via structured output. The rules constitution loads at every session start — no agent can override it. Hooks enforce by side-effect between sessions.
The engine
JD in, eight PDFs out.
A job description enters the system. The engine triages, tailors, validates, and renders. The model only fills values the schema allows, with content the source corpus already contains.
The interface — Triage
Every JD gets scored before anything else runs.
The triage step applies an HR rubric — location, salary floor, lane fit, applicant pool, disqualifiers — and emits a FIT, STRETCH, or SKIP verdict. Only FIT and STRETCH proceed to the tailoring pass. SKIPs auto-log with the verdict reasons.
Triages
7 decisions logged
| Employer | Role | Date | Verdict |
|---|---|---|---|
| Centro CX | Product Owner Digital CX (m/w/d) | 2026-05-23 | FIT |
| Alpine Fintech | Business Analyst Claims | 2026-05-23 | FIT |
| Solaris AG | Senior Product Manager (100%) | 2026-05-22 | SKIP |
| Neura Consulting | AI Domain Lead | 2026-05-22 | STRETCH |
| Pragma Engineering | Business Solution Architect – AI & UX | 2026-05-21 | STRETCH |
summit re
Senior Product Owner
The interface — Variant
Language toggle. Status tracking. PDF on the fly.
Each variant shows the tailored content with a DE/EN toggle. Status moves from draft through applied. The PDF renders on download — page-count cap and ATS extraction enforced at render time. If either check fails, the build fails.
Enforcement
What happens when a claim can't be traced.
Every fact in the CV has to link back to a source file. Sometimes the model produces a line that doesn't. Two options: refuse to generate the PDF, or generate it but flag the ungrounded line.
The engine flags. The flagged line becomes a ticket the operator has to resolve before the next run. Over time this makes the system sharper — every near-miss is logged, not silently swallowed.
Block
Engine refuses. No output, no record of what went wrong. Strict, but silent.
Warn ✓
Engine ships, but the ungrounded claim becomes a finding. Tracked, visible, resolved before the next pass.
What this proves
Not a side project. A way of working.
The engine solved my problem. The method behind it is what I'd bring to a client engagement.
Business problem first, technology second.
The starting point was "applications take too long and drift" — not "let's use Claude." The tool choice followed the constraint analysis. That's how I'd scope a client's AI use case: identify where the pain is, then design the solution.
Rules first, system second.
The twenty-five-rule constitution existed before the first line of code. Constraints shaped the architecture — not the other way around. For a client, that means guardrails are designed in, not patched on after an incident.
Teachable, not bespoke.
The rules-constitution + hooks + agent pattern is a methodology, not a one-off. A client team can learn it, adapt it, and run it without me in the room. That's enablement — not dependency.
Let's talk.
If the discipline reads as a fit — I'd be glad to walk through the system live.
Get in touch →