OSIO documentation

Work and responsibility

OSIO treats Work as durable organisational responsibility intended to outlast conversations and changing executors.

Browse documentation

In OSIO’s architecture, Work is durable organisational responsibility. It is more than the text of a request or the temporary state of an agent. It describes something the organisation has taken responsibility for moving toward an appropriate result.

Work is designed to remain understandable when:

  • the originating conversation ends;
  • a model call finishes;
  • an agent or process restarts;
  • an executor is replaced;
  • a provider changes; or
  • a machine restarts, where persistence allows.

The work should not require a new agent to reconstruct the organisation from scratch each time it runs. Relevant context, the record of authority, unresolved questions and evidence belong to the continuing organisational state, not solely to the executor’s current memory. A stored authority record does not make permission permanent: consequential actions still require authority that applies when they are taken.

A commitment as Work

For example, an Owner might say:

“I told Acme I’d send their revised proposal tomorrow. Make sure I don’t drop it.”

Conceptually, this is not just a chat message to answer once. It describes a commitment with an intended outcome, a time constraint and work that may continue after the conversation. OSIO’s design aims to preserve that responsibility and its relevant context as work progresses.

This example explains the model; it is not a claim that every such commitment can currently be created or handled in a generally available product.

Work can pause or change

Durable does not mean that work is always active or that its outcome is guaranteed. Work may wait for information, be blocked by a dependency, require a person’s judgement, receive evidence that changes the next step or remain unresolved. A responsible system should make those states visible rather than silently treating an unfinished commitment as complete.

What “persistent” means here

Persistence is an architectural requirement: the organisation’s responsibility should not be tied to one model session or running agent. Actual availability depends on the product and the persistence provided by its current implementation. This documentation does not promise that every type of work or every event is supported in the product today.