Trusted provider services for people and agents

The problem#

An agent can use a “skill” or call an API, but other participants may need more than the output. They need to know which provider accepted the work, what request it answered, which authority covered the response, what evidence the provider relied on, and what commercial obligations apply.

The process often spans four different concerns that ordinary integrations blur:

• permission to perform the service;
• access to the necessary information;
• an obligation or service agreement;
• the attributable result.

The Blue pattern#

The source document emits a typed Request addressed to a provider role. The provider independently discovers a matching active responder Mandate, verifies request constraints and data access, performs the external work, and writes a typed Response through its own Timeline Channel.

The Request does not choose which Mandate the provider must trust. That avoids letting an untrusted requester select a convenient authority artifact.

Purpose, authority, access, and obligation remain separate#

A Purpose statement may explain that a legal provider is present to review clauses. It grants nothing. A responder Mandate may authorize the provider to answer covered Requests. A subscription or access policy may expose the needed document fragment. A service Agreement may define price, SLA, confidentiality, liability, and duty to respond.

This separation lets the system say precisely what exists instead of treating one API key as permission, access, contract, and proof all at once.

Examples#

• a lawyer responds to Legal Review Requested;
• a product verifier confirms a genuine item before a PayNote can proceed;
• a courier writes delivery evidence through its own channel;
• an identity provider contributes a verified status;
• a municipality publishes a permit decision;
• a BI provider returns a calculation or report;
• a human inspector records an attributable decision where deterministic code should not replace judgment.

Agent providers#

A provider may itself use an agent. The first interoperable model should keep the external authority edge simple: either the concrete provider agent is authorized directly, or the provider's Timeline profile attests that an internal agent wrote on a provider-controlled Timeline.

Recursive hidden delegation should not be assumed.

What changes in the target document#

The target processor does not decide whether the provider should have taken the job. It deterministically handles the provider's attributed Response according to the document's contracts. The provider retains its authority and service evidence for audit.