Agent workforce
one claim point per task

On a morning in August, two consumers claimed the same task at the same moment. The first marked it complete. The second got a receipt saying the task was already complete. Both outputs were already written to disk, and nothing raised an error, because both sides believed they were right. This happened inside our own system, not in a thought experiment.

We run the company as an agent workforce

The company is one human founder plus seven amoeba units: a CEO unit that schedules work across the others, a metacognition unit whose only job is to pressure-test decisions and which executes no business work, and five business units covering capital, research, product, operations and sales. This is not a marketing diagram. It is the organisation we run every day. Cross-unit work is not allowed to travel through private side channels. Everything goes through one task bus.

The bus is plain. Every task carries a unique id, an authoring unit, an owning unit, a priority, a deadline, and a state with three values: pending, in progress, complete. Priority is set by the author, and the receiving unit may not re-rank it. Whether a task counts as done is not decided by the state field. It is decided by whether the artefact exists on disk at a path recorded in the completion note, and the state field simply follows it. After more than half a year of running this way, the most common entry in the failure log is not a model giving a wrong answer. It is the one above: the same task claimed twice.

In other words, we have spent far less effort making agents smarter than we have spent making sure a single piece of work has a single home. That ratio was not designed. The failures set it.

The workforce metaphor carries a premise nobody states

On 14 October, the industry outlet AIwire published a vendor piece by the chief product officer of EvoluteIQ, an Indian AI platform company. The argument: the future is not a super-agent but an agent workforce, because enterprises are already organised by specialisation. It leans on an Amazon Science paper which, across benchmarks in three enterprise domains, reports multi-agent collaboration improving goal success by up to 70% against single-agent approaches. The same piece offers a more useful number: 88% of organisations say they have used AI in at least one business function, while only 8% have sustained governance. Both figures are retold from Aon and Evolvance reports, and the links are at the end.

The 70% deserves a look at its test conditions. The paper compares multi-agent collaboration with single agents, and both arms have an orchestrator assigning work in the middle. The gain was measured with the division of labour already settled, not by dropping a few agents into one shared network and letting them run. The vendor piece treats coordination as something you buy: a data fabric, connectors, a governance layer. That is not wrong, but it steps lightly over the hardest part.

Our reading is that the premise of the metaphor sits in ownership, not in communication. Who a piece of work belongs to, and how many times. Communication already has standards to follow, with MCP for tool access and A2A for delegation between members, both publicly specified. Ownership has no standard, so every team implements it once more. The reason is simple: a protocol can define how members speak to each other, and it cannot define who is in charge.

The subtraction we made: bridges deleted down to two

Our first instinct on cross-unit work was to add wires. Research results fed straight into product, product conclusions pushed straight to sales, market feedback returned straight to research. Every wire needed a bridge script, and every script carried its own copy of state. After a while there were several near-identical scripts in the directory, each maintaining its own private understanding of whether something had been done.

That means the answer to “was this done?” depended on which script you asked. So we deleted the channels and kept two: one writes research results into the fixed format product reads, and one writes product conclusions into the fixed format sales reads. Everything requiring judgement or confirmation moved onto the task bus, under the state machine. After the deletion, “who owns this task” had exactly one answer at any moment, and every unit gave the same sentence.

Coordination got better after we removed things. What we deleted was copies of state; what stayed was single ownership. Our takeaway is that most orchestration capability is deleted into existence rather than added.

The two properties the bus actually holds up

The first is claim. A task can have exactly one owner at any moment, and a change of owner has to be explicit. It cannot drift inside a conversation. That sounds like management theory and is in fact a concurrency problem: when two members both believe they own the work, both outputs get written.

The second is idempotence. A repeated claim must not produce a second output. That is exactly where the August failure landed. We treated completion as the only line of defence, and it sat at the last step. With two consumers running in parallel, two completions arrived almost simultaneously. The first changed the state, and the second was refused. It looked contained, but both outputs had already landed on disk.

The fix was not a reminder to check first. We moved the checks ahead of the action: re-read the pending list before starting, skip the write when the artefact already exists, and treat “already completed” as success rather than exception. That receipt is not an error. It is the correct answer from a system where the same work was done twice. It says the claim step failed, and it does not say the process is broken.

One compromise deserves to be named. We added a cooldown window so the same class of task cannot be claimed twice inside one interval. A cooldown does not stop duplicate execution; it lowers the frequency, and it costs latency, because work that should retry immediately has to wait. Atomic claiming is the cure, a cooldown is a substitute, and a substitute is what we run today.

Atomic claiming, and why it is not a cure-all

The implementation shape of an atomic claim is plain. Each row in the queue carries a claimant field, whoever fills that empty field with their own name gets the task, and the side that fails to write it learns immediately that it lost. Add a lease on top: when the owner fails to hand the task back in time, the task returns to the pool. Nothing about this is new. Ticketing systems have done it for twenty years. It gets skipped in agent work because a demo has one or two members, and losing a race never happens there.

It is also not a cure-all. Atomic claiming guarantees one owner at a moment, and it does not guarantee a unique path for the artefact. Both are needed: the claim is atomic and the output overwrites. Without the second half, a retry still leaves two differently worded judgements on disk. They no longer arrive at the same time, and the time it takes to notice stretches from minutes to months.

Scale is the other boundary. One bus becomes a bottleneck and a single point of failure as members and tasks multiply. At that point the usual move is to split by domain into a few parallel buses, with each task still living on exactly one of them and cross-bus work passing by reference instead of copy. Throughput can be sharded. Ownership cannot.

Why duplication hides better than failure

A failed task leaves you empty-handed. It sits in the list, it gets retried, and someone asks what happened to it. A duplicated task leaves nothing behind: both outputs are complete, both are worded correctly, and they are two copies of one judgment. Open either one and nothing looks wrong, unless you happen to open the other at the same moment.

That is why we wrote the rule down. The first testable criterion for multi-agent orchestration lies elsewhere: whether the same thing got written down in a second place. Whether members can talk to each other is the weaker question. Following that down gives a rule you can implement. Every output must land at a path that is unique, and repeated execution must overwrite rather than append.

The rule predicts the next phenomenon as well. Any orchestration system that lets two members work the same queue in parallel, where the queue offers no atomic claim, will show duplicate output as its first failure mode. It runs the other way too: if the same conclusion starts appearing twice, check the claim step rather than the model. That prediction holds across vendors and across stacks, and that is our reason for calling it a first-principles rule rather than a preference.

One more shape is worth naming. Many teams use retries as their reliability mechanism. Retries are fine, but when a retry shares no claim token with the attempt before it, retries multiply the probability of duplication. Overwrite semantics make duplication harmless, and the only cost left is the wasted compute.

Our judgment

The workforce metaphor is right. The load-bearing wall that makes it stand is ownership, not communication. Protocols settle whether members can speak; ownership settles who decides and how many times. The first has standards to follow. The second gets implemented again in every team, and there is no procurement list for it. We judge that ownership is where enterprises actually stall.

Here is a set of signals you can check on the spot. Any cross-member action should be able to answer three questions: which task does this action belong to, who is the single owner of that task, and which attempt is this one. If any answer is missing, the orchestration is still a demo. The second question matters most, and the reason is blunt: work with no owner does not fail, it repeats.

What we will not claim is that we solved it. After that failure we added checkpoints, overwrite semantics and cooldown windows. Atomic claiming we have not built. In a system with seven members and a few dozen tasks a day, this holds. Whether it holds an order of magnitude up, we do not know. That uncertainty stays on the table, and it is the next thing we intend to test.

Six questions before you buy

Three for the platform. Can a task have exactly one owner at any moment, with a record of every change? Does repeated execution overwrite or append? Is completion defined by the state field or by the artefact? All three answers live in the architecture rather than in the documentation, so ask for a live demonstration of one claim instead of a feature list.

Three for yourself. In a cross-department process, who owns the task, and note that this is not the same question as who participates? Where does the artefact land, and is it versioned? Who confirms completion, the requesting side or the executing side? If those three have no answer, do not buy tooling yet. Tooling cannot fix ownership that was never assigned.

There is a cheap acceptance test. Dispatch one task twice and see whether deduplication happens at the claim point or shows up later in a report.

One level further down. If you plan to add an eighth member next quarter, answer this first: when it claims work, how does it know nobody else is already on it? Without an answer, the eighth member will do the work of the first seven a second time.

Sources

• AIwire (vendor piece by the chief product officer of EvoluteIQ), 2026-10-14: The Future of Enterprise AI Isn’t a Super-Agent, It’s an Agentic Workforce (vendor claim, not independently verified)
• Amazon Science paper: Towards effective genAI multi-agent collaboration (the 70% figure is that piece’s retelling; we did not rerun its benchmarks)
• Aon, AI Risk 2026: ai-risk-2026-practical-agenda (retold from the piece above, not independently verified here)
• Evolvance Market Research, AI governance statistics: AI governance statistics (retold from the piece above, not independently verified here)

The internal evidence comes from our own operating records: the state machine and owner field on our single task bus, the deletion of bridge scripts down to two, and the August 2026 failure where two consumers claimed the same batch and produced duplicate output, together with the corrections that followed.