The meat proxy problem in teams using AI agents

Someone asks a question in the team chat. A colleague takes it to their agent, gets an answer and pastes it back. Another colleague copies that answer into a different agent to check it, add missing details or prepare the next question.

Repeat until the team has a decision, or a sufficiently long thread.

The people are talking to each other, but part of the conversation is happening between agents, with humans carrying the messages. The "meat proxy" description fits that part rather well. We have capable assistants at both ends and a person in the middle operating the clipboard.

It is tempting to connect the agents and remove the extra hops. I think that is worth exploring. The complication is that each person also brings different access, a different specialty and a different piece of the work. A pasted answer can carry some of that with it, even when nobody writes down what was added.

So the question I would start with is: which messages could disappear, and what would have to replace the work they currently do?

Why the relay exists

Take a fictional team discussing a slow export endpoint.

Backend engineer: My agent checked the export route. It suggests returning a job ID and generating the ZIP in the background.

Support engineer: I asked mine to check the support history. A customer's overnight script expects the ZIP in that response. Here is the integration requirement we can share from the ticket.

Backend engineer: It now suggests a separate asynchronous endpoint and keeping the existing one. Can we retire the old route later?

Product owner: The account team promised to keep that integration working through renewal. I can confirm the commitment. Changing it needs a separate decision.

There is useful work in this exchange. The code analysis found a way to move the slow work out of the request. Support supplied a compatibility constraint. Product supplied a commitment that affects the migration plan.

The access is different too. The coding agent can inspect the implementation. The support agent can inspect ticket history. The product owner may have the relevant account context. Giving all three the same question does not give them the same basis for answering it.

Some of the human effort could be pure forwarding. The backend engineer may copy a support answer unchanged into the coding session. That looks like a connection we could automate.

Other messages contain a correction, an interpretation or a commitment. If the support engineer removes customer details before sharing the requirement, the handoff includes a disclosure decision. If the product owner says the team cannot retire the route yet, that statement has an owner whose role matters.

Those jobs could also acquire better tooling or explicit rules. But a replacement needs to account for them. Moving the text faster only addresses the forwarding part.

What gets lost between one answer and the next

The most obvious waste is copying. I am more concerned about what survives the copy.

An agent might say, "For the callers covered by these tests, the change appears compatible." The message in chat becomes, "My agent checked it. Looks compatible." The next agent receives the shorter version and treats compatibility as an established input.

The original limit has disappeared before the next round of reasoning starts.

The same can happen to evidence. A conclusion arrives without the code revision, ticket passage or failed test that produced it. Another person asks for a second opinion, but the second agent has only the first agent's opinion to inspect.

That can still be useful for finding a logical gap. It gives much less assurance about a claim that depends on a source the second reviewer has not seen. Two agents agreeing after reading the same summary may simply be accepting the same premise.

In the export example, the useful second check is specific: does a customer actually depend on the synchronous response? Support can answer from another source. Asking another coding model whether the first response "sounds right" does much less to resolve that uncertainty.

I would want a shared answer to retain a small amount of context about how it was produced: what was checked, the relevant version or time window, the conclusion, and what remains unresolved. There is an established foundation for recording how information was produced in the W3C PROV family, which models sources, activities and attribution. A team could borrow those ideas without adopting a whole provenance system for its chat.

For this discussion, a short note might be enough:

Question: Can the current export route return a job ID instead of a ZIP?
Code checked: export handler at revision 8c4f2a1.
Constraint: an existing customer integration expects a ZIP response.
Basis: a support requirement approved for sharing with this project.
Proposal: add an asynchronous route; preserve the current response.
Open decision: who can approve a retirement plan for the old route?

That is a proposed handoff format, with fictional identifiers. The point is to give the next participant something more useful than a paragraph introduced by "my agent says". A source reference that the recipient cannot open should make that limit visible; another qualified person may still need to verify it.

Of course, if filling in the note takes longer than the original conversation, we have invented a form. I would start with the evidence and open question that people keep having to ask for.

Access makes the direct connection more complicated

The quick architectural answer is one shared bot with access to everything. It can read the code, search the tickets, inspect the account notes and answer the team directly.

That is convenient until it needs to decide which of those findings may go into which conversation.

A support agent being allowed to read a ticket does not establish that everyone in an engineering channel may read the ticket. A shareable technical requirement might be appropriate for that channel while the customer's private details are not. Even a summary can reveal restricted information, so shortening the source is not enough to settle the question.

Manual forwarding already has this problem. The human in the middle can disclose too much as well. Automation makes it important to specify the recipient and permitted scope rather than rely on an informal assumption about what colleagues usually share.

The identity behind a request matters. Is an agent asking on behalf of the backend engineer, on behalf of the project, or under a service identity with its own permissions? These can produce different legitimate answers.

For integrations that use MCP, its authorization specification requires servers to validate that access tokens target the intended server. Connecting systems does not mean passing one person's credentials through every participant. The team still needs its own policy for which derived findings can be disclosed to a requester or channel.

I would also separate permission to obtain an answer from permission to act on it. The support requirement can explain why an endpoint matters. The decision to change a customer commitment needs whatever authority the organization assigns to that decision. A direct connection has to preserve that distinction somewhere.

With that in mind, I can see several plausible ways to reduce the relay.

Keep the handoff but make it more useful

For occasional cross-team questions, I would consider keeping the human handoff and improving the message.

Forward the relevant finding, its basis and the unresolved question. Say when the person has checked something themselves. If an agent produced a draft that nobody has reviewed, keep that status clear. There is a meaningful difference between "here is a possible explanation" and "I checked the failing request against this code path".

In the export discussion, support could forward the customer dependency once, with an approved description that the engineering agent can reuse. The engineer would not need to keep returning to ask which part of the answer was confirmed.

This makes sense when the specialist is doing useful interpretation or the request is too infrequent to justify an integration. It also keeps the exchange visible to the people doing the work.

It is a poor fit when the same colleague forwards unchanged answers all day. If every export investigation requires the same person to ask the same support question, a better message template will only make the interruption more tidy.

Give the task a shared place

Another option is to make the task, rather than each private agent chat, the place where the agreed context lives.

A ticket, document or shared thread could hold the current question, the constraints accepted so far, relevant source references and the remaining disagreement. People and agents could add findings to it within their existing permissions.

For the export change, the brief would retain the requirement to preserve the ZIP response. A coding session started tomorrow would get that constraint from the task instead of reconstructing it from three people's chat histories. Support could correct the brief if the dependency turned out to concern only one version of the integration.

I find this attractive when the churn comes from lost assumptions and stale copies. It also gives a reviewer a visible record of why the proposal changed.

There is upkeep. Someone has to distinguish a current constraint from a suggestion the team rejected yesterday. Restricted evidence needs an appropriate place and a shareable account of what it establishes. Personal agent history may contain unrelated work that never belonged in the task.

A shared task brief also does not require every agent to comment on every message. An explicit request such as "check the compatibility claim" is easier to follow than several assistants continuously producing reactions. The team needs an answer to its question, and somebody has to read what gets posted.

Let specialists answer bounded requests

If requests across a boundary are frequent and predictable, an agent could ask the relevant specialist agent directly.

The engineering agent might ask: "Which documented integrations depend on the current export response? Return the requirements that can be shared with this project, plus any limits on the check."

The receiving service would decide what that requester can obtain, search its permitted sources and return a scoped result. The engineering agent could then use that result in its proposal. A human would be involved where the request needs additional context, disclosure review or a decision outside the automated policy.

This seems more useful than giving the coding agent unrestricted access to the support team's entire working context. It also lets the support side maintain its own terminology and rules for interpreting tickets.

Protocols can supply part of the connection. The A2A specification defines agent discovery, messages, tasks and artifacts. It leaves authorization decisions to the receiving server's policies. That gives a team machinery for exchanging work while keeping separate permissions; the team still has to define what a useful, shareable answer contains.

I would want the exchange attached to the visible task: the question asked, the returned finding and a clear status if the request could not be completed. Otherwise, the copying may disappear while the important discussion moves somewhere the team cannot follow.

There is also a stopping problem. One agent asks a follow-up, the other requests clarification, then the first expands the investigation. For an initial experiment, I would bound the request and make unresolved disagreement an explicit result. That gives the task owner a chance to decide whether the next round is worth doing.

This option asks the team to operate a service: someone owns the specialist's behavior, permissions, availability and corrections. It is more appealing for a repeated support or platform question than for a one-off conversation about an unusual product decision.

Put one agent on the task

The fourth option is to organize the assistant around the piece of work instead of around the person currently typing.

One task agent could maintain the export investigation, inspect the sources granted to that task and ask specialists for missing evidence. People would bring their expertise into the same working record. There would be less need to translate the discussion back into several private sessions.

That could work well when a task has a clear owner and most of the handoffs exist because everyone started in a different chat. A bug investigation or a migration proposal seems a reasonable place to try it.

The task agent would need a defined scope. It would not automatically inherit all the permissions or private history of everyone who comments. The task owner would also need a way to request a separate check of a disputed assumption.

This changes the review pattern. A second reviewer can investigate the original compatibility question before reading the task agent's proposed answer. Or the support specialist can check the customer evidence while the task agent handles the implementation. Those are useful differences in what gets examined, even if there is only one main working session.

I am less sure how well this works when ownership itself is contested. A shared agent can collect the disagreement and describe the choices. The organization still needs a way to decide whose constraints govern the result. That mechanism could be a person, a review process or an explicit policy, depending on the work.

Which option matches the actual interruption

These arrangements address different sources of friction. A team could use more than one.

What keeps happening	An option to try	What the team takes on
Occasional questions need a specialist's interpretation	A short, deliberate human handoff	Continued interruption and manual selection of what to share
People repeatedly reconstruct the same task context	A shared task brief or thread	Keeping the accepted constraints and open points current
The same bounded question crosses a team boundary every day	A specialist agent that accepts scoped requests	Owning its access rules, results and operation
Several private sessions are investigating one well-defined task	One task agent with specialist input	Defining its scope, decision owner and review process

Before building anything substantial, I would look at a few real threads and compare the agent's answer with the message the person actually sent.

An unchanged forward suggests a possible connection to automate. An added constraint suggests context the receiving side lacks. A deleted claim may reveal useful review. A sentence such as "I checked this and we can proceed" may contain a commitment that the replacement needs to represent.

Then I would try to remove one repeated handoff. If the next request takes less human effort to resolve, while keeping the relevant evidence and decision owner visible, that is a useful result. Fewer messages alone would tell me very little. The work might simply have moved into a hidden conversation that someone has to audit later.

Where I am still unsure

I do not have a settled answer about whether the assistant should belong primarily to a person, a team or a task. Different work may need different arrangements. A personal agent can carry valuable working context; a shared task can make collaboration easier to inspect; a specialist service can preserve a useful access boundary.

Has anyone already made this less awkward in a real team? Did you put the agents in a shared thread, expose scoped specialist requests, give one agent the task, or keep the human handoff deliberately?

I would like to hear which messages stopped needing a person to carry them, and which ones you still want a colleague to stand behind.