AI coding agents have changed what a single person can get done in a day. You describe a change, and an agent reads the code, edits files, runs the checks, and comes back with a result. Tools like Claude Code and Codex have made this part of everyday work for a lot of people, including us.
The agents got good quickly. The way we work with them has not caught up yet.
Where the friction is
We kept running into the same handful of problems.
The work is stuck on one machine. An agent session lives in a terminal on the computer where it started. If you step away, you lose sight of it. Checking whether a task is finished, or whether it is waiting for an answer, means going back to that desk.
Results arrive as transcripts. When a session ends, what you have is a long scroll of messages and a set of changed files. Working out how the result was reached, and whether you trust it, takes real effort. Picking it up again a week later takes more.
Handing off is awkward. A teammate cannot easily see what your agent did, comment on it, or continue from where it stopped. Sharing usually means pasting fragments into chat.
Credentials and control get blurry. Teams want to see each other’s agent work. They do not want to share model accounts, give each other control of their machines, or spend each other’s budgets. Most setups make you pick between visibility and clean boundaries.
Long tasks meet real life. Laptops sleep. Connections drop. Processes restart. When that happens partway through a task, it is often unclear whether the work finished, failed, or is still running somewhere.
What we believe
RunStead is our attempt to make agent work easier to follow, review, and hand on. We do not have a finished product to show yet, but we do have a few principles that shape every decision we make.
- The person who starts a session controls it. Teammates can see and comment on what you choose to share. They do not get to drive your session, your machine, or your spending.
- Credentials belong to their owner. If you use your own model account, it stays on your own machine. If you use a platform service instead, that is a separate, deliberate choice, and we never switch between the two behind your back.
- Work should be traceable. A good result is one you can explain: which steps were taken, which files changed, what was checked. That record is what makes it possible to continue, reuse, or hand the work off.
- When we do not know, we say so. If the system cannot confirm how a task ended, it should tell you, not guess, and never quietly run the task twice. We will write about the engineering behind this separately.
- Honest about what exists. This blog will keep a clear line between what we are designing and what actually works. When something is a goal, we will call it a goal.
What happens next
We are building now. A small, invite-only pilot will open later, and we will share what we learn along the way: product decisions, engineering notes, and the things that turned out to be harder than expected.
If that sounds useful, the simplest way to follow along is the RSS feed.