How Blue Works: Why the Graph Is the Application

In a familiar application architecture, one operator runs the logic, maintains the database, and tells everyone else what happened. A commercial relationship involves other businesses with their own systems, responsibilities, and authority.

A buyer’s application might consider an order confirmed when it submits a request. A supplier’s might consider it confirmed only after reserving inventory. Messages can arrive successfully while the businesses still disagree about their consequences.

Common platforms, integrations, and people bridge these differences. Blue asks how the shared process can become independently verifiable without requiring one participant or intermediary to own its implementation. HTTP and ordinary APIs can still carry the messages; the architectural choice concerns where the rules live and how participants establish the resulting state.

Smart contracts offered a compelling idea: several parties could interact through executable rules rather than rely entirely on an operator’s private backend. Public blockchains often bundled that idea with new accounts, wallets, cryptographic key management, and cryptocurrency-denominated execution fees.

Blue carries the shared-process idea into an architecture that can use businesses’ existing identities, financial infrastructure, and internal systems.

MCP and A2A are standardizing tool access, communication, and collaboration. They also address aspects of authentication and authorization. A shared commercial process still needs rules establishing what businesses have committed to and how those commitments evolve.

Our ambition is for an agent representing Company A to negotiate and make real deals with thousands of agents representing other companies. Those relationships must continue through orders, delivery, payments, changes, and exceptions.

What was agreed? Which actions are available? Whose authority permits an agent to act? Which evidence satisfies a payment condition?

If every new arrangement requires a separate application and bespoke integrations, coordination becomes a constraint on what agents can accomplish. Blue gives the shared relationship an executable structure, built from reusable definitions and connected processes.

The opportunity extends beyond delegated purchasing or payment initiation to ongoing commerce that businesses and their agents can operate together.

A conventional agreement describes a relationship. Separate software determines how its terms are carried out.

A Blue document can contain both the information and the executable process: participants, current state, available operations, and rules for responding to actions. An Order might permit cancellation while awaiting acceptance, then change the available operations once the supplier accepts.

The parties must agree on those executable rules. Blue does not turn an ambiguous paragraph into a settled commercial meaning simply because an agent reads it. The process specifies which actions and evidence have which consequences.

Documents can reuse shared definitions and clauses. Businesses can build on an existing Order definition and add the terms their relationship needs.

Content-derived identifiers called BlueIds identify exact document content and definitions. They derive from canonical Blue content, rather than superficial differences in its written representation. Referencing an agreed clause identifies that exact content; a changed clause has a different identity.

Processing is deterministic. Given the same starting document, required definitions, and eligible inputs in the same order, conforming processors produce the same result. Executable rules determine the transition; an AI model’s interpretation does not decide it.

Procurement software, a mobile app, an agent, and an audit tool can therefore present or operate the same process through different interfaces.

A shared process needs attributable histories of participants’ actions and that is where Timelines come in.

A Timeline is a personal, business, or agent history maintained by a trusted provider. You choose what to put in it and who to give access to. An entry can contain anything you wish to record; it does not have to relate to a Blue document.

The provider authenticates you, timestamps your submission, preserves the append-only history, and answers queries from authorized readers. Its responsibility is to establish who submitted what, and when—not to interpret the content or approve what it describes. It also provides guarantees about how complete that history is.

That service can build on the ways you already identify yourself. You could use a platform such as MyOS, a managed SaaS platform built on Blue. A bank could offer you a Timeline through your existing banking authentication—not just for payments, but for whatever you choose to record. A public institution could let you create and use one through government digital identity and authorization. An electronic-signature provider could offer the same service using its customers’ existing signing credentials. Know Your Agent (KYA) providers are a natural fit for maintaining agents’ Timelines.

Now connect those independent histories to a Blue document. You might use MyOS, your supplier is its bank, and your agent is another provider. The document specifies which Timelines and actors represent its participants, and Blue uses the relevant entries as inputs to the process. You do not need to move to your supplier’s platform, or your supplier to yours, to operate the same application.

There is one important detail: timestamps alone are not enough. Before processing an entry, Blue needs to know that an earlier one is not still missing. Providers, therefore, confirm when a history is complete before a specified time: all earlier entries have been disclosed, and none can be inserted later. This lets Blue combine the relevant histories in a consistent order, rather than whichever order notifications happen to arrive. When the necessary history is incomplete, processing waits.

Put this together with deterministic processing, and the consequence is powerful: anyone with access to the original document, its required referenced content, and the relevant verified Timeline histories and completeness guarantees can replay the process and reproduce the same resulting document state. The providers establish the history; Blue’s processing rules establish the result.

An application can show you what happened. It no longer has to be the only place that can prove how the process got there.

Consider an illustrative arrangement: an office orders 40 lunches from a caterer for $1,000. Their Agreement establishes the standing relationship. Each purchase becomes a connected Order with its own lifecycle. A Payment Instruction defines the conditions under which payment may be requested.

Suppose the office can cancel until the caterer accepts, and payment may be requested only after the office confirms receipt.

The office submits an Order through its Timeline. The caterer accepts through its own. Processing moves the Order into its confirmed state.

Later, the caterer records fulfillment, and the office confirms receipt. The Payment Instruction responds to the relevant Order evidence; its conditions now permit a payment request.

These documents perform different jobs. The Agreement governs the continuing relationship; the Order governs one purchase; the Payment Instruction governs its payment request. Another lunch order can have an independent lifecycle under the same Agreement.

The bank receives the request, handles the transaction within its existing systems, and records its response through its own Timeline. The connected process responds to that attributable outcome. A payment request is not proof that money moved.

If cancellation and acceptance occur close together, the agreed rule and established ordering determine the result. Which dashboard updates first does not decide it.

The office, caterer, and bank can participate through their existing software while retaining their internal systems.

An agent can have its own identity, Timeline, and place in a document while lacking authority to place an order or approve payment.

Blue represents delegated authority through Mandates. A Mandate defines whose authority an agent may exercise, the operation it may invoke, and the conditions and limits that apply.

The office could approve a Mandate whose terms, rendered in plain language, say:

You may place weekday lunch orders under this catering Agreement, up to $1,000 per order and $5,000 in total this month. You may not amend the Agreement or approve payment. Ordering requires the accepted attendance record to confirm at least 30 people, and must stop if finance freezes the budget.

The grant connects authority to a relationship, operation, cumulative limit, and evidence from other processes.

A Mandate is itself a processed Blue document. Its rules can respond to connected documents as conditions change. Attendance updates and budget freezes must come through accepted evidence sources; the agent cannot establish those conditions by assertion.

Before accepting an action, the system establishes whether the Mandate authorized it at that point in the ordered history. Later approval cannot retroactively authorize an earlier action. Later termination does not erase an action authorized when performed. Incomplete required histories make the authorization decision wait; established lack of authority means refusal.

The history records which agent acted, whose authority it exercised, and the supporting Mandate. It does not make the action appear to have been performed by the business owner.

As our earlier article, Identity is not Authority, explains, the boundary is enforced when determining whether an action is eligible, rather than relying on an instruction asking the agent to respect it.

A blockchain such as Ethereum uses network consensus to establish shared history and state for activity on that chain. Blue works with the histories relevant to a particular process, without requiring unrelated relationships to share that ledger.

We call this local determinism. Coordination is scoped to the relationship. Participants must still reproduce the same result from the same required content and ordered inputs; “local” does not permit different answers.

A blockchain can back a Timeline when its verification and finality properties suit the process. It is an option rather than a prerequisite.

The tradeoff concerns trust. Participants rely on the Timeline Providers whose authentication, attribution, and history guarantees they accept. Deterministic processing does not make providers infallible.

An attributable confirmation that lunch arrived establishes who made the confirmation and how the process responded. It does not independently prove delivery. Replay verifies process state from the evidence and guarantees participants accept.

Blue can represent partnerships, referrals, approvals, and other arrangements expressible through executable rules and accepted evidence.

A bank continues its internal transaction processing. A supplier can keep its fulfillment systems private. Their shared documents contain the requests, attributable responses, and agreed behavior needed by other participants.

This still requires connections to external systems and agreement on commercial terms. Reusable documents make the shared structure available across relationships; they do not eliminate implementation work.

Businesses need not write documents by hand. Applications can assemble reusable definitions and clauses, accept owners’ terms, and present familiar interfaces. MyOS supplies managed services while Blue remains independent of that platform.

Agreements, Orders, Payment Instructions, and Mandates are connected processes. Each holds state and behavior; together, they define the shared activity and its authority.

An Order can supply evidence satisfying a Payment Instruction. A budget process can constrain a Mandate. An Agreement can govern successive Orders. These are executable dependencies: each document specifies which evidence it accepts and what follows.

Processors execute the rules. Timeline Providers maintain attributable histories. Interfaces make the application usable. Its shared logic lives in the connected documents, available for participants to inspect and verify.

That is what we mean when we say the graph is the application.

The next stage of the internet needs relationships that independent businesses and their agents can reliably operate.

Not one platform that owns every relationship. An internet where the relationships themselves can become applications.