As AI coding agents become more capable, I think we need to rethink one assumption that still shapes a lot of developer tooling:
The terminal session that starts the work should not necessarily own the work.
For short interactions, the traditional model is perfectly fine:
open terminal
→ start agent
→ ask for something
→ get result
→ exit
But agentic development is moving beyond short conversations.
Tasks can now involve:
- retries
- approval gates
- parallel branches
- long-running implementation work
- rate limits
- scheduled execution
- external validation
- Git worktrees
- multiple agents
- human intervention halfway through a workflow
At that point, the task starts looking less like a chat session and more like a workload.
The terminal is ephemeral
Terminal sessions are temporary by nature.
You close the tab.
Your SSH connection drops.
Your laptop sleeps.
You restart the application.
You simply want your terminal back for something else.
None of those things should necessarily mean that the underlying work has to disappear with it.
That is the distinction I wanted to make in vincent.
The execution should live somewhere durable
In vincent, workflow execution is owned by a background daemon.
That layer is responsible for things such as:
- workflow state
- agent processes
- scheduling
- persistence
- retries
- approvals
- Git worktrees
- task lifecycle
The TUI, CLI and API are clients of that state.
They let you inspect and interact with the work, but they do not define its lifetime.
Conceptually:
CLI
│
│
TUI ── Control Plane ── API
│
│
Agent Workloads
Close the TUI and the workload can continue.
Reconnect later and you can inspect the same task again.
Use another client and you are still looking at the same underlying execution state.
Why I think this matters
As coding agents become more autonomous, the distinction between interface and execution lifecycle becomes more important.
We already accept this separation in many other areas of software engineering.
A Kubernetes workload does not disappear because you close kubectl.
A CI pipeline does not stop because you close the browser tab.
A background job does not belong to the shell command that originally enqueued it.
So why should a long-running AI engineering workflow belong to one terminal process?
Agentic coding is becoming infrastructure
The more responsibility we give coding agents, the more orchestration concerns start appearing:
state
retries
concurrency
approval
scheduling
recovery
observability
persistence
Those are not really terminal concerns.
They are control-plane concerns.
And I think developer tools built around agents will increasingly need to treat them that way.
The terminal still matters
None of this means the terminal is going away.
Quite the opposite.
The terminal is still one of the best interfaces for developers.
But there is an important difference between:
"The terminal controls the workload."
and:
"The terminal owns the workload."
I strongly prefer the first.
The terminal should be a window into the system.
Not the system itself.
I wrote more about the reasoning and the architecture behind this approach in the vincent documentation:
👉 https://lezli01.is-a.dev/vincent/docs/why/the-terminal-should-not-own-the-work.html
Vincent is an open-source project exploring workflow-driven, human-controlled AI software development.
I’m curious how other agent frameworks and developer tools approach this problem.
Should long-running coding agents belong to the terminal session that launched them, or to a durable orchestration layer behind it?
Top comments (1)
Treating the terminal as a client also makes recovery semantics much clearer. The durable workload should expose a monotonic event log and explicit states such as waiting-for-approval, outcome-unknown, and completed, rather than trying to reconstruct truth from terminal output. Then reconnecting is a read of current state, not a fresh agent guessing where the old session stopped.