ExpertsFMBox's Aaron Levie: On Reinventing Yourself in the AI Age and Enterprise Diffusion
Training Data · September 15, 2026
5 Selected Lessons:
framework · 2 reasoning_pattern · 1 heuristic · 1 interpretation · 1
Box's domain-tuned agent harness vs. raw API
Source
Training Data — Box's Aaron Levie: On Reinventing Yourself in the AI Age and Enterprise Diffusion (September 15, 2026) · at 24:08 ▸
When this applies
when deciding whether to wrap a general-purpose AI capability with domain-specific tooling rather than exposing the raw API to end users
The takeaway
Wrapping a general capability in a harness built from deep, accumulated domain knowledge of user behavior outperforms handing users the raw general tool directly.
Why it works
Deep knowledge of how users actually search, which document they pick, and the system's permission/file structure lets a harness pre-filter, re-rank, and chunk data in ways a generic API call cannot, producing measurably better accuracy and latency.
One level up
Durable product advantage in an AI-commoditized world comes from proprietary behavioral/domain data about how your specific users actually operate, not from the model itself.
Where it stops holding
This stops working when the domain knowledge used to build the harness becomes generally available to model providers (e.g., if Box shares its system-understanding data with labs and they bake it into the base model).
Detail
procedure:
- Accumulate deep domain knowledge of user search/selection behavior
- Build harness with access to search system, file system, text/chunk extraction, on-the-fly embeddings
- Agent performs multiple searches, re-ranks results, pulls relevant info, sometimes reads full document
- Benchmark harness against raw API calls to frontier models
benchmarks: {"comparison":"meaningfully better results on accuracy and latency vs. giving raw API access"}
rationale: We kind of know exactly how to tune it for our workflows.
In their words
Then we compare that against like, well, what if we just gave, you know, Claude our API or gave OpenAI our API and we see like meaningfully better results on accuracy and latency? Because again, we kind of know exactly how to tune it for our workflows.
Internal token-leaderboard inspection for spreading AI best practices
Source
Training Data — Box's Aaron Levie: On Reinventing Yourself in the AI Age and Enterprise Diffusion (September 15, 2026) · at 57:46 ▸
When this applies
when rolling out a new tool/practice across an organization and wanting to convert isolated pockets of excellence into company-wide capability
The takeaway
Use raw usage metrics not as a KPI to reward directly, but as a discovery mechanism to find and then disseminate genuinely superior practices across the organization.
Why it works
Ranking employees by raw usage (tokens) surfaces outliers; inspecting those outliers distinguishes wasted usage from genuinely superior workflows, which can then be captured and taught via live demos to the rest of the team.
One level up
Spread organizational capability by finding and replicating your own internal best performers, not just by issuing top-down mandates or external training.
Where it stops holding
This stops working when high usage doesn't correlate with quality or effectiveness at all, making the leaderboard a noisy signal, or when the resulting live-demo trainings aren't adopted downstream.
Detail
procedure:
- Track a leaderboard of employees by AI token usage (not as a reward system, but a diagnostic)
- Inspect top usage to determine if it reflects good practice or wasted tokens
- If it reflects a genuinely better workflow, pull the team into a room for a live demo
- Propagate the learned practice to the rest of the organization
benchmarks: {"example":"probably one of our top three AI users at box is wasting half their tokens; two others are doing something worth an internal training session"}
rationale: How do we show everybody what it looks like to work in this way?
In their words
So, you know, we had this thing like two weeks ago where I was like, can you just get everybody in a room, you know, on this particular team and just like show them how this one person is using AI?
Infrastructure-vs-application historical analogy
Source
Training Data — Box's Aaron Levie: On Reinventing Yourself in the AI Age and Enterprise Diffusion (September 15, 2026) · at 5:08 ▸
When this applies
when a new foundational infrastructure layer emerges and you're trying to predict whether a parallel application ecosystem will also create large value
The takeaway
Looking at history of the same category (infra then apps) is a reliable prior for predicting the next cycle, even when the specifics seem implausible in the moment.
Why it works
People systematically underestimate how much value will be created above infrastructure because they can't yet imagine the specific products that will need to exist once the infra lowers the cost of some capability.
One level up
Analogical reasoning from a prior technology cycle is a legitimate forecasting tool, with appropriate humility about specifics.
Where it stops holding
This stops working when the new technology genuinely collapses the need for an application layer (e.g., if models become so capable and so integrated that no bridging software is needed at all).
Detail
approach: Ask: in the last analogous technology cycle, did the infra layer capture all the value, or did unforeseen application companies also capture massive value on top of it?
signals:
- if you'd extrapolated from early infra you'd have missed the application layer that later emerged
- trillions of dollars of market cap created above the infra layer that infra builders didn't anticipate
rationale: If you looked at early GCP/AWS roadmaps you would not have predicted Snowflake or Databricks — yet they created huge value, suggesting the same dynamic will repeat with intelligence/models and AI application companies.
In their words
If you were to go back, you know, 10 years ago and you were to look at what was happening in the data space and you looked at what GCP, early kind of versions of GCP was building or AWS is building, I guarantee you would not have predicted Snowflake or Databricks existing.
Code is accepted AI output, content is suspect — because of a trust signal, not a quality signal
Source
Training Data — Box's Aaron Levie: On Reinventing Yourself in the AI Age and Enterprise Diffusion (September 15, 2026) · at 18:44 ▸ · at 21:58 ▸
When this applies
when introducing AI-generated output into any domain and predicting whether users will embrace or resist it
The takeaway
AI-generated output is accepted fastest in domains where output is evaluated purely on functional correctness, and resisted longest in domains where output is a proxy for a person's judgment or trustworthiness.
Why it works
Code is a pure utility judged by whether it works; prose/content carries a social signal about the author's judgment, knowledge, and trustworthiness, so AI authorship undermines that signal and triggers distrust even if the content itself is fine.
One level up
The social function of an artifact (what it signals about its creator), not just its technical quality, determines the speed of acceptance of automation.
Where it stops holding
This stops working when audiences stop treating the content as a signal of the author's personal competence (e.g., once a specific trusted source — like a known expert's byline — removes the need to verify authorship, as Levie notes with the Druckenmiller piece).
Detail
rule: Expect fast acceptance of AI automation wherever the artifact is judged purely by function (code); expect lingering 'slop' stigma wherever the artifact stands in for a person's judgment or expertise (decks, essays).
threshold: Acceptance flips once the audience already trusts the named author/source enough that authorship-verification no longer matters (e.g., trusting 'it's Stan' over worrying about AI involvement).
rationale: When you get a presentation from somebody, there's an association: are you trying to decide if you can trust that person to execute on or understand that topic — AI authorship clouds that judgment.
In their words
So there's probably like more symbolism to this actually topic than than than just like the the slop element but like actually like diffusion of AI in general is sort of almost ties to this code.
AI leverage advantage for new founders vs. structural discount for compliance-bound incumbents
Source
Training Data — Box's Aaron Levie: On Reinventing Yourself in the AI Age and Enterprise Diffusion (September 15, 2026) · at 1:01:51 ▸
When this applies
when comparing how much a new entrant versus an established, regulation-bound incumbent can benefit from a new leverage-multiplying technology
The takeaway
A new leverage technology benefits unconstrained new entrants disproportionately more than incumbents who carry trust/compliance/legacy obligations that limit how fully they can adopt the same leverage.
Why it works
New founders can design their whole company around AI-native workflows from day one with no legacy trust/compliance obligations, letting a 2-person team do what previously took 40 people; incumbents handling sensitive data must preserve certain human checkpoints (e.g., code review) for customer trust/compliance reasons, permanently capping their achievable productivity multiple.
One level up
Structural obligations accumulated by maturity and trust (compliance, security guarantees) are a permanent tax on an incumbent's ability to fully exploit a new general-purpose leverage technology.
Where it stops holding
This stops working in domains where incumbents carry no special trust/compliance obligations, or where the compliance requirements can themselves be automated without loss of trust.
Detail
situation: Levie saw a product demo by a two-person startup that he judged would have been a 40-person project five years earlier (or when Box was starting).
decision: Box, as an incumbent handling sensitive customer data, chooses not to remove certain human checkpoints like code review, despite the productivity cost, because customers require that trust.
outcome: New founders get outsized leverage from AI with no such constraint; Box accepts 'a little bit of a discount on the productivity' permanently, due to its position in the stack.
lesson: When evaluating how much an incumbent versus a new entrant can benefit from a leverage technology, account for the incumbent's trust/compliance obligations as a structural, non-removable tax on adoption.
In their words
We're not like, we're very uncomfortable at the idea of like sort of, you know, removing the code review and like some of these things that get talked about because our customers can't possibly entrust us with their data security and compliance if we don't take that seriously. So we're always going to have a little bit of a discount on the productivity because of where we are in the stack, what we do as a business.