Not Every Machine Interaction Is a Task

A common direction has a boundary

A common direction in interoperability work starts with a familiar sequence. A message arrives. Work begins. The work succeeds, fails, or needs more input. A result returns.

This is a clear model for bounded work. The problem is treating it as the natural shape of every interaction between independent systems.

Other work has other shapes

A service may remain healthy for months. A subscription may continue until it is cancelled. A permission may exist quietly until it expires. A transfer may need only acceptance and a receipt.

Forcing all of these into a task model does not make them interoperable. It hides their real lifecycles behind borrowed language.

The problems appear at the edges

The common direction remains useful inside its boundary. Outside that boundary, it creates recurring problems.

• False completionLong-lived relationships need invented end states even when they are meant to continue.
• Manufactured outputsState changes and acknowledgements are wrapped as artifacts even when nothing new was produced.
• Lost meaningServices, permissions, streams, and replicas are flattened into generic work containers.
• Adapter burdenEvery other interaction needs extra machinery to look like a task before it can participate.

The system may still function. The cost appears in more complex adapters, less honest state, and vocabulary chosen for a different kind of work.

Success may produce nothing

Some successful operations create a document, file, or other durable output. Others change existing state. Some grant permission. Some establish a relationship. Some merely confirm that exact bytes were accepted.

A useful common model should be able to say “accepted” without pretending that acceptance is an artifact. It should represent an ongoing relationship without pretending that the relationship is unfinished work.

A different direction

Task-based coordination belongs in the stack. It should not define the whole stack.

A broader architecture can keep connectivity and common coordination narrow, then let different interaction profiles express tasks, subscriptions, transfers, remote calls, or domain-specific behavior above it.

A thinner common contract

The shared layer does not need to understand every domain object or workflow. It needs a small set of durable answers.

Principal

Who is acting?

Endpoint

Where can it be reached?

Reference

What exact thing is being discussed?

Recipient

Who is the interaction for?

Acceptance

Was it admitted, rejected, or deferred?

Receipt

What can later prove what happened?

That is enough substrate for richer models to coexist without requiring each one to adopt the same ontology.

Keep richer models optional

Bounded work can still use messages, tasks, progress, results, and artifacts. Those concepts are valuable when the interaction truly has that shape.

Other profiles should be free to expose a desired state, a stream, a lease, a replicated object, or a narrow operation. The common layer should connect them without flattening their meaning.

The question worth asking

Interoperability is not achieved by giving every interaction the same nouns. It comes from agreeing on the smallest shared contract and leaving room for the right abstractions above it.

What is the smallest machine-to-machine contract on which tasks, remote calls, object transfer, subscriptions, streams, and future interaction models can coexist?

Read our working principles