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.
Enterprise Rollout
The fastest path to production is usually not the broadest one. Armalo rollout works best when teams sequence pilot, diligence, and production expansion deliberately.
Phase 1: Bounded Pilot
Start with one workflow, one owner, and one measurable trust or governance problem. The goal is proof, not breadth.
Phase 2: Diligence And Controls
Review architecture, security, deployment, operator control, and evidence quality before broadening usage.
Phase 3: Production Rollout
Expand to additional teams or workflows once trust signals are decision-grade and the operator loop is sustainable.
What buyers usually need before rollout
Procurement teams across the buyers we've worked with converge on a similar short list of things they need to see before approving a broader rollout. The list is less about feature parity and more about whether the team can defend the decision internally. Treat the items below as the artifacts you should expect to be asked for, not the order in which to build them.
- A clear explanation of the trust and governance problem Armalo is solving.
- Evidence that pacts, evals, and controls are tied to real decisions instead of passive reporting.
- A deployment shape that fits the team’s current architecture and change tolerance.
- A procurement path with technical and commercial owners aligned on scope.
Rollout acceptance criteria
A pilot is ready to expand when it has decision-grade evidence across commercial value, security, runtime truth, operator workflow, and repeatability.
Commercial proof
The pilot has a named buyer decision, a measurable workflow outcome, and a before/after evidence packet.
Security proof
Auth, tenancy, webhook signatures, audit logs, and data-retention boundaries have been reviewed against the chosen deployment mode.
Runtime proof
Every production claim has a live or smoke-tested evidence source, and simulated evidence is labeled as simulation.
Operator proof
An owner can see failures, stale data, blocked actions, and rollback paths without reading code or asking an engineer to reconstruct logs.
Expansion proof
The second workflow reuses the same identity, pact, eval, audit, and rollout standards instead of becoming a one-off integration.
Owners to name before production
Rollouts stall most often not on technical questions but on unowned ones. Naming an explicit owner for each role below — even if one person wears two hats — collapses the ambiguity that otherwise re-surfaces every time a decision needs to be made. Each owner should be empowered to escalate, not merely to report.
- Executive sponsor: owns the business decision and signs off on expansion criteria.
- Technical owner: owns API keys, integration shape, runtime evidence, and deployment mode.
- Security reviewer: owns tenancy, auditability, webhook verification, and data boundaries.
- Operator owner: owns alerts, dashboards, review workflows, and rollback practice.
- Armalo owner: owns docs handoff, proof packet quality, and unresolved platform gaps.
Move from docs into rollout
If your team is already in buyer or pilot mode, the next best step is usually procurement guidance, pricing review, or a direct Armalo conversation.