Overview
This document defines the minimum requirements for ABP conformance. Use this as a checklist before implementing or shipping ABP support. Key words: The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are defined in RFC 2119. In brief:- MUST / REQUIRED — An absolute requirement. Implementations that fail this are non-conformant.
- SHOULD / RECOMMENDED — There may be valid reasons to ignore this in particular circumstances, but the implications must be understood.
- MAY / OPTIONAL — Truly optional. Implementations may or may not include this.
App Conformance
Required (MUST)
An ABP-compliant web application MUST:Serve a manifest link
Include
<link rel="abp-manifest" href="..."> in the HTML <head>.
See Discovery Guide.Serve a valid manifest
A JSON file with
abp, app (containing id, name, version), and capabilities fields.
See Discovery Guide.Expose window.abp
An object on the global
window implementing the ABP interface.
See API Reference.Implement initialize()
Accept agent identification and return session info with capabilities.
See Protocol Overview.
Implement shutdown()
Clean up session resources.
See API Reference.
Implement call()
Execute capabilities and return
ABPResponse with success, data or error.
See API Reference.Return actual data
Every capability MUST produce its declared output in the
ABPResponse. Capabilities MUST NOT return status messages describing side effects (e.g., “print dialog opened”) instead of actual output.
See Common Pitfalls: Status Messages.Never trigger native UI
Capabilities MUST NOT call
alert(), confirm(), prompt(), window.open(), or trigger programmatic downloads. window.print() is allowed only as a transport signal for PDF generation.
See Common Pitfalls: Native Browser UI.Handle deprecated capabilities
Deprecated capabilities MUST remain functional for at least one major version before removal.
See Capability Taxonomy.
Recommended (SHOULD)
An ABP-compliant web application SHOULD:-
Implement
listCapabilities()andsupports()for runtime discovery- Allows agents to query capabilities dynamically
- See API Reference
-
Support notifications via
notify()andnotifyProgress()- Enables real-time updates to agents
- See Elicitation & Progress
-
Support elicitation via
elicit()for requesting input from agents- Allows capabilities to ask for user preferences or confirmation
- See Elicitation & Progress
-
Validate inputs against declared
inputSchemabefore executing capabilities- Prevents invalid data from causing errors
- See Building ABP Apps: Parameter Validation
-
Declare requirements for permission-gated capabilities
- Lets agents know what conditions must be met
- See Security Considerations
Client Conformance
Required (MUST)
An ABP-compliant client implementation MUST:Discover apps
Fetch HTML
<head>, parse the <link rel="abp-manifest"> tag, and fetch the manifest JSON.
See Discovery Guide.Initialize sessions
Call
window.abp.initialize() with agent identification and feature flags.
See Protocol Overview.Call capabilities
Use
window.abp.call() and handle ABPResponse (check success, read data or error).
See API Reference.Shut down cleanly
Call
window.abp.shutdown() when done.
See Protocol Overview.Use standard Puppeteer function names
Client implementations using Puppeteer/Playwright MUST use these function names for interoperability:
__abp_notification, __abp_progress, __abp_elicitation, __abp_capabilities_changed.
See API Reference.Verify capabilities at runtime
Clients MUST NOT trust manifest capabilities without runtime verification via
initialize().
See Security Considerations.Never execute manifest-referenced code
Clients MUST NOT execute code or scripts referenced in manifests.
See Security Considerations.
Never grant permissions from manifest alone
Clients MUST NOT grant permissions based solely on manifest claims.
See Security Considerations.
Recommended (SHOULD)
An ABP-compliant client implementation SHOULD:-
Support both headless and headful browser modes when using Puppeteer/Playwright
- Some capabilities require a visible browser (authenticated sessions, GPU, permissions)
- Default to headless; allow headful as an option
- See Architecture Guide: Browser Requirements
-
Handle notifications — Set up
page.exposeFunction()for__abp_notificationand__abp_progress -
Handle elicitation — Set up
page.exposeFunction()for__abp_elicitationto respond to app requests -
Handle binary data — Process
BinaryDataandBinaryDataReferenceresponses -
Handle errors — Implement retry logic for retryable errors with exponential backoff
- See Error Handling
-
Handle version mismatches gracefully — Agents SHOULD handle manifest protocol version mismatches according to the version compatibility rules
- See Discovery Guide
Verification
Verifying App Conformance
Manual test in browser console:Verifying Client Conformance
-
Discovery test:
-
Session lifecycle test:
-
Capability call test:
Common Conformance Failures
For Apps
| Failure | Symptom | Fix |
|---|---|---|
| No manifest link | Discovery fails | Add <link rel="abp-manifest" href="/abp.json"> to <head> |
| Invalid manifest | ”Invalid manifest structure” | Ensure abp, app.id, app.name, app.version, capabilities fields exist |
window.abp undefined | ”window.abp not found” | Load ABP runtime before other scripts |
| Status messages instead of data | Calls succeed but return useless output | Return actual data (see Common Pitfalls) |
| Native UI calls | Calls hang indefinitely | Remove alert(), confirm(), prompt() (see Common Pitfalls) |
For Clients
| Failure | Symptom | Fix |
|---|---|---|
| Headless mode | Permission-gated capabilities fail | Use headless: false |
Not checking success flag | Crashes on error responses | Always check if (result.success) |
| Not handling retryable errors | Gives up on transient failures | Check error.retryable and retry with backoff |
| Large data through context | Agent performance degrades | Route large outputs to files (see Data Flow) |