The Person AI Actually Amplifies Isn't Who You Think

Everyone is talking about which jobs AI will replace. The more interesting question is which jobs it makes irreplaceable — and why those people rarely show up in procurement conversations.

There's a piece making the rounds on Hacker News this week — LLMs reward expertise — that uses Terence Tao's conversation with ChatGPT about the Jacobian Conjecture to make a simple argument: domain knowledge determines what you can extract from an AI model. Tao gets a fundamentally different response than a non-mathematician asking the same question, not because he prompts differently, but because he knows what to push back on and what to ignore.

The piece is about individual productivity. But there's an enterprise version of the same observation that we've been watching play out across deployments for the past two years — and it explains a failure mode that doesn't show up in any post-mortem we've read.

The question that changed how we scope projects

About a year into our B2B AI work, we started asking every prospective client a question that sounds technical but isn't:

"Who in your organization knows both how the business process we'd be changing actually works, and where the underlying data lives?"

The answers split cleanly into two categories.

In the first category: the sponsor pauses, thinks for a moment, and names someone. Usually a senior analyst or an operations manager who's been at the company long enough to have accumulated context that isn't written down anywhere. Someone like Maya — a coordinator at a nine-location fertility network who'd been running their Athena implementation for seven years. When we asked if she could join the next scoping call, she did. And the conversation that followed wasn't "here's what AI can do." It was "here's specifically what breaks in your intake process, and here's exactly which fields in your system are dirty enough to break any model you put on top of them."

That project finished three weeks early.

In the second category: the sponsor names a function, not a person. "That would be IT." Or: "The workflow stuff is kind of distributed across the team." That answer — which always sounds reasonable in the moment — is a description of a structural gap. The technical knowledge and the operational knowledge live in different places, with different people, on different timelines. Getting them to communicate with each other, on your schedule, for a project that isn't anyone's top priority, is not an engineering problem. It's an organizational condition you can't build around.

Those projects take twice as long. And they produce clients who walk away saying "AI is harder than we expected" — when what they mean is "we didn't have the person who makes this work."

What this person actually does

The reason we call this person the connector is that their value isn't domain expertise in the traditional sense. Maya wasn't the best clinician or the best database engineer at her organization. She was the person who understood both sides well enough to translate between them.

This is a specific and underappreciated skill. It requires knowing enough about the business logic to understand why a process works the way it does — including the informal, undocumented reasons that experienced humans rely on but that never make it into any spec. And it requires knowing enough about the data reality to understand which of those informal inputs have a corresponding field in the system, and which live only in someone's head.

The seangoedecke piece describes this in the context of individual AI users: the domain expert can push the model harder because they know what a good response looks like. They can say "no, I think it could be simpler here" or "but don't we already do X?" The connector does this at the organizational level — they can push the deployment harder because they know where the model's assumptions will collide with the reality of how the business actually operates.

Without them, AI deployments don't fail. They drift. The model gets built on top of a process that the deployment team partially understood. It performs well in testing, where the inputs are clean and the edge cases are known. It performs poorly in production, where the inputs are messy and the edge cases are exactly the cases that required human judgment to begin with. And nobody can explain why, because nobody has the full picture.

Why enterprise procurement doesn't screen for this

The standard enterprise AI procurement conversation covers a lot of ground: budget, timeline, technical requirements, security posture, integration complexity, ROI expectations. It does not typically cover: does your organization have a person who bridges operational logic and data reality, and is that person available to work with us?

There are several reasons for this.

The first is that the connector role doesn't have a job title. Maya's title was something like Clinical Operations Coordinator. She wasn't hired to be the bridge between business process and data architecture. She became that bridge by accident, over seven years, because she was curious and capable and nobody else filled the gap. You can't put "connector" in a vendor RFP and expect a useful answer.

The second is that the connector isn't usually in the room when the deal is being sold. The sponsor is there. The decision-maker is there. The IT security lead might be there. The person who actually knows where the patient ID appears in seventeen different formats across three different systems is not there, because nobody thought to invite her.

The third is that the procurement frame treats AI deployment as a product purchase, not an organizational capability question. You evaluate the vendor's product. You evaluate the vendor's team. You rarely evaluate your own organization's readiness in a specific enough way to surface the connector question.

This is a meaningful gap. Not because it causes projects to fail outright — it usually doesn't. It causes them to take twice as long, cost more than budgeted in internal time, and produce a result that underwhelms everyone relative to the original expectation. Which is a subtler failure mode, but an extremely common one.

What changes when the connector is identified early

When we find the connector in the discovery phase — before we've signed anything — the entire shape of the engagement changes.

Scoping becomes specific instead of aspirational. Instead of "we'll build an AI system that handles insurance verification," the conversation becomes "we'll build something that can handle the clean cases that currently take Maya four minutes each, and flag the edge cases that currently require her to call the payer directly — and here's exactly what 'clean' means in your specific data."

Data readiness work compresses. The connector already knows which data is clean and which isn't. She knows it because she's been working around the dirty data for years. What takes us weeks to discover through auditing, she can often tell us in an afternoon — not because she has access to better information, but because she has the organizational memory to interpret what she's looking at.

Post-launch support becomes proactive instead of reactive. The connector can catch model errors before they propagate, because she knows what the correct output should look like. She doesn't need a dashboard to tell her something went wrong. She reads the output and knows.

The deployment we described at the fertility network — the one that finished three weeks early — wasn't exceptional in its technical complexity. It was exceptional in that we had Maya from week one, she was empowered to make decisions, and her boss had the organizational standing to keep her available to us when her other responsibilities competed for her time. The technical work was the same as any other project. The organizational conditions were different.

The talent dynamic nobody wants to say out loud

Here's the uncomfortable implication of the seangoedecke argument applied to enterprise AI: the people whose value increases most as AI gets better are often not the most senior people in the organization.

The connector — Maya, or her equivalent in any industry — is typically mid-level. Not on the leadership team. Probably not making a VP salary. Not obvious to anyone who looks at the org chart from the outside.

But she's the person who determines whether a $300,000 AI deployment finishes in four months or eight. She's the person whose availability decides whether the model learns the real process or a simplified version that breaks in production. She's the person who, when the model gets something wrong, can explain why — and whether the fix is a model problem or a data problem or a process problem.

As models get more capable, the bottleneck shifts further in her direction. A better model doesn't reduce the need for someone who can translate between the business and the data. If anything, a better model amplifies the translation gap — because a more capable model will confidently do more with whatever it's given, including confidently doing the wrong thing with a process it misunderstands.

The organizations that figure this out will start screening for it explicitly. They'll ask, before signing any AI deployment contract, whether the connector exists and whether they're available. They'll treat connector availability as a project resource the same way they treat engineering time and infrastructure budget.

The organizations that don't will keep discovering, six months into deployments, that the gap was there all along — it just didn't have a name.

One thing we might be wrong about

The connector model assumes that a single person can bridge the operational and technical sides of a business process. In straightforward workflows, this is often true — one person with the right combination of experience and curiosity covers enough ground to make the translation work.

In complex regulated environments — healthcare systems with multi-layered EMR architectures, financial institutions with decades of legacy data governance, pharmaceutical companies with regulatory data requirements that span multiple jurisdictions — the translation work may require more than one person. The "connector" becomes a small team, or a structured process, rather than an individual.

We've worked in some of these environments and found that the principle holds even when the implementation is more complex: what matters is whether the organizational bridge exists, whether it's available to the deployment team, and whether someone has explicit responsibility for maintaining it. The failure mode is the same regardless of scale — when that bridge is absent or unavailable, the deployment runs on assumptions instead of reality.

The question worth asking, regardless of organizational complexity, remains the same: who in your organization knows both how this process actually works and where the data lives? If the answer is "nobody," that's not a technical gap. It's the project risk.

Working notes from B2B AI deployment in North America. Part of an ongoing series on what we keep noticing across wildly different industries — and what the industry isn't ready to say out loud.

The connector question — "who in your organization knows both the business process and the data reality?" — is one of the first things we work through with clients before any deployment begins. If you're evaluating an AI project and haven't mapped this yet, [a 1-on-1 strategy call with our engineering team](https://zenaicorp.com/en) is where that conversation starts.