vincent: a local-first control plane for AI coding agents

A developer has released Vincent, an open-source, local-first control plane for AI coding agents. Vincent orchestrates agents from providers like Claude Code, Codex, and Cursor Agent, allowing users to manage multiple agent sessions, enforce deterministic checks, and intervene when necessary. The tool uses YAML workflows to mix agentic steps with deterministic operations and Git worktrees for task isolation.

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 https://github.com/lezli01/vincent Vincent stands for: V endor- i ndependent co n trol plane for exe c uting na t ive ag ent 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 https://github.com/lezli01/vincent 📖 Documentation: https://lezli01.is-a.dev/vincent/ https://lezli01.is-a.dev/vincent/ Feedback, issues and contributions are very welcome.