Sandeep Barhanpuresandeep@terrainailabs.comLinkedInGitHub

← Projects

Traverse

A workspace for coordinating coding-agent work. Planned for November 2026.

October 2026

Who it is for

A developer or operator coordinating coding agents across repositories, worktrees, sessions, reviews, and CI.

The problem

Assigning work to several agents creates coordination work: defining permitted files, following sessions, identifying blockers, and checking whether review and test evidence applies to the work being released.

How it is used

The intended workflow starts with a repository and a task with explicit file scope. The operator follows progress and blockers, reviews the evidence, and makes the release decision.

Controlled agent creation and delegation are planned parts of that workflow. They are explicitly disabled in the current prototype.

The Traverse board, showing a demo workspace with synthetic tasks, October 2, 2026
The Traverse board for a demo workspace. A sidebar lists three projects, notes-web, Scratch and sync-service, with their tasks. The board has four columns. Idle and Working holds one idle task, “Upgrade the date library and pin it”, and four working tasks such as “Add keyboard shortcuts to the note editor”. Needs you holds “Fix flaky timezone test in the scheduler”, marked input needed. In review holds two tasks with open pull requests. Ready to merge and Merged holds “Add rate limit headers to the public API”, ready, and “Fix dark mode contrast on the settings page”, merged. Each card shows its branch name and when it last changed.

Demo data, not a recorded run. Agent creation stays disabled in the current prototype.

One synthetic task from the same demo workspace, October 2, 2026
One demo task, “Add rate limit headers to the public API”. The center shows the agent transcript: the request, a search for the rate limiter, reading and updating the middleware file, writing a test file, a passing Go test run, opening a pull request, and a summary that the headers are set and checks pass. The right panel shows that pull request, open and ready to merge with checks passing, two session controls, and the activity: workspace created, pull request opened, then idle.

Demo data, not a recorded run. Agent creation stays disabled in the current prototype.

Constraints and decisions

The prototype has to distinguish observing work from authorizing a change. A session can be visible in the workspace without the operator having approved a new agent, worktree, or delegated task.

The current decision is to keep mutable agent creation disabled while the authorization path is unfinished. The design builds on a pinned upstream runtime and adds governance around it. The record does not establish a formal comparison of alternative runtimes.

How it works

An early local desktop prototype integrates repository registration and runtime observation. It can observe sessions, terminals, files, pull requests, and CI, with policy boundaries around the work.

The prototype uses a pinned Apache-licensed upstream runtime with Terrain governance around it. It is not a wholly original runtime.

Traverse: observation and planned execution
Traverse: observation and planned executionThe operator selects a repository and defines scoped work. Controlled execution is planned and disabled today. The operator inspects progress, review, and CI evidence before making a release decision.Select repositoryTask + permitted filesCurrent prototypeAuthorize executionAgents and worktreesPlanned; disabled todayReview the workProgress, review + CIHuman release decision
Read the workflow as text
  1. Select repository. Task + permitted files. Current prototype.
  2. Authorize execution. Agents and worktrees. Planned; disabled today.
  3. Review the work. Progress, review + CI. Human release decision.
Step through the diagram
Traverse: the intended workflow and what is built
The dashed box is planned and disabled in the current prototype. Shaded boxes are the operator’s steps.

The dashed box is planned and disabled in the current prototype. Shaded boxes are the operator’s steps.

Open diagram at full size
Read the workflow as text
  • Operator: repository and a task with explicit file scope.
  • The prototype starts with repository registration.
  • On a pinned Apache-licensed upstream runtime with Terrain governance, it can observe sessions, terminals, files, pull requests and CI, within policy boundaries.
  • Agent creation and delegation: planned; disabled today.
  • Operator: follow progress, review the evidence, decide the release.

Current state and planned work

Built: early local desktop/runtime integration, repository registration, observation of development activity, and policy boundaries.

Still under development: controlled mutable agent execution and the authorization path. No public availability, adoption, or performance result is claimed.

I plan to build Traverse in November 2026. That is a development plan, not a confirmed launch date.

Learnings

What I learned: the earlier Harness work showed that file scope and approval freshness need explicit checks. Historical passing tests also need to be tied to the files actually in use.

What changed: Traverse carries those lessons into its policy boundaries. Mutable agent creation remains disabled while authorization is unfinished.

What to test next: verify authorization end to end before enabling execution, then check whether review and CI evidence remains bound to the exact work a human is releasing. These are proposed validation steps, not Traverse outcomes.