Why enterprises need AI
Much of enterprise work depends on language, unstructured information, and professional judgment that traditional software cannot economically encode. Foundation models are turning that work into a general, scalable software capability.
Jonathan
Founder
Why am I convinced that AI matters?
Because enterprise demand and technical capability have finally begun to meet.
Much of the work inside a company depends on understanding language, processing unstructured information, and applying professional judgment: reading resumes and contracts, interpreting customer intent, comparing alternatives, synthesizing complex material, and handling exceptions in context. These tasks have always mattered to efficiency, quality, and revenue. Traditional software has struggled to cover them economically with fixed rules, so people have continued to do most of the work.
Foundation models change what is implementable. They are not limited to one narrow task defined during training. Through natural language, they can interpret, extract, generate, reason, and produce structured output. As tool use, long context, multimodality, and coding improve, models can also connect to enterprise data and business systems, then continue through multi-step work based on feedback from the environment.
As a result, work that once required a person—or could not be done thoroughly because the unit cost was too high—is beginning to have a general, scalable software path. Companies can process a larger share of their information, apply professional methods to more cases, and reserve human attention for exceptions, high-risk decisions, and relationships.
That is the fundamental reason I am convinced about AI:
Foundation models are turning language understanding, knowledge processing, and parts of professional judgment into general software capabilities. They expand the range of problems software can address and reduce the marginal cost of cognitive work.
There are two steps in that claim, and both matter. Advances in models make these tasks technically feasible. Companies then use business knowledge, context, tools, harnesses, and evals to turn general capability into a controlled, reusable production system that produces results.
This does not mean any one implementation will remain correct. Models and APIs will keep improving. When reasoning, tool use, or context capabilities change, teams should re-evaluate the routing, prompt patches, tool strategies, and operating boundaries in their agent harnesses. The business application built on top must still prove user demand, effectiveness, and return on investment independently.
The durable opportunity is therefore not one model, agent architecture, or short-lived product. It is a more stable relationship: enterprises will continue to need information processing, professional judgment, and knowledge reuse; models will become more capable at those tasks; and evolving engineering systems will convert that capability into productivity.
Software is moving from executing rules to participating in cognitive work
Traditional software is best at deterministic tasks.
When fields are explicit, rules are stable, and the process can be enumerated, code, databases, and workflows produce reliable results. Calculating a price, checking inventory, enforcing an approval, and updating an order status do not need AI. Adding a model would usually make them less predictable.
But a large amount of enterprise work does not fit that structure:
- Reading resumes, contracts, reports, emails, and customer feedback
- Inferring the intent behind different expressions
- Comparing several options and explaining the tradeoffs
- Generating, synthesizing, and explaining material from context
- Deciding what to do when an exception appears
These tasks are not rule-free. Their rules are simply difficult to write down completely. An experienced recruiter deciding whether a candidate fits a role does more than match keywords. They consider industry background, career continuity, transferable skills, the stage of the role, and the employer’s preferences. Much of that judgment lives in experience rather than database fields.
Historically, software could manage the inputs, routing, and outcomes of this work, while people still performed the actual interpretation and judgment. AI changes that boundary: software can begin to participate in the cognitive process itself.
The model can interpret unstructured information and produce a structured judgment or recommendation. Deterministic systems can continue to own data, permissions, rules, and execution. People can remain responsible for goals, values, and high-risk decisions.
This is not about replacing all software with AI. It is an expansion of what software can do.
Enterprises need AI because cognitive capacity has always been scarce
Many enterprise problems do not come from ignorance about the right method. They come from not having enough people to apply that method to every task.
A senior recruiter knows how to analyze a role, but cannot inspect every resume in the talent database. A sales leader knows how to research an account, but the team cannot prepare every conversation to the same depth. A technical leader knows how to review architectural risk, but cannot join every design discussion and code change.
This creates several persistent constraints:
- Information is sampled or ignored because processing all of it costs too much.
- Professional methods depend on a small number of experienced people and are hard to reproduce consistently.
- Quality varies widely when different people handle the same kind of task.
- Personalized analysis is too expensive, so companies provide standardized results.
- Experts spend too much time organizing repetitive work instead of making high-value judgments.
The value of AI is not just saving a person a few minutes. It changes how cognitive capacity is supplied.
Information that could not be reviewed item by item can first be analyzed by AI, allowing people to focus on high-value and high-risk cases. Methods that once spread only through training and collaboration can gradually be encoded in prompts, rules, skills, tools, and evaluation criteria, then applied across more work.
That value appears in three forms:
- Greater coverage: bring information into the analysis process that was previously uneconomical to process.
- Lower cost of applying expertise: give more employees and customers access to baseline professional assistance.
- More expert attention for high-value work: shift people from repetitive organization toward judgment, communication, relationships, and accountability.
This is why AI should not be valued only in hours saved. It can also expand the range of services a company can provide, improve consistency, and make personalization affordable.
Tacit knowledge must become explicit before the organization can reuse it
One easily overlooked fact about enterprise AI is that a model does not know how the company actually works.
Important knowledge is often undocumented. It lives in expert experience, communication habits, historical cases, and judgments about exceptions. Employees absorb it through sustained collaboration. A general model cannot acquire it from nowhere.
One of the central jobs of enterprise AI is therefore to turn tacit knowledge into explicit assets the system can use:
- The goals, principles, and constraints of the current situation
- The operating procedure, judgment steps, and exception handling for a class of tasks
- The inputs, outputs, and permission boundaries of a business capability
- Strong examples, failures, and acceptance criteria
- Which steps may run automatically and which require human responsibility
Making knowledge explicit does not mean putting every lesson into one enormous prompt. Different knowledge belongs in different forms. Situation-specific goals may enter a prompt. Reusable methods may become skills. Executable capabilities need tool contracts. Deterministic rules and permissions should remain in code and the runtime. Quality standards belong in evals.
Only then is knowledge not merely recorded, but discoverable, loadable, executable, verifiable, and continuously correctable.
This is an important difference between enterprise AI and an ordinary model call. Model capability is becoming widely available. What remains unique to a company is its business knowledge, workflows, feedback data, and quality standards. Those assets should not be thrown indiscriminately into context. They need to become prompts and skills, retrievable knowledge, tool contracts, deterministic rules, and eval datasets that the runtime assembles for the task at hand.
In an agent system, this production environment around the model can be described as the harness. It does more than wrap a tool call. It manages context selection and compaction, tool execution, task state, permissions and sandboxes, human-in-the-loop controls, retries and recovery, observability, and evaluation feedback. Turning business knowledge into assets answers what the system works from. Harness engineering answers how the model can keep working safely and controllably in the real environment. Together, they determine whether general model capability becomes enterprise capability.
AI is also changing how software itself is produced
Enterprises need AI not only because it can enter products and business workflows, but also because it is changing how software gets built.
AI coding has already reduced the cost of implementation, experimentation, and iteration. A prototype that once took days may now be tested in hours. Developers can understand unfamiliar code, generate tests, compare approaches, and locate problems faster. Product and business teams can participate more directly in early validation.
Lower implementation cost does not make technical work unimportant. Scarcity is moving upstream and toward the system level:
- Choosing a problem worth solving
- Understanding real business constraints
- Deciding whether to use rules, a workflow, or model capability
- Providing agents with effective context, tools, and operating boundaries
- Building evaluation and feedback loops
- Owning the outcome and its risks
AI coding lowers the cost of producing features. It also moves the center of technical work toward three questions: why should we build this, how should the system be designed, and how will we prove it works?
I am optimistic about AI not only because it creates new product capabilities, but because it changes software production, organizational knowledge, and team collaboration at the same time.
Every enterprise AI use case must answer five questions
Believing in the long-term direction of AI does not mean every use case should adopt it.
AI is probabilistic. It can generate incorrect content, misunderstand intent, or make inconsistent judgments. The closer it gets to business execution and high-risk decisions, the less a successful demo can tell us about its value.
Every proposed use case should answer at least five questions.
1. Value
Does the task contain expensive cognitive work that fixed rules cannot cover well? If existing code and workflows already solve it reliably and cheaply, AI is usually unnecessary.
2. Capability mix
What must the model actually do: interpret, extract, judge, generate, or combine enterprise data with external tools? A system should not become an agent merely because one step uses a model.
3. Autonomy
Which steps must remain under deterministic code or predefined workflows? Which decisions genuinely require the model to respond dynamically to context? A sound principle is minimum necessary autonomy: give the system only the dynamic decision-making freedom required to complete the goal.
4. Control
Can errors be detected, limited, handed to a person, or safely degraded? When money, permissions, customer rights, or irreversible actions are involved, human responsibility and system boundaries must be explicit.
5. Evidence
Compared with people, rules, and the existing system, does AI actually improve quality, efficiency, coverage, or business outcomes? Technical metrics must eventually connect to task success, human correction, adoption, cost, or conversion—not stop at “the model’s answer looks good.”
These five questions turn “should we use AI?” from a trend judgment into a business judgment.
A conviction creates enterprise value only after it reaches production
Understanding why AI matters is only the beginning. If a team cannot answer where it belongs in the business, how it will reach production, and how effectiveness will be proved, the direction will not become enterprise value.
The path from conviction to results has several links:
Long-term changes in AI capability
→ cognitive tasks worth solving inside the enterprise
→ a business baseline based on people, rules, and existing systems
→ a combination of model reasoning, retrieval, tools, and orchestration
→ business knowledge as assets and harness engineering
→ real users and business workflows
→ quality, efficiency, coverage, and business outcomes
Each link has its own failure mode:
- The wrong use case: the team uses AI to solve a problem that does not matter.
- Business knowledge remains tacit: the model can produce only generic answers without operational depth.
- System boundaries are unclear: probabilistic judgment flows directly into high-risk actions.
- There is no evaluation system: the team cannot distinguish a lucky demo from repeatable performance.
- The product never enters a real workflow: even a capable model fails to create adoption or business outcomes.
Enterprises therefore need more than developers who can call a model. They need people who can connect direction, business reality, and production. That work has four parts:
- Judge the direction and boundaries: understand what AI can change and what should not be delegated to it.
- Model the use case and its knowledge: express business goals, expert practice, data, risk, and acceptance criteria clearly.
- Design and implement the production system: combine models, retrieval, tools, workflows, or agents, then use a harness to govern context, execution, state, permissions, human intervention, recovery, observability, and evaluation feedback.
- Own the outcome: connect technical performance to quality, efficiency, coverage, adoption, and business results, then evolve the system from feedback.
AI will keep lowering implementation barriers, but it will not complete this chain automatically. Bridging these layers is the core value of technical leaders, architects, and AI builders in the AI era.
Application teams should not bet on models; they should convert capability into value
I am convinced about AI because foundation models continue to cross the usability threshold for real tasks. Software can address more cognitive work, and the cost of reproducing and applying expertise is falling. That underlying change has already made new products and ways of working possible.
For an enterprise application team, foundation models are supplied primarily by model providers. The team’s job is not to predict which provider will win, nor to train the foundation model itself. It is to understand the current capability boundary and answer two questions closer to the business: Which tasks have models become good enough to handle, and how can that capability be adapted into verifiable enterprise value?
That requires several kinds of judgment:
- Task fit: should the model interpret, extract, generate, judge, or make dynamic decisions? Which parts should remain with rules, workflows, or people?
- Model selection: compare quality, stability, latency, cost, data security, and provider constraints on representative tasks rather than relying only on public benchmarks.
- System adaptation: isolate provider differences through a model abstraction and harness, then build around context, tools, state, permissions, human intervention, and evals.
- Continuous evolution: rerun the evaluation set after model upgrades and determine which prompt patches, routing rules, and custom mechanisms can be simplified or removed.
- Value validation: connect model performance to task success, human correction, processing cost, adoption, and business outcomes.
The model is an improving foundation, not the final value of an enterprise application. The enterprise remains responsible for use-case selection, capability adaptation, production engineering, and validation. Even a strong model will not create growth automatically if the task is unimportant, business knowledge is missing, system boundaries are unclear, or the product never enters a real workflow.
My conviction rests on several durable changes:
- Software is gaining the ability to interpret and process unstructured work.
- The cost of reproducing and applying professional cognition is falling.
- Tacit enterprise knowledge can gradually become reusable software assets.
- AI coding is lowering the cost of software production and validation.
- Business judgment, system boundaries, context, evaluation, and governance are becoming more important.
But every specific use case must still be judged by results. If an AI system provides no stable improvement over the rule-based or human baseline, if its error cost cannot be controlled, if the data and evaluation conditions are inadequate, or if users do not keep using it, investment should not expand.
Teams should also revisit old designs as models improve. Problems that once required elaborate prompts, routing rules, or custom patches may now be covered by native model capability. Long-term commitment to AI does not mean accumulating complexity forever. It also means deleting mechanisms that are no longer necessary.
A reliable long-term view is not the belief that every problem will become an agent. It is the recognition that model capability is changing the structure of software and knowledge work, combined with the discipline to evaluate every use case with evidence, define AI’s boundaries, and stop, narrow, or return to rules and people when results are insufficient.
Why do enterprises need AI? The answer can be reduced to one sentence:
Under verifiable and controllable conditions, turn cognitive work that was difficult to scale into reusable software capability.
That is more durable than any particular model, framework, or product.
Related reading
- AI-native companies reorganize context — how a general model receives the business facts, current state, and judgment required for the task at hand.
- Existing company data is the first AI-native asset — how enterprise data becomes context the model can actually use.
- Why AI agents need a harness, not just a better model — what the system around the model must provide once AI begins to act.
- Evaluation — how real tasks, outcomes, traces, and graders turn failures into a feedback loop.