Careers · Agentic AI · Build-first

    Agentic AI and build-first workflow

    We hire people who want to build with agents — not only use them. From PRD to reviewed PR, specialised AI agents run implementation and verification; humans own prioritisation, quality, and decisions. Home care is the hard real-world domain where the workflow has to prove itself.

    Caire agentic AI build-first workflow and product context

    Our way of building

    Build-first means: plan before code, small vertical releases, traceability, and human responsibility before automation — the same continuous learning loop as the product itself.

    Plan before code

    We write down goals, risks, and user value before agent flows implement.

    Verification at every step

    AI can produce a lot, but code, design, content, and data flows are reviewed as product work.

    Hard domain, real stakes

    Home care is the proving ground: planners, caregivers, clients, and family — not a demo sandbox.

    Small vertical releases

    We prefer useful improvements that can be tested, measured, and improved over large opaque leaps.

    Delivery mandate

    Humans define what. Agents execute how.

    Product owners write a PRD with change, success metric, and non-goals. Darwin then runs preflight, intake, scope, a native implement session (spec + tests + code + dossier), verify, and the external reviewer loop — humans approve the evidence before merge.

    North star

    features per second per dollar

    We measure the elapsed time from PRD intake to merged PR, model spend per shipped feature, and token efficiency. The point is not replacing product judgment; it is removing avoidable handoffs from work that has already been specified.

    Workflow

    Eight stages, PRD to PR

    Each stage produces a checked artifact. The next stage refuses to start without it, making the pipeline a one-way contract from product intent to merged change. Stages and tooling evolve — treat this as the current contract shape, not permanent law.

    #StageOutputOwner
    0PreflightEnv/auth proven before any model spendOrchestrator
    1IntakeWorktree, branch, install + generateOrchestrator
    2PRDValidated frontmatter + readinessHuman (wrote) / runner
    3ScopeAnything left to build? (~$0.16)Scope gate
    4ImplementSpec + tests + code + dossier in one sessionNative executor
    5VerifyRepo gate green + acceptance coverageOutcome kernel
    6Reviewer loopPush, PR, Codex/CodeRabbit settledReviewer loop
    7Approve + mergeHuman Approve → gh merge --autoHuman + merge queue

    Migrated platform source

    The detailed operating model behind the culture page

    Each workflow concept is shown as part of one operating model, so candidates and partners can understand how strategy, implementation, verification, and review connect.

    Vision and mandate

    The job is to shorten the path from product intent to verified change without removing accountability. Read this first: humans own priority, quality, and decisions.

    SourceThe job descriptionAbout CaireThe role

    Agent roles and model routing

    The workflow splits responsibility across Architect, Editor, Reviewer, Verifier, and Orchestrator. The role chooses the model by task, cost, risk, and context.

    The five rolesCost rationaleRouting matrixPer-role responsibilities

    Darwin as orchestrator

    Darwin is a thin in-house Node loop that holds intake, queue, status, and evidence together. It should stay simple, observable, and replaceable in parts.

    End-to-end flowA single orchestratorOrchestrator runtimeRunner resilience

    Darwin component map

    The component map separates what is used by the PRD-to-PR pipeline, what is parked, and what remains in the prioritized build queue.

    Used by PRD-to-PR pipelineParkedOutstandingTelegram routing

    Model and vendor agnosticism

    The adapter shape lets the workflow select a model without locking the product process to one vendor or one interface.

    The ruleAdapter shapeWhat this rules outWhat this allows

    Spec as contract

    Spec means testable acceptance scenarios, not loose wishes. Gherkin and a done contract gate reduce spec drift between PRD, tests, and implementation.

    GherkinDone contract gateSingle-source-of-truthSpec drift

    Reviewer feedback loop

    The review loop polls external reviewers, classifies severity, and re-enters the editor with an idempotent action list.

    The pollSeverity → actionRe-entering the editorShort-circuit

    Scale or kill

    Automation should scale only when evidence, cost, and quality hold. Otherwise it must be easy to stop or roll back.

    ScaleKillAuto-promoteAuto-rollback

    Throughput and business signals

    The features per second per token metric is read together with cost, quality, and business signals to see whether the workflow actually improves delivery.

    Features per second per tokenWhere it's loggedWho reads itBusiness signals

    Verification and evidence

    Every delivery should leave a trace: trace.zip, screenshot.png, console.log, test excerpts, and a short explanation of what the artifact proves.

    wiki/raw/dossiers/<feature>/trace.zipscreenshot.pngconsole.log

    FAQ for candidates

    What does Caire mean by agentic AI and build-first?
    Build-first means product intent is written as a PRD, agents run implementation and verification, and humans approve evidence before merge. Agentic AI here means specialised roles (architect, editor, reviewer, verifier, orchestrator) — not chat assistance.
    Do I need home-care experience to apply?
    No. We hire AI builders and product engineers who want to work with agent pipelines. Home care is the domain where we prove the workflow; curiosity about real users matters more than years in the industry.
    Is the pipeline on this page the definitive truth?
    No. We iterate the implementation quickly. This page describes principles and a current snapshot — do not treat diagrams and stages as immutable documentation.

    Want to see the pipeline up close?

    Twelve guides cover every stage in depth — vision and mandate, agent roles, the dossier pattern, the reviewer-feedback loop, and the orchestrator that ties it together.

    Caire Core

    The product we build and the way we build it share a philosophy: trace what changed, learn from outcomes, and keep humans accountable for decisions that matter.

    Deep dive

    How the workflow works in practice

    Product detail

    Humans define what. Agents execute how.

    Workflow diagrams

    Diagram 1

    Loading diagram...

    Diagram 2

    Loading diagram...

    Diagram 3

    Loading diagram...
    Workflow section

    Humans define what. Agents execute how.

    CAIRE's engineering execution model is an agentic PRD-to-PR pipeline. A human writes a product brief; specialised AI agents handle spec, tests, implementation, review, and verification; the human approves a screenshot. Compute is the bottleneck — not headcount.

    From a sentence to shipped software. The human appears in two places only — writing the PRD, and approving the dossier screenshot.

    The mandate

    The agentic workflow is not "AI assistance for engineers". It's the execution model. Four commitments make the workflow distinctive.

    Humans define what and why. Agents execute how.

    Product owners write PRDs. The pipeline takes the PRD from there — spec, tests, code, review, dossier, merge — without a human in the middle of any stage.

    Tool and model agnosticism.

    Every model call goes through an adapter. Routing is config, not code. When a better or cheaper model ships, rotation is a quarterly review — not a refactor.

    If it works, scale automatically. If it doesn't, kill automatically.

    Post-merge metrics ramp a feature 1% → 100%. Regression flips the flag back. The decision is mechanical — humans don't decide "ok, ramp this".

    Execution tied to business signals.

    Cash balance, revenue, and burn are system inputs. The orchestrator refuses to spawn an expensive run if today's budget is exhausted. No human "tighten the belt" call.

    The north star: features per second per dollar

    Every architectural decision in the pipeline is graded by one question: does it make us ship more features per second, per dollar (and per token)? The metric is deliberately tiny in absolute value. What matters is the trajectory.

    Features per second

    Wall-clock from PRD intake to merged PR. Squeezing this means parallelising stages, caching specs, removing human round-trips. Every shipped feature lands a row in .compound-state/agent-service.db with its elapsed time.

    Per dollar

    Total model spend across all eight stages, per merged PR. Cheaper providers, smaller models for cheap routing, batch APIs, prompt caching — every lever points back here. The orchestrator refuses runs whose projected cost would exceed today's budget.

    Per token

    Total input + output tokens across the pipeline, per merged PR. The cleaner the spec and the tighter the dossier contract, the fewer tokens the editor burns iterating. Tokens are a leading indicator of cost.

    The trajectory matters

    An optimization mathematician agent reads the throughput log every week and proposes routing changes — different model per role, different batch size, different cache strategy. The CPO/CTO agent ratifies. The ratchet only moves one way.

    This page itself will move with the metric. New routing wins, new agent prompts, new dossier shapes — every improvement that nudges features-per-second-per-dollar lands here as a refresh.

    Eight stages, PRD to PR

    Each stage produces a checked artefact. The next stage refuses to start without it. The pipeline is one continuous flow, not a checklist — every stage hands off a typed result.

    Re-entry: verify and the reviewer loop may send work back to implement (max 3 cycles). Merge runs only after human Approve — not in the unattended walk.

    The contract is sharp: no dossier, no merge . Every stage's output is a typed, persisted artefact that the next stage reads — and that a human, an audit, or a future agent can replay.

    Who shows up where

    The agentic workflow doesn't make humans disappear — it makes them strategic. Each role has one or two narrow places to step in. Everything else is software.

    Product owner / PM

    Defines what + why Writes the PRD in wiki/plans/ with a success metric and explicit non-goals. Approves (or rejects) the dossier screenshot before merge. Sets the regression threshold that scale-or-kill watches post-merge. 💻

    • Writes the PRD in wiki/plans/ with a success metric and explicit non-goals.
    • Approves (or rejects) the dossier screenshot before merge.
    • Sets the regression threshold that scale-or-kill watches post-merge.

    Developer

    Reviews, doesn't author Reads the auto-generated spec for drift from the PRD. Argues down P2 reviewer comments with a justification when the agent is wrong. Maintains the agent prompts and the model adapter — code about how code gets written. 🛠️

    • Reads the auto-generated spec for drift from the PRD.
    • Argues down P2 reviewer comments with a justification when the agent is wrong.
    • Maintains the agent prompts and the model adapter — code about how code gets written.

    DevOps / SRE

    Owns the substrate Operates Darwin (the orchestrator runtime), the launchd job slots, the merge queue. Watches the throughput log: cost per merged PR, features per second per token. Approves model-routing rotations from the optimization mathematician's weekly proposal. 🧪

    • Operates Darwin (the orchestrator runtime), the launchd job slots, the merge queue.
    • Watches the throughput log: cost per merged PR, features per second per token.
    • Approves model-routing rotations from the optimization mathematician's weekly proposal.

    QA / Tester

    Writes the rules, not the cases Curates the Gherkin patterns the Test-writer agent compiles from. Audits dossier summary.json for skipped scenarios or empty Playwright traces. Owns the "no dossier, no merge" gate — the only thing the orchestrator cannot skip. 📈

    • Curates the Gherkin patterns the Test-writer agent compiles from.
    • Audits dossier summary.json for skipped scenarios or empty Playwright traces.
    • Owns the "no dossier, no merge" gate — the only thing the orchestrator cannot skip.

    Investor / Board

    Watches the leverage Reads cost-per-merged-PR trending down month over month as the routing matrix tightens. Tracks features-per-second-per-token as the leverage ratio that doesn't depend on hiring. Ratifies quarterly model-routing decisions; does not pick models. 🔍

    • Reads cost-per-merged-PR trending down month over month as the routing matrix tightens.
    • Tracks features-per-second-per-token as the leverage ratio that doesn't depend on hiring.
    • Ratifies quarterly model-routing decisions; does not pick models.

    Customer evaluator

    Audits the trail Inspects wiki/raw/dossiers/<feature>/ on a merged PR — full Playwright trace, screenshot, console log. Reads the PRD frontmatter to map a shipped feature back to the original brief. Verifies vendor-agnosticism by reading the routing config — no provider lock-in to inherit.

    • Inspects wiki/raw/dossiers/<feature>/ on a merged PR — full Playwright trace, screenshot, console log.
    • Reads the PRD frontmatter to map a shipped feature back to the original brief.
    • Verifies vendor-agnosticism by reading the routing config — no provider lock-in to inherit.

    What gets shipped this way

    The pipeline targets steady-state product engineering — the work that, in a traditional team, fills standups and sprints. Bigger architectural moves still get a human-led plan.

    Ship a UI feature

    A new banner, a new page, a form variation. PRD names the acceptance scenarios; pipeline writes vitest + Playwright tests; Editor implements; Verifier captures the screenshot dossier.

    Fix a resolver bug

    PRD frames the bug as a failing scenario. Test-writer compiles it; Editor fixes; resolver-reviewer + perf-reviewer catch N+1 regressions before the PR opens.

    Add a metric

    Throughput row, KPI tile, dashboard chart. Spec names the data source; tests assert the shape; the dossier shows the metric rendering with realistic seed data.

    Rotate a model

    Quarterly: the optimization mathematician proposes a routing change based on cost, pass rate, latency. CPO/CTO agent ratifies. One config edit; the adapter handles the rest.

    Refresh a wiki page

    Audit pass like the agentic-workflow audit itself: identify drift, fix the doc, run yarn wiki:lint , ship. Wiki-only PRs use the same eight stages with the verifier in light mode.

    Hypothetical example: extend an external boundary

    A hypothetical external data flow starts with a PRD. Tests cover the boundary, and the dossier records what was actually verified. The example describes the engineering method — not a shipped integration or product catalogue.

    What keeps it from going off the rails

    Autonomous loops without guardrails are how AI projects burn budgets and ship regressions. Every stage of the pipeline is fenced. The Editor agent sits at the centre, surrounded by mechanisms that can either slow it down, redirect it, or stop it entirely.

    Eight independent guardrails. No single one prevents bugs alone; together they make autonomous shipping safe enough that the human's only required action is reading a screenshot.

    Spec is the contract

    The Editor cannot ship behaviour the spec didn't name. Drift between the PRD and the spec is itself a P2 finding for the verifier — and the spec is short enough to fit in every agent's context, so drift is always provable.

    Iteration is bounded

    MAX_ITERATIONS = 8 on the editor's inner loop, plus a max of 3 re-entry cycles from review or Codex feedback. Hit the ceiling and the run surfaces failure to a human — it never grinds.

    Cost is bounded — when you turn it on

    The optional PIPELINE_BUDGET_ENFORCEMENT flag (off in pilot, on once revenue is real) refuses further model calls when the per-run cost would exceed the cap. In pilot the human is the only PRD producer, so cost is implicitly bounded.

    No dossier, no merge

    A green CI run is necessary but not sufficient. The dossier — Playwright trace, final screenshot, console log, machine-readable summary — proves the feature actually rendered. Reviewers can replay the trace; the human sees the screenshot.

    Three surfaces into the loop

    Same pipeline, three ways to enter it. Pick the surface that matches the moment — a PRD in version control, a form on the Dashboard, a message on Telegram. Every surface produces the same dossier and the same merge decision.

    File-based PRD

    Write wiki/plans/<feature>-YYYY-MM-DD.md , create an isolated worktree with ./scripts/git/worktree-add.sh , and the pipeline runs against that branch. Reviewer subagents lint the diff, the verifier captures the dossier, the merge queue lands the PR. Best for engineers shipping in version control.

    Darwin Dashboard

    Paste a PRD path, click start , watch the pipeline progress at localhost:3010 . The dossier viewer surfaces the screenshot, console log, and machine-readable summary inline. Approve / Reject is a button — no GitHub round-trip required. Best for product owners who want a UI, not a CLI.

    Telegram

    Post a PRD link to interface-agent . The same backend runs the pipeline; the dossier screenshot posts back to the originating thread. Reply approve and it merges. The lightest possible surface — a notification and an image. Best for the founder reading on a phone between meetings.

    Why this works

    The pipeline is built on three open patterns and one discipline. Nothing here is bespoke for the sake of bespoke.

    Aider's architect / editor split

    One expensive reasoning pass produces the spec; many cheap edit passes implement against it. ~1/14th the cost of running every call on the reasoning model — the cost driver is the editor, not the architect.

    Spec-driven development (Gherkin)

    Plain language is too imprecise to coordinate multiple agents. Acceptance scenarios in Gherkin are short enough to fit every agent's context, precise enough to compile to failing tests, and greppable.

    Playwright dossier (no dossier, no merge)

    A green CI run is necessary but not sufficient. The dossier — trace, screenshot, console log, machine-readable summary — proves the feature actually rendered, in a real browser, in the state the spec named.

    Reviewer-feedback loop

    External review bots (Codex, CodeRabbit) post comments after every push. The pipeline polls them, treats P1/P2 as failed tests, and re-enters the editor automatically. The discipline is non-optional.

    Comparison table

    #StageOutputDriven by
    0Preflight Prove git/gh auth and a real 1-token model call before any spend.Environment OK or BLOCKED-ENV .Orchestrator
    1Intake Create isolated worktree, branch, install + generate.Worktree ready.Orchestrator
    2PRD Human wrote the plan; runner validates frontmatter + readiness.wiki/plans/<feature>-YYYY-MM-DD.mdHuman (wrote) / runner
    3Scope Cheap question: any unbuilt code work left? (~$0.16).Continue building, or retire to wiki/plans/shipped/ .Scope gate
    4Implement One native Claude session: Acceptance Contract, tests-first, code, self-review, dossier.Code + wiki/specs/ + wiki/raw/dossiers/ in the worktree.Native executor
    5Verify Outcome kernel: artifacts exist, then the repo's own gate.yarn verify:changed green + acceptance coverage.Outcome kernel
    6Reviewer loop Rebase, push, PR; poll Codex/CodeRabbit; P1/P2 re-enter implement.Open PR with settled findings.Reviewer loop
    7Approve + merge Human approves dossier; only then does merge run.gh pr merge --auto --squash via /approve .Human + GitHub Merge Queue