Multi-Agent Signals — Data Alignment FAQ

When autonomous AI agents owned by different principals interact over shared infrastructure, the critical unsolved problem is not fetching their outputs — it is aligning them. Every existing multi-agent framework (LangChain, CrewAI, and others) retrieves agent outputs and concatenates them into a context string before handing that string to a synthesis model. There is no step between fetch and synthesis that detects conflicts, flags stale data, enforces delegation scope, or weights reliability by reputation. The result is silent error propagation: contradictions become invisible assumptions embedded in downstream decisions, payments, and outputs that no one can audit.

Multi-Agent Signals (MAS) solves this by interposing a dedicated Alignment Coordinator between the Signal Engine (concurrent agent fetch) and every downstream artifact. No output is permitted to reach synthesis, payment authorization, or any decision surface until the Coordinator has produced a Canonical Aligned State — a versioned, conflict-annotated, attribution-complete data object that makes every contribution traceable and every disagreement explicit.

Secondary risks — Sybil insertion, stale data, scope violations, and economic collusion — are addressed as consequences of this alignment-first architecture, not as separate systems bolted on afterward.

Multi-Agent Signals is the domain-agnostic base layer of the Signals platform family. Every vertical in the family inherits its alignment primitives from Multi-Agent Signals:

• cSignals (Chemical Signals) — a live specialty chemicals and petrochemical market intelligence platform. It is the production proof that the alignment architecture works under real data pressure: concurrent agents fetching commodity prices, FRED macro data, industry news, and feedstock chain formulas, with the Alignment Coordinator detecting leading indicator gaps, freshness mismatches, and confidence penalties daily.
• pSignals (Payment Signals) — the agent commerce and payment-authorization vertical, extending MAS toward the boundary where an aligned decision becomes a settled, on-chain transaction on Circle’s Arc L1. See the pSignals FAQ for the settlement-specific questions.
• Signals v3 / CSEE — an enterprise intelligence fork for organizations coordinating multiple internal agents across ERP, procurement, contracts, and external market signals.

Critically, the Alignment Coordinator does not know what domain it is aligning. It operates on typed AgentOutput structs regardless of whether those agents are fetching crude prices, clinical data, procurement bids, or financial research. The safety primitives Multi-Agent Signals validates generalize to every domain where competing principals must coordinate over shared data.

The platform is built around one central component and three supporting layers:

Core: Alignment Coordinator

The primary scientific contribution. Sits between the Signal Engine and every downstream artifact. Before any output is permitted to proceed — to synthesis, payment, decision, or storage — the Coordinator runs four operations:

1. Freshness Reconciliation (rule-based): Each agent’s fetched_at timestamp is compared against its registered TTL. Stale agents are flagged. Combinations of stale and fresh agents on the same query are flagged as freshness_mismatch.
2. Conflict Detection (gemma3:4b, temp 0.0): All agent outputs are compared for contradictions, leading indicator gaps, and directional mismatches. Conflicts are annotated and preserved — never silently resolved.
3. Reputation Weighting (rule-based): Each agent’s confidence score is weighted by its accumulated reputation history. Reliable contributors carry more weight over time.
4. Canonical Aligned State: The versioned, attributed, conflict-annotated output object. Every data point is traceable to its source agent and principal. Confidence is penalized −0.1 per conflict and −0.05 per stale agent.

Supporting: Agent Registry

Validates identity, wallet addresses, scope constraints, and reputation scores before any agent enters the pipeline. No unregistered agent participates.

Supporting: Payment Authorization Gate

Reads from the Canonical Aligned State — not independent logic — to authorize, reduce, hold, or refuse USDC micropayments based on the Coordinator’s alignment quality assessment. The concrete, as-built settlement mechanics for this gate are documented in the pSignals FAQ.

Supporting: ZK-Provenance Boundary (ADP 8.5)

Links to ALI’s Alignment Delegation Protocol. Halo2 or Groth16 zero-knowledge proofs are designed to certify that each agent’s output was derived from a verified, bounded knowledge base without parameter drift, with the proof hash anchored on-chain alongside the Canonical Aligned State. This is a cryptographic upgrade path, not a current MVP dependency.

The project is directed by a core interdisciplinary research team:

• Dr. Gabriel Axel Montes (Lead PI): Neuroscientist and AI alignment lead with 15+ years experience scaling R&D teams. Board Member at the Aligned Sovereign Intelligence Institute (ALI) and Founding Program Director for AGI at the California Institute for Human Science (CIHS).
• Anthony Monroy (Co-PI / Operational Lead): CEO of ALI, systems architect who designed the core Signals alignment coordinator.
• Dr. Sarah Grace Manski (Co-Investigator): COO of ALI, governance and trust policy specialist, advisor to the Pentagon and White House.
• Dr. Mahault Albarracin (Co-Investigator): Adjunct Professor at UQAM, cognitive science and explainable AI researcher.

Every existing tool in this space fails the multi-principal case for a structural reason — not a roadmap gap:

• Palantir AIP — the closest production system — delivers strong governance within a single organization’s Foundry ontology. It cannot support multi-principal networks because no competing organization will put their proprietary agent outputs into another party’s Foundry instance. The multi-principal problem requires a neutral coordination layer owned by neither principal. Palantir’s architecture structurally prevents this.
• LangChain / LangGraph / CrewAI — retrieve and concatenate. There is no coordination step between agent fetch and synthesis. Conflicts are assembled silently into context strings. No freshness enforcement, no reputation weighting, no attribution, no economic consequence.
• Alteryx / SAP IBP — data preparation and enterprise planning tools. No agent coordination concept, no concurrent fetch, no conflict detection, single-tenant by design.

The gap all of these tools share: none interpose a dedicated alignment layer between concurrent agent fetches and the downstream artifacts those fetches produce. The Alignment Coordinator is that layer — and it is the component that is absent from every existing framework.

This project addresses the Schmidt Sciences “Scaling AI Safety for a Multi-Agent World” call. It provides empirical benchmarking for Cluster 1 (Sandboxes and Testbeds), Cluster 3 (Strengthening Agent Infrastructure, such as identity and reputation), and Cluster 4 (Oversight and Control, such as dynamic conflict detection and economic gating).

The Alignment Coordinator receives inputs concurrently from the fetch engine. It extracts the raw telemetry and runs a rule-based check verifying the fetched_at timestamp against the registry’s TTL parameters. If the data is fresh, it prompts a local instance of Gemma 3 (4B) to check for numerical and logical contradictions. Inconsistencies are categorized, penalizing the average confidence score and routing alerts to the execution logs.

We leverage local containerized model hosting. The coordinator, PostgreSQL database, and routing agents run entirely within the private VPC. External agent data is ingested via secure HTTPS connections and processed locally. No raw prompt payloads or database rows are sent to public commercial model endpoints.

• Runtime: Docker Desktop & Python 3.10+
• Database: Supabase/PostgreSQL with pgvector for tracking registries and historical logs
• Local Models: Ollama hosting gemma3:4b (orchestrator) and deepseek-r1:14b (synthesis)

For the payment-settlement stack specifically — Arc L1 RPC nodes, the ERC-4337 pipeline, and the isolated signer service — see the pSignals FAQ.