When Your Best People Become the Middleware

Before automating a workflow, find the judgment that makes it work.

Imagine a B2B technology company. A customer emails to ask whether the delivery date they were promised still holds, because they are about to schedule their own rollout around it.

The CRM shows the original commitment, and an AI assistant connected to it could draft a courteous confirmation in seconds. The company's most experienced delivery lead would not send it. An engineering dependency changed last week, after that date was recorded. If the company confirms now and the date slips, the customer will have committed their own people to a promise nobody checked.

The work between the steps

Before replying, the lead notices that the CRM and the engineering plan disagree. They ask the engineer who owns the dependency whether it moves the date. They check whether the CRM entry is a forecast or a date already given to the customer. They decide the gap is big enough to bring in the account owner, and only then draft a reply that someone with authority over the commitment has agreed to.

The process map says "receive inquiry, check status, respond." None of that work appears on it. The lead has become the organization's middleware, carrying information and decisions between systems and teams that don't connect on their own. The company depends on what this person knows because its systems and its decision rights don't join up, and it has depended on that long enough to stop noticing.

A workflow can look healthy for years because a capable person repairs it every day. Automate the visible steps and you can remove the repair along with the delay. An agent connected to several tools could then act on one reading of the situation across all of them before anyone checks whether the reading was right.

Not every gap is a defect

Some of what the lead does is repair. If they re-key a date because two systems don't synchronize, the answer is to fix the synchronization. Some of it is context that can be written down, such as which CRM field holds a forecast and which holds a commitment.

Other coordination exists for good reasons. A forecast, a customer commitment, and a contractual obligation are different things owned by different people, and at times they are supposed to diverge. Better integration can get the right information to the lead faster. It doesn't remove the need to judge whether this dependency threatens this customer, or to negotiate what the company is now willing to promise.

Some of the work is a decision nobody has made. If sales and delivery each believe they own the customer commitment, the lead is settling that conflict one case at a time. The organization still has to decide who owns the commitment. An agent can apply that decision once it exists.

Where AI helps

An assistant can pull the CRM record, the delivery plan, and the contract terms into one view and flag that the dates disagree. A study of 5,172 customer-support agents published in The Quarterly Journal of Economics found that access to a conversational AI assistant raised issues resolved per hour by 15% on average, with larger gains among less experienced and lower-skilled agents. The study concerns people using an assistant at one company, not autonomous agents or company-wide returns. Whether an assistant can support this delivery lead's judgment needs its own test.

The harder questions are which interpretation the company has authorized, which information is current, and which exceptions matter. Those need testing against real cases. For many workflows, an assistant that prepares the evidence for a person is enough, and simpler designs are often the better place to start.

Mapping what the proposal misses

Before approving an automation proposal, I would ask the team to sit with the people who do the work and walk through a few recent cases, including ones that went badly. What did they check, who did they call, what didn't they trust, and what stops working when they are away?

For this workflow, I would start by having the assistant assemble the evidence and flag disagreements. Changing a customer promise would still need approval. Record who owns each proposed change.

For each piece of hidden work, decide what needs to change and who owns it. The options are to fix a defect, capture context, provide AI assistance, delegate a bounded action, resolve ownership or authority, or keep the work with a person. A few real cases are enough to start.

A narrower proposal

In this example, the map changes what gets funded. The original proposal was an agent that answers delivery questions. The mapped version is smaller and easier to approve: the agent assembles the CRM record, the engineering plan, and the contract terms, flags conflicts, and drafts a reply for the lead. A person still approves any changed promise, and the delivery and account owners settle who owns the commitment before anyone asks an agent to apply that rule. The pilot would test whether this reduces the lead's time chasing information without weakening the answer.

That is the scope I would fund first, with the map attached to the business case.

If you'd like the rest of this series, which turns a map like this into an agent's operating rules, subscribe to Uncharted.

Originally published on LinkedIn on October 20, 2026.