Vincent 0.9.0: Coding-agent automation that knows when to stop

Vincent 0.9.0 is out.

And while there are plenty of new features in this release, the part I care about most is something less flashy:

Vincent is getting better at knowing what it should not do.

Fourteen days after 0.8.0, the release contains:

• 428 commits
• 23 additions
• 6 changes
• 11 fixes
• 57 pull requests represented in the changelog

For anyone unfamiliar with the project, vincent is a local, vendor-independent control plane for coding agents.

It can run tools such as Claude Code, Codex and Cursor through explicit workflows, isolate tasks into branches and worktrees, coordinate parallel work, enforce gates, run verification, and keep the orchestration state on your machine.

0.9.0 takes another major step toward making that model useful for longer-running automation.

Work can now start itself

Until 0.9.0, something had to explicitly invoke vincent.

You could create a task from the TUI, CLI or API, but there was always a direct action that started the process.

0.9.0 introduces event triggers.

Vincent can now react to:

• GitHub issues
• GitHub pull requests
• command output
• signed HTTP events
• cron schedules
• recurring intervals

That means workflows such as these are now possible:

issue receives "agent-please" label
        ↓
Vincent creates task
        ↓
workflow starts
        ↓
agent implements change
        ↓
checks run
        ↓
human reviews result

Or:

02:00 every night
        ↓
dependency audit
        ↓
agent investigates outdated packages
        ↓
proposed changes wait for review

But adding event-driven execution introduces a much more important question:

Who is allowed to turn automation on?

Agents can propose automation. They cannot arm it.

Triggers are intentionally conservative.

A trigger does nothing until both the trigger itself and trigger support globally are enabled.

When a trigger is armed for the first time, vincent records the events that already exist instead of executing a backlog of old work.

Triggered tasks can also default to a paused state.

And there is another rule I consider particularly important:

An agent can create or modify a trigger proposal, but vincent will refuse to apply it if doing so would arm the trigger.

There is no override flag.

The agent can write the automation.

A human decides whether that automation gets authority to run.

That distinction is going to matter more as coding agents become increasingly capable.

From issue to pull request to merge

Vincent 0.8.0 could open a pull request for a task.

0.9.0 goes further.

From the task itself you can now:

• inspect PR checks
• comment
• re-run checks
• close a PR
• reopen it
• merge it

But again, the interesting part is the boundary.

The merge action is not exposed as an MCP tool.

Agents do not get the merge button.

And when a human requests a merge, vincent checks that the exact state being reviewed is still valid.

It refuses the operation if:

• the branch is behind
• a check is still running
• the PR head has moved

The goal is not to eliminate human involvement.

The goal is to make human involvement happen at the places where it actually matters.

Agents now live inside the task container

Containerized tasks are also more complete in 0.9.

Previously, command steps and checks could execute inside the task container while the actual agent CLI still ran on the host.

That meant a supposedly containerized workflow was partially split across environments.

Now, when a task defines a container image, the agent itself runs inside that container as well.

That gives the workflow a much cleaner execution boundary:

task
 └── container
      ├── agent
      ├── commands
      ├── checks
      └── task environment

The transcripts, cost tracking and controls remain available just like they are for host execution.

Talk to a task after it stops

A workflow stopping does not necessarily mean the work is finished.

Sometimes a task is blocked.

Sometimes it is sitting at a gate.

Sometimes it failed in a way that needs investigation.

0.9 adds the ability to open a conversation with an agent directly on that task.

The agent starts with the task context, its branch and the reason execution stopped.

So instead of reconstructing the problem somewhere else, you can investigate it where the work actually happened.

Parallel workflows got harder to break

0.8 introduced fan-out workflows: one task could split an issue into multiple parallel lanes.

0.9 contains the first substantial reinforcement of that system.

Previously, blocked lanes could make the fan-out painful to recover.

Now retrying the parent task can re-admit all blocked lanes below it.

Vincent also tracks resource usage across the whole task tree more accurately, including a new tree-wide spending ceiling:

parent task
├── lane A
├── lane B
├── lane C
├── retries
└── follow-ups

        ↓

one shared cost limit

That matters once a single user action can produce a substantial amount of autonomous work.

Better observability into what the agent actually received

Agent orchestration becomes difficult to debug when configuration comes from several levels.

What model ran?

What effort level?

What exact prompt was rendered?

Was the value set globally, in the workflow or on the step?

0.9 adds a Step Details view that records the actual values when execution happens.

That includes:

• rendered prompt or script
• agent
• model
• effort level
• source of each configuration value
• execution outcome

Older task attempts are not retroactively guessed.

If vincent did not record something at the time, it says so.

That sounds small, but I think this kind of honesty in tooling matters.

A lot of 0.9 is about refusing invalid states

There is a pattern throughout this release.

Vincent now refuses more operations that previously could have been ambiguous or silently incorrect.

For example:

• unsafe PR merges are refused
• trigger proposals cannot secretly arm automation
• invalid retry configuration on unsupported workflow steps is rejected
• conflicting TUI keybindings are rejected before being written
• branches with commits beyond their base are protected from permanent deletion

That leads to one of the principles behind this release:

Much of a stable release is a promise about what the tool will refuse to do.

Features make automation powerful.

Refusals make it trustworthy.

Better recovery and operational tooling

There are plenty of smaller changes around the edges too.

Scheduled backups can now be maintained by the daemon.

Individual deleted tasks can be restored from an archive.

Agent usage limits are tracked more carefully so multiple tasks do not repeatedly launch processes into a known quota wall.

vincent doctor performs more useful diagnostics.

vincent agents shows installed agent versions, authentication state and quota information.

And vincent can now detect when its installed agent skills are older than the running build.

None of these features make a particularly dramatic screenshot.

They do, however, make a system considerably nicer to operate.

Vincent is building vincent

One metric from this release probably says more about the project than anything else.

Between the 0.8.0 and 0.9.0 tags, 88 pull requests were merged.

76 originated from vincent/ task branches.

The 0.9 release preparation itself was also executed as a vincent workflow: 21 steps that eventually produced the PR used to prepare the release.

Using your own orchestration system to build itself is an extremely effective way to discover where the abstractions break.

And they do break.

0.9 contains plenty of fixes precisely because vincent is now exercising those workflows every day.

The road to 1.0

Vincent is still 0.x.

Some interfaces still change.

Some workflow configurations that previously failed silently are now errors.

Some TUI keys moved to make behavior consistent.

That instability is intentional while the foundations are still being hardened.

For me, the important change in 0.9 is that vincent is starting to feel less like a tool that happens to run coding agents and more like an actual control plane for agent-driven software work.

Something can observe an event.

Decide that work may need to happen.

Create a controlled task.

Run agents in isolated environments.

Fan the work out.

Verify the results.

Produce a pull request.

And then stop at the boundary where a human decision still matters.

That is the direction I want to keep pushing toward 1.0.

---

📖 Full 0.9.0 release write-up

https://blog.lezli01.is-a.dev/blog/vincent-0-9-release/

💻 GitHub

https://github.com/lezli01/vincent

Feedback, issues and contributions are very welcome.