AI coding agents have become surprisingly capable.
But once I started using them seriously, I ran into a different problem:
Starting an agent is easy. Managing many of them isn't.
A few tasks quickly turned into multiple terminals, repositories, branches, prompts, transcripts and agent sessions. I wanted to be able to start work, leave it running, see what every agent was doing, enforce deterministic checks, intervene when necessary, and switch between different agent providers without redesigning the whole workflow.
So I built Vincent.
👉 https://github.com/lezli01/vincent
Vincent stands for:
Vendor-independent co*ntrol plane for executing native agent* tooling.
It is an open-source, MIT-licensed, local-first orchestrator for AI coding-agent workloads.
The idea
Vincent isn't another coding agent.
Instead, it sits above the agents you already use.
Currently it can execute:
- Claude Code
- OpenAI Codex
- Cursor Agent
Vincent uses their native CLIs and the authentication already configured on your machine. It doesn't try to replace them and it doesn't need to store their credentials.
The architecture is centered around a local daemon:
┌─────────────┐
│ TUI │
└──────┬──────┘
│
┌──────▼──────┐
CLI / scripts ──►│ Vincent │◄── REST / SSE
│ daemon │
└──────┬──────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Claude Code Codex Cursor Agent
The daemon owns the state, scheduling and execution.
That means I can close the TUI or terminal and the tasks continue running.
Workflows instead of giant prompts
One of the biggest things I wanted was to avoid solving everything with one enormous AI prompt.
Vincent workflows are YAML and can mix agentic steps with deterministic operations.
A workflow can contain things like:
- agent prompts
- shell commands
- verification checks
- conditions
- loops
- parallel execution
- isolated fan-out
- reusable workflow includes
- human approval gates
Conceptually, you might have something like:
steps:
- name: implement
agent: codex
prompt: |
Implement the requested change.
- name: test
run: go test ./...
- name: fix
if: previous.failed
agent: codex
prompt: |
The tests failed.
Fix the implementation based on the failure.
The important part isn't the exact syntax here.
It's the separation of responsibilities.
If a compiler, test runner, linter or script can determine something reliably, I don't want to spend AI tokens asking an LLM to do it.
Use agents where reasoning is useful. Use normal software everywhere else.
Checks, not claims
This led to another important design decision.
An agent saying:
"I've completed the task and all tests pass."
doesn't mean the task succeeded.
Vincent can use deterministic checks to decide that.
If a check fails, the actual failure can be fed back into the next attempt.
So instead of:
Agent: looks good!
Task: success
the model becomes closer to:
Agent makes change
↓
Run real verification
↓
success?
/ \
yes no
↓ ↓
next retry with
step real failure
This makes agent execution much more useful for unattended workloads.
Every task gets its own worktree
Parallel agents modifying the same checkout is a great way to create chaos.
Vincent isolates development tasks using Git worktrees.
Each task gets its own:
- worktree
- branch
- execution state
- transcripts
- step history
So multiple tasks can operate against the same repository without competing over the developer's working tree.
You can also configure global and project-level concurrency limits.
Humans are still part of the workflow
I don't think autonomous should mean uncontrollable.
There are situations where I explicitly want an agent to stop.
Vincent supports human gates, blocked tasks and intervention.
For example, a workflow can require approval before something sensitive happens.
If an execution fails, I can inspect the result and decide whether to:
- retry it
- edit and retry
- repair it with another agent
- skip the step
- abort the task
There are also follow-up runs, so after an agent finishes a task I can ask it to make another change on the same branch and worktree without reconstructing the context manually.
A TUI for watching the factory
Vincent includes a terminal UI because once several workloads are running, visibility becomes important.
The TUI gives me a central view of:
- running and queued tasks
- workflow steps
- live agent output
- duration
- token usage and cost
- blocked tasks
- projects
- workflows
- agent availability
It's essentially the dashboard I wanted when I started running multiple coding agents simultaneously.
Crash recovery matters
This is one of the less glamorous parts of agent tooling, but probably one of the more important ones.
What happens when the orchestrator crashes halfway through a 30-minute agent task?
Vincent is designed around durable state.
Transitions are persisted, interrupted executions can be reconciled after restart, transcripts are retained, and tasks don't simply disappear because the UI closed.
I've tried to treat agent workloads more like real jobs running on an execution platform than temporary terminal sessions.
Vendor independence
I also deliberately don't want workflows tightly coupled to a single AI vendor.
An individual workflow step can choose an agent, model, reasoning effort and permissions.
That means one workflow could theoretically use different models for different parts of the job.
It also means switching your preferred agent doesn't require throwing away the orchestration layer around it.
It works from more than the TUI
The TUI is useful for humans, but Vincent isn't TUI-only.
Operations are also available through the CLI and a localhost REST + SSE API.
For example:
vincent project add /path/to/repo
vincent task add \
--project 1 \
--title "Add a health endpoint"
vincent task ls --state running
vincent workflow validate \
.vincent/workflows/feature-pr.yaml
Commands support JSON output as well, so Vincent itself can become part of larger automation.
Installing it
On macOS:
brew install lezli01/tap/vincent
On Windows:
winget install --id lezli01.Vincent --exact
or:
scoop bucket add vincent https://github.com/lezli01/scoop-bucket
scoop install vincent/vincent
With mise:
mise use -g github:lezli01/vincent
There are also deb/rpm packages and standalone binaries for Windows, macOS and Linux.
Why I open sourced it
Agentic development is moving extremely quickly.
I don't think the interesting problem anymore is simply:
"Can an LLM write this function?"
The problem I'm increasingly interested in is:
"How do we turn AI agents into reliable, observable and controllable software-engineering workloads?"
That involves scheduling, isolation, verification, retries, state management, human gates, observability and cost management.
In other words, a lot of familiar software engineering problems — just applied to a new kind of worker.
Vincent is my attempt at building that layer.
It's still pre-1.0 and evolving quickly, but I already use it for my own development workflows.
The project is now MIT licensed, so you're free to use it, modify it, build on it or contribute.
If this problem sounds familiar, I'd love to hear how you're currently managing multiple coding agents.
And if you want to try Vincent:
⭐ GitHub: https://github.com/lezli01/vincent
📖 Documentation: https://lezli01.is-a.dev/vincent/
Feedback, issues and contributions are very welcome.
Top comments (1)
The "checks not claims" section is the part that makes this actually useful for any real workload. We went through a painful period where agent success messages weren't correlated to actual outcomes, and we only caught it because we had an integration test suite that ran regardless of what the agent reported. The worktree isolation is also the right call - we hit merge chaos early on when we ran multiple agents against a shared checkout. The follow-up runs on the same branch without reconstructing context is the feature I'd have wanted most six months ago.