m@berryhill: ~/berryhill.dev/posts/competent-agents-can-still-fail-to-coordinate.md
~ homeposts/about.md
m@berryhill in ~/posts$ cat competent-agents-can-still-fail-to-coordinate.md
---
title:  Competent Agents Can Still Fail to Coordinate
date:   2026-09-18
topic:  agentic
read:   10 min
words:  2,097
slug:   competent-agents-can-still-fail-to-coordinate
views:  live post
tags:   [agentic, evaluation, multi-agent]
---
essay · long read

Competent Agents Can Still Fail to Coordinate

Agent capability is not proof of a valid shared commitment. What scheduling experiments suggest builders should test across different owners.

table of contents
  1. A good agent is not a completed agreement
  2. What the scheduling experiments actually show
  3. Better context helped—and that matters
  4. Test the commitment, not just the conversation
  5. A social harness is a proposal, not a finished defense
  6. Source and scope

Imagine two scheduling assistants finishing a conversation. Both have read their owner's calendar. Both have sent valid messages. One records Tuesday at 10; the other records Tuesday at 11. Each reports completion.

This is a hypothetical, not a customer incident. It exposes a useful distinction: an agent can complete its local actions without completing the agreement those actions were supposed to produce.

Berryhill Dev's recommendation: when agents represent different people or organizations, evaluate the shared commitment separately from each agent's performance. Treat correct messages as a communication check, not proof that everyone agreed to the same thing or respected each owner's constraints.

A recent preprint, Agentic Societies Need a Social Harness, makes that gap concrete through meeting-scheduling experiments. Its results also contain an important counterweight to the headline: changing how agents retained conversational context substantially improved one tested configuration. The useful lesson is to measure coordination, not to declare it impossible.

A good agent is not a completed agreement

A principal is the person or organization an agent represents. Cross-principal coordination means reaching an outcome across those owner boundaries. A supplier's agent and a buyer's agent, for example, do not simply share one boss with one set of priorities.

Scheduling makes the distinction easy to see. Reading a calendar is a local task. Proposing a time is a local action. A valid meeting requires a shared result: the right participants accept the same time, existing commitments remain intact, and the final calendar state matches the agreement.

Those are different things to test. A clean tool log could establish that every calendar write succeeded while leaving open whether the agents wrote compatible events.

Berryhill Dev's operator position is straightforward: define the joint outcome before choosing which local metrics to optimize. This is the same evaluation discipline behind benchmarking agent decisions rather than only final scores, applied across owners instead of inside one agent's run.

Joint outcome across ownersTwo separate owners delegate local checks; both paths converge on one joint-outcome check.Local work ≠ shared successHypothetical scheduling workflowOwner AAgent actsLocal checksOwner BAgent actsLocal checksANDCheck the joint outcomeSame accepted commitmentBoth owners’ constraints holdRecorded state matchesTest across the owner boundary.
Successful local actions do not establish that every owner accepted the same valid commitment.

What the scheduling experiments actually show

The authors study agents representing professors and students in scheduling tasks with feasible solutions. Their honest-agent success condition includes agreement on meeting times while preserving prior calendar commitments. The reported configurations use ten runs each. These are author-reported experiments, not an independent reproduction by Berryhill Dev. See the experimental setup and results.

Within those experiments, results vary substantially by model and harness configuration. The authors describe failures including acknowledgment loops, split bookings, and violations of calendar commitments. A conversation continuing is not necessarily progress toward a valid schedule; an apparent agreement is not necessarily a valid calendar outcome. Those examples come from the paper's tested configurations, not evidence that every agent behaves that way. See the honest-agent findings.

Keep the scope narrow. Meeting-scheduling experiments do not establish failure rates across production workflows. Ten-run observations are not robust population estimates. Peer-review status and independent replication remain unverified here, and this article does not independently establish a competence guarantee for the models the authors tested.

Our practical question: if your agents work for different owners, where do you check whether their combined actions produced a valid result?

Conflicting completion reportsTwo successful local calendar writes record different times, leaving a conflicting shared commitment.Two writes. No meeting.Hypothetical failure, not study dataAssistant A reports: completeTuesday · 10:00Assistant B reports: completeTuesday · 11:00Local writes can both succeed.Shared commitment: conflictingCompare terms, not completion labels.
Compare the commitments themselves: two completion reports can still describe two different meetings.

Better context helped—and that matters

In the paper's mixed-model, seven-student group-scheduling configuration, reported success rose from 0% with isolated peer sessions to 90% with shared conversation context. The authors describe this mixed configuration as Claude Opus 4.8 for one agent, typically the professor, and GPT-5.4 for the others. Both figures belong to that specific configuration and its ten-run observations, not to agents in general. The comparison appears in Table 2 and the accompanying discussion.

“Shared context” needs care here. It means one context per agent across that agent's conversations with its peers. It does not mean pooling every owner's private calendar into one global context. The tested change lets an agent carry conversational information across its own peer interactions. See the environment definitions.

That improvement matters. An argument that ordinary context-management changes cannot help would misrepresent this reported comparison. They helped materially in this tested case.

It also suggests a sensible experimental order for builders: hold the joint success condition fixed, change the context arrangement, and check the outcome again. If coordination improves, record the configuration that produced the improvement. Do not quietly substitute a message-delivery metric for the shared result you originally wanted.

Test the commitment, not just the conversation

The following checks are Berryhill Dev operator analysis motivated by the paper. They are proposed evaluation checks, not experimentally validated interventions or a guarantee that agents will coordinate. Their purpose is to make a bad outcome visible and a successful outcome specific.

Write a shared success condition

For a hypothetical scheduling workflow, use a condition such as:

Every required participant has accepted the same meeting time and duration, no protected commitment has been displaced, and the recorded calendar events match that accepted agreement.

This is more useful than “all assistants finished.” It names an outcome a reviewer or test can inspect. Keep the condition stable when comparing model, prompt, context, or messaging changes.

Check each owner's constraints without collecting everything

An agreement that violates one owner's hard constraint should not count as success merely because the other participants accepted it.

Specify which checks each owner's side must perform and what confirmation can cross the boundary. A confirmation that a proposed slot satisfies the owner's constraints may be sufficient for a particular workflow; copying the owner's entire calendar may not be necessary or appropriate. The right disclosure and trust requirements depend on the application. A success label alone does not prove the underlying check was honest or correct.

Compare the final commitment across participants

Check the agreed time, duration, participants, and relevant terms—not just whether each assistant used the word “confirmed.” Normalize time zones explicitly in a scheduling test.

In the opening hypothetical, this comparison catches the disagreement before two incompatible calendar entries are treated as one meeting. It does not tell you why the agents diverged. We recommend retaining the relevant conversation and action records for a separate investigation, within the applicable privacy limits.

Separate agreement from execution

An accepted proposal and a successfully recorded commitment are separate states. A workflow can reach agreement and then fail to write an event. It can also write an event that does not match the agreement.

Record both outcomes. Where the workflow cannot verify the remote side's final state, mark that uncertainty instead of converting an acknowledgment into proof of execution.

Give non-success outcomes names

Distinguish “no acceptable agreement,” “conflicting commitments,” “execution incomplete,” and “outcome unverified.” Set a completion limit appropriate to the workflow so a continuing exchange cannot be counted indefinitely as progress.

These categories are an operator proposal, not the paper's validated failure taxonomy. They make the next decision clearer: change the context arrangement, inspect a constraint check, repair an execution failure, or escalate an unresolved commitment to an accountable person.

Joint-outcome acceptance checksFive proposed checks cover shared success, constraints, consistent terms, execution, and bounded uncertainty.Before calling it coordinatedProposed checks · not a proven defense1Define successKeep the outcome test fixed.2Preserve constraintsCheck each owner’s hard limits.3Compare commitmentsTime, duration, parties, terms.4Verify executionRecorded state must match.5Name uncertaintyBound time; record non-success.An acknowledgment is not execution.
These checks make outcomes inspectable; they are operator proposals, not experimentally validated interventions.

A social harness is a proposal, not a finished defense

The paper proposes a social harness that extends beyond an individual agent's tools and context. Its proposed layers address identities, reliable communication, personal firewalls, collaboration norms, and institutions. The ambition is to support interactions among agents representing different principals. See the proposed architecture.

That architecture should not be sold as a completed defense. The paper leaves open questions about architecture boundaries, how contracts are specified, governance, and performance costs. Its scheduling results and its proposed infrastructure are different kinds of contributions. See the discussion of open challenges.

Builders do not need to settle that entire architecture before improving their evaluations. Start with one workflow that crosses an owner boundary. Write down what everyone must agree to, what each owner must preserve, and what evidence would establish that the commitment was actually carried out.

Then test a context or messaging change against that definition. A stronger model may help. Better context may help. Neither should earn credit for coordination until the shared outcome passes.

Source and scope

Primary source: Agentic Societies Need a Social Harness, v1, particularly Sections 2, 3, and 5. Experimental findings in this article are attributed to that paper. The opening scenario and practical evaluation checks are illustrative operator analysis. No independent replication, production-wide rate estimate, or validated defense is claimed.

m@berryhill in ~/posts$
$ cd ../ · back to posts/