Documentation

Documentation is the durable reference layer for vespid.ai: the parts of the project that should still make sense after launch notes and one-off debates stop being enough.

Featured guide

Vespid quickstart

Start here if you want the shortest path from clone to a live HTTP demo: install dependencies, run the gateway and appointment service, then inspect the discovery, grant, approval, artifact, and audit flow end to end.

install run demo inspect flow

Project

See the full project surface

Move back to the project page when you want the architecture summary and public entry points around the repo.

Blog

Read the reasoning

Use the blog when you want the product and architecture decisions behind the docs, not just the durable mechanics.

3 core references The docs stay intentionally small so every page explains something structural about the contract or gateway model.

1 local demo path Everything routes back to the same ordinary-HTTP quickstart instead of diverging into adapter-specific setup guides.

1 contribution surface Support and feedback should start from reproducible contract or runtime questions, not abstract “agent platform” requests.

Core references

The current documentation spine

If you read only three pages, they should tell you how to run the prototype, how the contract and gateway fit together, and how to propose work without losing the trust-boundary assumptions behind the project.

Quickstart

Run the prototype

Clone the repo, start the demo, and inspect the live HTTP flow before debating adapters or packaging.

Contract model

Understand the contract and gateway boundary

Use the contract model page to understand why the service contract stays canonical and the gateway keeps enforcement in band.

Support

Propose work that can be reproduced

Use the support page for issues, documentation gaps, and new demos that are grounded in the existing HTTP runtime story.

Reading path

Start with quickstart

Read Vespid quickstart first for the smallest useful local workflow.

Then read the model

Use Contract and gateway model to make sure the contract surface and runtime semantics stay aligned.

Then return to the repo

Move back to vespid whenever you need the public code surface behind the documentation.

Operating rules

Rule

Stable

Ordinary HTTP first

The supported v0.1 agent path is generic HTTP through the gateway runtime, not a new framework-specific client surface.

Rule

Stable

The contract is canonical

The service manifest, OpenAPI document, and x-agent-* extensions define what downstream adapters are allowed to project.

Rule

Stable

Gateway enforcement stays in band

Authorization, approval, task resume, artifacts, and audit should stay visible in the runtime path instead of being hidden behind adapter magic.

Rule

Stable

Adapters come later

MCP, skills, actions, A2A, and UI projections can exist later, but they have to inherit the same contract and gateway semantics.