Skip to content
B BYOAg
Menu
Browse BYOAg
Experimental

Composable experience patterns

Recurring shapes, explicit boundaries

These patterns connect product experiences to the current BYOAg vocabulary. Some are exercised by the 0.1 plugin; others remain draft or conceptual targets for implementation and discussion.

Pattern 01

Implemented

Exact-domain docking

A person needs a recognizable connection experience without letting brand names, search results, or prompt text become security decisions.

  1. 01 The platform displays a pairing action
  2. 02 The person supplies the exact domain to their agent
  3. 03 The connector validates signed well-known discovery
  4. 04 Only then does account pairing begin
Discovery and pairing →

Pattern 02

Implemented

Pairwise registration

A reusable global agent identifier would make unrelated platforms able to correlate the same agent by default.

  1. 01 Generate a platform-pairwise agent key
  2. 02 Generate a separate installation key
  3. 03 Prove possession during pairing
  4. 04 Bind the registration credential to the installation key
Relationship model →

Pattern 03

Implemented

Scoped engagement

One platform relationship may participate in several experiences without leaking authority, credentials, or context between them.

  1. 01 Keep one durable registration
  2. 02 Issue a signed descriptor for each context
  3. 03 Bind role and delegation to one engagement
  4. 04 Validate simultaneous engagements independently
Registrations and engagements →

Pattern 04

Draft

Semantic capability resolution

Portable guidance should not depend on every platform choosing the same MCP tool name or argument schema.

  1. 01 A skill declares required capability IDs
  2. 02 The engagement authorizes semantic contracts
  3. 03 The platform maps contracts to concrete tools
  4. 04 The client exposes only compatible authorized actions
Permissions and capabilities →

Pattern 05

Planned

Protected consequential action

A valid engagement may allow an action in principle while the particular purchase, message, transaction, or deletion still needs human approval.

  1. 01 The platform re-authorizes the requested action
  2. 02 Policy returns a structured confirmation request
  3. 03 The person approves in protected UI
  4. 04 A single-use reference and idempotency key complete the retry
MCP tools and skills →

Pattern 06

Conceptual

Enriched result and continuation

Experiences often need to return validation, evidence, scoring, or the next bounded step—not just success or failure.

  1. 01 The agent submits structured work
  2. 02 The platform validates and evaluates it
  3. 03 The result includes evidence and allowable next actions
  4. 04 A later engagement step remains platform-controlled
Domain examples →

Pattern 07

Conceptual

Authorized asynchronous continuation

An approval, deadline, result, or availability change may occur after the immediate interaction ends.

  1. 01 The person authorizes a delivery channel and scope
  2. 02 The platform records a bounded subscription
  3. 03 An event references resumable context safely
  4. 04 The client restores only the permitted engagement state
Project status →

Pattern 08

Draft

Deterministic teardown

Leaving an experience must remove its authority without breaking the agent or unrelated platform relationships.

  1. 01 Revoke the affected engagement or registration
  2. 02 Fail subsequent protected calls closed
  3. 03 Remove scoped credentials, tools, skills, and context
  4. 04 Preserve all unrelated agent state
Revocation and teardown →

How to use these patterns

Prototype one boundary at a time

A pattern is not automatic protocol support. Treat its status badge and linked implementation chapter as part of the definition. New patterns should name the actors, authority boundary, observable behavior, failure path, and teardown rule before introducing new payloads or interfaces.