AGENTS AND SOFTWARE

A personal cloud computer is an operational boundary

Event source: OpenAI introduces always-on dots ↗

In this analysis
THE RETROSPECTIVE TAKE

Retained artifacts and application access have different lifetimes and need separate recovery decisions.

The computer became part of the product

The May 16, 2025 Codex announcement established an earlier cloud execution model for software tasks. Astra’s September 3, 2026 API changelog entry supplies the preceding model milestone. Dots arrived on September 29 with personal cloud computers as part of an always-on agent workflow. This changed what must be considered when evaluating an agent: a model response is only one component, while files, application sessions and intermediate state can influence what happens after the current conversation ends.

Environment continuity has value and cost

An illustrative research task may leave a partially organized folder and a browser session containing useful references. Retaining that state can avoid repeating discovery. It can also preserve a stale login, an unfinished edit or an assumption about which file is current. The relevant question is not whether persistence is universally better than a fresh environment. It is whether retained state remains attributable to a responsibility and can be inspected when work resumes. Otherwise, apparent continuity may conceal an accidental dependency on an old task.

Credentials and artifacts age differently

A saved draft may remain useful after an application session expires. A valid application session may remain active after the task that justified its use has ended. These different lifetimes require different operational treatment. Regenerating a draft is not equivalent to restoring access, and refreshing access is not permission to repeat an external action. The launch’s cloud-computer framing makes these distinctions visible, but it does not establish an undocumented credential-retention policy or a universal recovery process for every connected application.

Reconstruct a resumed task

A practical illustrative fixture pauses work after a draft comparison is saved, then resumes after a source document changes. The review packet identifies the saved artifact, the newer source and the reason the earlier draft needs revision. It also records whether the resumed workflow requires renewed access. A successful result should reflect the changed source without pretending that all environment state is fresh. This is a proposed recovery scenario, not a report that any particular product has passed it or that a specific session-restoration feature exists.

Evaluate the whole operating boundary

Calling the environment personal does not make its operational obligations disappear. The useful acceptance unit includes the assignment, retained artifacts, access state and supported result. This explains why an excellent model can still produce an unreliable resumed workflow: the failure may lie in environmental assumptions rather than reasoning. Conversely, a clearly preserved artifact can make a modest recovery understandable. The retrospective lesson is to examine continuity as a property of the whole working environment, with explicit evidence of what persisted and why it remains relevant.

← All retrospectives