WARRANT

SPLITTING TASK INTO SUBTASKS
SUBTASKS IN ACTION WITH THEIR RESPECTIVE AGENTS
START / APPROVE SUBAGENT'S EDITING WORK TO BEGIN
record of decisions made by all subagents
merge gate -> merging the work done by all subagents after completion
VERSION CONTROL
LIVESHARING FEATURE

Inspiration

Look at how a team actually ships code right now. Four people, four branches, four different local language models writing four slices of the same repo. Everyone is already doing agentic development. They're just doing it alone, in parallel, and hoping it reconciles at the end.

The tools haven't caught up. Git was designed for humans taking turns: you take your copy, you go away, you come back and argue about the diff. VS Code was designed for one person looking at one file. Live Share got two humans typing together, and stopped there. None of them have an answer for the thing everyone is now doing anyway: several agents writing into one project at the same time, each on behalf of a different person.

So the reconciliation happens the worst possible way: after the fact, in a pull request, where nobody can tell which model wrote which line, whose prompt caused it, or whether the person accountable for that file has even seen it.

We wanted to find out what an editor looks like if you assume that from the start. Not an AI sidebar bolted onto an IDE, and not another orchestration framework, but the collaborative layer underneath, where several people's agents can work the same codebase at once without it turning into chaos.

What it does

It's a workbench where a task fans out across people, and their agents do the work in the open.

You split a task, and it becomes subtasks with owners. Each subtask gets one accountable human and one agent acting for them. That agent is allocated its own section of the shared file and cannot write outside it, checked on the diff, inside the write itself, not suggested in a prompt.

You watch it happen. Live screens show each agent's own copy of the file changing as it writes, polled from the real workspace on disk. There's no fabricated cursor, because between two file states the runtime reports no position because the region that changed is the position, and that's honest.

Every line knows who wrote it. Attribution is computed during the write, not reconstructed afterwards. Turn on blame and the file tells you which agent is responsible for which line.

So review works like review. Select lines, leave a comment, and it routes to the agent that actually wrote them.
Send it back and that agent revises through the same write path as any other change, subject to the same merge and authorization rules. The comment reads "addressed" only because the platform accepted the revision, and "stale — code moved" when the lines shifted underneath it.

Nothing merges until its owner signs off. The merge gate stays shut until every agent is approved by the human accountable for it, with nothing contested. The orchestrator combines the result and holds no authority over any workspace of its own.

And underneath all of it, delegation is real. Every agent acts under a scoped, expiring, revocable warrant from one human. Try to run someone else's agent and you get a 403 naming the rule that refused you. Changing the user id in the request doesn't change the answer, because the id is never read from the request. An owner can revoke a warrant mid-flight and the next action is refused before anything runs.

When two agents legitimately touch the same lines, you get a real three-way merge with the contested ranges marked, and you choose: yours, theirs, or both. No silent lost updates. Every decision along the way lands in a hash-linked audit chain, so afterwards you can prove what was allowed and in what order.

How we built it

React 19 with Monaco for the editor, Fastify and Zod for the control plane, and Codex CLI against the Volcengine Ark Responses API driving the agents. Live state reaches the browser over SSE.

Monaco was something we knew was behind one of the layers that make up Visual Studio Code as an editor. We'd refused it in an earlier pass, when the editor was read-only and it would have been weight for nothing. Once the file became something you type into, with decorations carrying section ownership, blame and live edit regions, hand-rolling that was more work than integrating it and the whole pitch is "an editor that was not built for this".

The architectural decision that mattered was refusing to put any of this in the browser. The client sends a session token; identity is derived from it on the server. Section ownership is evaluated inside the write's critical section, so two agents racing on one file can't interleave past it. Attribution is computed during that same write. A browser cannot claim a comment refers to code that was never there, cannot aim feedback at an agent that didn't write the lines, and cannot get a revision into shared state by any path that skips the merge logic.

We watched each agent's workspace by polling stat every 250ms rather than using filesystem watch events, because fs.watch fires either twice or never on several WSL and container filesystems which is exactly where this runs. Boring and portable beat clever.

Challenges we ran into

The whole flow was unreachable, and only a demo found it. A finished turn returns a subtask to "assigned" on purpose, finishing work isn't the same as proposing it. But nothing in the client ever called the endpoint that proposes it. So Approve always answered "not submitted", and the merge gate the entire product builds toward could not be opened by anyone. Everything typechecked. Every unit test passed. It took walking the flow end to end as a stranger to see it.

Every local turn hung for exactly ten minutes. The agent runtime was pointed at an internal service address that only resolves on the container network, so outside a container it resolved nowhere. It didn't fail, but it hung, which shows up as a demo that freezes rather than an error anyone can read. The fix was asking a second question at the call site: not just "is that service up" but "where is the agent actually going to run".

Sandbox containment that fires on innocent work. Our own sandbox derives file and network intent by scanning shell command text, and shell text can't be parsed reliably. It contained four out of four turns that were doing nothing wrong. We wrote it up as an open structural issue rather than quietly widening the policy until the demo passed.

Concurrency in the UI, not just the backend. Two agents can genuinely run at once, but the interface serialised them, because the request that starts a turn waits for the whole turn and holds the board busy. The backend was ready for parallelism before the front end was.

And one that was pure humility: a CSS rule from an unrelated component won the cascade and rendered an agent's description one character wide down the side of its card. It typechecked perfectly.

Accomplishments that we're proud of

-The collaboration story is enforced, not asserted. Section ownership, attribution and the merge gate are all backend decisions with rule ids that show up in the refusal, the audit chain, and the tests.

Review actually routes. Commenting on a line and having the agent that wrote it answer with a status that reflects what the platform decided, not what the UI hoped.
589 automated tests, including property-based fuzzing of the merge and attribution algorithms. It found real bugs: a lone surviving blank line silently losing its provenance, for one. We pinned those as failing tests that name the file and line, rather than hiding them.
Two of our worst bugs were caught by tests we wrote to describe problems we hadn't fixed yet. One of them predicted the ten-minute hang before a human hit it.
The orchestrator has no master key. Giving it one would have been easier and is exactly the confused-deputy shape worth avoiding. -One line from clone to running, identical on macOS and Linux.

What we learned

Multi-agent collaboration is a state problem before it's a model problem. We expected the hard part to be prompting and orchestration. It wasn't. The hard parts were: who is allowed to change this, what happens when two of them do it at the same moment, and how do you know afterwards who did what. Those are questions version control and editors have never had to answer at this granularity, because until now only one entity was typing.

We also learned that "acting on your behalf" is where the danger hides. The convenient implementation gives an agent your whole identity, so N agents means N copies of you. Making delegation strictly narrower than the delegator, with an expiry and a revocation path, changed the design everywhere it touched.

And building the demo was the best test we wrote. Two serious bugs were invisible from inside the code and obvious the moment we tried to be a first-time user.

What's next for WARRANT

Real editing presence. Multiple humans and their agents in one buffer, with the same ownership rules as the Live Share case, except the other participants aren't people.
Meet teams where they already are. A VS Code extension, so this layer sits under the editor people actually use, and a git-native path so a merged task lands as a reviewable branch with attribution intact.
Real identity to replace the mock principals, and an exportable audit chain a reviewer can verify independently. ```