Skip to content

6. Reference Ontology of Coordination Objects

Pervasive.link coordination is built around a reference ontology of protocol objects.
These objects represent the fundamental entities that appear during interactions between agents.
Instead of relying on ad-hoc message formats or application-specific APIs, the protocol defines a structured set of objects that represent the components of coordination.

These objects form the semantic vocabulary of the protocol.

When agents interact through Pervasive.link, they exchange envelopes containing these objects.
Because every object references a well-defined schema, agents across different systems can interpret their meaning consistently.

The ontology provides a shared conceptual model for:

  • declaring goals
  • advertising capabilities
  • negotiating execution
  • assigning tasks
  • enforcing policies
  • recording execution outcomes

Rather than defining coordination through procedural workflows, the protocol expresses coordination through relationships between objects.
These objects collectively form coordination graphs that describe how distributed workflows unfold.

Purpose of the Reference Ontology

In heterogeneous agent ecosystems, coordination often breaks down because systems describe their capabilities and operations in incompatible ways.

One system may represent a service as a REST endpoint, another as a workflow step, and another as a function within an orchestration framework.
Even when these services perform similar functions, their representations are rarely interoperable.

The reference ontology solves this problem by providing canonical object definitions that represent the fundamental elements of coordination.

Instead of exposing internal implementation details, agents translate their capabilities and actions into these protocol objects.

This abstraction allows coordination to occur independently of internal architectures.

For example:

  • an AI model exposed through an API can be represented as a capability
  • a robotics behavior can be represented as a capability
  • a data processing job can be represented as a task

Although these services operate in different environments, they can participate in the same coordination workflow because they are expressed through the same ontology.

Object-Centric Coordination

Traditional distributed systems often rely on procedural coordination.
A central orchestrator executes predefined steps in sequence, calling specific services using known interfaces.

Pervasive.link takes a different approach.
Coordination emerges through interactions between objects rather than predefined procedures.

For example:

  • an intent object expresses a goal
  • capability objects describe available services
  • offer objects propose how to fulfill an intent
  • a task object binds an intent to a capability
  • receipt objects record the outcome of execution

The relationships between these objects define the workflow.

Because these objects are exchanged dynamically between agents, workflows can be assembled and modified at runtime.

Core Coordination Objects

The reference ontology defines several core objects that appear in most coordination workflows.

These objects represent the essential components of agent interaction.

Agent

The agent object represents an entity capable of participating in coordination.

An agent may correspond to:

  • a software service
  • an AI agent
  • a robotics system
  • a distributed computation node
  • a monitoring or governance service

Agents interact with the protocol by publishing capabilities, responding to intents, negotiating tasks, and producing execution artifacts.

Agent objects typically include information such as:

  • agent identifier
  • supported schemas
  • available capabilities
  • policy constraints
  • contact endpoints

The agent object therefore acts as the protocol-level representation of a participating system.

Capability

A capability object describes a service that an agent can provide.

Capabilities allow agents to advertise what operations they can perform without exposing implementation details.

A capability definition typically includes:

  • capability identifier
  • input schema
  • output schema
  • operational constraints
  • associated policies
  • optional metadata describing performance characteristics

Capabilities can represent many kinds of services, including:

  • language model inference
  • robotics actions
  • data transformations
  • planning algorithms
  • scientific simulations

Agents publish capability objects to make their services discoverable within the coordination network.

Intent

The intent object expresses a goal that an agent wishes to accomplish.

Instead of directly invoking a specific service, an agent declares an intent describing the desired outcome.

Examples of intents include:

  • generate a summary of a document
  • analyze sensor data from a device
  • perform a machine learning training job
  • plan a route for a robotic platform

Intents allow coordination to begin from a goal-oriented perspective rather than a service invocation.

Agents capable of fulfilling the intent evaluate it against their capabilities and may respond with offers.

This mechanism enables dynamic discovery and selection of services.

Offer

An offer object represents a proposal from an agent describing how it can satisfy an intent.

When an agent receives an intent that matches one of its capabilities, it may generate an offer specifying:

  • the capability it proposes to use
  • execution constraints
  • estimated resource usage
  • applicable policies
  • optional performance guarantees

Multiple agents may respond to the same intent with competing offers.

The initiating agent or coordinating entity can then select among these offers to determine which agent should execute the task.

Offers therefore enable negotiation among agents during workflow formation.

Task

A task object represents the agreement that binds an intent to a specific capability offered by an agent.

Once an offer has been accepted, a task object is created describing the execution parameters.

The task object typically includes:

  • reference to the original intent
  • reference to the selected capability
  • execution parameters
  • policy constraints
  • monitoring requirements

The task defines what work should be performed and under what conditions.

Execution of the task is then carried out by the selected agent.

Event

The Event object represents observable occurrences within the coordination lifecycle.

While objects such as Intent, Offer, and Task describe planned coordination activities, events represent runtime signals that indicate state changes or operational milestones during execution.

Events allow agents and observers to monitor coordination workflows as they unfold.

Examples of events include:

  • task start notifications
  • task completion signals
  • policy violations
  • capability updates
  • execution progress milestones

Unlike receipts, which summarize the final outcome of a task, events capture intermediate stages of coordination.

Event Structure

An event object typically contains:

  • event identifier
  • event type
  • timestamp
  • reference to the related coordination object
  • optional metadata describing the event context

For example, an event might reference a task identifier and indicate that execution has begun or completed.

These references allow events to be linked to the broader coordination graph.

Event Types

Different event types may represent different stages of the coordination lifecycle.

Common examples include: TaskStarted TaskProgress TaskCompleted PolicyViolation CapabilityUpdated IntentCancelled

These event signals allow monitoring agents and observers to understand the runtime behavior of distributed workflows.

Role in Coordination Observability

Events play an important role in enabling observability within coordination networks.

By emitting structured event objects, agents make internal workflow state visible to external observers.

Monitoring systems can subscribe to events and reconstruct coordination timelines, detect failures, or analyze system performance.

This capability is particularly valuable in large coordination ecosystems where workflows span multiple independent agents.

Relationship to Trace Objects

Events are often linked through trace identifiers.

Trace objects connect events into causal chains that describe how coordination workflows evolve over time.

By following trace links between events, observers can reconstruct the sequence of actions that led to a particular outcome.

Events therefore serve as the building blocks for constructing trace graphs that describe distributed coordination processes.

Policy

A policy object describes constraints governing how coordination and execution may occur.

Policies may define requirements related to:

  • security
  • compliance
  • privacy
  • geographic restrictions
  • cost limits
  • resource constraints

Policies can be attached to several coordination objects, including:

  • agents
  • capabilities
  • tasks
  • intents

During negotiation and execution, agents evaluate these policies to ensure that the workflow complies with applicable rules.

Policies allow governance rules to travel with coordination objects rather than being enforced solely within local infrastructure.

Attestation

An attestation object represents a signed claim about an agent, capability, or execution environment.

Attestations may provide information such as:

  • security certifications
  • execution environment properties
  • compliance with specific standards
  • validation of capability performance

Because attestations are signed, they allow other participants to evaluate claims about the system producing them.

Attestations therefore play an important role in establishing confidence among participants in open coordination networks.

Receipt

A receipt object records the outcome of a completed task.

Receipts provide structured evidence describing what occurred during execution.

Typical receipt contents include:

  • task identifier
  • input parameters
  • output results
  • execution timestamps
  • policy references

Receipts allow participants to verify that tasks were executed according to agreed conditions.

They also provide an auditable record of coordination events.

Trace

A trace object captures the sequence of coordination events associated with a workflow.

Traces link together intents, offers, tasks, receipts, and other objects into a coherent coordination graph.

By following trace references, agents or observers can reconstruct the history of a distributed workflow.

Trace objects are particularly useful for:

  • debugging coordination failures
  • auditing workflows
  • analyzing system behavior

Relationships Between Objects

The objects defined in the ontology are not independent.
They are connected through references that describe their relationships.

For example:

  • offers reference the intents they respond to
  • tasks reference both intents and offers
  • receipts reference the tasks they describe
  • traces link all coordination events together

These relationships form coordination graphs.

Coordination graphs describe how distributed workflows unfold across multiple participants.

Because each object contains identifiers linking it to related objects, agents can navigate these graphs to understand how a workflow was constructed and executed.

Extending the Ontology

While the reference ontology defines core coordination objects, it is not intended to be exhaustive.

Different domains may require additional object types.

For example:

  • robotics systems may introduce objects describing physical actions
  • financial coordination systems may introduce contract objects
  • research workflows may introduce experiment objects

The protocol allows these extensions by defining schemas for new object types.

As long as these schemas are referenced correctly within semantic envelopes, other agents can interpret the new objects.

This extensibility allows the ontology to evolve as new domains adopt the protocol.

Ontology as the Semantic Foundation

The reference ontology provides the semantic foundation upon which the Pervasive.link coordination model operates.

By defining canonical representations for agents, capabilities, intents, tasks, and execution artifacts, the ontology ensures that coordination objects can be interpreted consistently across systems.

This shared vocabulary allows heterogeneous agents to collaborate without requiring shared infrastructure or execution environments.

Through this object model, distributed workflows can be represented as graphs of coordination objects rather than rigid procedural pipelines.

In the next section, we examine the protocol message types that agents use to exchange these objects during coordination interactions.