Conduit: The Work Around the Agent

There is a simple test for any tool that claims to work for you:

What does it leave behind?

If the answer is a long chat, it produced a conversation. Software teams need more: a branch, a diff, a test result, a pull request, and a record of what happened between the instruction and the outcome.

That is why I built Conduit.

Conduit gives coding agents the environment around real work. You can start a task from the web or Slack. Conduit creates an isolated cloud workspace, connects it to the selected repository, records the run, and returns the result for review.

The model matters. It is not the whole product.

The instruction becomes a session

Suppose you ask Conduit to fix a mobile navigation bug.

Conduit first writes the session, your message, and the initial lifecycle event to PostgreSQL. The session begins as pending. The API then places a run_session job on Amazon SQS and returns the session to the browser.

The browser does not wait for a sandbox to start or a repository to clone. A separate worker handles that long-running work.

This split is practical. Agent work does not fit inside a normal web request. Infrastructure has to start, credentials may need refreshing, a repository has to be prepared, and the engine returns output over time.

Starting work and completing work are different facts. Conduit stores them as different states.

The agent gets a boundary

The worker creates a cloud sandbox. Modal is the current provider, but the session runner talks to a SandboxProvider interface rather than Modal directly.

The same boundary exists for the coding agent. Claude Code, Codex, and OpenCode implement one AgentEngine contract. The runner can start an engine, resume its conversation, receive events, wait for the result, or stop the run.

For a repository session, Conduit prepares a real checkout, configures Git credentials, and records the base commit for review. Attachments and enabled organisation skills are copied into the workspace before the engine starts.

The agent can inspect the repository, edit files, run project commands, and use Git. Your laptop is not that environment. A new session gets its own filesystem and processes.

This prevents one task's installed packages, generated files, or running services from quietly becoming another task's starting point.

The live stream is not the source of truth

Each engine produces events in its own format. Conduit translates them into a smaller set the interface understands: lifecycle changes, assistant text, activity, diagnostics, file diffs, screenshots, authentication prompts, and pull-request artifacts.

More importantly, every event is written to PostgreSQL with a sequence number before Conduit publishes a wake-up through Redis Pub/Sub.

Redis tells the interface that something changed. PostgreSQL says what changed.

The browser keeps a Server-Sent Events connection open and remembers the last sequence it received. If the connection drops after event 41, it reconnects with after_seq=41. The server reads events 42 onward from PostgreSQL and sends them in order.

The timeline can recover because its history does not live inside the live connection.

A typing indicator says something is happening. A durable event log shows what happened after you looked away.

Completion has a shape

When the engine exits successfully, Conduit stores its final response and redacted diagnostic output. It then examines the repository.

If the working tree changed, Conduit records a review diff. If the agent moved to a non-default branch, it records the branch. If a pull request exists for that branch, it attaches the URL, title, and branch to the session.

The coding agent owns branch creation, commits, pushes, and pull-request creation. Conduit detects and records those results. It does not claim a pull request that was never opened.

For interface work, a repository can provide .conduit/preview.sh to start its services inside the sandbox. The agent can inspect that preview with Playwright, capture a screenshot, and attach it to the same timeline.

The result is not only the agent saying that the page is fixed. The reviewer can inspect the changed files, the running application, the screenshot, and the pull request when one exists.

The session continues

After a completed message, the session becomes idle. A follow-up reuses the available checkout and resumes the same engine conversation.

If you send another instruction while the agent is running, Conduit requests cancellation of the active message and runs the newer pending message next.

If the old sandbox is unavailable, Conduit creates a replacement. It clones the recorded session branch when one exists, otherwise the default branch, and provides a bounded set of earlier messages as context.

The filesystem is disposable. The branch and conversation record are durable.

Conduit does not make a successful engine exit equal a correct change. It does not merge at the end of the session lifecycle. Completion means the run finished, the result was stored, and the available Git artifacts were collected. Acceptance remains a separate decision.

That is the point of Conduit:

Give the agent a clean place to work

Keep an ordered record of what it does

Return an outcome a human can inspect