# Dots changed a task into an ongoing responsibility

How always-on dots change task completion into responsibility management, with explicit triggers, stale assumptions and stopping conditions.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-29
Original announcement: https://openai.com/index/introducing-dots/
Canonical URL: https://retrivium.ai/retrospectives/dots-persistent-responsibility/

## The unit of work became persistent

[Codex's introduction on May 16, 2025](https://openai.com/index/introducing-codex/) described an earlier cloud agent organized around software tasks. The [September 3, 2026 Astra entry in the API changelog](https://developers.openai.com/api/docs/changelog) provides another model-generation milestone. On [September 29, OpenAI introduced dots](https://openai.com/index/introducing-dots/) as always-on agents with cloud computers and learned context. The useful contrast is between completing a bounded assignment and maintaining an ongoing responsibility. The latter needs a reason to act again after an apparently successful result, without treating repetition itself as progress.

## A responsibility needs a trigger and a stopping condition

An illustrative responsibility might be to maintain a weekly project briefing from approved sources. “Prepare this briefing” is a task; “keep the briefing current” leaves the trigger, freshness requirement and completion boundary unspecified. A workable interpretation identifies what changes justify another pass and when no update is needed. This is an editorial design recommendation, not a statement that the launch guarantees a particular scheduling mechanism. The distinction matters because an agent can produce repeated polished documents while failing the intended responsibility of noticing material changes.

## Persistence introduces stale assumptions

A single assignment can often rely on assumptions that remain valid during its execution. An ongoing responsibility encounters changed ownership, retired documents and revised priorities. Learned context can reduce repeated explanation, but it can also preserve an assumption after its justification disappears. In the briefing example, the project contact may change while an old distribution preference remains in memory. The appropriate response is to reconsider the responsibility's operating context, rather than treating every remembered detail as permanently authoritative.

## A responsibility record makes review possible

A useful illustrative artifact pairs a responsibility statement with its permitted sources, last supported result and unresolved uncertainty. During review, compare a new source change against the previous briefing and ask whether the update was justified. Also include a period with no material change: unnecessary publication should not count as useful work. This fixture distinguishes responsiveness from activity volume. It does not assert that dots exposes a specific record schema or that any autonomous behavior is correct without inspection of the resulting evidence.

## Completion changes meaning

For persistent agents, “done” can mean that the current cycle is complete while the responsibility remains active. It can also mean that the responsibility itself has ended. Confusing these meanings produces either abandoned work or endless continuation. The September announcement makes this distinction operationally important, but capability alone cannot define an organization's desired stopping rule. A clear persistent assignment therefore explains what may restart work, what must be reviewed, and what ends the mandate. That is the meaningful difference from merely repeating a one-time prompt in the background.

## Related reading

- [Tools and execution boundaries](/journal/openrouter-tool-calling/)
- [Evidence across operations](/journal/provider-request-id-trace-context/)