11 posts tagged with "workflow"

Persistent coordination. Ephemeral execution. Durable evidence.

We have been building AI agents as though they are employees.

We give them long-running sessions, persistent responsibilities and an ever-expanding list of things to do. Then we wonder why their context fills up, why decisions drift, and why so much of the token budget disappears without a corresponding improvement in delivery.

There is a simpler way to think about it.

The intelligence does not need to persist. The work does.

Why are we paying for yesterday's task again?​

The most immediate problem with reusing the same subagent is not philosophical. It is computational.

A worker finishes Task A. Its conversation now contains the instructions, files, tool outputs, failed approaches, diagnostics and final report for Task A. We then give the same worker Task B. Depending on how the runtime manages context, much or all of that previous history can be sent through the model again, even though Task B does not require it.

Finish Task B, add Task C, and the burden grows.

In a simple illustrative model, suppose every task introduces 10,000 tokens of history, all of which are retained and reprocessed on subsequent tasks. Over ten tasks, the cumulative history processed is:

If that growing history is processed once per task, the total across ten tasks is 550,000 tokens of accumulated context, compared with 100,000 tokens for ten independent 10,000-token tasks—before considering common instructions, model-specific caching, truncation, summarisation and other runtime behaviour. This is an illustration, not a measured benchmark or universal billing prediction.

The exact cost depends on the model, prompt caching, context management and what gets retained. But the architectural problem remains: unrelated history can be repeatedly carried forward for no useful reason.

That is a poor way to spend a finite token budget.

And cost is only half the problem. Each old instruction and abandoned hypothesis competes for attention with the work that actually matters now. Bigger context is not automatically better context.

The persistent-agent trap​

A long-running agent is useful when the objective itself requires ongoing responsibility. A project needs decisions, sequencing, dependencies, status and continuity.

But keeping every execution worker alive turns a clean delivery system into a growing collection of conversations. You gradually acquire duplicated ownership, stale assumptions, hidden work queues and unresolved intentions. A worker starts as a tester and, three assignments later, is also changing the architecture.

You have not created a better team. You have created more places where project state can become trapped.

The answer is to separate coordination from execution.

One coordinator, disposable workers​

A project has one logical coordinator for an objective or EPIC. It owns priorities, task boundaries, delegation, integration and acceptance. The coordinator session can itself be replaced when needed, but the logical ownership and delivery state survive in durable records.

A subagent gets one bounded assignment. It receives only what it needs: objective, issue, relevant baseline, permitted scope, acceptance criteria, validation commands and expected evidence.

It performs the work, returns the result, and closes. It does not inherit unrelated tasks, collect an open-ended schedule or silently become another coordinator.

Parallelism is allowed where workers have explicit boundaries and do not collide in their changes. The key is one accountable coordinator, not an invisible pyramid of persistent agents.

One assignment, not one tool call​

One-shot does not mean a subagent only gets a single prompt or tool call. It can run commands, write code, test, diagnose and iterate within its assigned scope.

A task contract might look like this:

Task: JAVA-WRAPPER-014
Execution: JAVA-WRAPPER-014/attempt-1
Baseline: <full commit SHA>
Objective: Launch a supplied JAR with validated arguments
Scope: Java wrapper module and its tests
Acceptance: CLI behaviour, exit-code propagation, test evidence
Return: commits, changed files, test results, risks
Expiry: governed time/resource boundary

After it returns, the coordinator independently verifies whether the result meets acceptance criteria. Completion is not the same as acceptance. If the worker failed, or the evidence fails review, the coordinator records what happened and starts a new bounded execution with the relevant findings.

Starting fresh must not become a loophole for repeating the same failed strategy. The governed circuit breaker still applies.

Persist useful information, not the entire conversation​

This is the crucial distinction.

The next worker might genuinely need to know that a test failed, that a particular design was rejected, or that a public contract cannot change. It does not need 80 pages of chat history showing how the previous worker discovered those facts.

Persist the distilled evidence: the requirement, baseline, commits, test outputs, relevant diagnostics, failed hypotheses, decisions and next steps.

Then build the next worker's context from those authoritative artifacts.

The durable system becomes the memory. The workers remain disposable.

Failure becomes a bounded event​

If a worker stalls or exhausts its context, terminate or close that execution and preserve its disposition. Another worker can take the assignment from the last verified state without relying on a mysterious previous conversation.

That requires more than a good prompt. Each dispatch needs a unique execution ID, bounded lifetime and clear write ownership. Before retrying, the coordinator checks whether the earlier execution already changed files or triggered side effects. Otherwise, a delayed worker and its replacement can both apply the same change.

If the runtime does not support actual lease revocation or archival, the coordinator should record that limitation and enforce the closest possible boundary through tracked status and controlled write access. A governance document must not pretend a mechanism exists when it does not.

Does starting fresh always save tokens?​

No. A new agent may have to reread the same large codebase or rebuild its environment. Prompt caching can also reduce the price of repeated shared context. For a tightly coupled, short sequence of related actions, continuing a bounded worker may be more efficient than restarting after each tool call.

The goal is not maximum agent turnover. It is minimum irrelevant context per verified outcome.

That means choosing task boundaries that produce meaningful, independently reviewable results. A worker can spend time on one coherent task. It should not carry its last ten unrelated jobs into the eleventh.

Archive the worker; keep the proof​

A returned worker is not a permanent member of the team. Its result is an artifact for the coordinator to evaluate.

Archive the execution after its outputs and disposition are recorded—even when it failed. Archiving does not erase logs or evidence. It ends the worker's ability to keep acting as an ongoing collaborator.

The coordinator's own continuity follows the same principle. Before a session handoff, preserve the EPIC, open issues, in-flight executions, decisions and next actions. A successor session reconstructs the work from those records. There should never be two competing coordinators for the same objective.

What we added to VibeGov​

We formalised this approach in GOV-11: Ephemeral Subagent Execution.

The rule requires one-shot task contracts, durable evidence, coordinator-owned verification, worker archival, safe retries and explicit handoff semantics. It expresses an architectural contract; individual runtimes still need to implement and verify the relevant enforcement mechanisms.

This builds on Explicit Orchestration Beats Hidden Agent Pyramids, and responds to the delivery risk explored in Bankruptcy by Monday Morning.

Design for throughput, not conversation longevity​

The unit of value in an autonomous software factory is not a busy agent or a long transcript. It is a requirement that has moved into a verified state.

We should not celebrate how many agents are still running. We should ask how much irrelevant history they are carrying, what each one owns, what evidence it returns, and how safely the work can resume when it disappears.

Keep the coordinator's responsibility continuous. Keep the worker's assignment bounded. Keep the evidence durable.

Stop keeping your AI agents alive just to remember work that belongs in the repository.

Do not just prompt the machine.

Conduct it.

Most AI teams do not fail because one prompt was bad.

They fail because every miss, regression, awkward result, and near miss gets patched with one more instruction.

Add one more reminder. Add one more warning. Add one more exception. Add one more paragraph explaining what should have been obvious. Add one more "always do this." Add one more "never do that."

At first, this feels like progress. The system got something wrong, so now the team has corrected it.

But over time, the prompt stops being a tool and starts becoming sediment.

That is how you get death by 1000 prompts.

The problem is not prompting itself. Prompting matters. Clear instructions reduce mistakes.

The problem is prompt accumulation without governance.

What death by 1000 prompts looks like​

You can usually spot it quickly.

The bootstrap prompt becomes enormous. The same rules get repeated in every session. Agents need hand-carried context because the important behavior does not live anywhere durable. Simple tasks only work if someone remembers the exact latest wording. The team keeps adding exceptions, but very little is being simplified. Merged lessons never become rules. The system becomes more fragile as more guidance is added.

This is not operational maturity. It is operational debt.

The team starts thinking the fix is better prompting, when the real problem is that the system has no stable way to learn.

Every failure becomes another patch in active text instead of an improvement in how the system actually operates.

The real issue is not intelligence. It is operating shape.​

A lot of prompt sprawl is actually a design smell.

It usually means one or more of these things are missing:

• no canonical rules
• no durable memory
• no explicit workflow closure
• no distinction between review, proposal, and live change
• no promotion path from incident to lesson
• no stable project source of truth
• no cleanup discipline after work lands

So the agent keeps depending on live chat and oversized prompts to behave.

That creates a strange illusion: the system looks highly instructed, but it is actually weakly governed.

It has lots of words and not enough structure.

Prompts should start work, not hold the whole system together​

A prompt has a role.

It should help frame the task, the current objective, the immediate constraints, and the operating mode.

That is useful.

But a prompt should not be the only thing stopping chaos.

If the same correction has to be repeated again and again, it is probably no longer just prompt content. It is a rule that has not yet been promoted into the system.

That is the key shift:

• a prompt is situational
• a rule is durable
• a spec defines scoped truth
• memory preserves continuity
• a workflow defines repeatable closure
• governance decides what becomes stable

Once you see that distinction clearly, a lot of AI delivery problems become easier to diagnose.

Why teams keep falling into this trap​

Because prompt patching is easy in the moment.

Something went wrong, so you add another sentence. Something drifted, so you add another warning. Something was misunderstood, so you add another block of explanation.

That gives immediate relief.

But it also hides the deeper question:

Why did this need to be said again?

If the answer is "because this is a recurring invariant," then the fix is probably not another prompt patch. The fix is to move that lesson into a governed surface.

That might be:

• a rule file
• a spec
• a checklist
• a project doc
• a memory convention
• a release or closure routine
• a validation gate
• a canonical operating pattern

Without that promotion step, every learning event stays trapped in transient text.

That is how systems become verbose without becoming reliable.

What to do instead​

The answer is not "never use prompts."

The answer is: stop using prompts as your only learning mechanism.

Here is the better pattern.

1) Promote repeated lessons into durable rules​

If the same instruction keeps getting repeated, stop treating it as temporary.

Turn it into a canonical rule.

For example:

• if agents keep starting new work from the wrong branch, that is not a prompt tweak; it is a git workflow rule
• if agents keep confusing review with modification, that is not a wording issue; it is an execution boundary rule
• if work keeps being left half-closed, that is not minor cleanup; it is a closure rule

Repeated pain should become reusable governance.

See:

• Published GOV 02 Workflow
• Published GOV 10 Agent State Closure and Git Hygiene

2) Move important behavior out of chat-only state​

If the only place a critical lesson exists is in live conversation, you do not have continuity.

You have dependency on recall.

That is fragile for humans, and even more fragile for agents.

Important operating behavior should live somewhere durable:

• rules
• specs
• project docs
• issue trails
• memory files
• release and closure routines

Chat should not be the only archive of how the system is supposed to behave.

See:

• Agent Continuity Bootstrap
• Published GOV 09 Agent Continuity Bootstrap
• Published GOV 11 Agent Legibility and In-Repo Truth

3) Treat closure as part of execution, not optional cleanup​

A lot of prompt sprawl comes from unfinished work.

Not just unfinished code. Unfinished state.

The repo is left on the wrong branch. The issue is still open. The PR is merged but the branch still exists. The decision never got written down. The lesson was noticed but never promoted.

Then the next prompt has to compensate for all of that unresolved residue.

This is why closure matters so much.

Good systems reduce future prompt burden by ending work cleanly. Bad systems increase future prompt burden by carrying residue forward.

See:

• Published GOV 10 Agent State Closure and Git Hygiene
• Published GOV 13 Review Loops and Completion Discipline

4) Separate review from change​

This one matters a lot.

When someone asks for a review, they are not necessarily asking for live edits.

If a team does not clearly distinguish:

• review
• proposed wording
• live change

then every interaction becomes ambiguous.

That ambiguity creates more corrective prompting later.

A governed system should make the action boundary visible.

Review means inspect, critique, and suggest. Change means edit. Those are not the same thing.

5) Make the default path clean and boring​

The healthiest systems are not the ones with the most instructions.

They are the ones where the correct path becomes routine.

For example:

• merged branches are deleted by default
• stale branches are archived only when needed
• local repos return to their resting branch
• issue state matches delivery state
• recurring lessons get published into canonical guidance
• new work starts from known clean conditions

When the default path is clean, you need fewer rescue prompts.

That is the whole point.

The governance pattern that actually scales​

A useful pattern here is:

incident -> diagnosis -> rule -> publication -> enforcement -> reuse

That is how you stop one mistake from becoming twenty future reminders.

Something goes wrong. You inspect what really failed. You decide whether it was local, scoped, or systemic. If it is systemic, you promote it into governance. You publish it in the surfaces agents actually use. You make the clean path explicit. Then the next run starts from the improved system rather than from a longer prompt.

That is how a governed system gets lighter over time instead of heavier.

Good systems need fewer reminders over time​

This is the real test.

A mature AI operating system should not require more and more prompt mass just to maintain basic quality.

It should need fewer reminders because the important lessons have been absorbed into the environment.

That means:

• the rules got better
• the docs got sharper
• the memory got cleaner
• the workflow got stricter
• the closure got more complete
• the defaults got safer
• the need for repeated rescue prompting went down

If your prompt keeps growing but your operating quality is not stabilizing, the prompt is not your solution.

It is your symptom.

Avoiding death by 1000 prompts​

So how do you avoid it?

Not by trying to write the perfect mega-prompt.

You avoid it by building a system that can learn structurally.

Use prompts for task framing. Use rules for invariants. Use specs for scoped truth. Use memory for continuity. Use workflow for closure. Use governance to turn recurring mistakes into reusable discipline.

That is how you stop every lesson from becoming one more paragraph in a bloated prompt.

That is how you stop fragility from masquerading as thoroughness.

That is how you build systems that get calmer, cleaner, and more reliable as they evolve.

The goal is not to create a prompt so large that nothing can go wrong.

The goal is to build an operating model that no longer needs to be rescued by one.

Related reading​

• Published GOV 02 Workflow
• Published GOV 09 Agent Continuity Bootstrap
• Published GOV 10 Agent State Closure and Git Hygiene
• Published GOV 11 Agent Legibility and In-Repo Truth
• Published GOV 13 Review Loops and Completion Discipline
• Output Quality and Anti-Slop

A lot of agent discussions still assume there is one loop.

The agent is running. The loop is going. Work is happening.

That sounds fine until you try to govern it. Then you discover that "the loop" is hiding several different kinds of work with different sources, different outputs, and different reasons to pause.

VibeGov should be more explicit.

The real shape is usually three loops​

In practice, agent-enabled work often has at least three loops running in parallel:

• a Build Loop
• an Exploratory Loop
• a Human Feedback Loop

And once those exist, you also need one important rule for how they pause:

• Scoped Blocking

1) Build Loop​

The Build Loop is the delivery loop.

Its job is not to invent work. Its job is to consume already-governed work and turn it into clear outputs.

That means the Build Loop should take input from:

• the repository,
• the issue backlog,
• the bound specs or requirements,
• and the current governed delivery state.

And it should write back:

• code,
• docs,
• tests,
• evidence,
• issue or PR state,
• release-readiness or shipping outputs when relevant.

The important boundary is this:

build should not recursively self-source its own next work from its own outputs.

If it does, the delivery loop becomes unstable. Instead of a governed execution path, you get a self-expanding activity engine.

2) Exploratory Loop​

The Exploratory Loop is the non-delivery intelligence loop.

Its job is to inspect reality and feed governed work into delivery.

That can include:

• UI exploration,
• workflow review,
• spec exploration,
• issue exploration,
• drift detection,
• gap analysis,
• backlog hydration,
• and exploratory report generation.

This is also where a lot of confusion happens. People hear planner or evaluator and assume those roles must belong to a delivery harness. But that is too narrow.

In VibeGov terms, exploratory work can absolutely include:

• planner-style scoping of a review surface,
• evaluator-style judgment of coverage, artifacts, or review quality,
• and even generator-style output when the output is an exploratory artifact rather than a delivered product change.

What makes the work exploratory is not the role name. What makes it exploratory is that it is not directly delivering the product change.

3) Human Feedback Loop​

A lot of loop talk accidentally removes the human except as a final approver. That is too weak.

The Human Feedback Loop should be first-class.

Its job is to inject:

• approval,
• correction,
• judgment,
• taste,
• reprioritisation,
• missing context,
• or strategic redirection.

Without this loop, the human falls out of the operating model. Then teams start claiming the human is "in the loop" when the human is really only around to react to surprises.

4) Scoped Blocking​

Once you accept that there are multiple loops, blocker handling has to get sharper too.

A human question, missing dependency, or unresolved approval should not automatically freeze everything.

That is why VibeGov needs scoped blocking.

Scoped blocking means:

• pause the exact lane that truly needs the answer,
• keep unrelated build work moving,
• keep unrelated exploratory work moving,
• and make the blocked boundary explicit.

This is stronger than simply saying "blockers should redirect work." It explains which work should pause and which should continue.

Why this matters​

Without this model, teams drift into four bad habits:

• treating all agent work as one vague loop,
• letting build recursively invent new work for itself,
• turning human-in-the-loop into stop-the-world behavior,
• or misclassifying exploratory planner/evaluator work as delivery.

The result is usually motion without clean governance.

Diagram​

Loop system view​

This is the important boundary to notice: build consumes governed work from repo/specs/issues and writes clear outputs back, while exploration and human feedback feed new governed work into the source side.

Scoped blocking view​

This is the important blocker rule: pause only the lane that truly needs the missing answer. Do not let one unresolved human input freeze every build and exploratory path by default.

With the three-loop model, the system becomes easier to reason about:

• Build changes reality.
• Exploratory understands reality.
• Human feedback reshapes intent.
• Scoped blocking prevents one unanswered question from freezing the whole system.

That is a much better operating model than pretending there is just one loop and hoping everyone means the same thing.

Related reading​

• Build Loop, Exploratory Loop, Human Feedback Loop, and Scoped Blocking
• Execution Modes
• Exploratory Review Mode
• Evaluation Pattern
• Reference Reading
• Published GOV 02 Workflow

This is the operating-discipline piece in the series. Once throughput, budget, and runtime control are all in view, teams still need a practical rule for day-to-day execution: reward governed movement, not polished activity.

AI has made one old delivery weakness much more dangerous.

Teams can now generate enough visible activity to look productive long before they have produced trustworthy progress. That makes bad management easier, not harder, because dashboards and updates can look healthy while delivery quality quietly rots.

That is why progress over perfection matters so much in AI-native delivery. Not because standards should drop. Not because teams should accept sloppy work. But because the wrong kind of perfectionism and the wrong kind of activity theater both create the same failure: work that looks like momentum without becoming governed movement.

The new trap: activity that feels like progress​

AI can produce a lot of things quickly:

• drafts
• variants
• summaries
• issue text
• implementation attempts
• review notes
• test scaffolding
• status updates

All of that can be useful. Some of it is genuinely valuable. But volume creates a dangerous illusion.

A team can have:

• long transcripts
• many tool calls
• many generated files
• lots of discussion
• lots of revisions
• lots of "almost done"

and still be weak on the things that actually matter:

• is the issue clear?
• is the spec bound?
• did validation run?
• did the PR move?
• did blockers get captured?
• is release-readiness improving?

That is the distinction this post cares about. Visible activity is not the same thing as governed progress.

What progress should mean​

Progress in AI delivery should mean work crossing real gates.

Not every task needs every gate. But meaningful work should become more:

• explicit
• bounded
• verifiable
• reviewable
• traceable

That usually means some sequence like:

• vague request becomes issue
• issue becomes implementation-grade
• issue binds to requirements or spec
• work stays inside scope
• validation produces evidence
• blockers become tracked follow-up instead of hidden excuses
• review and release status become more trustworthy

That is progress. It has shape. It leaves artifacts. It improves the state of the system.

Why perfection is the wrong target​

A lot of weak delivery culture hides behind perfection language.

People say things like:

• we are still polishing
• we need a bit more confidence
• it is not ready to show yet
• the write-up is not perfect
• the automation is not complete

Sometimes that caution is justified. Often it is just unstructured delay.

AI can make this worse because it gives teams endless ways to keep refining presentation without tightening the delivery core. A model can always rewrite the doc, generate another variant, or search for another angle. That can create a kind of productivity loop where the team keeps touching work without moving it meaningfully closer to done.

Progress over perfection is the antidote.

It asks:

• what gate can this item cross now?
• what evidence is missing?
• what blocker needs to become explicit?
• what follow-up should be created instead of silently absorbed?
• what is the smallest governed step that reduces ambiguity or risk?

This does not lower the bar. It changes the unit of progress from "felt completeness" to "visible governed movement."

Governance gates make progress measurable​

The reason governance matters here is simple. Without gates, teams drift back toward vibes.

Governance gates are not there to slow work down. They are there to reveal whether work is actually becoming more trustworthy.

Examples of useful gates in AI-native delivery include:

Issue gate​

• has the work item been clarified?
• is the problem statement real?
• are constraints, non-goals, and acceptance criteria explicit?

Spec gate​

• is the work bound to an existing requirement?
• if not, was a SPEC_GAP or new requirement created?
• does the spec describe what success means?

Scope gate​

• is the branch/change set coherent?
• did the work stay inside the approved problem?
• were unrelated edits avoided?

Validation gate​

• did tests/checks/manual proof actually run?
• are outcomes recorded?
• are failure behaviors visible instead of softened away?

Review gate​

• is the PR or handoff reviewable?
• are artifacts understandable to someone new?
• are risks and residual gaps explicit?

Release-readiness gate​

• is the candidate safer to release than before?
• were smoke/build/deploy checks completed when needed?
• were regressions or rollout gaps tracked instead of ignored?

Each of those gates turns abstract motion into legible progress.

The difference between movement and theater​

This is where a lot of AI delivery goes wrong.

Teams start measuring what is easiest to count:

• prompts written
• tokens consumed
• hours spent with agents
• files changed
• draft count
• messages exchanged

Those metrics can be operationally interesting. But they are easy to game and easy to misread.

A stronger question is:

What is now true in the governed delivery system that was not true before?

Examples:

• the issue is now implementation-grade
• the requirement is now explicit
• the blocker now exists as a tracked artifact
• the validation now has evidence
• the PR is now reviewable
• the release candidate is now safer

That is movement. That is much harder to fake.

AI makes backlog hydration more important, not less​

One of the best side effects of a progress-over-perfection model is that it treats discovery as real work.

AI systems are very good at surfacing adjacent gaps, alternative interpretations, missing assumptions, and hidden failure paths. That value gets wasted if every discovery stays trapped in chat or in a person's head.

Progress often means converting what was just learned into artifacts that future work can use:

• focused issues
• spec updates
• blocker records
• traceability notes
• follow-up validation targets

That is one reason governed teams often look slower in the short term but move faster over time. They preserve the learning. They do not have to rediscover the same ambiguity every week.

A practical operating question​

If a team wants to work this way, a useful recurring question is:

What is the next smallest governed step that improves delivery confidence?

Sometimes the answer is implementation. Sometimes it is clarifying the issue. Sometimes it is updating the spec. Sometimes it is running one high-signal validation command. Sometimes it is writing the blocker down honestly and moving on.

All of those can count as progress if they improve the governed state of the work.

The important thing is that the step should leave the system clearer than it was before.

What teams should reward​

If organizations want better AI delivery behavior, they should reward:

• clearer issue quality
• cleaner spec binding
• honest checkpointing
• explicit blocker routing
• evidence-backed validation
• coherent PR movement
• trustworthy release-readiness status

They should reward much less:

• endless transcript volume
• polished but weak status summaries
• giant drafts without decision movement
• pseudo-confidence without proof
• private progress that never becomes team-readable artifacts

Progress over perfection is really a discipline of making work visible in the right places.

The point​

The point is not to move fast carelessly. The point is not to celebrate partial work as finished. The point is not to replace quality with speed.

The point is to stop confusing polished activity with governed movement.

AI can make teams look busy at extraordinary scale. A mature delivery system needs a stronger test than that.

Progress over perfection means asking whether work is:

• clearer
• more bounded
• better evidenced
• more reviewable
• more traceable
• closer to trustworthy release

If the answer is yes, progress is happening. If the answer is no, the team may just be producing better-looking ambiguity.

That is the difference governance helps make visible.

Series navigation​

• 1. From Token Burn to Governed Throughput
• 2. AI Budgets Are Part of Delivery Infrastructure
• 3. Company Work Should Run on Company-Governed AI
• 4. Progress Over Perfection in AI Delivery ← you are here
• 5. Unbudgeted AI Is Unmanaged Production Capacity

And once organizations start depending on that governed movement, one final management question appears: what happens when the capacity behind it is real, but still unofficial and unbudgeted? That is the final piece in the set.

Related docs​

• Checkpoint Reporting
• Execution Modes
• Workflow Quality Rubric
• Published GOV-02 Workflow
• Published GOV-06 Issues

Teams often bootstrap the governance folders and stop there.

That is useful, but it leaves one of the most dangerous gaps open:

• agents still have a path to work directly on protected branches
• promotion to production can blur into normal integration
• hotfixes can land fast and still leave develop behind

If the repo workflow is loose, the governance is only half-installed.

The missing bootstrap step​

Bootstrap should not only install rules. It should install the repository path those rules have to travel through.

For a strict VibeGov setup, that means:

• main is the promotion/release branch
• develop is the normal integration branch
• issue-scoped feature/, fix/, docs/, and chore/ branches start from develop
• agents do not commit directly to main or develop
• normal work reaches develop through pull request
• promotion from develop to main is a separate, explicit decision

That is the branch contract. Without it, the rest of the delivery loop is easier to bypass than teams usually admit.

Why develop matters so much​

The point of develop is not to create ceremony. It is to separate normal integration from release promotion.

When all work aims straight at main, teams lose a clean place to ask:

• what is ready to integrate?
• what is ready to promote?
• what evidence is attached to each decision?

develop gives the system a stable answer. Normal work integrates there first. Promotion to main becomes visible instead of accidental.

Why issue-scoped branches matter​

Agents are fast enough that "small shortcut" branching habits become system-level problems.

Issue-scoped branches force three good behaviors:

1. the work has a tracked reason to exist
2. the scope stays isolated while the change is in motion
3. reviewers can map the branch back to issue and spec intent quickly

That is why the branch name itself should carry the issue ID. It turns Git history into traceability instead of mere chronology.

Pull requests are the integration gate​

The important rule is not merely "use pull requests sometimes." It is "normal work must enter develop through pull requests, and agents do not bypass that gate."

That matters because pull requests are where teams can reliably attach:

• issue links
• spec links
• validation evidence
• risk notes
• release-readiness context

The pull request is where branch workflow meets governed evidence.

Promotion and hotfixes should be explicit too​

Promotion from develop to main is not just another merge. It is a release decision.

That decision should be visible in its own pull request so reviewers can ask whether the integrated work is truly ready to become the production/reference state.

Hotfixes need the same clarity from the other direction:

• branch from main
• merge back to main through an explicit hotfix pull request
• then back-merge or otherwise reconcile into develop immediately

Without that last step, the repo begins to lie about its own state. main contains reality, develop contains a stale story, and the next integration cycle inherits the drift.

Branch protection turns the policy into reality​

A written workflow is better than nothing, but protected-branch settings are what stop the shortcuts from becoming normal.

That is why VibeGov bootstrap now needs more than a rule file. It also needs:

• a repo pull-request template
• a branch protection checklist
• adoption docs that explain the promotion and hotfix path clearly

Those artifacts make the workflow teachable and enforceable instead of tribal.

Practical takeaway​

If you want agents to inherit good delivery behavior, bootstrap the Git path as well as the governance text.

Install the folders, install the rules, and also install the strict branch and pull-request contract before product code begins.

Related docs​

• Bootstrap
• Quick Start
• Branch Protection Checklist
• GOV 02 Workflow

A lot of teams say they have an SDLC. What they usually mean is that work somehow moves from request to code to deploy.

That is not the same thing as having a delivery system you can trust.

The VibeGov SDLC is an attempt to make that system legible. Not heavier. Legible.

The normal vague loop​

The default software loop often looks like this:

• someone asks for something
• somebody starts building
• a few checks happen
• something gets merged or shipped
• issues found later go into chat, memory, or nowhere

This can look fast for a while. But it accumulates a specific kind of damage:

• intent gets forgotten
• evidence gets replaced by confidence
• exploratory review becomes a pile of notes
• blockers stall work silently
• delegated agent work becomes hard to supervise
• future contributors inherit output without reasoning

That is how teams end up busy but under-governed.

The VibeGov loop​

VibeGov tries to force clarity at the points where teams usually hand-wave.

The loop is:

1. bootstrap governance and repo structure
2. turn requests into issue/spec-bound work
3. choose the execution mode explicitly
4. execute one bounded unit with visible ownership
5. require evidence before completion claims
6. report checkpoints that another operator can actually use
7. feed discoveries back into backlog, specs, and traceability
8. repeat with better context than the previous cycle

The shape matters more than the slogan.

Why mode selection matters so much​

A lot of delivery confusion comes from mixing up two very different jobs:

• Development changes reality and must prove the change
• Exploration inspects reality and must create follow-up work

When those modes blur together, teams start claiming progress without the right proof. A review note gets presented like a fix. A successful render gets presented like a validated workflow. A smoke check gets presented like release readiness.

Explicit mode selection stops that collapse.

Why evidence changes the quality of the whole system​

The strongest thing VibeGov does is simple:

It refuses to treat "looks good" as a serious completion standard.

That means work should end with proof appropriate to the mode:

• tests, builds, smoke checks, and resulting-state verification for Development
• scenario outcomes, artifact creation, and honest confidence limits for Exploration

Without that, teams are not really closing loops. They are just narrating motion.

Why backlog hydration belongs inside the SDLC​

In a weak process, exploratory findings become loose notes. In VibeGov, they become tracked engineering work.

That distinction matters.

If a review finds a broken interaction, a missing contract, or an ambiguous behavior, the result should not be "we noticed it." The result should be:

• a focused issue
• a spec or traceability update
• a next execution path

That is how exploration improves delivery instead of merely commenting on it.

Why delegation is still part of the SDLC story​

Modern SDLCs increasingly involve delegated agent work. That means SDLC governance now has to include orchestration discipline too.

If a parent thread spawns a worker and then disappears, the system may still be running, but it is not being supervised well. So the VibeGov SDLC also expects:

• bounded delegated work units
• visible ownership
• visible checkpoints
• visible completion, blocker, or recovery state

A runtime that stays alive is not enough. A governed loop must stay inspectable.

The real outcome​

The goal is not more process theatre. The goal is that each cycle leaves behind durable truth:

• why the work existed
• what changed
• what proved it
• what is still missing
• what should happen next

That is what makes an SDLC useful under pressure. Not that it sounds mature, but that it stays honest when things get messy.

Related docs​

• The VibeGov SDLC
• Execution Modes
• Checkpoint Reporting
• GOV 02 Workflow

A multi-agent system can look healthy for exactly the wrong reason:

• the worker spawned successfully
• the session exists
• the runtime says it is still alive

That is not the same thing as governed execution.

Recent project learnings made this painfully clear. A parent thread can successfully launch a worker thread and still fail the real governance test by going quiet afterwards.

The hidden failure mode​

People often focus on whether ACP setup works at all:

• can the worker spawn?
• can the runtime create a session?
• can you read results back later?

Those are important setup questions. But they are not the whole question.

The deeper question is:

does the parent keep visible ownership of the delegated unit until completion, blocker, or explicit handoff?

If the answer is no, the system has a supervision problem even if the worker runtime is technically healthy.

Worker health is not governance health​

A worker can be:

• alive
• executing
• emitting some output

And the governance can still be weak.

Why? Because a silent parent creates ambiguity:

• who owns the unit right now?
• how long has it been running?
• has anyone checked progress recently?
• is the latest state meaningful progress or a stale transcript?
• when will the next supervisory action happen?

Without those answers, a parent thread is not orchestrating. It is just launching.

Delegation does not end accountability​

This is the key lesson.

Delegation does not transfer orchestration accountability.

The parent may delegate execution. It does not delegate responsibility for visible supervision.

In governed systems, the parent should still:

1. announce the delegated unit clearly
2. report worker identity when available
3. perform early follow-up checks
4. continue periodic supervision for long-running work
5. report completion, blocker, or recovery action explicitly

That is what turns delegation into governed execution instead of fire-and-forget behavior.

Why cadence matters​

A common failure pattern is vague follow-through:

• one start message
• maybe one worker id
• then silence
• then, much later, either a result or nothing

That pattern is operationally weak because it hides whether the parent is still on top of the unit.

Governance should not necessarily hardcode one universal timing rule for every environment. But governance should require that a system define:

• an early-follow-up checkpoint window
• an ongoing supervision cadence for long-running work
• an escalation expectation when progress is stale or ambiguous

The runtime or project docs can set the exact numbers. Governance should enforce the accountability shape.

What this means for ACP setup docs​

ACP setup docs should not stop at:

• how to spawn sessions
• how to configure backends
• how to attach tools
• how to read transcript output

They should also explain:

• how the parent tracks ownership after delegation
• how follow-up checks are scheduled or enforced
• how elapsed runtime is surfaced
• how stale or missing readback is escalated
• how the parent proves it is still supervising the worker thread

That is where setup guidance meets governance.

The better practical test​

Instead of asking only:

did the worker spawn successfully?

Ask:

if this worker runs for 20 minutes, can a human still see who owns it, how long it has been running, what its latest known state is, and what the next supervisory step will be?

If not, the setup may be functional but it is not yet governable.

Related docs​

• GOV 02 Workflow
• Checkpoint Reporting
• Workflow Quality Rubric
• Explicit Orchestration Beats Hidden Agent Pyramids

A lot of multi-agent failure is not caused by weak models. It is caused by weak structure.

One agent quietly spawns another. That worker quietly turns into a coordinator. Soon the team has a small invisible management hierarchy inside the runtime, while the human only sees a vague status line and a missing result.

VibeGov should be stricter than that.

The governance principle​

Governed execution should use explicit orchestration and bounded work units.

That means the parent orchestration context should:

1. select one tracked unit of work
2. announce that delegation clearly
3. hand the unit to one bounded worker or lane
4. receive a visible result bundle
5. only then continue to the next unit by default

This is not an argument against capable workers. It is an argument against hidden coordination.

Why hidden agent pyramids are bad governance​

When a worker turns into a silent coordinator, teams lose the things governance is supposed to protect:

• Visibility — humans cannot tell what is actually running
• Accountability — ownership gets blurred across layers
• Recovery — failures become harder to isolate and restart
• Evidence quality — outputs arrive detached from the unit that produced them
• Scope control — sub-work expands without an explicit decision

A system can still look busy while becoming less governable. That is the trap.

Sequential bounded stages are usually the safer default​

People sometimes overcorrect and say all work must be linear forever. That is too absolute.

The better rule is:

prefer sequential bounded stages when they improve observability, recoverability, or handoff clarity.

If a workflow is easier to inspect, interrupt, retry, or hand off when split into clear stages, that is the right default.

Parallelism is still allowed​

VibeGov is not anti-parallel. It is anti-opaque.

Parallel lanes are fine when each lane still has:

• an explicit owner
• bounded scope
• visible checkpoints
• clear evidence outputs
• recoverable failure handling

The issue is not "more than one worker." The issue is "more than one hidden coordinator."

What belongs in governance vs implementation docs​

This principle belongs in governance because it defines the shape of accountable execution.

What does not belong in governance:

• exact runtime settings
• queue TTLs
• model defaults
• local file paths
• wrapper commands
• temporary transcript or recovery hacks
• patch-specific engineering notes

Those are implementation details, runbook material, or architecture notes. Useful, yes. Governance, no.

The practical test​

If a human asks, "what is running right now, on which tracked unit, with what evidence expected?" the system should answer that directly.

If the honest answer is, "well, one worker spawned another coordinator which then delegated a few things internally," governance has already weakened.

That is why explicit orchestration matters. Not because it is pretty, but because it keeps multi-agent delivery legible under pressure.

Related docs​

• GOV 02 Workflow
• Execution Modes
• Checkpoint Reporting
• Workflow Quality Rubric

A lot of weak review culture comes down to two mistakes:

1. teams confuse visible UI success with real workflow success
2. teams report partial review as if it were complete review

Those two mistakes create a huge amount of fake confidence.

The UI-success trap​

A button click, success toast, redirect, or green checkmark can all look convincing.

But none of them prove that the intended mutation actually happened.

If a workflow claims something was saved, deleted, synced, imported, connected, or reconfigured, the review should verify the resulting state:

• does the change survive refresh?
• does the downstream view reflect it?
• is the source-of-truth actually changed?
• is the deleted thing really gone?

If the answer is unknown, the review is not finished.

The completeness trap​

Teams also love saying things like:

• "reviewed"
• "tested"
• "looks good"

Those phrases are dangerous when they hide partial coverage.

A useful review should end with an explicit completeness label:

• Complete
• Complete-with-blockers
• Partial
• Invalid-review

This is not bureaucracy. It is honesty.

Why this matters for backlog quality​

When review completeness and persistence proof are weak:

• false positives enter release decisions
• backlog items get under-scoped
• regressions survive because surface behavior looked fine
• future contributors inherit unclear status

When they are strong:

• backlog items become more implementation-ready
• issue severity becomes easier to judge
• release confidence becomes more trustworthy
• teams spend less time rediscovering the same gap

The governance principle​

Good review does not ask only:

Did the interface react?

It also asks:

Did the system outcome actually happen, and how complete was the review that claims it?

That question is where a lot of workflow maturity lives.

Related docs​

• Workflow Quality Rubric
• Exploratory Review Mode
• Checkpoint Reporting
• GOV 08 Exploratory Review

Most delivery stalls are not caused by impossible engineering problems. They are caused by weak blocker handling.

Teams hit missing permissions, broken dependencies, unclear requirements, or bad runtime state, then respond with the same message: blocked, waiting.

VibeGov uses a harder rule.

A blocker is a routing event​

A blocker means the current item cannot advance with useful confidence right now. It does not mean the whole loop stops.

In VibeGov terms, blockers should be handled inside the active execution mode:

• Development blockers should redirect implementation or release-readiness work
• Exploration blockers should redirect review scope
• Development release-verification blockers should reduce confidence and shape the go/no-go recommendation

That distinction matters because one blocked path should not erase all other ready work.

What good blocker handling looks like​

When VibeGov declares a blocker, it expects:

• bounded effort to confirm the problem
• evidence showing what was attempted
• a tracked blocker artifact
• a clear statement of what remains unvalidated
• the next best unblocked item or route

That turns a blocker into navigational information instead of dead time.

Weak and strong examples​

Weak blocker report:

• "Blocked, waiting on environment."

Strong blocker report:

• "Blocked on the permission state required for approval review. Attempted standard and elevated-user paths; neither can reach the control in the current environment. Blocker artifact linked with confidence limits. Moving to the notification audit route."

The strong version makes recovery possible. The weak version just spreads ambiguity.

Why this improves flow​

Better blocker handling gives teams:

• less idle time
• better evidence of real dependencies
• cleaner handoffs
• faster restart when the blocker clears
• more honest backlog sequencing

The goal is not to hide blockers. The goal is to stop letting one blocker quietly freeze everything else.

Read the operational guidance:

• Execution Modes
• Blocker Escalation
• Checkpoint Reporting
• Workflow Quality Rubric
• Published GOV-02