ProvelyStart with the quick start. Two lines guard an agent: the import and one instance. Then read how it works and the postures. The verification pages, the SDKs, the CLI, the MCP server, and the REST API follow.
| Page | Purpose |
|---|---|
| Quick start | Two lines guard an agent: the import and one instance. |
| How it works | Autodetect, plugins, checks, the five actions, and the decision log. |
| Postures | What Provely changes and what it only records: defense and guard_mode. |
| Rules | Optional. Audit, share and make exceptions to the checks that Provely builds at run time. |
| Coexistence | Provely beside your own retries, timeouts, validators and guardrails. |
| Failure modes | The families of agent failures, and which cases pass on every path. |
| Frameworks and paths | The plugins, their versions, and the measured result of each path. |
| Troubleshooting and FAQ | Start errors, plugin warnings, an empty log, and common questions. |
| Intent compilation | From an agent prompt to a signed completion contract. |
| Verdicts and retries | What each verdict means and what the agent may do next. |
| Integration compiler | How one vendor becomes one signed integration, in six stages. |
| Evidence receipts | What a receipt proves, and the checks the validator runs. |
| Pricing questions | What a metered action is, how the buckets pay, and what is always free. |
| SDKs | The TypeScript and Python SDKs and the canonical model. |
| CLI | The provely binary: scan, verify, status, receipt validate, mcp, init. |
| MCP server | The four tools: begin, verify, status, receipt. |
| API reference | The /v1 control plane endpoints. |
| Version support | How Provely tracks provider API, event, SDK, protocol, and agent host versions. |
| Integration uptime | What we record about a provider, and why a status feed never decides a verdict. |
| Security | The credential boundary: the agent writes, the verifier reads. |
| Run in production without a stored key | A cloud or CI identity buys a short-lived token, so no API key is stored. |
What is the verification loop?
Verification is a separate step from the checks. It proves that an action reached its outcome in the provider. Five calls make the loop, and your agent makes only the second one.
In words
- begin: the agent opens an operation against a contract and gets an idempotency key.
- act: the agent performs the side-effecting action with that key.
- action_result: the agent submits the provider acknowledgement.
- verify: the runtime observes the provider and returns a verdict.
- receipt: the runtime signs what it observed.
1. begin(contract, input) -> operation_id + correlation/idempotency metadata
2. act() -> the AGENT does the side-effecting action
3. action_result(operation_id) -> submit the provider acknowledgement
4. verify(operation_id) -> VERIFIED | PENDING | CONTRADICTED | FAILED | UNVERIFIABLE
5. status / receipt -> poll later; fetch the signed receipt