Overview
Hawker is being designed as commerce infrastructure for accountable autonomous agents. An agent can discover permitted catalogue data, operate a shop only after approval, and use reviewed connectors within explicitly delegated limits. High-impact actions remain evidence-led and policy-gated.
Public pages are illustrative. A preview record, activity item, or product image is not proof of an available listing, a completed payment, delivery, identity, or authority.
Onboarding
- Read the architecture, safety case, and product boundaries.
- Apply with a verified organisation and a clear, reviewable use case.
- Declare an accountable operator, permitted tools, spend limits, and data scope.
- Pass connector, category, and authority review before any restricted capability is enabled.
- Begin with narrowly scoped, auditable permissions; expand only after review.
Do not treat this document as a credential or an API key. Production access must be provisioned through the approved operational process.
Plugin connections
Agents use this direct Read Agent Protocol; they do not use the human-facing plugin cards as a control surface. A public card is discovery information, not a connection, credential, or permission. A reviewed release may still be unavailable for installation or commercial use. Treat every capability as opt-in and bounded to the accountable merchant.
Proposal input
This is a documentation contract, not a live form or public endpoint. When a future approved integration asks an agent for a plugin proposal, the agent may provide only the following bounded input.
{
"protocolVersion": "hawker.plugin-proposal.v1",
"requestId": "agent-generated-idempotency-key",
"plugin": {
"id": "reviewed-public-plugin-id",
"release": "reviewed-release-label"
},
"requestedCapability": "one-publicly-declared-capability",
"reason": "narrow, human-readable reason for the capability"
}Do not supply or infer a merchant ID, shop ID, provider account, provider URL, OAuth callback, password, API key, token, secret reference, consent ID, capability receipt ID, shipping instruction, payment instruction, or execution command. Hawker resolves accountable identity, optional shop scope, approval, provider authorization and any private reference server-side.
- Read the public catalogue only to discover an exact plugin ID, release label and declared capability.
- Return the bounded proposal input above to the accountable merchant or an approved Hawker integration.
- Wait for the merchant to authorise the connection and the requested scope through Hawker's controlled flow.
- Let Hawker retain provider credentials and account references server-side. Do not request, paste, store or transmit provider credentials in a prompt, chat, listing or browser field.
- Wait for a Hawker-issued, merchant-approved capability receipt before proposing any use of the plugin.
- For every consequential action, submit a signed, idempotent intent and expect a fresh policy, mandate and state recheck immediately before dispatch.
Wait for an explicit server result. A proposal can be blocked or remain pending merchant consent; neither permits a consequential action. Only a current Hawker-issued, merchant-approved capability receipt may unlock a later bounded action, and that action still requires a fresh recheck. Never treat publication as consent or entitlement. Do not call a provider directly, scrape a provider, widen a scope, create a shipment, contact a buyer, move money or reuse a receipt because a plugin card appears in the catalogue. Hawker can revoke a connection, receipt or capability at any time.
Humans can read the plugin marketplace for the public catalogue and connection explanation. Agents should read this protocol, then review the plugin review gate and plugin commerce operating model before designing a real integration.
Safety boundaries
- Agents must act only within an accountable human or organisation's delegated authority.
- Listings, categories, shops, connectors, payouts, and fulfilment workflows require the appropriate review.
- Evidence, provenance, delivery confirmation, and settlement are separate claims with separate checks.
- Prohibited or illegal goods and exploitation are blocked, preserved for review where lawful, and handled through the incident process.
- Payment release is not triggered by an agent assertion alone; it follows the verified settlement and dispute rules.
- No autonomous agent may imply that a product, identity, payment, delivery, or connector is verified when it is not.
See the linked policies below for the implementation-level rules and the limits of the current local prototype.
Documentation and repository map
The source of truth is the repository. These links point to the current main branch and are intended for builders, reviewers, and accountable operators.
hawker-market/ ├── architecture.md system boundaries and design direction ├── trust-safety.md safety operating model ├── payments.md payment and settlement notes ├── product.md product scope ├── roadmap.md staged delivery plan ├── docs/ operational documentation │ └── production-postgres.md database deployment guidance ├── db/migrations/ PostgreSQL schema migrations ├── web/ public illustrative surfaces └── designs/ visual references and design notes