← Back to blog
How We Built Charlie

AI engineering work becomes dependable when one system owns it from request to review.

Charlie turns a request into accountable work, keeps follow-ups attached to work already in progress, runs code in the right repository, verifies what changed, and returns the result where the team asked.

Series
15 chapters
Published
2
Outcome
From request to handoff
One request / five boundaries / one owner

See every handoff without losing the work

Signal
Sentry issue
Owner
tsk_482
Proof
Commit + checks
  1. 01 Provider received

    Sentry signal received

    signal.normalize

    Normalize and enrich the failed deploy event before routing.

  2. 02 Coordination owned

    Durable task owns the request

    tsk_482 · queued

    Create one task with lifecycle, lineage, and an open mailbox.

  3. 03 Runtime running

    Bounded run claims work

    run_07 · claimed

    Construct sourceable context and execute with explicit tools.

  4. 04 Compute effect

    Devbox produces an effect

    patch + findings

    Inspect the regression, change the repository, and return evidence.

  5. 05 Team surface interrupt

    Follow-up interrupts safely

    mailbox.append · seq=18

    A clarification enters the active task instead of creating parallel work.

  6. 06 Runtime verified

    The same task rejoins and verifies

    tests=passed · read-back

    Resume at a checkpoint, incorporate the follow-up, and record proof.

  7. 07 Team surface complete

    Origin thread receives the handoff

    commit + checks

    Return the terminal result and durable artifact links where work began.

System invariants

The rules that make autonomy dependable

The implementation can change. These constraints cannot. Each one preserves a property the team needs when work spans models, tools, providers, and time.

Durable owner spine tsk_482

One identity carries lineage, mailbox state, run history, proof, and terminal status.

01One durable owner
A request and every follow-up resolve to one task identity.
lineage + mailbox + terminal state
02Bounded execution
Every run has a claim, scoped context, explicit tools, and an ending.
run record + tool results
03Follow-ups reach current work
New input reaches the current owner at a safe checkpoint.
mailbox sequence + checkpoint
04Proof before completion
Important claims point to artifacts another person can inspect.
commit + read-back + checks
Operational guarantees

What each stage must guarantee

A stage is complete only when it leaves a durable record for the next boundary—not when the model says it is done.

  1. 01 signal

    Receive the signal

    Provider events become one normalized, enriched envelope before routing.

    Proof record signal_qZN · source + actor + request
  2. 02 ownership

    Assign durable ownership

    One routing decision creates work, rejoins an owner, wakes a role, or stops.

    Proof record tsk_482 · lineage · mailbox
  3. 03 run

    Execute a bounded run

    The scheduler claims explicit work with scoped context, tools, and compute.

    Proof record run_07 · claim · tool results
  4. 05 verify

    Build proof

    Claims are backed by artifact IDs, provider read-back, tests, and CI state.

    Proof record commit · checks · read-back
  5. 06 handoff

    Return to the team

    The result lands where the request began with durable links and clear status.

    Proof record origin thread · terminal result
Reading map

15 chapters, from signal to handoff

Published chapters are linked. Every forthcoming chapter remains an explicit status record in dependency order from signal intake through team handoff.

A

Durable ownership

Establish the coordination layer and the task as the unit of work.

01—02
  1. 01 Published

    Why agents need a coordination layer

    The problem with one-shot prompts and chat sessions.

  2. 02 Published

    The task, not the chat

    Durable work identity, lifecycle, lineage, mailbox, and terminal result.

B

Signal and routing

Turn provider events into one explicit ownership decision.

03—04
  1. 03 Next

    Turning webhooks into work

    Slack, GitHub, Linear, and Sentry events become enriched signals.

  2. 04 Forthcoming

    Routing is ownership

    Assign each Signal to accountable work, scoped roles, or an explainable no-op.

C

Bounded execution

Schedule, execute, record, and delegate work without losing control.

05—08
  1. 05 Forthcoming

    Scheduling durable work

    Keep accepted work claimable and recoverable across delivery repeats and restarts.

  2. 06 Forthcoming

    The executor loop

    Resume execution without losing tool order or repeating uncertain effects.

  3. 07 Forthcoming

    Task graph vs transcript ledger

    Preserve both ownership lineage and the ordered history visible to the model.

  4. 08 Forthcoming

    Delegation without swarms

    Divide work while one parent remains accountable for scope and synthesis.

D

Rejoin and compute

Incorporate follow-ups while preserving runtime and repository state.

09—12
  1. 09 Forthcoming

    Follow-ups while work is running

    Attach changed requirements to active work and incorporate them at safe boundaries.

  2. 10 Forthcoming

    Devboxes as the agent’s body

    Turn plans into durable, reviewable artifacts in a scoped execution environment.

  3. 11 Forthcoming

    Context without magic memory

    Use context with visible provenance, scope, and freshness instead of hidden memory.

  4. 12 Forthcoming

    Daemons: persistent roles, bounded runs

    Run recurring repository roles as finite, accountable activations.

E

Proof and handoff

Make effects inspectable, legible, and visible to the team.

13—15
  1. 13 Forthcoming

    Proof, not vibes

    Match completion claims to inspectable artifacts and independent evidence.

  2. 14 Forthcoming

    Making agent work legible

    Give reviewers a legible work record and one clear next action.

  3. 15 Forthcoming

    What we learned building Charlie

    Synthesize the judgments that make autonomous engineering work dependable.