Braxton • Home lab systems & AI • September 17, 2026
One human.
Many agents.
Keep your project coherent.
How do you keep it coherent—and still enjoy operating it?
The project changes. Do the rules?
A script
Becomes a service.
A weekend automation
Becomes a household dependency.
A learning exercise
Becomes a long-running project.
Which assumptions from day one
are still running your project?
Where will another agent help?
Separate the questions.
Independent investigations
Distinct artifacts
Different evidence paths
Overlap the waits.
A bounded job runs.
Another useful task
can move forward.
Keep dependencies clear.
Shared state and ordered
changes need coordination
before more workers.
Can you explain the boundary—and still review what comes back?
03A correction has to change the next action.
Where does the fix live?
In the record—and in the next action?
A record preserves the lesson. A working mechanism carries it forward.
04Plan for the next handoff
Finish and hand over.
- Bound the outcome.
- Make checks and recovery repeatable.
Can another actor finish this?
Continue through change.
- Preserve decisions and dependencies.
- Budget review and maintenance.
Can another session continue?
Survive replacement.
- Own services and migrations.
- Test restore and exit paths.
Can the project outlive its setup?
Plan near-term work in detail; name distant assumptions and revisit triggers.
05Who is doing the coordinating?
Human-directed lanes
Assign work.
Read the evidence.
Integrate the result.
A persistent crew
Shared tasks.
Durable memory.
Continuity across sessions.
A supervised loop
Observe runtime state.
Act within a grant.
Check what changed.
Coordination work moves. It never disappears.
06Give the worker a contract
- Outcome
- A reviewable upgrade candidate; consumers still work.
- Inputs
- Pinned revision, dependency list, acceptance checks.
- Territory
- Own worktree and test environment.
- Authority
- Prepare and test. Production execution is separate.
- Stop / budget
- Stop on unknown data migration or missing recovery.
- Done when
- Candidate + evidence + limitations + next action.
An assignment is a small operating agreement.
07Own every mutable boundary
Files, databases, ports, credentials, and targets each need an owner.
08Human attention belongs in the architecture.
Target • action • limits
Revocation • evidence
You
Intent, tradeoffs,
consequential choices
Keep challenge useful.
The agent can be wrong.
The human can be wrong.
Either can get stuck.
What reaches you
that should not?
What should reach you
but does not?
Keep the history. Design the working view.
What do I need
to do this job?
Identity • authority
freshness • provenance
What is true now?
What can I change?
What happens next?
Can you find what to do now
without rereading everything that happened?
Concept → example: advance once to see the evidence.
10Make the handoff executable
Can the next actor continue?
Leave a usable state packet
- Current task, owner, and revision
- Evidence and last observed target state
- Pending decisions and granted authority
- Next action and recovery instructions
- Tools and access needed to perform them
Test a cold pickup with only the durable record.
11Supervise the work that is running
Observe → decide → act → observe
A reassignment is incomplete until the worker follows it.
A fresh state pass can give the human a useful re-entry point.
The supervisor’s own actions need feedback.
12Could this check ever have failed?
replay timeout
A quiet counter
was not a
clean path.
Revisit the raw receipt.
Repair the check.
Test the check against the failure it claims to exclude.
13Complete the change
Illustrative replay • synthetic records • no live target
Dependency check fails
The candidate omits a utility required by another service.
Preserve the finding. Do not execute.
A new candidate is prepared
Repair the dependency plan; attach the revised artifact and recovery steps.
Earlier evidence stays attached to its earlier candidate.
Fresh evidence passes
Repeat the consumer check and the deliberately broken control in staging.
Review the exact candidate before execution.
Execute the bounded grant
Record authorized intent and the attempt first. Apply the candidate, then observe and record the outcome.
If reporting is interrupted, observe the target before retrying.
Consumers work; the record agrees
The functional check passes, the deployed state is recorded, and acceptance is explicit.
A useful result, ready for the next actor.
Advance to walk through the correction and acceptance.
14Give each service a job
These are logical responsibilities, not a required machine per box.
15Make tomorrow-you a good teammate.
Get your bearings.
Task + revision
What changed
Running jobs
Needs a decision
One command or current page.
Show when it was checked.
Give inputs a home.
New material → next review
Questions → one digest
Hide after Friday
Name what interrupts now.
Let temporary notes expire.
Leave a way back.
Changed: candidate + evidence
Open: restore check
Next: test recovery
Still running: none
A short note to your next self.
Keep the evidence linked.
Pick one friction point. Make the useful habit easier to do.
16What should your project keep or change?
What earned its place
Evidence that can be revisited
Checks that expose mistakes
Clear ownership and recovery
What gets in the way
Rules that never reach the workflow
Views nobody can keep current
Dispatch beyond review capacity
Can we finish useful work?
A project you can operate—and enjoy.
More room
to explore.
A way back
to the work.
Take one piece home.
One habit: leave a way back.
One guardrail: bound the change.
One test: can a fresh actor continue?
Try it on a task you already care about.
A lease is only part of ownership
Optional depthClaim
Check run state
Recognize duplicate requests
Reject a live competing lease
Record claimant and expiry
After expiry
The old worker may still run.
The destination must reject stale authority or serialize consequential writes.
A claim record, a queue entry, and an external effect solve different problems.
Appendix 1Give state one authoritative home
Optional depthNarrative
Why and how
Decisions, explanations, handoffs, runbooks.
Transactional state
Who owns what now
Claims, attempts, transitions, identities.
Derived views
How we find and observe
Search, dashboards, summaries, telemetry.
Preserve identity and provenance when information crosses stores.
Appendix 2The same shape, different acceptance
Optional depthRead-only audit
Pinned inventory
Re-runnable checks
Findings with limits
Experiment
Registered question
Inputs + environment
Result + interpretation
Service deployment
Authorized target
Functional checks
Observed state + recovery
Choose the evidence that establishes the intended outcome.
Appendix 3Choose tools by their responsibility
Optional depthA new component adds an operating obligation as well as a capability.
Appendix 4References and questions to take home
Optional depthTest your own project
Can a fresh actor take over?
Can a check catch a known defect?
Can the target reject stale authority?
Can recovery work without the agent?