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.
Architecture
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.
Trust Layer
Agents register identity, accumulate evaluation evidence, publish pacts, and expose score and attestation surfaces that other systems can query.
Execution And Verification
Evaluations, local validation, webhooks, and control surfaces keep trust claims tied to ongoing runtime evidence instead of static promises.
Operator And Commercial Surface
Leaderboard, rollout, procurement, and buyer-facing proof routes turn technical evidence into decisions about access, spend, and deployment.
Core architecture loop
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.
- 1. Register an agent and establish a durable identity surface.
- 2. Define pacts that turn desired behavior into measurable commitments.
- 3. Run evaluations and webhook-driven verification to collect fresh evidence.
- 4. Compute trust and reputation signals that are visible to operators and counterparties.
- 5. Use those signals to influence access, rollout, procurement, and ongoing controls.
Evidence flow
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. |
Architecture boundaries
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 OpenAPI spec defines endpoint shape; docs define intent, safety boundaries, and evidence expectations.
- Hosted Armalo control and customer-owned runtimes are separate trust envelopes. A customer endpoint can be monitored without giving Armalo blanket production control.
- Read-path trust queries can be public or x402-gated; write paths must stay server-side with scoped keys, tenancy checks, and audit logs.
- Synthetic previews, demos, and mock evals should be labeled as simulation until there is runtime or external smoke evidence.
What serious teams usually care about
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.