Trust Is the Rail

Payments Move at the Speed of Trust

In 1871, if you wanted to send money from New York to San Francisco, the fastest legal option was to walk into a Western Union office and hand a clerk your cash. What happened next was something completely new. The clerk did not put your money on a train that crossed the country. Instead, something stranger and more durable took hold. The New York clerk telegraphed a signed, coded instruction to an office at the destination, and a San Francisco clerk paid your recipient from Western Union's own cash drawer after verifying identity against a password included in the message.

The payment time across that distance was reduced by weeks because of a simple instruction sent over a wire. The reason the instruction was worth honoring was that the receiving clerk believed the sending clerk. They both worked for a company whose name, procedures, and network of offices made the message trustworthy. As you have probably guessed by now, this is where the term wire transfer comes from.

While wire transfers enable money to move quickly, it is important to note how long that trust took to build. Western Union spent the 1850s consolidating smaller telegraph companies. Its transcontinental telegraph was completed on October 24, 1861, when the line connected the country and ended the Pony Express within days. Western Union introduced money transfer over that same telegraph network in 1871. The wire infrastructure was built in a decade. The trust to move value across it took another.

In other words, payments move at the speed of trust and always have. Wire transfers today settle quickly because two banks trust a shared rail where information is transparent and easily verified. Similarly, real-time gross settlement systems like Fedwire facilitate payments by concentrating settlement trust in one place. Cross-border payments can take days because trust degrades across correspondent hops, where each party reconciles, records, and re-verifies. When payments drift into lower-trust territory, systems add gates and guardrails: escrow, dual approvals, and pre-funded nostro accounts.

A quick mental model for me is that payment systems flow freely when trust is concentrated and are forced to reconcile when trust is distributed.

Agents Distribute Trust

Which brings me to agents and what I have been up to recently.

For a year now, the loud advice on building agent systems has been to push reasoning into the agents themselves. Each agent owns its domain, plans its own work, decides when it is out of scope, and coordinates with peers. On paper, it is beautiful to see 100 agents fan out to do long-horizon tasks and deep research. In practice, each additional agent further distributes the trust surface. Consequently, every new trust boundary becomes a place where reasoning pauses and reconciliation starts.

Anthropic published the receipts in its write-up on building a multi-agent research system. Its Research system uses an orchestrator that fans out to parallel subagents. It also costs about 15 times the tokens of a chat interaction. Not because subagents are wasteful, but because trust across agents is expensive. Each subagent gets its own context to be trusted with, its own reasoning that has to be reconciled at the end, and its own possibility of drifting from the shared frame. Anthropic names a specific anti-pattern: domains that require every agent to share the same context or depend heavily on each other are a poor fit for multi-agent systems today. For payments, it means we should not distribute the ledger.

Distributing the ledger means we end up with fractional records of transactions and balances across multiple parties and entities, much like how every bank keeps its own books in a transaction between banks. This is the large problem Bitcoin and cryptocurrency were trying to solve. When different agents hold separate pieces of payment-related context or truth, we return to the quagmire of deciding which source of truth to trust and how to tie out the differences.

Cognition, the team behind Devin, makes the same argument in principle form in Multi-Agents: What's Actually Working. Two rules stand out: share context, and remember that actions carry implicit decisions. Translated into trust language, the trust envelope must cover the full trace, and every unrecorded decision is a place your trust silently erodes.

The Orchestrator as Clearing House

At work, we are building conversational AI for Fortune 100 treasury teams that move serious money every day. We are starting with conversational AI for navigation, payment search, authentication, entitlement management, and reconciliation workflows. The larger goal is to move large amounts of money agentically by using AI to compress what Western Union had to build across two decades: the infrastructure decade and the trust-building decade. Until strong guardrails and evals are in place, the primary goal is to build trust by allowing users, and eventually agents, to reconcile at every step.

Workflow components like finding a payment and amending a payment could, in theory, be handed to two smart agents and left to negotiate the order of operations and the outcome. That would fit neatly under the current dogma of agent swarming and A2A protocols.

That is not the choice we have made to start with. Instead, we rely on a central orchestrator that acts as our clearing house. It holds the shared context, resolves entitlements at each step, plans the two branches in sequence, and reconciles their outputs, including API errors or requests for more information, into one coherent answer. The agents themselves are surprisingly thin by design. Our payment search agent is a declarative state machine, not a reasoning loop. Our FAQ agent retrieves and cites. Neither classifies intent nor decides what should be routed to it. That work happens in our orchestrator where the trust lives.

The tradeoff is that the cost to earn incremental trust is real. Adding a new domain means teaching the orchestrator, mapping out fuzzy unhappy paths, and deciding how to return the user to success. It would be much easier to ship a self-contained agent and rely on distributed reasoning. It would also mean the downstream effects are that we distributed the audit trail across services that do not share entitlement state. Any internal control function or external regulator would rightly ask us to prove the trust boundary at every hop.

The instinct to make agents smart is really the instinct to distribute trust. In consumer research assistants, where the failure mode is a wrong citation, that instinct can be fine. In regulated treasury, where the failure mode is an unauthorized payment or a mis-scoped disclosure, the risk vs reward equation completely flips.

The heuristic I would hand another PM building in a regulated environment is short. Push a reasoning capability into an agent only when the trust boundary genuinely belongs there. This may look like a domain-shaped signal like an entitlement violation or a scope rejection, where the orchestrator would have to duplicate the agent's model to compute it. Everything else, including intent, decomposition, retry, clarification, handoff, and aggregation, should start at the orchestrator where trust is concentrated.

Western Union did not become a household name because it laid the fastest copper. It became a household name because when a clerk in San Francisco read a coded telegram from New York, they honored it. Reasoning is the same. Your agents move as fast as your trust does.