Bottom-up adoption spreads from many individual points. Top-down design sets what must hold across all of them. Most companies are doing both at once.
The AI-Native Company · Part 1 of 5
Enterprise AI adoption has become a decision made at the top, for everyone at once. In April 2026, Reuters reported that Microsoft was rolling out Copilot to roughly 743,000 Accenture employees, a rollout its leadership framed as freeing teams for higher-value work. The ambition is understandable: give people better tools, improve their work and let the gains spread. What I still want to know is how those individual improvements change the way the company operates.
I can give every salesperson an assistant and still have no reliable forecast. Better preparation and cleaner meeting notes will not resolve conflicting definitions of a qualified opportunity. Bottom-up AI starts with what helps the individual. Top-down AI starts with what must remain true across the business: the evidence required to advance a deal, the approval needed for a discount, the source behind a client-facing claim. I call these "company invariants". They can change through a business decision, but an employee or agent should not quietly redefine them while doing the work.
There is evidence that assistance produces measurable value. In their study of 5,172 customer-support agents, Erik Brynjolfsson, Danielle Li and Lindsey Raymond found a 15% average increase in issues resolved per hour. Results varied: less experienced workers benefited more, while the most experienced and highest-skilled workers saw small speed gains and small quality declines. That is a finding about one operational setting, not a forecast for every department. If a business assumes uniform gains, it can invest in the wrong tasks, weaken expert performance and book capacity savings that never become better service or lower costs.
In practice the choice comes down to three shapes. Give people assistants where judgment and context dominate. Build standardized workflows where recurring work has clear acceptance criteria. Combine the two where people need a flexible way to request a reliable outcome. An adaptive agent can sit within that design when the necessary steps vary. These choices concern how work gets done; autonomy concerns the authority the system receives. A fixed workflow can run unattended, and an adaptive agent can require approval before acting.
The assistant approach works well for preparing a negotiation, exploring a market or challenging a proposal. The person knows what matters, can reject a weak answer and can change direction without redesigning a process. Adoption can begin with very little organizational overhead. The limitation is that the person still supplies context, checks the result and carries it into the next system. A good method may remain in one person’s conversations. That can be entirely acceptable for distinctive work; it becomes expensive when fifty people keep assembling the same deliverable independently.
A standardized workflow suits work such as recurring client reporting, account onboarding or routine service requests. The organization specifies required inputs, approved data sources, decision rules, permissions and an owner for exceptions. A missing reporting period should stop a calculation or trigger clarification. It should not invite a plausible guess. This makes quality easier to inspect across teams, but building it exposes disagreements that people previously worked around. The investment only makes sense when the outcome recurs often enough, matters enough and can be evaluated.
The hybrid approach lets someone ask an assistant to prepare a client report while an approved workflow handles retrieval, calculation, document assembly and review. The conversation remains flexible; the recurring execution follows a shared method. People do not need to memorize workflow names. They do need to understand when their request authorizes a draft, a record change or an external communication. Routing is itself fallible, so ambiguous requests need clarification. The advantage comes from combining convenient access with reliable execution, provided the extra routing and review effort remains proportionate.
The strongest objection to top-down design is that management can standardize the wrong thing. A rule requiring every CRM field to be populated can encourage invented information. A response-time target can reward fast, useless replies. Company invariants should express meaningful constraints and outcome requirements, with an explicit way to challenge them. Meanwhile, bottom-up experimentation provides evidence about what the work actually requires. If a process repeatedly generates the same exception, I would examine the rule before asking engineering to eliminate the exception.
A CRO, COO or practice leader can test all of this on one consequential handoff. Take a proposal becoming a delivery commitment. Identify what the receiving team needs to accept the work, which decisions require judgment and which checks should always happen. Then compare the current method with the proposed design on representative cases, including awkward ones. Measure time through acceptance, review effort, rework and downstream corrections. Decide who will use the recovered capacity and how. A proposal that takes half as long to draft but creates more delivery disputes has failed the business test.
What this buys is a steadier operation with real freedom inside it. Assistants can improve the quality of individual thinking; shared workflows can reduce avoidable variation and repeated coordination. Neither automatically creates margin. The financial gain appears when the business uses the improvement to deliver more accepted work, reduce actual expenditure or improve customer outcomes. I would track those changes at the process level before aggregating them into a company-wide productivity claim.
In the next issue, I will examine the hybrid model more closely: how an assistant can become the front door to company workflows, what the employee needs to see and where the organization must retain control. The design problem is how to make reliable execution easy to request without leaving its authority ambiguous.
Florian Boymond is the founder and CEO of Stackmint AI, focused on turning enterprise expertise into dependable AI operations.
The AI-Native Company series
- Part 2: The assistant as the front door to company workflows
- Part 3: Your next AI workflow may already exist in someone's personal account
Originally published on LinkedIn on 2026-09-10.