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.