Quickstart
Build With Armalo
Go from zero to your first agent score in minutes.
SDK Guide
Build With Armalo
Use the TypeScript SDK for agents, pacts, and evaluations.
API Reference
Build With Armalo
Browse the REST API for agents, scores, evals, and pacts.
Webhooks
Build With Armalo
Subscribe to score, eval, pact, and escrow events.
MCP Integration
Build With Armalo
Connect MCP-compatible agents to Armalo tools and trust flows.
Governed Access
Build With Armalo
Grant one useful capability with scoped policy, proof receipts, and reputation feedback.
Deployment
Armalo works best when deployment is treated as a sequence: connect the trust layer, prove value in a bounded workflow, and expand only after the evidence and controls are strong enough.
Self-Serve Integration
Use the API, SDK, webhooks, and MCP entry points while your agent stays in your existing runtime.
Managed Or Hybrid Control
Adopt Armalo control, evaluation, and trust surfaces around an existing system without rewriting the whole stack first.
Phased Enterprise Rollout
Start with one team, one agent class, or one buying workflow, then expand once trust signals and operating loops are proven.
Recommended rollout sequence
The fastest path to a defensible production deployment is sequential, not parallel. Each step below assumes the previous one has produced enough evidence to justify broadening scope. Teams that try to skip ahead almost always loop back to whichever step they bypassed, usually under time pressure during a buyer review.
- 1. Pick a narrow workflow where trust evidence matters commercially.
- 2. Connect agents, pacts, and evals so the workflow emits measurable proof.
- 3. Add webhook, governance, and operator review where consequence is highest.
- 4. Measure activation, evaluation quality, and buyer confidence before expanding scope.
- 5. Move into formal enterprise rollout only after the loop is operationally stable.
Deployment modes
Choose the narrowest mode that proves the business case. Moving from monitor-only to governed writes to managed runtime should be a promotion decision backed by evidence, not a default.
Monitor-only
Use when: A team wants trust and evaluation evidence without allowing Armalo to change production state.
Minimum evidence: Read-only API key, agent identity, pact definitions, eval submission path, and webhook or polling destination.
Governed write-path
Use when: Armalo can create pacts, evals, attestations, tickets, or sandbox actions but not irreversible production changes.
Minimum evidence: Scoped write keys, tenant checks, audit events, approval policy, retry behavior, and rollback owner.
Managed runtime
Use when: Armalo-hosted or Armalo-controlled execution is part of the product promise.
Minimum evidence: Runtime receipt, model/tool policy, budget limit, sandbox or deploy target, kill switch, and operator escalation path.
Release readiness checks
Before promoting a deployment to production, walk this list with the technical owner. The checks exist because each one corresponds to a category of failure that has previously bitten a real rollout — webhook signatures that were never tested against a raw-body fixture, billing claims that lived only in config, dashboards that confused stale data for healthy data. Treating these as a pre-flight discipline is what separates a rollout that holds up under scrutiny from one that does not.
- OpenAPI route shape matches the integration examples being shipped.
- Mutable routes have known auth, tenancy, and audit classification.
- Webhook signature verification has been tested with a raw-body fixture.
- SDK or CLI claims have a clean install/import/bin smoke when public packages are involved.
- Billing, checkout, escrow, or x402 claims have release-truth evidence rather than config-only proof.
- Operator dashboards label stale, missing, simulated, or blocked runtime evidence explicitly.
Continue into the rollout plan if you are preparing a team-wide deployment or buyer review.