Guide · Foundational
Your Most Valuable Employee Might Be Acting as an API
The person copying information may be doing much more than moving it.
Remove unnecessary bridging without discarding the contextual expertise that makes it work.
The invisible integration layer
Consider an illustrative coordinator who reads a customer request in CRM, finds the engineering project, copies its reference into an ERP order and updates a planning spreadsheet. Each task looks small. Together they connect systems that do not share an adequate account of the same work. This is Human Middleware.
The bridge may be so reliable that colleagues stop noticing it. They see information appearing in the right place, not the effort required to put it there. The coordinator becomes the unofficial integration contract: knowing which system to trust, which names correspond and which incomplete requests should not move forward.
Do not confuse repetition with simplicity
A repeated action is not necessarily a mechanical action. The coordinator may spot that a familiar customer has requested a different site, that a project reference is an old revision or that an apparently missing approval is recorded under another name. The copy-and-paste is visible; the interpretation is not.
Before automating, observe several actual transfers and ask the person to explain why each choice was made. Separate verbatim copying, format conversion, identifier reconciliation, completeness checks and contextual judgement. These activities need different interventions. An API can transfer a field reliably and still transfer the wrong meaning.
Look for architectural causes
Useful questions concern system boundaries rather than personal efficiency. Do the systems agree on the business object? Is there a stable mapping between identifiers? Who owns the field being transferred? What event makes the next action ready? How are corrections and duplicates handled? Without those agreements, a connector can reproduce the same uncertainty at greater speed.
Sometimes the bridge exists because the standard process never accommodated a legitimate variation. Sometimes it exists because no one owns the integration. Sometimes the tools can already communicate, but teams have incompatible definitions of status. The presence of a manual bridge is a reason to investigate, not proof of any one cause.
Protect the expertise while changing the work
Invite the person into the design, including decisions about what must remain reviewable. Capture examples of ambiguous cases and the cues that resolved them. Make the explanation usable by others, not just a list of steps stripped of context. Some knowledge belongs in explicit rules; some requires training and expert escalation.
Removing humans is not the objective. A better design can reduce repeated transfers so experts spend more time resolving exceptions, teaching and improving the process. But that benefit should be tested rather than promised. If the automation creates a new review queue that requires the same person to inspect every record, the dependency may have changed shape rather than disappeared.
A safer transition
Start with a narrow, understood transfer. Define the input, identity mapping, expected output, failure handling and owner. Compare proposed results with the expert’s decisions before authorising execution. Record disagreements and ask whether the rule, data or underlying process needs to change. Do not quietly classify the expert as wrong because the software disagrees.
After release, inspect incomplete transfers, stale updates and changes in source systems. Give people a clear way to correct an item and understand what happened. The aim is not a perfect diagram of connected boxes. It is a working relationship between systems and people in which necessary judgement remains available and unnecessary bridging is no longer the organisation’s hidden infrastructure.
Questions worth asking
- Which part requires human judgement and which part exists because the systems cannot communicate?
- What does the person notice that is not represented in a field?
- Which ambiguous cases should remain with an expert?
Foundational explanation and illustrative examples. This article does not report findings from client engagements or establish a pattern in your organisation.