New hires spend their first month fighting infrastructure, not doing the job they were hired for. A relationship manager’s first weeks look less like relationship banking and more like ticket-chasing: a laptop that takes four days to provision, a VPN profile that does not work until IT re-issues it, a CRM login that arrives a full week before the core banking login does. 

The first two weeks get spent shadowing someone else’s screen, because there is nothing else to do yet. By the time access actually clears, the job the person was hired for has barely started.

An AI coworker hits the identical wall on day one, and for the identical reason. Not because it cannot do the work. Because the work was never the hard part.

Legacy systems do not care what is asking

A core banking platform built decades ago, running batch jobs overnight and exposing nothing in real time, is exactly as unhelpful to an AI coworker as it is to a new analyst trying to check an account balance on their first day. If there is no way to grant scoped, governed access to that system for a human, there usually is not one for a coworker either. 

Someone has to build that access first, and the work does not get easier just because the requester on the other end is software instead of a person.

This is usually where a workaround culture shows up instead: screen-scraping a legacy terminal, a shared login three teams quietly depend on, a nightly export into a spreadsheet that has become someone’s unofficial source of truth. Those workarounds are evidence of the same rot an AI coworker runs into, they just went unnoticed for longer because a person was patient enough to live with them.

This is also the part of AI adoption that never makes it onto a roadmap slide. Vendors show what a coworker can do once it has access. Nobody shows the four months it took someone to get a service account provisioned against a system that was never designed to be asked twice.

Siloed data confuses everyone equally

Ask any new hire what their most disorienting week was, and most will describe the moment they discovered the same customer had three different addresses on file: one in the CRM, one in core banking, one in whatever spreadsheet the branch team actually trusts. Nobody tells them which one is right. They learn it the slow way, usually after acting on the wrong one once.

An AI coworker runs into the same fog, minus the ability to lean over and ask a colleague which system to trust this week. If an enterprise has never reconciled its own systems into a consistent view of a customer, a coworker cannot manufacture that consistency on its own. 

It can only surface the conflict, the same way a careful new hire eventually learns to flag it instead of guessing, and the quality of that surfacing depends entirely on whether anyone built a way for it to compare the systems in the first place.

Access bureaucracy slows both down for the same reason

Provisioning a new employee usually means a request ticket, a manager’s approval, a security review, and a wait that has nothing to do with how capable the person is and everything to do with how the organization grants access to anything. 

An AI coworker needs the same kind of governed access, scoped to what the job actually requires and revoked the moment it is not needed.

Most enterprises do not have a fast version of that process even for humans, let alone one built for software that might need access to six systems in its first week. If anything, the review tends to move slower for a coworker the first time, because most security teams have a mature playbook for onboarding a person and no playbook yet for onboarding something that is not one.

The result is an AI coworker sitting exactly as idle as an unprovisioned new hire, for exactly the same reason: not a talent gap, an access gap.

The thing that was never actually the bottleneck

It is tempting to read all of this as a case against AI, or at least against the pace of AI adoption. It is closer to the opposite. Every one of these obstacles already existed before anyone tried to deploy a coworker. They were just easier to ignore when the person waiting on access was a new hire and not a piece of software with a sponsor asking why the pilot has stalled.

The teams that get an AI coworker running quickly are, almost without exception, the teams that had already done the unglamorous work of fixing their own onboarding: consistent access provisioning, a reconciled view of core data, systems that can grant scoped permissions without a six-week ticket. The coworker did not create that need. It just made the cost of not having it visible in weeks instead of years.

What this actually means for the team

None of this is a story about fewer people. A coworker blocked by the same legacy system that slows down a new analyst is not a threat to that analyst’s job, it is proof the two of them are fighting the same infrastructure. The teams worth paying attention to are not asking whether AI will replace headcount. They are asking why it took their last new hire six weeks to get useful, and whether they are willing to fix that before they expect a coworker to move any faster.

The AI coworker will not be slowed down by a shortage of intelligence. It will be slowed down by the exact same bureaucracy that has always slowed down every person who has ever joined that team, which is either a reason to be discouraged about AI, or the clearest argument yet for finally fixing the onboarding problem the organization already had.