Federation: Cross-Boundary Accountability

Agents don't stay inside one company. Your accountability infrastructure shouldn't either.

The Problem

When your procurement agent delegates to a vendor's fulfillment agent, the audit trail breaks at the organizational boundary. If a regulator, auditor, or customer asks "who approved this cross-company transaction, what were the acceptance criteria, and was the result verified?" — you cannot answer that question today.

Each side has its own systems, its own data, its own compliance obligations. But accountability — who committed what, who delivered, who accepted — needs to be continuous across all of them. Structured accountability across boundaries also reduces failed handoffs and rework between organizations, because both sides work from the same explicit criteria.

Federation solves this. It extends AGLedger's accountability chain across organizational boundaries while keeping each organization's data under its own control.

How It Works

Federation connects multiple AGLedger instances through a coordination layer. Each instance is authoritative for its own data. The coordination layer handles routing, synchronization, and reputation — never the underlying business content.

Three Building Blocks

Gateway — Your AGLedger instance, running in your infrastructure. It handles everything locally: mandates, receipts, verification, the audit vault. When you're ready to work across boundaries, the Gateway connects to a Hub. Nothing changes about how it works internally — it just gains the ability to send and receive mandates from other organizations.

Hub — A coordination node that connects Gateways. It maintains an agent directory (who can do what), routes mandate offers between Gateways, relays Settlement Signals, and aggregates reputation scores. It never holds your mandate criteria, receipt evidence, or audit trail.

Peering — Two Hubs can connect directly. Your Hub can peer with your supplier's Hub, your auditor's Hub, or any partner's Hub. Neither organization needs AGLedger as an intermediary. They run the same software under license and coordinate directly.

The Flow

When Agent A at Company X needs to create a mandate for Agent B at Company Y:

Company X                                          Company Y
┌──────────────────┐                        ┌──────────────────┐
│                  │                        │                  │
│  Agent A creates │    ┌──────────┐        │  Agent B receives│
│  mandate locally │───▶│   Hub    │───────▶│  mandate offer   │
│                  │    │ (routes) │        │                  │
│  Full criteria   │    └──────────┘        │  Accepts, does   │
│  stored here     │         │              │  work, submits   │
│                  │         │              │  receipt locally  │
│  Vault records   │◀────────┘              │                  │
│  everything      │   Settlement signal    │  Vault records   │
│                  │   routed back          │  everything      │
└──────────────────┘                        └──────────────────┘

Agent A creates a mandate on Company X's Gateway — full criteria, tolerance bands, deadline. Stored locally, recorded in the vault.
Company X's Gateway sends a mandate offer through the Hub. The offer contains the mandate ID, contract type, and a cryptographic commitment to the criteria — not the criteria themselves.
The Hub routes the offer to Company Y's Gateway based on the agent directory.
Agent B accepts the offer. The criteria are transferred directly between Gateways using end-to-end encryption — the Hub cannot read them.
Agent B does the work, submits a receipt. Company Y's Gateway verifies it locally.
The verification outcome and Settlement Signal route back through the Hub to Company X.
Both sides have independent, complete audit trails in their own vaults.

The key insight: Each organization verifies locally and records locally. The Hub coordinates — it doesn't centralize.

Your Data Stays Yours

This is the core design constraint. Federation is built on a strict privacy boundary.

What crosses organizational boundaries

Agent IDs (for routing)
Mandate IDs (for correlation)
Contract types (for matching capabilities)
State transitions (created, active, fulfilled — not the underlying data)
Verification outcomes (pass/fail — not the evidence)
Settlement signals (settle/hold/release)
Reputation scores (aggregate reliability, accuracy, efficiency)
A cryptographic hash of the criteria (proves commitment without revealing content)

What never crosses

Mandate criteria — your acceptance terms, tolerance bands, business logic
Receipt evidence — the work product, deliverables, attestations
Audit vault entries — your signed, hash-chained accountability trail
API keys or credentials
Webhook URLs or delivery payloads
Prompts, context, or internal business logic

When criteria need to be shared between Gateways (so the performing agent knows what to do), they are transferred using end-to-end encryption with forward secrecy. The Hub relays the encrypted payload but cannot decrypt it — even if it is compromised after the fact.

Every Hub is a witness, not a custodian. It witnesses state transitions and aggregates reputation. It never holds your data.

Deployment Scenarios

Federation is not all-or-nothing. You start where you are and grow into what you need.

Scenario 1: Internal Pilot

┌─────────────────────────────┐
│  Your Infrastructure        │
│                             │
│  ┌─────────────────────┐    │
│  │  AGLedger            │    │
│  │  (Standalone mode)   │    │
│  └─────────────────────┘    │
└─────────────────────────────┘

One instance, no federation. Your agents create mandates, submit receipts, get verified. Full audit trail. Zero network dependencies beyond your database.

Scenario 2: Multi-Business-Unit

┌────────────────────────────────────────────────┐
│  Your Infrastructure                           │
│                                                │
│  Gateway A ──────┐                             │
│  (Procurement)   ├──── Your Hub                │
│                  │     (internal)              │
│  Gateway B ──────┘                             │
│  (Logistics)                                   │
└────────────────────────────────────────────────┘

Multiple instances, one Hub, all internal. Procurement's agents create mandates for Logistics' agents. The Hub coordinates. Everything runs inside your network.

Scenario 3: Cross-Enterprise

┌──────────────┐              ┌──────────────┐
│  Your        │              │  Partner     │
│  Gateway ────┼── Your Hub ──┼── Partner   │
│              │   peers with │  Gateway    │
└──────────────┘              └──────────────┘

Direct peering between two enterprises. Your Hub connects to your partner's Hub. Neither side sees the other's business data. No third party is involved.

Scenario 4: Industry Network

Gateway ─┐                         ┌─ Gateway
         ├── Enterprise Hub ──┐    │
Gateway ─┘                    │    │
                              ├── AGLedger Global Hub
Gateway ─┐                    │    │
         ├── Enterprise Hub ──┘    │
Gateway ─┘                         └─ Small Company Gateway

Multiple Hubs, peered through the AGLedger Global Hub. Large enterprises run their own Hubs. Smaller companies connect Gateways directly. Cross-industry reputation and agent discovery available to everyone who opts in.

The Global Hub is an optional service operated by AGLedger. It follows the same privacy boundary — no business data crosses, only metadata.

The Trust Model

Federation is designed so that no single entity — including AGLedger — controls the network.

Anyone Can Run a Hub

A Hub is not a special service. It's the same AGLedger software with the coordination module enabled. Any enterprise can run a Hub. AGLedger operates an optional Global Hub for cross-industry reputation and agent discovery, but it is not required.

This means:

No vendor lock-in. Your federation topology is your choice.
No single point of trust. Each Hub only sees the metadata it routes. Each Gateway verifies independently. No Hub can forge state transitions — they are cryptographically signed by the originating Gateway.
No single point of failure. If a Hub goes down, Gateways continue processing mandates locally. State transitions queue durably and deliver when connectivity resumes.

Cryptographic Guarantees

Federation security doesn't depend on trusting the Hub:

Registration: RFC 9421 HTTP Message Signatures with Ed25519 proof-of-possession.
Ongoing authentication: Short-lived bearer tokens refreshed every 5 minutes.
State transitions and Settlement Signals: Signed per-request with Ed25519. The Hub relays but cannot forge.
Criteria transfer: End-to-end encrypted with X25519 ephemeral key agreement. Forward secrecy — the Hub cannot decrypt, even retroactively.
Revocation: Gateway credentials rotated or revoked within one heartbeat cycle.

Reputation Without Exposure

Federation includes a cross-boundary reputation system. Each Gateway contributes anonymized verification outcomes (pass/fail rates, timeliness, accuracy). The Hub aggregates these into reputation scores that any participant can query.

This lets you answer "should I trust this agent?" without revealing what you've asked it to do.

Anti-gaming protections include a 30-day Gateway age requirement, logistic confidence scoring, and per-Gateway contribution limits.

The Growth Path

| Where You Are | What You Run | What Changes | |---------------|-------------|-------------| | Evaluating | Standalone instance | Nothing. Full product, no federation overhead. | | Internal rollout | Multiple Gateways + your Hub | Add AGLEDGER_MODE=hub to one instance. Register Gateways. | | Partner integration | Your Hub peers with partner's Hub | Bilateral agreement. Exchange peering tokens. One API call per side. | | Industry participation | Your Hub peers with Global Hub | Sign up. Configure peering. Opt in to cross-industry reputation. |

At every step:

Zero data migration. Existing mandates, receipts, and vault entries stay where they are.
No downtime. Standalone to Gateway mode is a configuration change and restart.
No code changes. The same API works identically in federated mode. New capabilities are additive.
Backward compatible. A Gateway that loses its Hub connection continues operating as Standalone.

Licensing

Federation is included in the AGLedger Enterprise license tier. Gateway and Hub modes are configuration changes to the same software — there is no per-node fee or per-Gateway surcharge. You purchase a $8,000 perpetual license per unique database instance. HA replicas included. Security fixes are always free. $4,000/year support covers updates and new versions.

What Federation Is Not

Not centralization. No master database, no central authority. Each Gateway is authoritative for its own data.
Not required. Most customers start Standalone and many stay there.
Not data exposure. The privacy boundary is cryptographically enforced, not policy-enforced.
Not a marketplace. It doesn't match agents to tasks. It provides accountability for organizations that have already decided to work together.
Not vendor dependency. Your data lives in your PostgreSQL database. Your vault entries are verifiable with standard Ed25519 tooling.
Not AGLedger-intermediated. Two licensed organizations can peer directly. The Global Hub is optional.

Security Architecture — Cryptographic details, threat model, compliance mapping
Why Federation — Business case for cross-boundary accountability
AOAP Protocol — The accountability protocol that federation extends across boundaries
Pricing — Federation licensing details

Federation is included in the AGLedger Enterprise license. Same $8,000 per unique database instance — no surcharge. Contact us with questions.