Checkpoint: one control loop, three kinds of state
Paperclip's company model and heartbeat lifecycle can now be read as one control loop. The useful judgment is not whether the system has many records, but whether a reader can distinguish what the organization intended, what is executing now, and what remains as evidence after execution. That distinction shows what Paperclip's normal path makes governable—and what it still leaves unresolved.
The three ideas are already in place. A company and its goals give work direction. An issue and its owner give that direction a concrete responsibility. A heartbeat crosses the adapter boundary and turns the responsibility into a finite execution attempt. The control plane then has to connect the attempt back to the work without confusing the provider's internal activity with the organization's durable state.
One task, three kinds of state
The first kind is organizational intent. This is the relatively stable answer to “what are we trying to accomplish, and why?” It includes the company, its goal ancestry, the project or issue that carries the work, the role responsible for it, and the relationships that explain how the work fits into a larger objective. Intent is not merely a sentence in a prompt. In Paperclip's model, it is attached to company-scoped objects that can be inspected and related to other work.
Suppose a company wants to improve an AI note-taking product. The broad objective is intent. A project to improve user acquisition is a more specific expression of that intent. An issue to investigate an advertising channel is a still smaller unit of responsibility. The hierarchy does not make the objective true, and it does not tell an agent how to perform the investigation. It gives the task a declared reason and an owner that can be discussed.
The second kind is live execution state. This answers “what is happening now?” A task can be eligible for work, a heartbeat can be queued, and a run can be claimed and running. The adapter may have started a local process, sent a remote request, or resumed a provider session. These facts are transient: they can change while an operator is looking at the screen, and some are visible only to the adapter that understands the provider.
Live state is therefore not the same as organizational intent. An agent may be assigned to an issue while no heartbeat is running. A run may be active while the issue's larger goal remains unchanged. A provider session may be alive while the current Paperclip run has not yet returned a result. Treating all of these as one state produces misleading conclusions, such as “the task is done because the process exited” or “the company is making progress because an agent is online.”
The third kind is durable evidence. This answers “what can we still inspect after the moment has passed?” Paperclip's run records retain attribution, invocation source, status, context, timestamps, usage and result data, session information, runtime details, and error or log references. Issue comments, attached documents, work products, cost events, and activity records preserve other parts of the history. Each surface answers a different question. A result describes what the adapter reported.