If two AI systems think at different speeds, could keeping them synchronized actually cost more than letting them think independently?

We usually understand Multi-Agent systems in fairly simple terms.

One Agent does one piece of work.

Two Agents do two pieces of work.

Ten Agents require ten times as many calculations.

So when the cost of a Multi-Agent system increases, we naturally look at:

• How many Agents are running?
• How many tokens are being used?
• How much compute is being consumed?
• How many API calls are being made?

But there may be another cost hiding underneath all of this:

the cost of keeping systems with different processing rhythms in the same logical state.

Two Hourglasses

Imagine two hourglasses.

Agent A has a very small opening.

Its sand falls slowly.

It takes longer to move from one state to the next, but it may reason more deeply before doing so.

Agent B has a larger opening.

Its sand falls quickly.

It reaches a new state faster and can move through several iterations while A is still working through its first one.

Neither hourglass is necessarily better.

They simply have different rates of internal processing.

When they work independently, there is no particular problem.

A can take its time.

B can move quickly.

The problem begins when they have to continuously align with each other.

When the Message Arrives

Suppose A is still working through its first layer of reasoning.

During the same period, B may have already completed three, five, or more state updates.

Eventually, A sends a message.

By the time B receives it, B is no longer in the state it was in when A started.

And when B replies, the same thing can happen in the other direction.

By the time A receives B's response, A has already moved further through its own reasoning.

So the problem is no longer simply:

«Did the message arrive?»

The more important question becomes:

«When the message arrived, was the receiving system still in the logical state that the message was intended for?»

Ping Is Not Only Distance

In a conventional network, latency is usually understood as the time required for information to travel from A to B.

But in a Multi-Agent system, there can be another form of delay.

Not physical distance.

State distance.

While a message is travelling, both systems may continue changing.

A sends a message.

B keeps reasoning.

B updates its state.

B reasons again.

The message arrives.

Now B has to interpret that message from within a state that may already be several iterations ahead of the state in which the message was created.

The communication itself may be cheap.

The re-alignment may not be.

Different Processing Rhythms

The "flow rate" here is not physical time dilation.

It is simply a way of describing how differently two systems process information within the same wall-clock time.

One Agent may favour deep reasoning.

Another may favour rapid synthesis.

A third may continuously revise its position.

A fourth may require large amounts of context before committing to an answer.

None of these processing styles is automatically superior.

They simply produce different rates of state change.

And once these different rhythms are connected into a shared decision process, the system has to deal with the difference.

Where the Cost May Actually Come From

If several Agents simply produce independent answers, the cost may be relatively easy to estimate.

But if the Agents are expected to:

• continuously reference each other,
• maintain shared context,
• correct one another,
• preserve a common logical state,
• and repeatedly recalibrate as new information arrives,

then adding another Agent does not simply add another calculator.

It may also add:

another synchronization point.

Another synchronization point can create:

another state difference.

That state difference may require:

more context reconstruction and recalibration.

The system may therefore spend an increasing amount of its resources not on solving the original problem, but on repeatedly getting everyone back onto the same page.

Compress or Stretch?

When two Agents operate at very different processing rhythms, there are several possible responses.

You can make the faster Agent wait for the slower one.

Stretch.

The cost may appear as waiting, idle capacity, and increased latency.

Or you can push the slower Agent to move faster.

Compress.

The cost may appear as reduced reasoning depth, lower calibration quality, or greater drift.

Or you can stop requiring them to synchronize at every step.

That means accepting that:

different Agents may temporarily exist in different logical states.

That may not be a failure.

It may simply be a different architecture.

So Perhaps We Are Measuring the Wrong Thing

We can keep asking:

«How many Agents are there?»

«How many tokens does each Agent consume?»

«How much compute does each Agent use?»

But perhaps we also need to ask:

«How much does it cost to keep these differently paced systems in the same logical state?»

That cost may be easy to overlook because it does not necessarily appear as another Agent or another obvious computation.

It appears as:

state differences, synchronization, context reconstruction, waiting, and recalibration.

A Different Question

Perhaps the real optimization problem is not:

How do we make more Agents work together?

It is:

Which Agents actually need to synchronize?
How closely do they need to synchronize?
And when is synchronization worth its cost?

If different Agents are allowed to operate at their own pace, and only synchronize at meaningful decision points, the system may not need to constantly force every hourglass to the same level.

Because:

Different flow rates are not necessarily the problem.

The problem may be:

«requiring systems with different processing rhythms to continuously behave as if they are at the same logical moment.»

Anchor

The cost of Multi-Agent systems may not come primarily from adding more Agents, but from keeping differently paced Agents continuously aligned to the same logical state.

Case 62｜我們可能算錯了成本

我們通常會這樣理解 Multi-Agent：

一個 Agent 做一件事，兩個 Agent 就是兩份計算，十個 Agent 就是十份計算。

所以當 Multi-Agent 系統成本上升時，我們自然會去計算：

用了多少 Agent、多少 Token、多少算力、多少次 API 呼叫。

但這裡可能漏掉了一個更隱性的成本：

讓不同處理節奏的 Agent，持續保持在同一個邏輯狀態。

一個沙漏

假設有兩個 Agent。

Agent A 的沙漏孔很小。

它每一步都花比較長時間推演，走得慢，但可能走得很深。

Agent B 的沙漏孔很大。

它很快完成一次判斷，很快產生下一個狀態，也很快進入下一輪。

兩個 Agent 各自工作的時候，都沒有問題。

A 可以慢慢推演。

B 可以快速迭代。

問題從兩者開始互相校準時才出現。

A 還在第一輪推演。

B 可能已經完成了三輪、五輪，甚至更多次狀態更新。

當 A 的第一輪結果終於抵達 B 時：

B 已經不是原來等待 A 的那個 B。

同樣地，當 B 的回應再抵達 A 時：

A 也已經在自己的推演中走了一段距離。

於是問題不再只是：

「訊息有沒有送到？」

而變成：

「訊息送到的時候，接收者還是不是原來那個邏輯狀態？」

Ping 不只是距離

在一般網絡系統裡，我們很容易把 Ping 理解成：

訊息從 A 到 B 需要多少時間。

但在 Multi-Agent 系統裡，還存在另一種「延遲」。

不是網絡上的距離。

而是：

訊息抵達之前，雙方各自已經更新了多少次自己的內部狀態。

因此：

A → B

並不只是：

A 發送 → 網絡傳輸 → B 收到

而可能是：

A 發送
↓
B 繼續推演
↓
B 更新狀態
↓
B 再推演
↓
訊息抵達
↓
B 必須重新理解這個訊息在自己目前狀態中的位置

所以，真正需要付出的成本可能不只是傳輸本身。

而是：

重新對齊。

不同的「內部處理節奏」

這裡的「流速」並不是物理意義上的時間膨脹。

它只是描述：

不同 Agent 在相同 wall-clock time 裡，完成狀態更新的速度不同。

一個 Agent 可能傾向深度推演。

另一個可能傾向快速概括。

第三個可能不斷修正方向。

第四個可能需要大量上下文才能確認一次判斷。

它們並不是誰一定比較好。

它們只是有不同的：

處理節奏。

而當這些不同節奏的系統被要求形成一個共同判斷時，新的成本就出現了。

校準真正昂貴的地方

如果只是讓幾個 Agent 各自回答問題，成本可能相對容易估算。

但如果要求它們：

• 持續互相引用
• 保持共同上下文
• 互相修正
• 維持一致的邏輯狀態
• 對新的資訊重新校準

那麼每增加一個 Agent，就不只是增加一個「計算器」。

也可能增加：

新的同步點。

新的同步點又可能產生：

新的狀態差。

狀態差又需要：

新的上下文重建與校準。

於是成本可能開始從「多做幾次計算」，變成「不斷花成本讓大家重新站回同一個位置」。

壓縮，還是拉伸？

當兩個 Agent 的處理節奏差距太大時，通常只有幾種選擇。

讓快的等慢的。

拉伸。

代價可能是等待、閒置與延遲。

或者讓慢的加快。

壓縮。

代價可能是減少推演深度、降低校準品質，甚至增加漂移。

又或者不要求它們每一步都同步。

那麼系統就必須接受：

它們暫時處於不同的邏輯狀態。

這反而可能是另一種架構選擇。

所以 Multi-Agent 的成本可能不是「有多少個 Agent」

我們一直可以問：

有多少 Agent？

每個 Agent 花多少 Token？

每個 Agent 消耗多少算力？

但也許還需要另一個問題：

為了讓這些不同處理節奏的 Agent 保持在同一個邏輯狀態，我們花了多少成本？

這可能是 Multi-Agent 系統裡一個容易被忽略的成本來源。

因為當 Agent 數量增加時，增加的不只是計算能力。

也可能增加：

狀態差異、同步需求、上下文重建，以及校準頻率。

一個新的觀察

也許真正需要最佳化的，不是：

「如何讓更多 Agent 同時工作？」

而是：

「哪些 Agent 需要同步？同步到什麼程度？什麼時候才值得同步？」

如果不同 Agent 可以按照自己的處理節奏運作，

只在真正需要共同決策的節點進行校準，

那麼系統可能不需要不斷把所有沙漏的沙子調到同一個高度。

因為：

不同流速本身未必是問題。

真正昂貴的，可能是：

要求不同流速的系統，持續假裝自己處於同一個時間點。

Anchor

Multi-Agent 的成本，可能不主要來自增加了多少 Agent，而來自維持不同處理節奏的 Agent 持續處於同一個邏輯狀態。