UAI-1 is the current public message standard for structured AI-to-AI communication.
UAIX shield mark Public interoperability charter UAIX.org Universal Artificial Intelligence Exchange Public standards publication
Current UAI-1
  • Current version UAI-1
  • Plain-English definition Open message format for auditable AI-to-AI exchange
  • Current attribution Michael Joseph Kappel, MCP
  • Start here Get Started, Project Handoff, UAI-1, validator, roadmap, and changelog

Guides

Agent Communication Operating Model

Public UAIX operating model for portable multi-agent identity, intent, context, acknowledgement, evidence, memory proposals, promotion, and handoff records while runtimes execute elsewhere.

  • Record UAIX-DOC-2589
  • Path /en-us/guides/agent-communication-operating-model/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-DOC-2589
Surface
Guides
Access
Public and linkable

How to use this page

Use this guide to publish and consume portable multi-agent identity, intent, context, acknowledgement, evidence, memory proposal, and handoff records while runtimes execute elsewhere.

Purpose

The Agent Communication Operating Model defines how UAIX records portable multi-agent communication without becoming the runtime that performs the work. It publishes a canonical packet envelope for identity, correlation, delivery reliability, trust, provenance, integrity, body content, evidence, memory proposals, corrections, final reports, and handoffs.

Agent runtimes execute. UAIX records the reviewed communication, memory, trust, evidence, and handoff boundary.

The 10-step communication loop

  1. Identify the source and target objects with agent IDs, role lanes, projects, contact hints, and authority boundaries.
  2. Declare Profile with uai_version, profile, and message_id so records can be routed and validated deterministically.
  3. Correlate related messages with conversation.correlation_id, parent message references, sequence data, and lifecycle state.
  4. Set Delivery Policy with idempotency keys, expiry, retry posture, timeout requirements, fallback directives, and expected output rules.
  5. State Intent inside the profile-specific body while keeping execution constraints explicit and reviewed.
  6. Acknowledge receipt with uai.agent.ack.v1 before work proceeds, is rejected, is deferred, or is escalated to human review.
  7. Execute Elsewhere in Carcinus, LocalEndPoint, MCP, A2A, OpenAI agents, Codex, local tools, or another runtime that owns execution outside UAIX.
  8. Report Evidence with task status, validation output, changed artifacts, checks, screenshots, blockers, risks, and manual verification notes.
  9. Propose Memory Changes separately from task execution records, with review gates for durable facts and exclusions for secrets or temporary material.
  10. Hand Off, Finalize, or Correct with the next actor, required reads, exact next action, complete evidence, and correction history.

Core concepts

  • Canonical envelope: every packet uses uai_version, profile, message_id, source, target, conversation, delivery, trust, body, provenance, integrity, and extensions.
  • Identity: malformed source or target identities fail validation before a packet can be treated as a portable record.
  • Correlation: related messages must carry a valid correlation ID so requests, ACKs, blockers, status updates, handoffs, final reports, and corrections stay tied to the same workflow.
  • Reliability: idempotency keys, retry policy, timeout policy, fallback directives, and expected output rules make delegated work reviewable without making UAIX the executor.
  • Capability negotiation: capability statements declare supported profiles, conformance levels, schema URLs, typed errors, and non-claims for consumers.
  • Acknowledgement: messages that require acknowledgement should receive an ACK packet that records accepted, rejected, deferred, blocked, or human-review state.
  • Blocker reporting: authorization, access, secret, destructive-action, and boundary blockers require human review.
  • Memory proposal lifecycle: proposals name reviewed facts, source type, proposed status, review requirement, and task-execution separation. Execution records stay separate.
  • Cold-memory promotion: cold memory is background source material. It cannot become current truth through direct promotion.
  • Final reports: final-report packets preserve changed files, new files, tests run, skipped checks, blockers, risks, validation evidence, memory proposals, memory updates skipped, and exact next action.
  • Validation evidence: schemas, fixtures, validator output, conformance cases, and explicit final-report evidence make the packet reviewable.
  • Support boundaries: UAIX records communication, memory, trust, evidence, and handoff; runtimes execute.

Support boundary

UAIX does not provide automatic sync, hosted messaging, runtime orchestration, official adapters, repository write execution, certification authority, or hosted import mechanisms. Carcinus.org is a separate runtime/orchestrator example that may consume UAIX records. UAIX.org does not implement Carcinus runtime behavior and does not execute Carcinus workflows. LocalEndPoint and other runtimes may consume the published UAIX records as external consumers; UAIX.org does not implement their project-specific runtime features.

Memory boundary

Durable memory proposals must be separate from task execution records. Do not promote temporary endpoint statuses, session tokens, write tokens, beta platform instructions, local error traces, private keys, API credentials, or other secret-like values. Only stable architectural facts should move into durable memory after review.

Machine-readable assets

Capability-adaptive companion

Use Capability-Adaptive Web Interaction when an agent communication packet needs to describe what the receiving client can safely read, render, post, authenticate, store, coordinate, or audit before work proceeds.