Skip to main content

​
Overview

The Agent Triage Protocol (ATP) implements a carefully designed architecture to enable reliable, secure communication between AI services and human decision-makers. This page explains the key architectural components and how they interact.

​
Message Flow

The protocol implements a circular message flow pattern with the ATP server as the central orchestrator: In this flow, the ATP Server acts as the single point of coordination, handling both the forward path (notifications to users) and return path (responses to services).

​
Core Components

The ATP architecture comprises three primary components:

​
1. ATP Server

The central message broker and state manager that:
  • Receives notifications from AI services
  • Manages notification lifecycle and state transitions
  • Delivers notifications to client devices
  • Accepts responses from clients
  • Routes responses back to originating services via webhooks
  • Enforces security policies and rate limits
The ATP server maintains the source of truth for notification states while remaining stateless in its request handling. It serves as the trusted intermediary between services and clients, ensuring proper authentication and authorization at all boundaries.

​
2. Service SDK

Client libraries enabling AI services to:
  • Send notifications to the ATP server
  • Receive responses via authenticated webhooks
  • Handle notification lifecycle events (expiration, invalidation)
Service SDKs abstract away the complexity of the ATP protocol, allowing developers to focus on their service logic rather than communication details. These libraries handle authentication, request formatting, and response processing automatically.

​
3. Client SDK

Libraries for end-user applications to:
  • Receive notifications via WebSocket, Server-Sent Events (SSE), or polling
  • Display appropriate UI based on response types
  • Submit user responses to the ATP server
  • Handle error conditions and retries
Client SDKs ensure a consistent user experience across different platforms while implementing the protocol’s security requirements and handling edge cases like network failures or expired notifications.

​
Notification Lifecycle

The protocol defines five distinct states for notification entities: State transitions are unidirectional and atomic. Notifications may transition to terminal states (Expired or Invalidated) based on temporal constraints or service-initiated state changes. Understanding each state helps implementers handle edge cases correctly:
  • Created: The ATP server has accepted and stored the notification
  • Delivered: Confirms client receipt of the notification
  • Acknowledged: Represents user awareness (optional tracking)
  • Responded: Indicates user decision submission
  • Completed: Confirms successful delivery to the originating service
  • Expired: Occurs when deadlines pass without response
  • Invalidated: Happens when services explicitly cancel notifications due to changed circumstances

​
Service Registry

Each AI service must complete a registration process with the ATP server to establish authenticated communication channels. Registration provides:
  • Cryptographic credentials for secure API access
  • Callback endpoints for response delivery
  • Service metadata for client display
  • Operational capabilities and limitations
This registration process creates a secure trust relationship between the ATP server and each service, enabling proper routing and authentication of messages throughout the system.
⌘I