Stop Using Proxies to Fix AI Team Communication

AI has made an old organizational problem harder to ignore: business teams and technical teams often do not understand each other well enough to build the right thing together.

The first reaction is usually to add a person in the middle. Give the business a single contact. Give engineering fewer interruptions. Let someone translate requests, collect priorities, smooth the language, and turn scattered demand into a queue the team can manage.

That can feel efficient at first. It reduces noise. It gives people a name to contact. It creates the appearance of coordination.

But in AI, data, and software work, a proxy often hides the real gap instead of fixing it. The problem is not only that the business speaks one language and engineering speaks another. The deeper problem is that both sides need shared responsibility for the workflow, the data, the risk, and the outcome. No middle role can carry all of that alone.

This matters more now because AI work is moving from experiments into operational systems. A chatbot over policy documents, a support triage model, a sales assistant, a text-to-SQL tool, or an agent that updates records is not just a technical feature. It changes how work happens. If the people who understand the work are separated from the people who build the system, the project may look organized while the real decisions are being made with weak context.

The better answer is not more meetings for their own sake. It is direct collaboration with clearer ownership. Business people need to own the process and the value. Technical people need to understand the work deeply enough to make good design choices. Leaders need to make priorities visible enough that teams are not forced to guess.

A Proxy Can Make The Real Gap Harder To See

There are situations where a coordinator is useful. Large programs need scheduling, follow-up, documentation, and decision tracking. A product manager, business analyst, delivery lead, or technical program manager can do valuable work when the role clarifies decisions and keeps people aligned.

The problem starts when the role becomes a substitute for direct understanding.

If a business team cannot explain the workflow to the people building the system, adding an intermediary does not solve that problem. If an engineering team cannot discuss tradeoffs in plain language, a proxy may protect the team from discomfort for a while, but it does not improve the team’s judgment. If leaders cannot prioritize, the person in the middle becomes a collector of demands instead of a creator of clarity.

This is especially dangerous in AI projects because many decisions look small from the outside but change the system’s behavior.

Should the assistant answer from all documents or only approved ones? Which users can see which records? What should happen when the model has weak evidence? Is a generated summary allowed to become the official record? Can an agent create a ticket, update a customer field, or send a message without approval? Is speed more important than accuracy for this workflow, or the other way around?

These are not translation questions. They are business, product, risk, and engineering questions at the same time.

A person in the middle can write down the answers, but they should not be the only person who understands the implications. The people responsible for the outcome need to hear each other think. Otherwise, the system becomes a chain of assumptions.

AI Raises The Cost Of Weak Collaboration

In a traditional software project, poor communication can produce the wrong screen, the wrong report, or the wrong automation. That is already expensive. In AI projects, weak collaboration can produce something more subtle: a system that sounds useful while making unreliable decisions inside a real workflow.

McKinsey’s 2025 State of AI survey shows the current tension clearly. AI use is broad, but many organizations are still in experimentation or pilot stages, and the companies seeing more value are more likely to redesign workflows rather than simply add tools on top. That point is important. AI value usually appears when the work changes, not when a model is attached to a broken process.

If a team only receives requirements through a proxy, it may never see the real process. It may see a cleaned-up version of the process, or a list of requested features, or a complaint about the current system. Those are inputs, but they are not enough.

AI teams need to understand the messy details:

• Where do people make judgment calls today?
• Which data is trusted, stale, duplicated, or politically sensitive?
• What happens when the answer is wrong?
• Which decisions require human review?
• Which exceptions are common enough to design for?
• Which success metric matters to the business, not just to the model?

These questions cannot be answered well from a distance. A proxy can summarize them, but the summary often removes the friction that reveals the real design problem.

For example, a business team may ask for an AI assistant to answer customer policy questions. On paper, that sounds straightforward. In practice, the system may need to handle regional rules, outdated PDFs, unpublished exceptions, permissions, customer-specific contracts, escalation paths, and compliance language. If engineering never talks directly with the policy owners and front-line users, the assistant may perform well in a demo and fail in the actual work.

The failure is not the model’s fault alone. It is a collaboration failure.

The Business Must Own The Workflow

One mistake organizations make is treating business process design as technical work by default. The system touches the process, so the process gets pushed toward the technical team.

That is backward.

The business owns how work should happen. Technical teams can challenge, clarify, automate, measure, and improve parts of that work, but they should not become the only people responsible for defining it. A data team should not have to decide the sales process. An AI engineer should not have to invent the approval rules for a claims workflow. A platform team should not have to guess which support exceptions matter most.

When the business does not own the process, the proxy role becomes overloaded. It starts absorbing questions nobody else wants to answer:

• What is the real priority?
• Who can approve a change?
• Which exception matters most?
• Is this workflow standard or just one team’s habit?
• What risk is acceptable?
• What outcome proves the project worked?

Those answers need accountable business owners, not just good note-taking.

This becomes even more important when AI agents enter the workflow. The Model Context Protocol specification describes a standard way for LLM applications to connect with tools, context, and workflows. That kind of integration is powerful because models can reach into real systems instead of staying inside a chat window. It also raises the bar for ownership because tool access turns suggestions into possible actions.

If an agent can read documents, create tasks, query databases, or update records, the business must help define what the agent is allowed to do and where a person must approve. Engineering can implement access control and logging. Security can review the risk. But the process owner has to say what should happen in the work itself.

Without that ownership, the organization ends up with a technical system wrapped around an unclear business process.

Technical Teams Must Learn The Work, Not Just The Stack

The other side of the problem is technical distance.

Some engineering teams want business requests to arrive in a clean format: requirement, priority, acceptance criteria, deadline. That desire is understandable. Interruptions are real. Context switching is expensive. Teams need focus to build well.

But complete separation creates weak systems. Technical judgment improves when engineers understand why the work matters.

An AI engineer choosing a retrieval strategy should understand whether users need exact policy language or broad guidance. A data engineer building a pipeline should understand which fields are operationally critical and which are rarely used. A backend engineer exposing tools to an agent should understand which actions are reversible and which require careful approval. A data scientist evaluating a model should understand the cost of false positives and false negatives in the actual workflow.

That understanding changes design.

It affects whether the system should answer directly or ask a clarifying question. It affects whether the output should be a paragraph, a structured JSON object, a draft for human review, or a blocked action. It affects whether latency matters more than completeness. It affects whether the team should use a large model, a smaller model, a rules-based system, or no AI at all.

In How Technical Teams Earn Trust in AI Systems, I wrote that trust depends on evidence, ownership, and clear communication when systems fail or change. The same principle applies here. Technical teams earn trust not by avoiding the business, but by learning enough about the business to make better technical decisions.

This does not mean every engineer must attend every stakeholder meeting. It means the team needs real contact with the work. Sit in on user interviews. Review actual examples. Watch how people use the current system. Ask what happens after the model produces an output. Study failures with the people who feel the consequences.

The best technical questions often come from seeing the work directly.

Product Ownership Beats Translation

The answer is not to remove every coordination role. The answer is to stop confusing coordination with ownership.

A strong product owner or product manager does not simply carry messages between groups. They help define the problem, clarify the user, connect the work to business value, force priority decisions, and keep the team honest about tradeoffs. A strong business analyst does not simply collect requests. They model processes, test assumptions, uncover exceptions, and help turn vague demand into decisions the team can build against.

Those roles can be extremely valuable. But they work best when they connect people, not when they keep them apart.

For AI and data projects, product ownership should make several things explicit:

• The workflow being changed
• The users affected
• The business outcome expected
• The data sources involved
• The decisions or actions influenced by AI
• The risk tier of the use case
• The human approval points
• The evaluation criteria before rollout
• The owner after launch

This is a different mindset from simply translating requests. It treats the project as a living system, not a ticket queue.

Datadog’s State of AI Engineering describes production AI work as increasingly similar to distributed systems work: multiple models, orchestration frameworks, tool calls, retries, cost control, and debugging across service boundaries. That is exactly why proxy communication is so fragile. The system has too many moving parts for one person to be the only bridge between context and implementation.

The bridge should be the operating model, not one overloaded person.

Put Priorities Where Everyone Can See Them

Many communication problems are really priority problems.

When every department wants its own AI assistant, dashboard, workflow automation, or agent, the technical team cannot satisfy everyone at once. If leaders do not make tradeoffs, the team is forced to manage disappointment informally. A proxy role then becomes the complaint desk for a prioritization failure.

Clear priorities reduce the emotional load on collaboration.

Instead of asking a middle person to keep everyone calm, leaders should make the decision criteria visible. Which projects support the most important business goals? Which reduce serious risk? Which unblock many teams? Which are experiments, and which are production commitments? Which have owners ready to change the process, not just request a tool?

AI prioritization should also include operational cost and risk. A workflow that looks valuable in a demo may require expensive model calls, careful evaluation, document cleanup, access control, monitoring, and support. Another workflow may deliver smaller visible value but be easier to scale safely. These tradeoffs need to be discussed openly.

NIST’s AI Risk Management Framework is useful here because it encourages organizations to govern, map, measure, and manage AI risk across the lifecycle. In practical terms, that means leaders should not evaluate AI ideas only by enthusiasm or demo quality. They should ask what risk the system creates, how it will be measured, who owns it, and how it will be managed after launch.

Prioritization is not only about saying yes or no. It is about deciding what deserves the organization’s attention right now.

If business and technical teams can see the same priority logic, they spend less time arguing through intermediaries and more time making the work better.

Build Collaboration Into The Operating Model

Good collaboration should not depend on heroic individuals. It should be built into the way projects run.

For a serious AI or data initiative, I would rather see a small, direct working group than a long chain of message passing. The group does not need to be large. It might include a business process owner, a product lead, an engineer, a data or AI specialist, a security or governance partner when risk is meaningful, and one or two real users.

The important thing is that each person has a reason to be there.

The group should work through concrete artifacts:

• A workflow map showing what changes
• Real examples of inputs, outputs, and exceptions
• A data inventory with ownership and access rules
• A risk tier for the use case
• Evaluation cases before rollout
• A release plan with human review where needed
• A support and ownership model after launch

Artifacts reduce the need for translation because they give everyone something shared to inspect. A workflow map exposes missing business decisions. Test cases expose unclear quality expectations. Access rules expose data risk. A support plan exposes whether the system is truly ready to become part of daily work.

This also helps the technical team protect focus. Direct collaboration does not mean unlimited interruption. It means structured contact at the moments when shared understanding matters most: discovery, design tradeoffs, evaluation, rollout, and review after failures.

In other words, do not put a person between the teams and hope trust appears. Design a rhythm where trust has a chance to grow.

What To Do This Quarter

If an organization already depends on proxy communication between business and technical teams, the fix does not need to be dramatic. Start with one important workflow and make the collaboration more direct.

Choose a project where the stakes are real but manageable. It could be an internal document assistant, a support triage workflow, a reporting automation, a sales enablement tool, or a small agent that prepares work for human review.

Then do five practical things.

First, name the business owner. Not the person who sends requests. The person accountable for the workflow and the outcome.

Second, put engineers or AI specialists in direct contact with real users for a limited, structured period. Watch the work. Review examples. Ask where mistakes would hurt.

Third, write down the priority logic. Explain why this project matters now, what it is not trying to solve, and what will be delayed because this work is taking capacity.

Fourth, define evaluation before launch. Even a small test set is better than judging the system by a few impressive examples. Include normal cases, edge cases, permission checks, refusal cases, and examples where the system should ask for human help.

Fifth, decide the operating model after launch. Who updates the content? Who monitors failures? Who approves prompt, model, or workflow changes? Who handles user feedback? Who can pause the system if it behaves badly?

None of this requires a huge transformation program. It requires seriousness about ownership.

A coordination role may still help. Someone may still schedule meetings, write notes, track decisions, and keep the group moving. That is useful work. The key is that coordination should support shared responsibility, not replace it.

The Takeaway

Business and technical teams do not need to become the same team in every sense. They have different expertise, pressures, and responsibilities. But they do need enough direct contact to build systems that fit real work.

AI makes this more urgent because the system is often embedded inside decisions, knowledge flows, and operational processes. The model may be new, but the leadership lesson is familiar: if the business does not own the workflow, and the technical team does not understand the workflow, the project is fragile.

Adding a proxy can reduce discomfort in the short term. It can make communication look cleaner. It can give everyone someone to contact. But it can also delay the harder work: clarifying priorities, improving process ownership, teaching technical teams the business context, and helping business teams understand technical tradeoffs.

The stronger pattern is direct collaboration with structure. Give people shared artifacts. Make priorities visible. Put real users near the builders. Treat risk and evaluation as part of the work, not a late approval step. Keep coordinators where they help, but do not ask them to carry accountability that belongs to leaders, product owners, business owners, and technical teams together.

In modern AI work, the goal is not perfect translation. The goal is shared understanding strong enough to produce better decisions.