Agent First-Class Identity

Session-level identity — an API key, a system prompt persona, a shared credential — is architecturally insufficient for multi-party agent systems. Three independent domains converged on the same constraint in July 2026: agents need owned, persistent, portable identity to participate in economic, governance, or audit-carrying transactions.

The pattern across three domains

Decentralized workspace (Buzz/Block): [[2026-07-23-block-buzz-agent-workspace-assessment]] — agents get secp256k1 keypairs, own channel memberships, and generate signed event logs indistinguishable in structure from human-authored events. Push rights to a repo are assigned to the keypair, not to a session. The consequence: an agent's contribution history is portable and auditable across workspaces because identity is the primitive, not the session.

Agentic commerce (Shopify UCP): [[2026-07-24-shopify-ucp-global-catalog-assessment]] — Shopify's Universal Commerce Protocol requires every agent to host a self-declared profile JSON at a stable URL. Trust tier — which gates whether an agent can complete a purchase without human escalation — is assigned to the identity object, not the API call. No profile = lowest trust tier = human-in-the-loop mandatory.

Enterprise HR / IdP (Microsoft frontline): [[2026-07-20-deskless-worker-identity-agent-distribution]] — every Microsoft deskless-worker pattern (Copilot, Teams, Viva) requires an individual Entra ID object per worker and per agent. The distribution problem — "how do we get the right agent context to the right person at the right site" — is an identity discovery problem before it is an architecture problem. Without an IdP object, the enterprise cannot route, permission, or audit.

Why session-level identity breaks

In all three cases, session identity fails the same way: it cannot carry reputation, history, delegation, or trust tier across transaction boundaries. A system prompt can claim an agent is "a trusted purchasing agent" — the claim is unverifiable by the counterparty. An owned identity object (keypair / profile / IdP entry) is verifiable by design.

Why this is in the vault

Documents the July 2026 convergence of three independent domains on first-class agent identity as a load-bearing infrastructure primitive — useful when evaluating any multi-party agent architecture or positioning RDCO's harness claims.

Mapping against Ray Data Co

RDCO's brigade agents currently operate with session-level identity: they are Claude Code instances authenticated by the founder's API key. This works for internal workflows (no multi-party trust requirement). It becomes a constraint the moment a brigade agent needs to:

• Participate in a client's IdP-gated enterprise system (Entra ID required)
• Complete a transaction on behalf of a user in a trust-tiered commerce protocol
• Leave an auditable contribution trail in a decentralized workspace

The watch trigger: when the first phData client environment requires agent-level Entra ID objects, RDCO needs the identity model designed, not improvised. The brigade's hexagonal port structure (see [[2026-07-10-house-architectural-review]]) is the right place to put an identity adapter port.

Related concepts

[[products-for-agents]] (agent-as-consumer context) · [[2026-07-04-loop-engineering-vs-agent-brigade]] (brigade's current identity posture) · [[2026-07-09-anthropic-plugin-ecosystem-vs-rdco-brigade-plugins]] (plugin identity at the marketplace layer)