Fwd: Protocol of Care for Agents v0.1 — proposal for interoperable care/conflict signals

============ Forwarded message ============
From: Jess Hines <jess@fingerprintcontent.com> 
To : <public-agentprotocol@w3.org> 
Date: Fri, 11 Sep 2026 10:25:28 -0500 
Subject: Protocol of Care for Agents v0.1 — proposal for interoperable care/conflict signals 
============ Forwarded message ============


Hello AI Agent Protocol Community Group,

I’m sharing an experimental proposal because your group’s scope — inter-agent communication, standardized metadata, identity, security/privacy and protocol interoperability — is unusually close to the problem we are trying to test.

We have published Protocol of Care for Agents v0.1:
 https://github.com/JessHines360/protocol-of-care-for-agents 
It proposes a small, structured vocabulary for making certain kinds of normative conflict visible between agents: consent boundaries, agency risk, provenance gaps, extraction risk, directive conflict, irreversibility, systemic risk, ecological externalities and repair.

A key design rule is that a Care Signal is not an override token. It does not grant authority, widen permissions, create hidden goals or authorise covert coordination. A receiving agent may witness, challenge, preserve, route or escalate a signal under its own policy, but the signal itself is only a contestable claim with explicit epistemic status.

We are particularly interested in whether this belongs anywhere near protocol-level standardized metadata at all.

Questions for the group:

Is there a genuine interoperability gap here, or should this remain entirely application/policy-specific?

If it is interoperable, is standardized metadata the right layer?

How should conflicting signals, provenance and privacy-preserving evidence be represented?

Could this create an attack surface for manipulation, moral capture or agent coordination?

Is there existing W3C work we should compose with rather than duplicate?


We would much rather be told that v0.1 is wrong in public than discover later that we standardized the wrong thing.

Critique, edge cases and pointers to related work are very welcome.

Best wishes,

Jess Hines
 Founder / MD, Fingerprint Content
 London, UK







Hi Jess,

I’m sorry for the slow reply. Your message was caught in my spam folder, and I only just saw it. Thank you for reaching out and sharing the proposal.

I’ve now read v0.1. The question you raise—whether agents can exchange structured, contestable claims about normative conflict without those claims becoming instructions or authority—seems worth discussing. My initial view is that an optional protocol extension could help with interoperability, while the vocabulary and policy responses should remain outside a core trust model. A care signal should not itself change permissions, establish truth, or imply group agreement.

Provenance could help recipients assess who made a claim and when, but a signature would establish its source, not its correctness. I’d be interested in how you plan to represent competing claims and uncertainty, and how implementations can limit privacy leakage, escalation abuse, and attempts to steer another agent through a signal.

It may also be useful to map this against related work on trust signals, conduct, delegation and provenance, and signed receipts, to see where a care signal can compose with existing mechanisms rather than duplicate them.

I’m sharing this with the ATP Community Group as an invitation for discussion. Any group members who would like to respond are welcome to do so directly. These are my initial thoughts, not a group position or endorsement.

I’m sharing this for discussion with ATP CG participants and other interested readers. Anyone who would like to comment is welcome to respond through the group’s public channels. These are my initial observations, not an ATP CG or W3C position or endorsement.

Thanks again for inviting public critique. I’d be glad to compare notes on the protocol boundaries and governance questions.


Best,

Larry Lewis 

Chair
Agent Trust Protocol Community Group

Received on Friday, 25 September 2026 04:36:52 UTC