CLI coding agents have become genuinely useful, quickly. Claude Code, Codex, Gemini and OpenCode can take a described task and produce working code against a real repository. Most engineering organizations have quietly adopted them, one laptop at a time.
Which is where it gets interesting for anyone responsible for the platform, because that adoption pattern has a familiar shape: powerful capability, credentials on individual machines, no shared telemetry, no cost attribution, and no way to answer basic questions about what ran where.
But the operational gap is only half of it. The more interesting half is that a raw CLI agent starts every conversation from zero — no memory of your company, your codebase standards, or anything it worked out last week.
Worker and session are different things
The distinction that makes the rest make sense: a worker is a definition, and a session is an instance of it running.
A worker is closer to a job description than to a process. It carries a role, a knowledge base, a set of skills, and a choice of CLI — and it runs nothing until you start a session from it. Many sessions can run from one worker definition at the same time, each with its own workspace.
curl -X POST http://vwm-service/admin/workers \
-H "Content-Type: application/json" \
-d '{
"name": "code-reviewer",
"description": "Security-focused code reviewer",
"runtimeId": "rt-abc123...",
"cliType": "claude-code",
"agentMd": "You are a security-focused code reviewer.\nLook for OWASP Top 10 vulnerabilities.\nAlways explain your findings with severity ratings.",
"workerRepoUrl": "https://github.com/org/code-reviewer-kb",
"workerRepoBranch": "main",
"autoLearn": true,
"timeout": 3600
}'
Two fields there are doing more work than the rest. workerRepoUrl points at a git repository
that is the worker's institutional knowledge — engineering guidelines, company context, the tribal
knowledge a new colleague would need. It is version-controlled and reviewable, like everything else that
matters.
autoLearn is the compounding one. With it on, the worker captures what it learned at the end of
each session and feeds it into the next. The difference between a worker on its first task and the same
worker three months later is the point of the design.
Sessions carry a workspace, and a trail
Creating a session provisions a container with the worker's full context and clones the repository you want worked on. Note that this is a second repository: the knowledge base and the task workspace are deliberately separate, so what the worker knows does not get tangled up with what it is currently changing.
curl -X POST http://vwm-service/sessions \
-H "Content-Type: application/json" \
-d '{
"workerId": "wk-def456...",
"repository": {
"url": "https://github.com/org/my-project",
"branch": "feature/new-auth"
},
"breadcrumbs": ["ticket-123", "sprint-42"]
}'
breadcrumbs is small and worth copying. It ties the session to your ticket and your sprint, so
when someone later asks what this cost or why this change exists, the telemetry has an answer that means
something to a human.
The session starts pending while the pod comes up and the harness signals readiness, then goes
active. The workspace persists for the session's lifetime, so the worker holds context across
many prompts rather than re-reading the world each time.
Prompting, and what comes back
curl -X POST http://vwm-service/sessions/sess-jkl012.../prompt \
-H "Content-Type: application/json" \
-d '{
"prompt": "Review the authentication module in src/auth/ for security vulnerabilities. Focus on session management and token validation.",
"timeout": 120
}'The response is the part a platform team cares about:
{
"requestId": "req-mno345...",
"response": "I've reviewed the authentication module and found 3 issues:\n\n1. **High Severity** - Session tokens are not invalidated...",
"tokensIn": 1250,
"tokensOut": 890,
"durationMs": 15420
}Tokens in, tokens out, duration, and a request id — per prompt. That is the difference between "the AI spend went up this month" and knowing which worker, on which ticket, in which sprint. There are streaming (SSE) and asynchronous forms of the same call for long-running work, so a multi-minute task does not have to sit inside one HTTP request.
Why this belongs in the platform
Running a coding agent on your laptop is using it. Running fifty across an organization is an operations problem with all the usual parts: credentials that have to live somewhere managed, workspaces that outlive a container, spend that has to attribute to something, output that has to be reconstructible afterwards, and sessions that someone has to reap.
None of that is exotic. It is the same list you would write for any other workload. The difference is that coding agents arrived through developers rather than platform teams, so they skipped the step where somebody asks these questions first.
Being CLI-agnostic matters for the same reason model-agnosticism does. Different coding agents have real and changing strengths, and pinning an organization to one is the same mistake as pinning it to one model provider. New agents arrive as adapters without changing how your workers, sessions or knowledge bases work.
What this is not
Two honest clarifications, because this space attracts overclaiming.
It is not a replacement for your developers' local tooling. Developers should keep using whatever agent suits them at their own terminal. Virtual Workers are for the cases where a coding agent needs to run as part of a system — triggered by a workflow, operating on a shared workspace, producing output something else consumes — rather than under a person's supervision.
It is not autonomous engineering. A managed session is still doing what it was asked, and the quality of the result still depends on how well the task was specified. What the platform adds is not judgement. It is somewhere accountable to run these things, and a record afterwards of what happened.
The test that generalises
The useful question about any new capability is not whether it can be solved per team — coding agents obviously work fine on laptops — but whether every team should have to solve the operational half independently.
Credential handling, cost attribution, session lifecycle, telemetry and knowledge retention are the same problems whichever agent you run and whichever team runs it. Solving them once, in the environment, is the whole idea.
See how this fits the wider model in Introducing FireFoundry, or explore the platform.