Detecting overcommitted resources in multi-agent plans

When several parties, or the agents acting for them, make commitments in one plan and those commitments draw on the same equipment, working hours, or stock, check each commitment and then check them together against that shared source. Record which source each active commitment uses and how much, add up the allocations that point at the same source, and compare each total with the source's capacity. A resource checker in our collaboration-discovery research code does this.

Zhang Chenxi (Nature), who builds agent systems for manufacturers and distributors. 24 October 2026. Drafted with AI assistance.

It takes a ledger that records sources, capacities, commitments, and allocations. It checks that every active commitment (one that has not been withdrawn) is fully backed by its sources, and it totals what each source has been asked to give. It returns pass or fail plus the specific conflicts, so the plan can be revised. It does not search for the best allocation, and it does not build a schedule.

Two six-hour plans, one ten-hour piece of equipment

Take a made-up teaching example. A piece of equipment can still provide ten hours of work in a given period. Plan A needs six hours from it. Plan B also needs six. Checked one at a time, neither plan goes over ten. Accept both and the equipment has to run twelve hours.

The mistake is in what gets checked. Looking at commitments one by one, all we can see is "six is less than ten." Going back to the equipment they both depend on, we see "six plus six is more than ten." In a plan with several parties, this kind of double use does not have to come from deceit. Two local plans may simply never have been added up in one place. With agents, this is what happens when each agent checks only the part of the plan it drafted.

Once each commitment names its source, the sum itself is easy, and it catches an error that a read-through in natural language can easily miss. The work is in making that sum mean something.

Source tracing: check each commitment, then total each shared source

First give the equipment's available quota for this period an explicit identifier, such as "Equipment E, remaining hours this week," with a capacity of ten hours. Plan A and Plan B each allocate six hours from that identifier. Neither plan relies on a description that says "the equipment should be enough."

The checker starts with each commitment alone. Say Plan A promises six hours but lists source allocations that add up to four. Even if the equipment has plenty of capacity, the commitment is missing two hours of backing. The reverse also fails: listing eight hours behind a six-hour promise leaves the books unbalanced. The implementation requires the allocations listed for a commitment to sum to the quantity it promises.

After the single-commitment checks, it groups the allocations that point at the same source:

When the total exceeds the capacity, the source is overcommitted, and the checker names that over-allocated source and the two commitments that reference it. So the result is more than a red status: whoever revises the plan knows which two commitments to reopen. In our research code, a change that would turn this check red is rejected, and the ledger stays as it was.

If Plan B drops to four hours, the total becomes ten and the quantity check passes. Plan B could instead find other equipment, or the owner could explicitly add available hours to Equipment E. The checker does not choose among these repairs, and it does not agree on the owner's behalf to longer working hours. Its job is to pin the conflict down precisely enough for the next decision.

Validation rules: quantity balance, capacity limit, and matching resource type

The implementation also checks that the source is registered in the ledger, that source and commitment use the same resource type, that allocation and commitment use the same unit, and that the party making the commitment controls the source. Ten hours cannot back ten units of stock, and equipment that belongs to one party does not become a resource that another party can spend just because that party wrote it into a plan.

These facts decide whether the addition means anything. Written as rules, for each source s:

sum of the quantities that active commitments allocate from s ≤ capacity of s

and for each commitment c:

sum of the source allocations listed for c = quantity that c promises

The first rule stops one resource from being used twice. The second stops a promised quantity from going unbacked. They catch two different errors. A commitment with enough backing can still compete with another commitment for the same source, and a ledger with no over-allocation can still contain a commitment that did not receive its full allocation.

Capacity constraints of this kind appear in resource allocation, linear programming, and network flow. The classic network version is the maximum flow problem (Ford and Fulkerson, 1956): each link in a network has a capacity, and the task is to find the largest flow from one point to another. A maximum-flow algorithm searches for that flow. The checker here receives allocations that someone has already proposed and checks whether they break the constraints.

The summing step is not new. We put it in our research code so that a plan generated by a model has to answer to an explicit quantity relation. The model can propose "these two should be doable together," but that sentence cannot turn twelve into ten.

Where it stops: time windows and source identity must be defined first

"Ten hours" needs a definite meaning before the check says anything. If Plan A wants six hours in the morning and Plan B wants six hours in the afternoon, whether the equipment really has twelve usable hours in a day has to be defined separately. With Plan B cut to four hours, the total of ten passes the quantity check, but if both tasks have to run inside the same six-hour window, ten hours of work still do not fit.

The current check totals quantities by source identifier and does not build a schedule. That is why the teaching example ties both plans to one ten-hour quota for one period. To handle time conflicts, make the source express the time window, or connect scheduling constraints. A passing total does not mean a passing schedule.

Source identity matters just as much. Suppose two plans refer to the same piece of equipment under two different identifiers, and each registers ten hours of capacity. A program that totals by identifier may not see the double use. Resolving that is the job of the registration and identification layer, because a summing algorithm can only merge sources that the input marks as the same. Nor does the check prove that the equipment exists, that its available time is real, or that its owner will deliver.

The check still marks off a question a program can answer: whether, for sources that are registered, of matching type, and clearly identified, the active commitments conflict in quantity. Once that question is answered reliably, people and models can spend their attention on the allocations that need negotiation.

When the teaching numbers are run through the function, six plus six triggers the over-allocation report and six plus four passes. We have not measured how much it reduces conflicts in real projects. What the check gives so far is a way for double use of a source to show up, as a specific source and specific commitments, before it turns into an incident during execution.

For your own plans, name the shared source behind each commitment and add up the quantity per source and period before accepting the commitments together.

Evidence and scope

The checker is the function verify_k1_conservation in our research code. It stores quantities as Python Decimal values, not binary floats, so adding up fractional quantities does not carry binary rounding error into the comparison with capacity. Passing it does not mean a plan passes the research code's other checks, such as whether each commitment is authorized, whether required reservations are in place, and whether the receiving side has a plan to witness delivery.

We wrote this check as part of ToWow's research on agents that coordinate work between people. If your agents make commitments against shared equipment, hours, or stock and you want to compare notes, write to hi@towow.ai.

An earlier Chinese version of this article is at towow.net/articles/towow-capacity-reservation.

If you want a system like this built around your own workflow, see AI agent systems for manufacturers and distributors or write to hi@towow.ai.