The 2:17 a.m. Phone Call

This is a story I made up. The company, the customer and the night are invented, and so is the system in the second half. The problem is not.

---

The phone rings at 2:17 a.m.

You are the on-call engineer for a payments company, and the voice on the line belongs to the head of compliance, who does not sound like she was asleep either.

"A customer's transfer was blocked tonight. Forty-eight thousand, to a supplier, from São Paulo. She runs a small manufacturing business, it was the payment that keeps her people employed through the holiday weekend, and she is saying so loudly, in writing, to someone who copies regulators on things."

A pause.

"By nine this morning I need to tell them exactly why our system did that."

You say you'll look into it. You open the laptop. You are not worried yet. This is what you built the system for.

What you built

It is a good system. It has four agents, each very good at one thing: a fraud agent that watches for suspicious patterns, a risk agent that prices exposure, a growth agent that exists to stop the company from declining good customers, and a compliance agent that knows the rules of every jurisdiction you operate in. A planner sits on top, asks them questions, and combines their answers into a decision.

Each agent talks to the others. Signals flow all day: anomalies flagged, models retrained, context refreshed. When a transfer comes in, the planner calls the agents, the agents call each other when they need to, and a few seconds later the transfer is approved, held, or blocked.

Nobody ever drew a box around "the part where they decide." There was never a need to. It worked.

The same agents, the same night: an implicit mesh against an explicit, bounded session.

What the logs say

By 3:30 you have eleven thousand log lines across seven services and a timeline taped together out of timestamps.

At 01:51 a signal went out that the growth model had been updated, and its weights shifted. At 01:52 the transfer arrived. The planner asked compliance for a ruling, and compliance timed out once. The planner retried, and on the retry compliance was handed a trimmed context. The fraud score was not in it. Risk, meanwhile, had read fraud's answer as an input to its own, and fraud had said BLOCK with high confidence. The planner combined what it had. The transfer was blocked.

You read it again. Then you read it a third time, because you can think of three different explanations that all fit the evidence:

• Fraud was right, and the block was correct.
• The model update nudged growth, which nudged risk, which tipped the planner.
• Compliance never saw the whole picture and the block was an accident of a retry.

You cannot tell which. Every one of those stories is plausible, because the decision was never made in one place. It was the sum of a conversation, and the conversation left tracks, not a record.

At 6:40 a.m. you write the only honest sentence you can: the system's components interacted in ways we can reconstruct only partially.

The head of compliance reads it and is quiet for a while.

"Would it do the same thing again?"

You think about it.

"Probably," you say.

It is not an answer you can defend, and you both know it. You are not describing a decision. You are describing weather.

The same night, differently

Now rewind. Same company, same four agents, same transfer at 01:52. One thing about the system is different.

The moment that transfer arrived, the checkout service did not just call the planner. It started a session.

A session has an identity. It declares who may take part: fraud, risk, growth, compliance, and the service that started it. It says what kind of coordination this is, in this case a decision. It carries a time limit. It binds, at the moment it starts, which version of the rules governs it. And it ends in exactly one way: a commitment, or an explicit expiry, or a cancellation. After that, nothing more is accepted.

At 2:17 a.m. the phone rings. The head of compliance asks the same question. This time you ask for one thing: the session ID.

You open it, and the whole night is in one place.

Fraud evaluated the transfer: block, high confidence. Risk said review. Growth said approve, with less confidence than the other two. Compliance said review and attached an objection: the transfer crossed a jurisdiction boundary and may need a second sign-off. Everyone's position is there, in order, attributed, unchanged since the moment it was sent. The rule that governed the outcome is there too, and so is the version of it.

The session ended in one commitment: hold for manual review, with the reason and the dissent recorded.

Was it the right call? Maybe not. Growth made a fair point. But you can argue about this decision, because it is one thing, in one place, and you can hand it over. You can tell the head of compliance who took part, what each said, which rule applied and how it ended.

And when she asks, "Would it do the same thing again?", you can answer with something better than "probably." The same history, under the same versions of the rules, replays to the same result.

What you can hand over at 2:17 a.m.

You do not have to be right to be defensible. You only have to be legible.

What actually changed

Look at what is not different between the two nights. The models are no smarter. The agents are the same four agents. The transfer is the same transfer.

What changed is a boundary. In the first night, coordination was something that happened around the system, spread across calls and signals and retries, and the decision was whatever they added up to. In the second, coordination was an object: it had a start, a roster, a rule, a lifetime and an end.

That is a small idea, and it is the whole idea.

What this series is

I work on a protocol called MACP, the Multi-Agent Coordination Protocol. Its core rule fits in one sentence: binding agreement between agents must happen inside an explicit, bounded session. Everything else, the modes, the policies, the commitments, the runtime, follows from taking that sentence seriously.

It is an open standard with a reference runtime, two SDKs and a handful of tools. It is also still a draft, and I will be upfront about what is finished and what is not, because that is the only way a series like this is useful to you.

Over the next few weeks I will go from the idea to the wire: what a session is, what one looks like from start to finish, how its outcome becomes something anyone can check, and then how to run one yourself.

Next: the whole idea in one rule, and the two planes it divides the world into.

If you build multi-agent systems, I would love to hear what your 2:17 a.m. looks like.

Repository: github.com/multiagentcoordinationprotocol