Build agent-native services over ordinary HTTP.

vespid keeps the service contract and the gateway trust boundary in the same runtime, so a generic agent can use normal HTTP without bypassing scoped access, approval, or audit evidence.

Current status: public reference implementation for local evaluation, not a production-ready control plane.

Open the project page

• ordinary HTTP
• scoped access
• audit evidence

MIT-licensed public repoThe code, docs, and site all point to the same public repository: vespid-ai/vespid.

Reference HTTP demo includedThe quickstart runs a local appointment service plus a gateway runtime and drives the full authorization and approval flow.

Public docs and issue pathQuickstart, contract docs, contribution guidance, and the issue tracker are all part of the public surface.

Quickstart

Go from clone to a full trust-boundary demo in minutes

The shortest useful path is not a slide deck. Clone the repo, run the local demo, then inspect how the runtime moves from discovery to grant, approval, artifact, and audit.

CLI path

Local

Run the current reference slice

git clone https://github.com/vespid-ai/vespid.git
cd vespid
npm install
npm run demo:http
npm test

DiscoverLoad capabilities from /.well-known/agent-service.json plus OpenAPI agent extensions.

Authorize + approveWatch confirmBooking hit awaiting_auth, then resume the same task after grant issuance.

Inspect evidenceFetch the final artifact and audit trail after the task succeeds instead of trusting a hidden control plane.

Project

Read the project page

Use the project page for architecture, trust boundary, and the shortest summary of what is real in the current prototype.

Documentation

Follow the exact flow

Use the docs when you want the contract model, route semantics, and the exact HTTP path behind the quickstart.

Rationale

Why HTTP comes before adapters

Read the architecture note when you want the reason the project keeps the gateway runtime primary before adding more surfaces.

What the runtime proves

Keep discovery, authorization, approval, and audit in the same story

vespid is not trying to be an abstract agent manifesto. The point of the current slice is to keep the service contract, gateway semantics, and evidence model aligned enough that a generic agent can use ordinary HTTP without bypassing the real trust boundary.

Contract

Core

Discoverable service surfaces

A service publishes a machine-readable contract through /.well-known/agent-service.json plus OpenAPI agent extensions.

Authorization

Core

Scoped temporary grants

Consequential actions stay blocked until the gateway sees a usable grant that matches the task binding and capability.

Approval

Core

Task resume instead of duplicate execution

The original task is resumed after grant issuance and approval, which is the key invariant behind the current HTTP demo.

Evidence

Core

Artifacts and audit logs

Successful runs return artifacts and append audit evidence so the result is inspectable after the action, not only during it.

Open-source surface

Start from the public proof, then go deeper

The homepage should answer the basic OSS questions immediately: where the code lives, how to run it, how to review the security posture, and where to contribute improvements.

GitHub

MIT

Browse the repository

Read the public codebase, tests, docs, and issue tracker directly from the canonical repository.

The code-first entry point for builders who want proof before prose.Open GitHub

Quickstart

Local

Run the reference flow

Use the quickstart when you want the shortest route from clone to discovery, grant, approval, artifact, and audit inspection.

The fastest way to validate the current thesis on your own machine.Open quickstart

Security

Policy

Review the security policy

Check the supported version policy, disclosure guidance, and the security-sensitive surfaces around grants, approval, and audit.

A real trust surface, not a generic “contact us” footer.Open security

Contributing

Open

Improve the current slice

Use the contribution guide for the most useful next work: contract clarity, gateway correctness, runnable proof, and docs ergonomics.

The best next stop if you want to help sharpen the trust boundary instead of widening scope blindly.Open guide