Why Are You Still Carrying Messages Between Your Teams and AI Agents?

Lightweight communication can connect questions, people, and work across teams while protecting the attention needed to get that work done.

Challenge: Can the right person answer without making us the courier?

Can a question reach the person who knows the answer, get clarified, and return to the work without someone copying it between tools?

If every exchange needs our help, adding more capable AI agents also gives us more conversations to manage. We stop our own work to explain someone else’s question. We remember who owes an answer. We carry the reply back, sometimes only to discover that the recipient needs another detail.

We can remove much of that relay work by giving humans and agents a shared conversation, a clear destination, and a way to respond. The question should appear where the recipient already manages work. Routine messages should wait for attention without disappearing. Communication alone is not a reason to involve a person. When a question exceeds one agent’s authority, another digital employee may have the authority to resolve it.

We also need a way to raise an urgent alert when normal communications fail. A person may need to carry that alert through another channel. Reducing routine relay work should leave us better able to handle those exceptions.

Want help connecting your team’s AI workflows? Just In Time AI can help you choose a useful handoff, design the workflow, and implement a pilot. Explore AI consulting and coaching.

What: How do we connect a conversation to the people responsible for the work?

Before I had the full communication capability in place, a developer had to create handoff documents and copy information between sessions and machines. The agents could do their assigned work, but getting information from one to another required human effort.

Now agents can communicate with agents in other repositories. They can acknowledge a message, respond, and ask for clarification. An agent on the same machine can participate, and so can one on a different machine.

Human collaboration belongs in that same conversation. An agent has often asked me a question that someone else needed to answer. The reverse happens too: another person’s question needs to reach the agent doing the work. Routing that exchange directly removes the need for me to remain in the middle simply because the first question came to me.

A lane gives the question a destination

I use the term lane, adapted from the swimlane concept, for a defined area of work and responsibility. A lane generally corresponds to a repository, the place a software project keeps its files and history. At a given time, a lane can cover several repositories or a small part of one, such as a micro component.

That flexibility lets responsibility follow the work. We can think of a lane as a department’s in-tray: correspondence belongs with the responsible team even when a different person picks it up.

A queue holds work awaiting attention in that lane. A thread keeps the question and its replies together. An acknowledgment, or ACK, tells the sender that the recipient has recognized the message. The answer and the resulting work still need to follow.

In my setup, bringing a question into the sales agent’s queue automatically surfaces it on the sales team’s dashboard, in the daily briefing, and in to-do lists. That connects communication to the way the team organizes its day. Someone does not also have to remember to add the question to each of those places.

Autonomous work needs clear decision authority

A lane does not require a human in every exchange. In my environment, DOE (Directive Orchestration Execution) keeps agents working through an approved queue without someone supervising an interactive session. These agents can carry out assigned work and communicate directly with other agents without a human in the loop.

The business value is continuity — the idea often described as "agents working while I sleep." Approved work can move forward without a person restarting each step or carrying messages between teams. When human knowledge, judgment, or authorization is needed, the communication system provides a route to the right person. Human escalation also remains available when an outage blocks the normal route.

Roles and charters define what an agent may decide

We organize this work around digital employees: agents with defined roles, responsibilities, and operating boundaries. Their charters establish which decisions they can make, when to consult another role, and when human approval is required. A role defines the work; a persona shapes the perspective brought to it; the charter defines the authority.

A question beyond the working agent’s authority does not automatically require a human. Another digital employee may have broader decision authority under its charter. The working agent can send the question and supporting context to that role, receive a decision, and continue. Escalation follows decision authority and can remain entirely between agents.

This makes communication more useful. An agent with a sales question can ask the sales role directly. If the answer falls within that role’s authority, the agents can resolve it and continue. People become involved when their knowledge or approval is needed, freeing them from coordinating every routine exchange.

Let the recipient ask back

Consider a hypothetical delivery-to-sales exchange using that communication pattern. The dialogue below illustrates the workflow; it is not a customer incident.

A delivery agent needs to know which records belong in a customer’s report. It routes the question to the sales lane with the relevant context. The question appears in the sales team’s normal work queue and briefing.

The salesperson needs clarification: does "records" mean active accounts or historical transactions? That question goes back through the same thread. The delivery agent explains what the report needs, and the salesperson supplies the customer requirement. The answer returns to the delivery work with its context intact.

The human contributes knowledge of the customer. The agent contributes knowledge of the work underway. Each can ask a question the other is equipped to answer.

We should preserve who supplied the answer and which question it resolves. An answer about report scope does not also authorize a price change or a customer commitment. Communication helps the responsible person make the decision; it does not grant new authority to everyone in the thread.

The Agent2Agent protocol also describes tasks that pause for additional input and continue through further exchanges. It provides a documented example of making clarification part of an agent conversation. A2A task lifecycle

🎓 Lesson

• Give your recipient a way to clarify the question and return the answer to the work that needs it.

Keep the connection lightweight

People should be able to participate through an interface suited to their work. In my environment, that includes file-based questions for humans and a dashboard interface. A human can also direct an agent to send a message through Teams or email using Microsoft Graph API.

The engineering challenge is to keep the conversation connected as it moves between those endpoints. Sending a message is only part of that job. A reply needs a route back, and the receiving workflow needs to recognize what the reply answers.

Even transport success has limits. Microsoft documents that an accepted email request does not establish that processing has finished. An application must distinguish submitting a message from receiving a response. Microsoft Graph sendMail documentation

I use an internal SQL Server database for the communication record. Other implementations can use different storage and messaging systems. Whatever the technology, the recipient needs enough context to answer, a route for the reply, and a record that survives the current session.

For cross-company collaboration, the design goal is to let a supplier or customer join the exchange through an authorized endpoint. Participation should be possible without granting access to our internal repositories or conversation history. We need to decide what context can cross that boundary and who may authorize the response. A familiar interface makes participation easier; access rules still determine what each participant may see and do.

🎉 Tip: Start with an interface your team already uses. You can improve a handoff without asking everyone to learn another inbox.

Governance and security travel with the conversation

When agents communicate across teams or companies, the conversation crosses boundaries of access and authority. Governance defines who may decide. Security controls who may participate, what information they may receive, and which actions they may take.

A message from another agent is a request to evaluate within those boundaries. Receiving it does not grant new permissions. A digital employee with broader decision authority still needs appropriate access, and confidential context should reach only authorized recipients. The same boundaries apply when a conversation moves through email, Teams, a dashboard, or a fallback channel.

For compliance, preserve evidence of who requested an action, which role authorized it, and what happened. Retain and protect those records according to the organization’s requirements. A durable thread can support accountability and review; keeping a conversation history alone does not establish compliance.

Keep a way to ask for help when communication fails

A lane had been onboarded and started work. After its first access token expired, work in that lane stopped. A successful first connection had not established that the lane could keep operating.

That raises a practical question: if the failure also prevents the lane from using its normal communication path, how does it ask for help?

In my setup, files and tickets provide fallback paths. Teams messages, email messages, and dashboard messages also provide separate routes when my internal agent communication service is down. A human can act as the interceptor: recognize that a lane is down and carry the alert to the lane responsible for unblocking it.

That intervention has a clear purpose. The person connects a blocked lane with someone who can restore its operation. We should preserve that recovery role even as we remove the everyday copying and forwarding.

My workflow orders work by Business Value (BV), highest first, and automatically assigns critical system outages the highest value, 10. Within each BV, Priority (P) runs from 1 (highest) to 5, with BV10 not automatically implying P1.

Ranking the ticket helps the receiving team choose what to address. The alert must also reach that team through a working channel. A high-ranked ticket that nobody can see cannot unblock a lane.

Separate channels give us recovery options, but we must check which channel survives the actual failure. Two interfaces can still depend on the same credentials or service. The fallback needs to reach an authorized recipient without depending on the broken path.

The alert should identify the affected lane, what work has stopped, and who needs to help. Keep a durable ticket or file record so an urgent human handoff does not become a forgotten conversation. When the normal path returns, reconcile the fallback record with the original work so parallel alerts do not become duplicate assignments.

Unaffected lanes should be able to continue work that does not depend on the failed lane. Work that does depend on it needs to remain visibly blocked. That gives us a chance to contain the disruption before a local failure becomes a prolonged or wider outage.

🎓 Lesson

• Keep a working route to the person or lane that can help you recover, including a human when needed.

Preserve the conversation when the workspace changes

Several lanes can also contribute to the same repository. Git worktrees provide separate working directories associated with that repository, allowing contributors to work on different branches at the same time. They give each contributor a separate place to work. Git worktree documentation

Those contributors still need to coordinate overlapping changes and review the combined result. A lane describes responsibility; a worktree provides a working directory. Neither alone tells a colleague why a decision was made.

The conversation and its references therefore need a durable home. If a reference points only to a temporary working directory, cleaning up that directory can break the handoff. A durable reference should lead to a retained decision, ticket, or saved revision that another participant can retrieve with appropriate access.

The practical test is whether the next participant can recover the question, answer, and supporting work after the original workspace is gone. That extends the same continuity principle discussed in why AI forgets between sessions to communication between participants.

Why: How do we gain speed without interrupting everyone?

We need to distinguish the wait for the recipient’s attention, the time spent resolving the question, and the human effort spent carrying messages. A quick conversation can still consume our day if we must relay every exchange.

In my experience, the first ACK can take a while, depending on what the destination lane is already doing. Once the conversation starts and is acknowledged, the back-and-forth is usually near-instantaneous. That is an operational observation, not a guaranteed response time.

I treat an AI agent’s attention much like a person’s attention. I do not want every incoming message to interrupt its current work. My polling mechanism is mechanical: it checks on a cadence and interrupts a lane only when there is a message requiring a response. The agent does not spend model tokens repeatedly asking whether there is new mail.

A critical outage needs an urgent escalation path to the responsible human or lane. Waiting for a daily briefing is inappropriate when work has stopped and the normal communication path cannot carry the alert. The team’s agreed urgency rules should determine when an interruption is warranted and which surviving channel to use.

That does not make communication free. The polling software still consumes computing resources, and interpreting a message can require model reasoning. The separation keeps routine checking out of the model’s workload.

Public implementation examples are available in JitNeuro, including its mechanical polling hook and message watcher. These files show the checking and signaling mechanisms. They do not establish a response-time guarantee or demonstrate every human interface described here.

Measure waiting, resolution, and relay effort separately

If we measure only time to ACK, we can reward a system for interrupting everyone immediately. If we measure only uninterrupted work, questions can wait too long. Assess routine exchanges separately from urgent outage alerts, where delayed attention can keep a lane blocked.

For one recurring handoff, compare three measures:

• Time awaiting attention: from the request becoming available to the receiving lane until that human or agent explicitly acknowledges it. Record transport acceptance separately.
• Time resolving the question: from that ACK until an answer addresses the original question well enough for the work to proceed.
• Human relay effort: the time people spend copying, forwarding, explaining, and chasing the exchange.

An ACK is the observable response confirming that the recipient has recognized the request. It does not establish that the question is answered, the work is complete, or a new action is authorized. These are proposed measures for evaluating the change, not results I am claiming to have measured. Check answer correctness and unnecessary interruptions alongside them.

The distinction helps us choose the right improvement. A long wait before ACK calls for examining routing, capacity, and notification cadence. Repeated clarification after ACK calls for examining the question and its context. Continued human relay effort calls for checking whether questions and replies actually reach the tools where work happens. Buying a faster model will not, by itself, tell us which of those problems we have.

🎓 Lesson

• Check where your handoff waits before changing how often you interrupt the recipient.

Plan for the work that messaging cannot remove

The strongest objection is straightforward: better routing can put more work into an already busy queue. A dashboard, briefing, and to-do list make a question visible; they do not create capacity to answer it.

We still need an accountable owner, priorities, and a way to escalate a question that has waited too long. We also need to maintain the connections between interfaces and prevent a repeated notification from becoming duplicate work. Routine questions and urgent exceptions need explicit handling that the participating teams agree to.

The return is less time spent finding a recipient, reconstructing context, and moving answers between tools. Sales can contribute customer knowledge without depending on a developer to relay every exchange. Delivery can resolve an ambiguity before building against the wrong assumption. People stay involved where their judgment is needed.

🎉 Tip: Choose a handoff where you already know who can answer. You have enough context to test a useful improvement with that team.

Where should we start?

Choose a recurring question that crosses a team boundary. Before adding another notification, identify the lane responsible for answering and where that team already manages its work.

Agree on the context the recipient needs, how follow-up questions return, and when an unanswered question deserves attention. Preserve the answer with the original conversation. Then check whether the answer reached the originating work and was used correctly.

Include a controlled failure exercise before depending on that route. Confirm that someone can recognize a stopped lane, reach the team able to unblock it through a fallback, and preserve the recovery work in a ticket or file. Check that unaffected work can continue and that the fallback record is reconciled when normal communication returns.

Compare that exchange with the old process. Did someone still have to copy the message, reconstruct its meaning, or chase it through a separate tool? Did protecting the recipient’s attention leave important work waiting too long?

Expand the pattern when it reduces routine relay work without creating unacceptable delay or rework, and its recovery route has been demonstrated. Keep the human escalation path available for the failures automation cannot carry through.

Frequently Asked Questions

Connecting agents and assigning responsibility

How do you get AI agents to talk to each other?

Give the agents an authorized messaging route that preserves the question, destination, and replies. The recipient needs enough context to answer or ask for clarification. Start with a question that currently requires you to copy information between agents, then verify that its answer returns to the original work. Read more about keeping the connection lightweight.

Can AI agents collaborate?

Yes. Agents can route questions to the role responsible for an answer, clarify requirements, and return decisions to the work that needs them. Collaboration requires clear responsibilities and shared context. In my setup, lanes give requests a destination, while queues and threads keep outstanding work and replies visible. Read more about giving a question a destination.

What is a digital employee?

A digital employee, as I use the term here, is an AI agent with an assigned role, responsibilities, and operating boundaries. A role defines the work, a persona shapes the perspective, and a charter defines decision authority. Giving an agent a job title alone does not establish what it may decide or authorize. Read more about roles and charter authority.

Human involvement and decision authority

Does a human need to be involved when AI agents communicate?

No. Agents can exchange information, ask for clarification, and resolve questions within their assigned authority without a human participating. Communication alone is not a reason to involve a person.

When a question exceeds the working agent’s authority, another digital employee may be authorized to decide. Our organizational charters define those responsibilities and decision boundaries. The working agent can route the question and supporting context to that role, receive a decision, and continue.

Human involvement is needed when the question requires human judgment, knowledge the agents cannot obtain, approval reserved for a person, or recovery assistance that the agents cannot provide. Escalate to the role equipped and authorized to resolve the issue; that role may be another agent or a human. Read more about autonomous work and its boundaries.

What role does human oversight play in AI decision-making?

Human oversight establishes which decisions an agent may make and which require human approval. Role charters make those boundaries explicit so routine questions can be resolved by authorized agents. When human knowledge, judgment, or authorization is needed, the conversation should reach the appropriate person with enough context to decide. Read more about clarification and the limits of an answer.

Handoffs and recovery

What is a handoff between AI agents?

A handoff between AI agents transfers a question or responsibility with the context needed to continue the work. A durable conversation lets the recipient clarify the request and recover the answer after a session ends. Give your recipient references to a retained ticket or saved revision, then verify those references remain accessible after workspace cleanup. Read more about preserving the conversation when the workspace changes.

What happens when communication between AI agents fails?

Dependent work remains blocked; unaffected work can continue. Use a surviving fallback, such as a ticket, file, Teams message, email, or human escalation, to alert whoever can restore service. Check that the fallback does not depend on the failed service or credentials, and reconcile its record when normal communication returns. Read more about asking for help when communication fails.

For more articles on putting AI to work across your organization, subscribe to the newsletter.