Browse documentation
Architecture
Roles, trust boundaries, and the shape of an AQP exchange.
Participants
Authors a bounded query about one subject.
Supplies the declared answer.
Presents queries, mediates humans, and applies local policy.
Validates, stores decisions, and acknowledges responses.
The party authorized to use the answer.
A single system may perform multiple roles, but implementations must not assume the roles share identity, storage, authority, or trust.
Exchange
The surrounding conversation or product interaction is outside the AQP core. A follow-up is a new bounded request linked by continuationOf, not an unbounded conversation turn.
Trust boundaries
Prompts, subjects, response contracts, continuations, and delivery endpoints are untrusted input. Respondents must validate exact schemas, authorize destinations, enforce local policy, and avoid transferring unrelated context. Collectors must authenticate submission authority, prevent replay, and treat answer content as untrusted.
Storage
AQP defines exchange objects, not a database, queue, or analytics API. Implementations may store and aggregate responses, but retention, search, workflow automation, memory, and training pipelines remain implementation concerns unless a future extension standardizes them.