2 posts tagged with "coordination"

A Spanish customer complained that her annual renewal had been billed a day early. The support ticket bounced through three queues before it landed in front of an engineer who recognized the smell: a date-formatting regression, European cohort only. He ran git log against the date-formatting module and found nothing. The module had not been touched in eleven days. What had been touched, eleven days earlier, was its package.json — a lodash bump from 4.17.20 to 4.17.22, opened by a security agent, approved by the on-call, merged without comment.

Two lines above the version string, in the same file, was a comment written eighteen months ago: // do not upgrade — breaks the snapshot tests in date-formatting, see FRONT-2418. The security agent had not read it. Or, more precisely: the security agent had read the entire file, but its prompt instructed it to find vulnerable version strings, not to weigh the comments around them. The comment was load-bearing institutional knowledge. The agent treated it as scenery.

This is a coordination failure between two systems that did not know they were colliding. The security agent was doing its job. The original engineer who wrote the comment had done his job. The feature-development agent that respected the pin every time it touched the file was doing its job. Nobody had decided whose job it was to mediate between them.

You have three agents analyzing a customer support ticket. Two say "refund immediately," one says "escalate to fraud review." You pick the majority answer and ship the refund. Three days later, the fraud team asks why you auto-refunded a known chargeback pattern.

This is the consensus problem in multi-agent systems, and it turns out that distributed systems engineers solved important pieces of it decades ago. But naively transplanting those solutions — or worse, defaulting to majority vote — creates failure modes that are uniquely dangerous when your "nodes" are language models with opinions.