Ask almost any company right now what it wants from artificial intelligence, and the conversation eventually arrives at the same place: pull everything the organization knows into one system, and let its agents work with it directly. The request sounds technical, but what it usually turns up isn't a technology problem so much as a question most organizations have never had to answer directly, which is what they actually consider true and who gets to decide that.

What usually happens next is familiar enough to be almost universal. Someone connects the systems, points an agent at the resulting pile, and discovers what has quietly been true for years: five records for the same customer, each slightly different and none of them obviously correct; Slack channels nobody has opened since the person who ran them left; PDFs holding information that matters, filed somewhere a search bar can't reach. None of it is new, really. It has simply never had to answer to anything before now.

A person navigating that mess compensates without even noticing they're doing it. They know which spreadsheet is the real one, remember that the contract terms changed after that particular PDF was filed, and have, in effect, been quietly reconciling the organization's record of itself for years, one judgment call at a time, calling the result institutional knowledge. An agent doesn't have that judgment, at least not yet, and it doesn't quietly compensate the way a person does. It takes the data as given, and when the data disagrees with itself, the agent either picks one version with no way of knowing it's wrong, or it simply fails. Either way, the problem that was always there becomes impossible not to see.

This role is not new, even if it rarely had a name. Every enduring institution has had someone whose quiet job was exactly this: the archivist who decided which version of a document was the record of account, the chief of staff who kept straight what was actually agreed to in a meeting versus what people remembered agreeing to, the senior associate who was simply trusted to know which file was current. Institutions have always depended on this kind of invisible reconciliation, and what's new now is the expectation that it can be automated without ever being made explicit in the first place.

The easy conclusion is that this is an engineering problem, that better pipes and an enforced schema would make the mess resolve itself, and there's some truth in that; better infrastructure genuinely helps. But infrastructure cannot decide which of five customer records is correct, or whether an old PDF still governs a current relationship, or which abandoned Slack channel actually contains the reasoning behind a decision nobody wrote down anywhere else. Those aren't technical questions so much as questions about what an organization actually believes to be true, and most organizations have never been forced to answer them, because no single system ever needed one consistent answer before.

That's the real shift underneath the current rush to connect everything. It looks like a data problem, and it gets budgeted for like one, but what's actually being asked for is a kind of institutional memory most organizations have never deliberately built: one version of the truth, maintained on purpose, rather than many approximate versions quietly reconciled by whoever happened to be doing the work. Agents don't create this problem; they simply remove the person who used to paper over it.

Cleaning up the data is the visible task, the one that gets budgeted for. The harder, less visible one is deciding, deliberately and in advance, what the organization actually considers true, who gets to decide that, and how it stays true as things change. That kind of decision is difficult to make from inside the day-to-day running of a company, if only because the people closest to the mess are usually the ones who built the workarounds that created it in the first place. It tends to go better with someone who has watched this same pattern play out across a number of different organizations, and can see, from outside, which version of the record is actually worth keeping. Companies that treat this as a one-time cleanup project will likely be back here again within a year, while the ones that treat it as a standing discipline, built into how the organization keeps its own record, will be the ones whose agents can actually be trusted to work from it.

Every layer in an organization exists for a reason, even when nobody remembers what it was. Most of the time, that reason is judgment. Someone needed to take in more information than any policy could anticipate and decide what to do with it, and that someone needed to sit at a specific level, with a specific amount of authority, for the decision to actually stick.

AI is now doing a version of that same work. And most organizations haven't really reckoned with what that means.

Hierarchy, at its best, was never really about control. It was a bandwidth problem. No single person could process every piece of information moving through a growing organization, so companies built layers to compress it: a manager absorbing the noise from ten people and turning it into one decision, a director doing the same thing one level up. The org chart was, in effect, a map of where judgment calls happened and who was trusted to make them.

That system worked because the compression had to happen somewhere, and a person was the only tool capable of doing it.

That's no longer entirely true. AI can now take in a volume of ambiguous, unstructured information and produce something that looks a lot like judgment: a recommendation, a synthesis, a ranked set of options. It doesn't always get there the way a person would, and it isn't always right. But it's doing a version of the compression work that used to require a layer of management to exist in the first place.

Which raises a question most organizations haven't actually sat with: if part of what justified a layer was the judgment it performed, and a tool can now perform a version of that judgment, what is that layer actually for now?

Most companies haven't asked that question directly. They've added AI tools into the layers that already existed, which looks like progress — faster output, fewer bottlenecks — but quietly scrambles something more important: who actually owns a decision once AI has contributed to it.

When a recommendation comes from a model, gets reviewed by an analyst, and is approved by a director who didn't generate it and may not have the context to fully evaluate it, the chain of judgment that used to justify the structure has broken somewhere in the middle. Nobody necessarily notices, because the decisions still get made. But the accountability underneath them gets a little thinner every time this happens. And thin accountability is the kind of problem that stays invisible until it isn't.

What actually needs to happen is more deliberate than bolting a tool onto an existing structure. It's going back to the original question: where does judgment need to sit, and who is actually accountable for it? Decision rights then need to be redesigned around that honest answer, instead of around an org chart that was built for a world without AI in it.

That's a hard thing to do from inside a company that's still running day to day. It takes someone who can look at the structure itself rather than any one decision inside it, and who has seen enough organizations go through this kind of shift to know which parts of the old map are worth keeping and which ones were already starting to fail before AI ever entered the picture.

The organizations that get this right won't be the ones with the most AI tools. They'll be the ones that took the time to ask what their structure was actually for in the first place, and rebuilt it on purpose instead of letting it drift.

Most of what an organization actually believes about decision-making shows up nowhere more clearly than in how it hires.

I've run a lot of searches over the years, mostly in legal talent acquisition, and the clearest pattern I keep coming back to has almost nothing to do with the candidates themselves. It shows up after the interviews, once the feedback starts trickling in.

One interviewer comes back with "sharp, strong yes." Another says "fine, I guess, but I'm not totally sold." A third zeroes in on something completely different — how the person communicated, a gut feeling they can't quite explain, one offhand answer to one question that happened to stick with them. None of that is wrong, exactly. But none of it adds up to an actual decision, because nobody had agreed, going in, on the more basic question underneath all of it: what does a yes even require here?

That's the part I think is worth sitting with. A hiring process where feedback doesn't line up isn't really a hiring problem at all. It's a decision-making problem, just one you can finally watch happen — start to finish, in a few weeks, instead of playing out quietly over years.

Most decisions inside a company don't come with that kind of visibility. They get made quietly, by whoever happens to be in the room that day, and it's nearly impossible to trace the quality of the outcome back to any one cause. Hiring is different. It's one of the only places where an organization's decision-making muscle — or the lack of one — gets tested out loud, on a deadline, with a handful of people weighing in at once.

This shows up especially clearly in fields like professional services, where there's rarely a clean, objective bar to hire against. There's no code that compiles or doesn't. Almost every hire comes down to judgment, and it's in those judgment calls that the absence of a shared framework really starts to show.

The good news is that it's cheap to fix at this stage. One team, one hiring loop, one honest conversation about what actually counts as a yes, and you're most of the way there. What gets expensive is scaling a company on top of decision-making nobody ever actually aligned on in the first place — because by the time that gap shows up somewhere bigger and costlier, good luck tracing it back to something as simple as a missing shared bar.

What's actually needed here isn't more interviews, and it isn't more opinions either. It's a framework: a shared, deliberately built definition of what a yes requires, worked out and calibrated across everyone in the room before a single candidate walks in. Get that part right, and interviewers stop leaning on instinct alone. They start working off the same standard, and somehow the whole process gets faster and more honest at the same time.

Most organizations don't bother building that framework until a bad hire forces the issue. The ones that get ahead of it usually bring in outside eyes early on — someone who's built hiring systems across enough different organizations to spot the blind spots that are almost impossible to see from inside a process you run every single day. And that, I'd argue, is the real payoff of getting hiring right. Not just better candidates. A working, constantly tested model of how your organization actually makes decisions.

When was the last time someone three levels below you told you something was actually broken?

Not the type of feedback that is filtered or softened as it moves through the hierarchy of an organization, from manager, to director, to VP. By the time it reaches the top, you sometimes barely recognize the original problem.

And often this is the unwanted effect of a structure built by design, because most organizations build for efficiency first. Workflows get compartmentalized. Reporting lines get cleaner. Each layer of the org chart ends up responsible for passing information to exactly one layer above it. On paper, that looks tidy. In practice, it's a filter, and filters remove things — even the important ones.

Having watched this play out the same way across companies in a variety of industries, one thing rings true for all: the problem never really disappears, it just gets quieter. A workflow that's slowing a team down doesn't reach leadership as "this process is broken." If it reaches leadership at all, it shows up as a slightly lower productivity number two quarters later, stripped of context and entirely disconnected from its cause. By the time it's visible at the top, it's no longer an easily fixable issue. It will quietly establish itself as a trend. And trends are far more expensive to reverse.

This is why I've started thinking about culture the way I'd think about infrastructure. Nobody wants to prioritize budgeting for bridge maintenance until a bridge fails. The investment case stays invisible right up until the moment it becomes an emergency, or it starts showing up as an issue somewhere entirely different, making it hard to trace back to its origin.

As much as we want it to be true, a bold mission statement on the wall and the trendy values slide in the deck rarely capture it. What actually matters is the load-bearing system that lets information, decisions, and trust move through an organization without collapsing under pressure. Nobody notices infrastructure when it's working. Everyone notices it the moment it fails. That's usually mid-scale, or mid-merger — whenever the load eventually exceeds what the system was quietly built to hold.

So what does treating culture as infrastructure actually look like, day to day?

It looks like onboarding that tells people not just what to do, but how decisions actually get made and by whom — so new hires aren't spending their first six months reverse-engineering the org chart on their own. It looks like communication that runs in both directions across hierarchy: the highest level in a company should occasionally be talking to people three levels down instead of only hearing what's already been summarized by the level directly below.

That gets harder, not easier, as teams become more distributed — spread across time zones, geographies, and cultures with different norms around how directly people are comfortable raising concerns in the first place. This is a topic that deserves its own conversation, but it's worth naming here: the infrastructure has to be built for a team that isn't in one room, because the reality is, most teams aren't anymore.

And it looks like a formal process for surfacing issues, one people actually use — most open-door policies exist on paper and nowhere else. Most people don't feel comfortable escalating problems. They mention them quietly to a colleague in private, or decide it isn't worth the political capital to say something louder, and let it sit. Now take a moment and multiply that scenario across every team, every quarter, and you don't get one big visible failure. You get a hundred small silent ones, compounding.

I've seen this most clearly in legal and professional services, where culture tends to be more formal by design — and formality, for all its benefits, isn't always built for this kind of communication. In tech, a broken workflow usually announces itself: the code doesn't run, the feature doesn't ship, someone has to say so. In professional services, the failures are softer. A client relationship might be slightly more strained than it should be. A team might become slightly less willing to flag concerns, because that "isn't how things are done here." None of it is a crisis on its own. Left unaddressed, all of it eventually becomes one.

So, when was the last time someone three levels below you told you something was actually broken?

If the honest answer is "I don't know", that's the infrastructure gap showing itself. And like any infrastructure, it doesn't get fixed by being noticed once. It gets fixed by being built — deliberately, before the load gets too heavy to carry.

That's the real case for building macro-level strategy in from the start, and for having people in the room, either inside the organization or advising it, who are trained to see the whole system rather than the task directly in front of them. That holds regardless of industry. It's also, at its core, what good advisory work is meant to provide. A vantage point on the structure sitting underneath the immediate problem. The kind of perspective that's hard to build internally while you're still the one running the system, day to day.

Most advice about doing business across cultures concentrates on etiquette: how to greet someone, when to exchange a business card, which hand is appropriate for which gesture. These details matter less than they are made to seem, and the attention paid to them tends to obscure something that matters considerably more — that different business environments often operate on genuinely different logics for how decisions get made, not merely different customs for how those decisions get communicated.

The differences run deeper than style. In some environments, trust is established through contract and precedent before a relationship develops; in others, the relationship comes first, and functions as the enforcement mechanism a contract will later formalize. Time horizons diverge in a similar way — a decision one institution expects to resolve in a quarter may be, elsewhere, the opening move of a multi-generational commitment, with no real contradiction between the two; they are simply being measured against different clocks. Authority can sit in different places as well: with an individual empowered to decide alone, or distributed across a family, a council, or a set of relationships that outsiders rarely see in full.

The common failure in cross-border work is rarely rudeness. It is a category error — the application of one system's logic inside another system built on different premises. Someone accustomed to fast, metrics-driven decision-making can easily mistake patience for indecision in a relationship-first environment, and respond by pushing too hard, which reads as a lack of respect, or by disengaging too early, which reads as a lack of seriousness. The reverse happens just as often: someone accustomed to a slow, relational build toward trust can misread a fast, transactional counterpart as insincere, when speed was simply the register that counterpart's own system operates in.

Genuine fluency is not a matter of adapting the surface — adjusting tone, learning the customs, picking a side. It is the capacity to hold more than one logic at once without collapsing either into the other, and to recognize, in a given moment, which logic actually governs the decision in front of you. The same institution may reasonably operate on different logics for different kinds of decisions: quickly and transactionally for operational matters, slowly and relationally for anything involving real capital or a long-term commitment. Mistaking one for the other, in either direction, is where most of the damage happens.

What gets attributed to culture, in these moments, is more often a mismatch of logics wearing a cultural costume. The skill that actually matters is not translation — finding the equivalent word or gesture — but interpretation: understanding which system of reasoning a given decision is actually being made inside, and responding to that system on its own terms rather than on the terms that happen to be familiar.