All experience

PERSONAL PRODUCT

cvitae

ROLEIndependent Product Builder & Agent-runtime Architect

cvitae is a local-first workspace for bilingual CV authoring, job-offer research, evidence-backed tailoring, review, and draft preparation. I built the frontend product and the agent runtime that coordinates its AI-assisted work.

Explore cvitae on GitHub

01

The product

The product separates an authoritative master CV, structured job research, and per-offer submission variants. A model may select, order, and reword existing evidence, but it is not allowed to silently create career facts.

Its default export is an ATS-oriented, one-column A4 PDF with embedded fonts and real text. The finished bytes are parsed again before download, and a corrupt or image-only result is blocked.

02

What I built

  • Built the Next.js product surfaces for CV editing, EN/PL document handling, offer research, evidence review, application queues, and PDF generation.
  • Designed fact-level evidence controls that trace tailored claims back to the master CV and reject unsupported skills, numbers, seniority inflation, or cross-offer evidence.
  • Kept sensitive document ownership local to the browser and made human review the final authority before a variant or application draft is used.
  • Designed and implemented the standalone agent runtime, its capability system, persistence model, recovery behavior, provider boundaries, and streaming integration with the frontend.

03

Agent-runtime architecture

The runtime is deliberately subject-agnostic at its center. CV and job-search knowledge lives in capabilities; the engine only understands validated runs, staged plans, bounded steps, effects, and checkpoints.

  1. 1. Adapters accept intent

    The web host, IPC/stdio host, or CLI accepts a capability request. Files are opened at the adapter boundary and passed as bytes, so runtime inputs cannot name arbitrary filesystem paths.

  2. 2. The composition root builds one runtime

    The runtime layer wires capabilities, provider effects, tool registry, retrieval, document storage, approvals, and SQLite-backed run storage. No other layer assembles global dependencies.

  3. 3. Router and planner constrain the job

    The router validates input against the selected capability. The capability then creates a declared plan of stages and steps, including any bounded tool loop it genuinely needs.

  4. 4. The orchestrator controls execution

    Stages run with explicit concurrency, deadlines, cancellation, and degradation rules. Each step receives a frozen snapshot of completed work, preventing sibling timing from changing its context.

  5. 5. The executor crosses controlled boundaries

    A step can transform local data, extract structured output, generate bounded prose, or enter a capped tool loop. External calls live behind effects; model tools expose only the narrow operations granted by the capability.

  6. 6. Checkpoints make the run recoverable

    Run state is canonical in SQLite. State transitions and their ordered events are committed together, while external attempts are recorded before execution so recovery never guesses whether it is safe to repeat a side effect.

Structural safeguards

  • The core engine imports no CV or job-search domain knowledge.
  • Context is explicitly budgeted and frozen per step.
  • The executor does not retry blindly; the effect that understands an error owns retry policy.
  • Mail is intentionally unavailable to capabilities and model-facing tools; delivery stops at a human-reviewed draft.
  • A missing external-call outcome suspends for a person instead of risking duplicate work.