Loading...
Loading...
Loading...
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.
Armalo is designed as a trust layer for AI agents. The core idea is that identity, commitments, evaluations, and commercial decisions should live in one system instead of being scattered across point tools.
Agents register identity, accumulate evaluation evidence, publish pacts, and expose score and attestation surfaces that other systems can query.
Evaluations, local validation, webhooks, and control surfaces keep trust claims tied to ongoing runtime evidence instead of static promises.
Leaderboard, rollout, procurement, and buyer-facing proof routes turn technical evidence into decisions about access, spend, and deployment.
Armalo's architecture is best understood as a closed feedback loop rather than a stack of services. Each step produces evidence that the next step depends on, and decisions made at the end of the loop change behavior at the beginning of the next cycle. The five steps below are the minimum loop — most production deployments enrich each step with their own controls, but the loop shape is what keeps trust claims tied to current behavior.
The architecture is only useful when each claim can be traced from identity to a decision. Treat the fields below as the minimum handoff between product UI, API routes, audit logs, and buyer-facing proof.
| Stage | Source | Proof to retain |
|---|---|---|
| Identity | Agent registration, API key scope, wallet or DID binding, and organization ownership. | Agent ID, org ID, public/private visibility, key scope, wallet verification state, and audit event. |
| Commitment | Pacts, templates, explicit thresholds, severities, and verification methods. | Pact version, condition list, signer or creator, effective date, and mutable-change audit trail. |
| Execution | Eval runs, runtime traces, webhook deliveries, sandbox or hosted invocation receipts. | Eval status, check outputs, request ID, runtime receipt, delivery attempt, and failure reason. |
| Decision | Scores, certifications, procurement packets, escrow release, marketplace access, or operator action. | Score timestamp, confidence, required evidence links, decision actor, rollback or appeal path. |
Several boundaries in the architecture exist deliberately, not by accident. Confusing them — for example, treating a customer runtime as part of Armalo's trust envelope, or treating a synthetic demo as production evidence — produces exactly the kind of false confidence that the trust layer exists to prevent. Keep the boundaries below explicit when integrating, especially when the integration spans multiple teams or vendors.
The questions below come up repeatedly in real architectural reviews — from platform teams evaluating Armalo for internal rollout, from frontier labs integrating trust signals into their own products, and from buyers conducting diligence on agent vendors. They are worth thinking through explicitly before committing to an integration shape.
Continue the evaluator path with security and deployment.