The implementation problem has changed
Claude Does Not Need to Learn Your Business
You are not starting with empty software. You are starting with a prediction machine that has already learned the business world.
The wrong assumption
The prevailing story begins in the wrong place.
Claude is presented as a powerful but generic capability. It can write, reason, summarize, and analyze, but it does not understand your business. Therefore, the story goes, you must teach it how your company works. You must explain your industry, document every process, load every procedure, and carefully mold this general-purpose intelligence into something useful.
That is not what is happening.
Claude already knows how businesses work. It already knows enterprise resource planning, customer relationship management, supply chain management, product lifecycle management, demand planning, inventory management, purchasing, accounts receivable, and proposal development. It knows the standard practices, the common failures, the regulatory patterns, the industry vocabulary, and many of the exceptions that experienced operators learn over decades.
You are not starting with an empty piece of software and teaching it your business.
You are starting with a prediction machine that has already learned the business world. Your job is to connect it to the present facts of one particular entity and constrain its behavior accordingly.
The inherited model
The Old Meaning of a Solution
For most of my career, a technology solution had three parts: hardware, software, and services.
A company would usually begin with a management consultant. McKinsey, Bain, Accenture, or another advisory firm might start at the strategic level—with culture, competitive position, operating structure, and business requirements—but eventually the engagement narrowed to a technology decision.
The first major choice was software. If the company needed enterprise resource planning, it might evaluate SAP, Oracle, PeopleSoft, and several others. If it needed customer relationship management, it would select a CRM. Supply chain management and product lifecycle management had their own categories and vendors. Each application represented a defined collection of features and functions.
Once the software was selected, the company chose the hardware and technical infrastructure on which it would run. An IBM mainframe brought one family of operating systems and databases. Sun Microsystems brought another. The software decision helped determine the hardware decision.
Then came services.
The systems integrator installed the application, modified it, migrated the data, normalized the records, built the interfaces, configured the modules, and trained the employees. The software knew how to perform a category of work, but it did not know how this particular company performed that work. A large part of implementation involved closing that gap.
This is the mental model people are carrying into AI. They see Claude as a new piece of generic software that must be configured, customized, and taught until it finally understands the business.
But Claude is not an empty application.
No modules to install
The Capability Is Already There
SAP had to be explicitly programmed to create a purchase order. A CRM had to be explicitly programmed to manage an opportunity. A demand-planning application had to be explicitly programmed with forecasting and constraint logic.
Claude does not wait for those modules to be installed.
The features and functions are present as learned capability that can be generated when required.
Ask it to create a purchase order and it knows what a purchase order is, why it exists, what information it requires, how it relates to a requisition, and what risks must be controlled. Ask it to develop a production plan around capacity constraints and it knows the formulations, tradeoffs, and standard planning practices. Ask it to build a CRM and it understands accounts, contacts, opportunities, stages, follow-ups, conversion, retention, and pipeline management.
The sharper claim
The features and functions do not exist as fixed screens and modules. They exist in the latent geometry of the pretrained transformer.
This is why the phrase “Claude can become your ERP” is still too cautious.
Claude already contains the functional intelligence of an ERP. It already contains the functional intelligence of a CRM, an SCM platform, and a PLM platform. What it does not yet possess is authorized access to your current orders, customers, inventory, suppliers, contracts, policies, and transactions.
It knows the business function. It does not automatically know the current state of your entity.
That is the new integration problem.
The new implementation
You Are Not Training It. You Are Constraining It.
Training, integration, and constraint are different jobs. Treating them as one is why so many enterprise AI programs begin with months of documentation and still end without an operating system.
- Training
- creates general capability.
- Integration
- supplies current state.
- Constraint
- defines permitted behavior.
“Where are the open RFPs?”
Suppose you tell Claude to respond to every open request for proposal.
Claude does not need a course on RFP response. It already knows how to identify requirements, construct a compliance matrix, develop win themes, assign responsibilities, gather evidence, write the response, inspect it for omissions, and prepare the final submission.
Its first useful question is not, “How do you respond to RFPs?”
From there, it needs access to the company’s products, pricing, case studies, contractual boundaries, previous proposals, delivery capacity, and approval authority. Those are not lessons about how business works. They are facts about this business at this moment.
The frontier model providers have already performed the training. The enterprise does not need to repeat it. The enterprise needs to provide access and establish constraints.
Open the entity file
Tell Claude What Is Uniquely True Here
A landscaping company does not need to teach Claude landscaping. A veterinary practice does not need to teach it veterinary operations. A property manager does not need to teach it property management. A restaurant does not need to teach it hospitality. Each entity needs to narrow an enormous field of competent possibilities to the correct behavior for this entity.
01Local facts and exceptions
02Sources of truth
03Commercial boundaries
04Approval authority
A working demonstration
The Restaurant Test
Restaurant phone receptionists make this easy to see.
The phone agents I operate have handled more than 96,000 conversations since the beginning of the year. I have never trained one of them in how to talk to a restaurant customer.
I did not teach them what happy hour means. I did not teach them how to answer questions about gluten, children’s menus, reservations, parking, accessibility, private events, daily specials, or closing times. That capability was already present.
In its simplest form, the entire instruction can be one sentence: “You are the phone receptionist for this restaurant.” The agent will answer the telephone and conduct a recognizable restaurant conversation immediately.
What turns that recognizable conversation into this restaurant’s receptionist is access to this restaurant’s menu, hours, reservation policy, event spaces, accessibility details, parking instructions, and escalation rules.
The difference between a plausible answer and a reliable answer is not more knowledge about restaurants. It is connection to the restaurant’s present state.
The necessary boundary
Capability Is Not Reliability
This does not mean an enterprise can simply point Claude at every database and turn it loose. General competence does not eliminate the need for architecture. It changes what the architecture must do.
The system must retrieve current facts, identify the authoritative record, preserve provenance, enforce permissions, surface uncertainty, route exceptions, and leave an audit trail. It must know when to act, when to ask, and when to stop.
Those requirements are not evidence that Claude failed to learn the business. They are evidence that knowledge and authority are different things.
The old stack installed capability and then customized it. The new stack begins with capability and then binds it to reality.