Vincent v0.7.0: Better visibility, stronger automation, less babysitting

Vincent v0.7.0 introduces significant improvements to its agentic development workflow platform, focusing on better visibility and automation. The update adds a full-screen task workspace, configurable external notifications, and new CLI commands for task management, making it easier to operate agents without constant TUI monitoring. It also includes per-task spending limits and GitHub issue integration.

Vincent v0.7.0 is out. This release is mainly about one thing: Making agentic development workflows easier to operate when you are not staring at them. As Vincent has grown, simply starting an agent has become the easy part. The harder questions are: v0.7.0 tackles a lot of that. The TUI received one of its biggest UX improvements so far. Opening a task now takes you into a dedicated full-screen workspace with separate views for: Attempt selection follows you between views, outputs can be switched between retries, and failed attempts expose their result summary directly in the timeline. The main task board can now stay what it should be: a board. The details live where they belong. A running step can now publish its own status: vincent status "Running integration tests" That status becomes visible in the TUI and is also available through the API. This sounds like a small feature, but it changes the experience of running longer workflows quite a bit. Instead of: running... you can see something closer to: » Investigating the failing authentication test or: » Waiting for the GitHub checks to complete Agent steps also receive the VINCENT environment variables that command and check steps already had, so agents can report their own progress through their shell tools. Previously, Vincent could ring the terminal bell when a task reached an interactive state. That is useful — assuming the TUI is open. v0.7.0 adds configurable external notifications. You can run a command whenever a task enters states such as: notify: command: - notify-send - "Vincent needs attention" on: - blocked - awaiting input - awaiting gate - done Vincent passes a JSON payload to the command, including information about the task and the transition. Because this is command-based rather than tied to a specific notification provider, you can integrate it with whatever makes sense for your setup: The important part is that a task can now run in the background and actively tell you when human involvement is useful. A major goal of this release was reducing the dependency on the TUI for operational tasks. vincent task now includes commands for actions such as: vincent task pause vincent task resume vincent task skip vincent task approve vincent task reject vincent task retry vincent task repair vincent task archive vincent task answer This makes Vincent much easier to use from: For example, blocked tasks can now be discovered and retried programmatically: vincent task ls --state blocked --json \ | jq -r '. .id' \ | xargs -n1 vincent task retry The TUI remains useful for interactive work, but it is no longer the only practical control surface. Two new commands make debugging and remote operation significantly easier: vincent daemon logs and: vincent task transcript <task-id Daemon logs are read directly from disk, so they still work even if the daemon itself is unavailable. Task transcripts can be viewed as human-readable output, NDJSON, or raw agent JSONL. That makes it much easier to inspect what happened inside an attempt without digging through Vincent's data directory manually. Vincent can now create a task from a GitHub issue. For projects connected to GitHub, Vincent can pull in: Workflow fields can also be populated from issue metadata when their definitions match. This is a particularly useful bridge between traditional development workflows and agentic execution. An issue can increasingly become the starting point for a reproducible workflow rather than merely a description of work waiting for someone to pick it up. v0.7.0 also introduces per-task spending limits. That means autonomous workflows can have explicit boundaries around how much agent execution they are allowed to consume. For long-running or heavily automated workflows, this is an important safety mechanism. Autonomy is much more useful when it comes with limits. Workflow authors also get some useful additions. Create a starting workflow: vincent workflow init And render a workflow template without running it: vincent workflow render The latter is especially useful when building workflows with fields and templates because you can validate the generated result before actually executing anything. There is a lot more in this release, including: You can find the full list in the changelog. The goal with Vincent is not to build another chat UI around an LLM. I want the unit of work to be a workflow . Agents are one tool inside that workflow, alongside commands, checks, control flow, human gates, retries, parallel execution, and deterministic automation. And increasingly, I want those workflows to be able to run without requiring constant supervision. v0.7.0 is a fairly big step in that direction. If you're experimenting with agentic software development, I'd love to hear what kinds of workflows you're building. Full changelog: https://lezli01.is-a.dev/vincent/changelog.html https://lezli01.is-a.dev/vincent/changelog.html