Section 49.2: Cooperation, competition, communication

A message that never changes an action is just a robot group chat with better timestamps.

A Robot Group Chat

cooperation, competition, communication becomes useful when it is tied to a named interface, a replayable scenario, a failure diagnostic, and an artifact that records what changed in the action loop.

The key question is practical: Which variables are shared, which rewards are aligned, and which messages are worth their latency cost?

Theory

For Cooperation, competition, communication, the practical design rule is to make the interface inspectable before optimization begins: inputs, outputs, units, latency, bounds, and failure labels should all be visible in the saved artifact.

Worked Example

Consider two delivery robots and one charging dock. Cooperation schedules charging before failure; competition can starve a low-battery robot; communication helps only if messages change the next action.

Practical Recipe

1. Write the observation, action, and success metric before choosing a model.
2. Build a baseline that is simple enough to debug by inspection.
3. Add the library implementation only after the baseline behavior is understood.
4. Record failures as structured cases: perception error, state error, planning error, control error, or evaluation error.
5. Run at least one perturbation test before trusting the result.

Cooperation, competition, communication becomes useful when it is tied to a closed-loop contract for Multi-Agent Embodied AI. The contract names the participants, observations, action authority, timing budget, logging artifact, and recovery rule. Without that contract, a system can look capable in a notebook while failing the first time a partner delays, a person corrects it, or a deployment scene changes.

For Cooperation, competition, communication, separate the conceptual claim, the systems claim, and the evidence claim. A plausible mechanism, a clean interface, and a closed-loop result are different claims; the section should keep their evidence separate.

For Cooperation, competition, communication, the baseline and maintained-tool version should produce the same artifact schema and run on one task panel. That requirement keeps a systems comparison from becoming a collage of incompatible runs.

1. Write a one-paragraph task contract with observation, action, success, and failure fields.
2. Start with the smallest simulator, dataset, or wrapper that exposes the task contract faithfully.
3. Run one deterministic smoke test and one perturbation test before scaling.
4. Save a single result artifact containing configuration, seed, metrics, videos or traces, and failure labels.
5. Compare methods only when one script evaluates them on the same task panel.

When Cooperation, competition, communication fails, avoid labeling the whole method as weak. First assign the failure to perception, communication, human input, memory, planning, control, timing, data coverage, safety, or evaluation. Then rerun one controlled perturbation that isolates the suspected cause. This pattern turns a disappointing rollout into a reusable diagnostic asset.

# Compare team gain against communication cost.
results = [
    {"policy": "silent", "team_return": 78, "messages": 0},
    {"policy": "intent_bit", "team_return": 96, "messages": 12},
    {"policy": "full_broadcast", "team_return": 99, "messages": 140},
]

baseline = results[0]["team_return"]
for row in results[1:]:
    gain = row["team_return"] - baseline
    gain_per_msg = round(gain / row["messages"], 3)
    print(row["policy"], "gain", gain, "gain_per_message", gain_per_msg)

intent_bit gain 18 gain_per_message 1.5
full_broadcast gain 21 gain_per_message 0.15