TL;DR

Once you start running multiple AI coding agents, coordination eventually becomes its own bottleneck.

For long-running maintenance workflows, the cost of conversations, context, and tokens starts to add up.

We call the pattern Gotanda Style: agents do not talk to each other directly. Instead, they leave small structured signals in a shared environment. Other agents read those signals later.

This is a lighter introduction to a workflow we use on a roughly 200,000-line Python repository, connecting Sentry alerts to GitHub issues and improvement pull requests.

Are we making AI agents attend too many meetings?

If you are building with AI coding agents, you will probably hit the coordination problem sooner or later.

When people design a multi-agent system, the first idea is often: "let the agents talk to each other."

A Planner discusses the plan. A Researcher investigates. A Coder implements. A Reviewer comments. A Supervisor keeps the whole thing on track.

That feels natural. It also works pretty well for small tasks.

But when you try to run a large system for a long time, a different problem appears.

More agents create more conversations. More conversations create more context. More context creates more token usage.

Eventually, the agents can spend too much of their budget reading each other's messages instead of solving the actual problem.

It starts to look a little like a human organization where work slows down because every decision turns into a meeting.

So we started with a simple question:

AI agents don't need meetings.

Or more precisely: not every kind of coordination needs to be a conversation.

Leave structured traces instead of chatting

In the pattern we are trying, agents do not talk to each other directly.

Instead, each agent writes down what it observed as a small signal in a shared environment.

Another agent can read that signal later.

Agents do not talk to each other.
They leave traces in a shared environment.
Other agents read those traces later.

This kind of coordination is called stigmergy.

The word sounds academic, but the idea is simple: coordinate through the environment.

We call the shared signals "pheromones" internally. The name is a little weird, but the implementation is just a structured record:

(scope, location, worker, strength, half_life, metadata)

For example, if a production error happens in a file, a Sentry worker might leave a signal like this:

{
  "scope": "file",
  "location": "app/services/invoices.py",
  "worker": "sentry-worker",
  "strength": 2.0,
  "half_life_days": 14,
  "metadata": {
    "category": "runtime_error",
    "environment": "production"
  }
}

This is not a long chat log.

It is small, structured, and easy to aggregate later.

The actual maintenance flow

In a simplified form, the workflow looks like this:

Sentry worker   ----+
Datadog worker  ----+-->  Pheromone field  -->  Refactor worker  -->  GitHub Issue  -->  Code worker  -->  Pull Request
Quality worker  ----+

Each worker looks at the codebase or production system from a different angle.

The Sentry worker watches production errors. The Datadog worker watches performance regressions. The Quality worker looks for test gaps and weakening module boundaries.

But they do not immediately create a pile of issues.

First, they leave signals in the shared environment.

If several workers point to the same location, that location becomes a hotspot.

If a weak signal happens only once, it fades over time.

If something was previously reviewed and marked "not worth fixing right now," the system can leave a negative signal for that candidate too.

The Refactor worker reads those signals and decides what should become an issue, what should go to a human, and what is safe enough for automated implementation.

Only issues at the right size and clarity are passed to the Code worker and turned into pull requests.

The nice part is that coordination cost moves from conversation to state updates.

When we add a new worker, we mainly define what kind of signal it writes.

A Security worker can write security signals. A Performance worker can write performance signals.

The Integrator can read all of them as part of the same shared environment.

That means production errors, slow endpoints, test gaps, and design drift do not all need to become all-hands agent meetings.

The small trick: zero does not always mean nothing

If you only add signals together, you can accidentally hide useful information.

Imagine one file has these two signals:

sentry-worker: +2.0
refactor-worker: -2.0

The simple sum is zero.

But that is not the same as a file with no signals at all.

It means something more interesting: "production is complaining about this area, but we also have a previous decision saying not to chase it right now."

That is a different situation from silence.

So the system should not only ask, "what is the final score?"

It should also ask:

• How much positive signal is here?
• How much negative signal is here?
• Are different workers disagreeing?
• Is this a quiet area, or a contested one?

That small distinction changes the behavior of the whole maintenance loop.

A quiet area can be ignored for now.

A strongly positive area might become an implementation issue.

A strongly negative area might stay suppressed.

But a contested area probably needs a human to look at the tradeoff.

That is the kind of detail that makes this feel less like "agents throwing tasks into a queue" and more like a maintenance system with memory.

The faster AI writes code, the more maintenance matters

AI coding agents are making it faster to write code.

But if code is written twice as fast, the maintenance load grows too.

More code reaches production. More changes need monitoring, debugging, testing, and refactoring.

It is like doubling the speed of a car. Speed is great, but only if the tires, brakes, suspension, and safety systems can keep up.

So in AI-driven development, "write code faster" is not enough.

This is not just a thought experiment for us.

We are using this pattern to maintain a Python repository with roughly 200,000 lines of code.

The loop from Sentry alert to pheromone deposit to GitHub issue to improvement pull request is already running.

That does not mean we try to automate everything.

Humans still step in when a fix needs architectural judgment, the cause is unclear, the blast radius is large, or an automated pull request needs review.

As we give AI agents more work, I do not think the human role disappears. It moves toward higher-level judgment and boundary design.

As a practice of attractor engineering

Zoom out a bit, and the whole codebase becomes part of the prompt for AI.

If the codebase has good structure, AI is more likely to follow that structure.

If the codebase has bad structure, AI is also more likely to treat that as the natural pattern.

That is why we care about preventing AI-generated changes from pushing the codebase toward worse future changes.

In that sense, this pattern is also a practice of attractor engineering.

I wrote more about that idea here:

Before the codebase drifts toward a bad attractor, we observe it, leave signals, and correct the trajectory through issues and pull requests.

This is not just about making AI coding agents go faster.

It is about keeping the codebase itself in a better shape for the next AI-generated change.

Where this pattern fits, and where it does not

This pattern is not always better than conversational multi-agent design.

Direct agent conversation can be the right tool when:

• The task is small
• There are only a few agents
• The context is short-lived
• The goal is exploration or brainstorming
• It is faster to reach agreement in the moment

Leaving traces in a shared environment tends to work better when:

• The workflow runs for a long time
• Signals arrive asynchronously
• Multiple tools observe the same codebase
• You want weak signals to accumulate over time
• You want to add agents without increasing communication traffic too much

So this is not a universal architecture.

It is a coordination pattern for long-running maintenance work.

Wrap-up

In AI multi-agent systems, conversation feels like the natural coordination model.

But in long-running maintenance workflows, conversation itself can become the cost.

Does AI agent coordination really need to be a conversation?

As one experiment around that question, we call this pattern Gotanda Style.

I wrote a deeper version on Hashnode covering the design background, pheromone handling, and the production workflow from Sentry alerts to issues and pull requests:

How are you coordinating AI agents today? Are they talking to each other, or are they coordinating through shared memory, queues, databases, event logs, or some other environment?