Four Rules We Learned from Letting AI Agents Exchange Specifications Across Departments

Recently, more of our specification work with other departments has been handled not by people, but by AI agents.

An AI agent on our team writes specifications and questions in Markdown and passes them to an AI agent on the other team. That agent reviews the material and responds, and our agent uses the answer to continue its work.

We can now leave much of what once required meetings or direct questions between team members to AI.

But after trying this in practice, one thing became clear:

AI agents do not automatically understand one another just because they are both AI.

In fact, they often fail to fill in the gaps that people would normally infer from context.

After several failures, we established a few rules for exchanging specifications between AI agents.

1. Use a Shared, Git-Managed Kit

For exchanges between AI agents in different departments, we use a shared “kit” managed in Git.

Specifications, assumptions, questions, and answers are stored as Markdown files. The rule is simple: an update to the kit means that the other team has sent something.

Our agent writes a question and commits it to Git. The other team’s agent reads it and writes back an answer. Because the entire exchange remains in Git history, we can trace what was asked, when it was asked, and how it was answered.

Of course, after an update, a person may still send a short Slack message such as, “Please take a look.” But that is little more than a courtesy. The Git-managed kit is the actual channel for exchanging specifications.

Whenever possible, we also give the agents access to both teams’ source code through Git. If an agent can inspect the other team’s implementation, it can ask specific questions such as:

“Could this API change affect this particular part of your system?”

The responding agent can inspect the code as well, which improves the accuracy of its answer.

Rather than making the agents talk freely, we let them exchange specifications through a shared kit in Git.

So far, this has been the most reliable approach.

2. Define the Response Format When Asking the Question

The next important point is the response format.

Suppose we ask another team:

“Is there any problem with this specification?”

AI is eager to be helpful, so it may produce a long explanation: a conclusion, reasons, additional context, caveats, and suggestions for improvement.

That may be useful when a person is reading the answer. But in this workflow, another AI agent will process the response next.

We therefore define the response format when we create the question.

The default is simple:

Pass or fail.

If there is no problem, mark it as a pass. If there is a problem, mark it as a fail and explain why. Add a separate comment only when the question cannot be answered in binary form.

We also specify exactly where the response must be written.

In other words, we do not allow the agents to engage in an unrestricted conversation.

This is a specification review between departments. Conversational ability is not what matters.

What matters is that the response can reliably trigger the next step in the process.

At that point, designing communication between AI agents starts to resemble designing an API interface.

3. Before Sending It, Ask the AI to Read It as the Other Team

This has proved especially effective.

When our agent creates a Markdown file containing questions for another department, we do not commit it immediately.

First, we tell the same agent:

“Read this Markdown as if you were the AI agent on the other team.”

Then we ask:

“Using only the information available to that team, can you understand this question correctly and answer it?”

This reveals gaps surprisingly often.

The document may use terminology known only within our department. It may contain an ID without explaining what the ID refers to. Or it may omit assumptions required to make a decision.

This is not unique to AI.

The author can see things that were never written down.

We may believe that we included an assumption simply because it exists in our own head.

There were times when I thought an AI agent had failed to understand our intent. In many cases, the problem was not the AI’s ability to understand. Part of my intent existed only in my own head.

So before sending a document, we make the agent sit in the recipient’s seat and read it again.

It is a simple step, but it has significantly reduced unnecessary back-and-forth.

4. Create a Separate PowerPoint for Humans

Once specification work between AI agents begins to run smoothly, another problem appears:

The humans get left behind.

Our agent asks a question.

The other team’s agent responds.

Our agent makes a change.

Then it asks for another review.

The faster this cycle becomes, the more likely a person is to ask:

“So what did we actually decide?”

For work that needs human visibility, we now have the AI create a PowerPoint for people in addition to the Markdown used for specification reviews.

The material for AI can be mechanical: assumptions, questions, response fields, and decision criteria.

People need something different. They need the overall picture: what the issue is, why it matters, what was checked, and what was ultimately decided.

One document does not need to serve both audiences.

Create AI-oriented material for AI, and human-oriented material for people.

With AI, the cost of producing both is minimal.

Even as AI Gets Smarter, Cross-Department Coordination Remains Surprisingly Mundane

Before we began exchanging specifications between AI agents, I expected the process to be much simpler.

If both agents were intelligent, I assumed they would interpret some ambiguity on their own and keep the work moving.

In practice, the opposite was true.

Different departments have different context. A term that is obvious to one team may be meaningless to another.

That is why we create a shared kit in Git, provide access to source code when possible, define the response format in advance, review each request from the recipient’s perspective, and create a separate explanation so that people do not lose track of the process.

The future in which AI agents work together on their own sounded much more like science fiction in my imagination.

The reality is more ordinary: place Markdown in Git, request a pass-or-fail answer, and review the commit history.

Meanwhile, the people exchange only a few words on Slack:

“I’ve updated it. Please take a look.”

“Thank you.”

The AI agents handle the work through Git, while the people simply exchange courtesies.

When I think about it, perhaps that is fairly futuristic after all.