The runtime is the product

There is a familiar failure mode in AI-assisted engineering. A model produces a strong plan, begins a task, runs several commands, and then hits a missing credential, a flaky test, or a request that needs human approval. The session ends. Later, somebody opens a new window and starts again from a summary of what the first session thinks it did.

The model may have been capable throughout. What failed was the environment around it.

Once an AI system can change files, invoke tools, open a browser, or communicate with an external service, it is no longer only answering questions. It is participating in a process that has state, permissions, dependencies, costs, and consequences. That process needs a runtime.

Loom is an experiment in that layer. It is not a claim that a new model or editor should replace the tools engineers already use. Its premise is narrower: the working context around a task should be treated as durable infrastructure instead of scattered conversation.

A task is more than a prompt

The usual description of an agent begins with a prompt and ends with an output. That is an incomplete unit of work. In practice, a software task has at least five parts:

1. An objective. What is the requested change, and what constraints come with it?
2. A working state. Which repository, branch, files, environment, and external systems are involved?
3. An authority boundary. What can the agent inspect, edit, execute, or request approval to do?
4. A record of evidence. Which checks have run, what they showed, and what remains uncertain?
5. A continuation path. If the work stops, who or what can resume it without inventing the missing context?

Chat preserves a sequence of messages. That is useful for discussion, but it is a poor source of truth for a changing system. It does not naturally answer whether a command changed the filesystem, whether an environment is still valid, whether an approval was granted for this run or a previous one, or whether a screenshot belongs to the current branch. A transcript is evidence of conversation. It is not necessarily an operational record.

The runtime has to gather the pieces that matter and make their relationship clear. A task should know the branch it owns, the revision from which it started, the commands that produced consequential effects, the state of its checks, the approvals attached to its requested actions, and the open questions that prevented completion. Without that, every handoff begins with reconstruction.

State must survive the model's attention

It is tempting to put everything important into the model context: the issue, the code snippets, prior messages, the task plan, and the current status. This can work for a short interaction. It becomes brittle as soon as work lasts longer than one uninterrupted session.

Context is expensive, partial, and transient. It changes when a model is swapped, a session is compacted, or a new contributor takes over. It should contain the information needed for reasoning now. It should not be the only place that work exists.

Durable state belongs in the system that owns the work:

• repository changes belong on a branch with a legible diff;
• task intent belongs in a short, maintained brief rather than in an early message;
• executable evidence belongs with the command, test, preview, or artifact that produced it;
• approval decisions belong to the action and scope they authorize;
• unresolved questions belong in the task record where a reviewer can find them.

This does not require preserving every intermediate thought. In fact, an indiscriminate archive makes recovery harder. The design problem is editorial: retain the state that changes the next decision, discard the noise that does not, and preserve enough provenance to tell which facts are still trustworthy.

Capability should be explicit

An agent may be able to read a repository, edit a sandboxed branch, run a test suite, ask for a preview, query a service, or propose an external action. These are not variations of the same generic "tool call." They have different blast radii and should be represented differently in the runtime.

Reading a public file is often low risk. Updating a dependency lockfile can be locally reversible. Sending a message to a customer, rotating a credential, deleting data, or changing a production configuration are not. A capable runtime makes the distinction visible before the model acts, not after an incident forces the team to reconstruct it.

The control point cannot be a sentence in the agent's instructions. Models are useful at deciding how to pursue an objective; they should not be the final authority on what they are permitted to do. Permissions, network boundaries, credentials, and approval policies need to sit outside the model context so that they remain stable when the model improves, fails, or is replaced.

This is the practical meaning of least privilege in agentic software. A more capable model should be able to reason over a task better. It should not acquire more access merely because its reasoning improved.

Isolation is not an implementation detail

Concurrent work makes implicit state dangerous. If several agents and engineers can edit the same workspace, use the same credentials, or share a long-lived environment, an apparently local task can leak into another one. The resulting failures are difficult to diagnose because the relevant change may have happened outside the task that reported the error.

An isolated execution environment gives each task a clearer boundary. The task receives the files, tools, and credentials it needs. Its work is visible on its own branch or equivalent change set. When it completes, the environment can be discarded without losing the durable artifacts. When it fails, the failure can be investigated without guessing which unrelated process modified the machine.

Isolation is not a promise of perfect safety. A poor permission model can still expose a sensitive system, and a flawed test can still certify the wrong behavior. But isolation reduces accidental coupling. It allows the runtime to answer basic questions that shared environments blur: which task changed this file, which tool call came from this session, and which environment produced this result?

Recovery is a correctness property

Long-running work is ordinary work. A task pauses because somebody needs to approve an action, a dependency registry is unavailable, the engineer who started it goes to sleep, or a new request takes precedence. A runtime that treats every interruption as a restart loses information and makes complex tasks look simpler than they are.

Recovery requires more than a retry button. Retrying an external write without knowing whether it already happened can create duplicates. Re-running a migration without its prior state can make a damaged system worse. Resuming an old task with stale permissions may overstep the authority that was originally granted.

A durable task needs to know which actions are safe to repeat, which require inspection, which approvals have expired, and which environmental assumptions should be refreshed. It should make its pause state legible: blocked on a credential, waiting for a review, awaiting a service, or finished with a change ready to inspect. That is how a later session can continue the work rather than reenact it.

Review turns activity into shared progress

The final output of an agentic task should not be an eloquent completion message. It should be a reviewable proposal. What changed? What was verified? What risk remains? Which external actions, if any, were taken? What evidence supports the claims?

This is especially important when agents work quickly. Speed can create the illusion that the only meaningful event is the finished patch. In a shared system, the path to that patch matters. Review is the moment when private activity becomes shared knowledge and when a team can decide whether the work belongs in the system it maintains.

For straightforward changes, this should be light. A small diff, a focused test, and an honest note may be sufficient. For work that touches money, user data, or a production dependency, the same runtime should make deeper inspection possible without forcing every small task through a ceremony designed for the highest-risk one.

The model is inside the product, not the whole product

The next generation of models will be better at reasoning, tool use, planning, and code generation. None of that removes the need for state management, authority boundaries, isolated execution, recovery, and review. It raises the stakes for all of them.

The useful question is therefore not which model can complete the longest autonomous run. It is whether the system around that run can preserve context, limit authority, recover from interruption, and produce work another person can understand. That runtime is where capable models become dependable software.