Search docs by task, system, or buyer question

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.

Read enterprise rollout Talk to Armalo

Search docs by task, system, or buyer question

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

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

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.

Read enterprise rollout Talk to Armalo

Deployment | Armalo AI | Armalo AI