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:
V endor-i ndependent con trol plane for exec uting nat ive agent tooling.
It is an open-source, MIT-licensed, local-first orchestrator for AI coding-agent workloads.
Vincent isn't another coding agent.
Instead, it sits above the agents you already use.
Currently it can execute:
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.
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:
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.
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.
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:
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.
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:
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.
Vincent includes a terminal UI because once several workloads are running, visibility becomes important.
The TUI gives me a central view of:
It's essentially the dashboard I wanted when I started running multiple coding agents simultaneously.
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.
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.
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.
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.
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.