Born After AI: What a Company Founded Today Should Do Differently

Sean Campbell
Authored bySean Campbell

Sean Campbell, CEO of Cascade Insights®, writes about AI and the people who use it in his LinkedIn newsletter, The Human Side of AI. Subscribe there to get each new edition.

Plus: 24 AI links, stories, and tools worth your time this week. Jump to the roundup ↓

I’ve been thinking about a question lately: What would I build differently if my company’s born-on date were today, October 12th, 2026?

Consider the environment a company founded this morning is born into. In the last few weeks alone, Anthropic shipped Opus 5.5, Sonnet 5.5, and Haiku 5.5, and OpenAI shipped GPT-6.1 Sol along with always-on background agents it calls Dots.

The question I’m posing goes well beyond which AI subscriptions to buy. How would the work happen? What would I hire people to do? What would customers pay for? And how would people learn the judgment they need to direct work they increasingly aren’t doing by hand themselves?

History suggests the answer matters more than it seems. In April 1956, Malcolm McLean loaded 58 metal containers onto a converted tanker called the Ideal X in Newark and shipped them to Houston. The ports of Manhattan and Brooklyn, built around narrow piers and gangs of longshoremen moving cargo by hand, spent years trying to adapt. Across the harbor, the Port Authority built Port Newark-Elizabeth around the box itself, with big cranes, rail connections, and acres of flat land for stacking. Over the next couple of decades, most of the region’s cargo moved to New Jersey, and the old waterfront jobs went with it. Marc Levinson tells the story in The Box, and the ports that won out were the ones designed for the container from the beginning.

So here’s the key point: companies have born-on dates, the same way ports do.

In the past, a business built around cloud software could avoid a migration that an older company had to plan for, fund, and survive. A mobile-first company could design around the phone rather than spend years adapting something built for a desktop. Older companies spent years debating whether employees should get phones with access to company data. The ones born after mobile just handed them out on day one, because they already knew how to secure them.

Those companies weren’t necessarily smarter. They had fewer decisions to undo.

A new founding date doesn’t answer those questions, and founders can bring old assumptions into a brand-new company. But companies with a born-on date of October 12th, 2026, have an opportunity established companies don’t: they can make these decisions before another way of working becomes something everyone has to defend.

It starts with a clean slate

McKinsey’s 2026 State of AI survey puts the challenge in perspective. Just 6 percent of respondents qualified as AI high performers under its definition. Nearly three-quarters of that group reported fundamentally redesigning workflows because of AI, compared with about a quarter of everyone else. (McKinsey & Company)

Buying the tools and changing the work are different jobs, and the second one is harder. It means taking apart processes that often exist for good historical reasons, that people know how to operate, and that may have helped the company succeed. Someone has to explain what should change without pretending everything that came before was foolish.

A company born today can skip some of that negotiation. It can ask who, or what, should do the work before the answer becomes a job description, a vendor contract, or a department, or, more importantly, a living, breathing human being who has been doing that work for several years. A company born today will still make bad decisions. It just inherits fewer of them as legacy to work around.

So what should this company of today consider? Here are a few things from my perspective. If you have more, I’d love to hear them.

The company makes all of its work legible to AI

I like Y Combinator’s Tom Blomfield’s phrase “legible to AI.” It’s more useful than telling everyone to get better at prompting. The idea is to make the information that explains how the company works available to the systems helping operate it. (Y Combinator)

In the company I’m imagining, decisions get recorded with their reasoning attached. Pricing logic doesn’t live only in the founder’s head. Examples of good work come with an explanation of why they were good, instead of sitting in a folder of finished deliverables.

That doesn’t mean recording everything or giving every agent access to every document. Each one gets the context it needs, with appropriate permissions. And someone has to keep that context current. A beautifully documented policy that stopped being true six months ago is still a problem.

Think of this as onboarding the AI, much as we onboard a person. Here is what we know. Here is what we have tried. Here is what we promised the customer. Here is where you should stop and ask. Writing that down is work, but I’d rather do it once and maintain it than reconstruct it in a chat window every time. And if you don’t like writing it down, just have a conversation with your AI. That works well too.

Employees hand off work to AI, not just questions

There is a difference between asking AI to help with something and giving it responsibility for a defined piece of work.

OpenAI’s recently introduced Dots illustrate this direction: always-on agents that can work across connected applications and carry a task beyond a single conversation, within the access and approvals a user provides. (OpenAI) We’ve known this was coming for a while. Grok offers similar functionality as Grok Bots, and we’ll soon see it on every major AI platform. As the line usually credited to William Gibson goes, the future is already here, it’s just not evenly distributed. In a company born today, the agents are on the team before the second employee is.

In the company we’re discussing, that distinction becomes part of how jobs are designed.

Consider a proposal creation process. An agent might gather approved background material, check the request against previous work, identify missing information, and prepare a draft. A person might look at that draft and decide whether the opportunity is worth pursuing, resolve an unusual commitment, and approve what the company promises.

So the important design decision is where responsibility changes hands. Who checks the facts? What requires approval? What happens when the request doesn’t fit the pattern? Who notices that the agent has produced something plausible but wrong?

The person closest to the work should help make those decisions, within boundaries the company has agreed on, and should have the authority to pull work back when the arrangement stops working. That responsibility belongs in the role itself. Deciding what to delegate, what to inspect, and when to intervene is part of doing the job, rather than a separate AI initiative. Eventually, we’ll be asking the same questions about what goes to a robot as well.

AI sits in the P&L like rent

AI gets a budget from the first month, as part of the operating model rather than a pilot that has to keep justifying its existence. That still means watching what it costs.

Ramp’s June 2026 AI Index, based on spending data from more than 70,000 U.S. businesses on its platform, put median monthly AI spending at about $11 per employee. The top 1 percent spent about $7,450 per employee per month. Annualize that and you get roughly $89,000 per employee per year. That’s company spending divided by headcount rather than a personal allowance, but the scale looks a lot more like a second salary than another software subscription. (Ramp)

And if that employee plus their AI is producing two, four, or ten times as much useful work, that second “salary” could be a bargain.

Still, Uber offers a cautionary tale about how quickly usage can outrun a poorly thought-out AI spending plan. The company reportedly exhausted its entire 2026 AI coding tools budget in about four months. (Yahoo Finance)

So AI should be budgeted the way cloud infrastructure is, with a unit of measure attached: cost per resolved ticket, cost per completed analysis, cost per proposal ready to send. And the math should include the human time spent directing, checking, correcting, and rescuing the work. A cheap draft that needs two hours of repair may not be cheap. An expensive agent run that produces dependable work with little intervention may be a bargain. Ultimately, measure outcomes. Did you sell more, serve more people, reach more people, and achieve more of your company’s mission with AI in the room? And was the tradeoff on that spend worth it in the end?

Without that discipline, you end up on what I’ve called the Token Treadmill, where spending climbs and finished work doesn’t.

The company prices its service for results, not just hours

A company selling expertise has to settle the pricing question early. When AI makes production faster, what exactly is the customer buying: the time it takes to do the work, or the expertise and result they need?

A company born today has an advantage here because it has no hourly model to defend. It can define the offer, the quality standard, and the responsibility without starting from how many people will spend how many hours producing it. That’s a competitive threat to firms that bill by the hour.

I’ve written before about the Coupon Trap, where a firm knocks a percentage off the invoice because AI made the work faster and teaches the customer to expect a discount every time production gets more efficient. The born-today competitor, which uses AI throughout its operations, never has to have that conversation. It can say: here is what we will deliver, here is the standard we will meet, here is what we will take responsibility for, and here is the price. It doesn’t say the work will take X hours at Y bill rate. Those words never come out of its mouth.

Employees run frontier experiments inside each business unit

Each business function gets responsibility for testing what new AI capabilities change about its work. That means trying new models and agents on real work, comparing them with the current approach, and deciding what matters.

In my opinion, that experimentation belongs inside the function, not with IT. Sales needs people testing what AI changes about sales, finance needs people testing what it changes about finance, and HR needs people testing how it might change HR. IT should help with shared infrastructure, access, security, and evaluation tools. But whether a new capability changes how a proposal gets built or how an account gets analyzed is a business decision.

That doesn’t require a separate department inside every department. In a smaller company, it might be someone in each function with protected time and a clear mandate. And where the company can’t staff that capability, bringing in an outside group is perfectly reasonable, as long as the experiments stay grounded in the function’s work.

Like any good research team, this “lab team” should record failures as carefully as successes. Its reporting should be specific: this part of our operations can now run with less supervision; this approach failed on the cases that matter most; this cheaper model now meets our standard.

The company uses multiple models by default

I wouldn’t build this prototypical company around finding one model that does everything and then sticking with it for years, the way people stick with Workspace or Office 365 today. The better plan is to use multiple models, matching each to the work it does best at a cost that makes sense: one for difficult analysis, another for routine processing, another for a particular coding task.

In short, you need a reason for your model choices beyond “this is the subscription we bought.” That also means keeping the company’s instructions, context, examples, and evaluation cases in a structure it controls, so testing a different model doesn’t mean reconstructing the company’s working knowledge from scratch. It also makes it much easier to onboard a new AI platform from day one.

The company writes its AI policy on day one

The first AI policy gets written while the first workflows, job roles, and team structures are being designed, long before they’re implemented.

The policy would cover what agents can access, change, and send, when a person must approve an action, and who is responsible when something goes wrong. It would also cover what the organization tells customers about its AI use and how customers can reach a person when they have questions about it.

People can build tools, and someone owns what the team depends on

People should be encouraged to build small tools, artifacts, or apps for their own work. A marketing manager might make a lead-scoring tool. An operations lead might build a dashboard. Someone might create an application for five colleagues that would never have justified a conventional software project.

But this company would recognize that there is a real difference between “I built this for myself and my team” and “the company now relies on this to engage with customers.” That second category needs review, an owner, a maintenance plan, and someone capable of checking things the builder may not know to ask about.

So the company born today should make it easier for people to build, and make the move to shared infrastructure explicit. Someone has to own what the team depends on, and it can’t simply be whoever happened to build it on a Tuesday.

It hires people who can delegate and judge

Microsoft’s 2026 Work Trend Index, based on a survey of 20,000 AI users, describes the shift as people moving from doing the work to directing it, setting the quality bar, and owning the outcome. It calls the 16 percent of users who run multi-step workflows with agents and routinely redesign how they work “Frontier Professionals.” (Microsoft) I’d put the hiring requirement in plainer terms: can this person give work to someone, or something, else, and can they recognize when the result is almost right but not quite?

That’s the core argument of my book, The Art of Asking: Collaborating Effectively with AI. Good delegation involves more than making a request. You establish the context. You define the mission. You explain the quality standard. You specify the deliverable. And you give permission to challenge an assumption rather than quietly build on top of it.

That’s what I’d interview for. Give a candidate a realistic piece of work. Ask what they would delegate, what context they would provide, and what they would insist on checking. Then show them an imperfect result and ask what they would do next.

Being good at the work doesn’t automatically make someone good at handing it off. Wayne Gretzky, the greatest player in hockey history, had a losing record as a coach. And being comfortable with AI doesn’t mean someone can judge its output.

Which creates the hardest problem in this entire design.

People have born-on dates too

Someone starting their career today may encounter a very different set of expectations from the ones that shaped mine. Their first assignment probably won’t be to write a draft from a blank page, build a spreadsheet from scratch, or read through hundreds of customer comments one by one. It might be to direct an agent, inspect the result, and decide what deserves attention.

That could be a substantial advantage. It could also remove some of the practice through which earlier generations learned what to notice.

This is the part I think about hardest: the company I’ve described depends on people with judgment, while being designed to skip some of the work through which, historically at least, that judgment developed.

And it isn’t a problem we’ve solved. As I wrote in The Unwatched Hours, try walking up to someone and telling them they lack judgment. Some small part of their brain gets irritated or even mad, and most folks stop listening at that point. That’s what makes judgment so hard to teach, mentor, or grow, and in my estimation harder than any of the “soft skills” we’ve trained people on before. Whatever builds judgment in this generation can’t start and stop with telling people they don’t have it. That just builds resistance, not capability.

The good news is that AI can also be one of the best judgment-building coaches we’ve ever had, if it’s used deliberately. A junior analyst can ask an agent to argue the other side of their conclusion, critique a draft before their manager sees it, or explain why one approach works better than another. They can work through ten examples in an afternoon instead of ten over a year, and get feedback at the moment they need it instead of at the next review. Used that way, AI can shorten the apprenticeship.

So my answer would be to hire junior people deliberately, and design how they learn with AI as carefully as I design what the agents do. Some of their work should involve reviewing AI output, with a senior person reviewing their reviews. They should also get selected pieces of work to do themselves. Ask them to form a view before seeing the agent’s answer. Have them check the source material, defend a conclusion, and see what happened when the work reached a customer. The point is to give them an independent basis for saying, “This is wrong,” or, “This looks reasonable, but something important is missing.”

That takes manager time, and it may make a particular assignment slower. It’s an investment in the people who will eventually handle the work the company can’t safely delegate.

This is part of why I’ve moved toward oral defense for some activities in my classes, along with more personal reflection, whether through presentations, debates, or other formats. A single polished deliverable can’t tell me what someone understands. I want to understand why they made a choice, what evidence supports it, and what would cause them to change their mind. It’s the same bar I wrote about in Three Humans. At work, I would combine that explanation with observation and consequences. Can the employee spot the problem in a new case? Can they adjust when a client challenges the recommendation? Can they explain a mistake and do better next time?

In sum, a company born today needs people who can direct AI. It also needs a credible way to develop them, and AI can be part of that, too.

Freshest before

There’s at least one more problem that affects all of this: “born after AI” isn’t a permanent category.

A company founded in early 2023 was born in the chatbot era, designed around people asking questions in a chat window. A company founded this year is designed around agents carrying out defined work in the background. Both could call themselves AI-native, and they would still have very different assumptions about staffing, coordination, and supervision. Every AI-native company is built around the technology of the year it started, and that shapes its sense of what’s possible and what’s not.

And not everything old needs replacing. Some processes survive because they work, some controls exist because someone learned an expensive lesson, and some expertise becomes more valuable with experience. The question is whether the company can tell those apart from arrangements it keeps only because changing them would be uncomfortable.

I wouldn’t bet simply on the newest company. I would bet on the one willing to keep asking which assumptions still deserve to run the business, and the one that keeps its born-on date close to today, at least in attitude if not in reality.

If your born-on date was a while ago

Most of us don’t get to start over. We have customers to serve, commitments to honor, and people doing work that still needs to get done while we change it. The challenge is to redesign that work without stopping the business.

That’s what our AI Work Labs at Cascade Insights® are built for. We work with your team on its real work: deciding what to delegate, what context AI needs, where human judgment matters, and what should change around it.

You can’t change your company’s born-on date. But you can get through the redesign a lot faster than if you figure it out alone.

What caught my eye in the world of AI this week

Here are just a few of the things that caught by eye in the world of AI this past week.

Model Watch & New Releases

Agents & Tools at Work

Work, Skills & Adoption

Voice, Video & Embodied

Writing, Provenance & Disclosure

Home » Blog Posts » Born After AI: What a Company Founded Today Should Do Differently
Share this entry

Get in Touch

"*" indicates required fields

This field is for validation purposes and should be left unchanged.
Name*
Cascade Insights® will never share your information with third parties. View our privacy policy.