AI Should Learn the Business, Not the Other Way Around

Artificial intelligence is getting very good at a lot of things.

It can read documents, summarize meetings, draft emails, search for information, build reports, and answer complicated questions. The products being built by the major AI companies are genuinely impressive.

But they have a hard limit.

They do not know your business.

They do not know which spreadsheet your team trusts, which folder contains the final version, or why one manager approves a request before it moves to another department. They do not know that two employees can use different words for the same task. They do not know which rules are written down and which ones exist because someone learned a painful lesson five years ago.

The AI is general. Your business is specific.

That gap is becoming one of the central problems in business AI.

This argument begins with an important human-first foundation.

Tiankai Feng has spent years making the case that data and AI strategy cannot be separated from the people expected to use them. In Humanizing Data Strategy, he organizes the human side of data around five ideas: competence, collaboration, communication, creativity, and conscience. He later carried that work directly into Humanizing AI Strategy, which places human mindsets, skills, and behavior at the center of AI strategy.

The argument here builds on that foundation and focuses on a specific design problem. How can a powerful, general AI system fit the particular people, roles, workflows, and systems of one business?

The answer is not simply more training for employees. It is an organization-specific translation layer.

That layer has to do more than connect software. It has to keep three perspectives coherent: what the individual intends, what the organization requires, and what the AI is doing. That is the practical problem of cognitive alignment.

The Employee Becomes the Missing System

Many companies are trying to solve this problem by teaching employees how to use AI.

Employees learn how to write better prompts. They copy information from one system into another. They explain the same background every time they begin a new conversation. They tell the AI which format to use, which details matter, and what it misunderstood.

Then they check the answer, fix the structure, move the result into the correct system, and tell the next person what happened.

The employee becomes the memory, the translator, the integration, and the quality-control process.

This can make AI look useful in a demonstration but frustrating in daily work. The demonstration starts with everything prepared. The employee starts with information spread across email, documents, databases, conversations, and several different software platforms.

The AI may be able to perform the task. The employee still has to assemble the world around it.

When employees must constantly explain the business to the AI, the business has not fully implemented AI. It has distributed the implementation work across its employees.

The Training Trap

Training matters. People should understand what an AI system can do, where it can fail, and what information should not be placed into it. They should know how to review its work instead of treating every answer as fact.

But training is often asked to solve the wrong problem.

If employees must memorize special prompts, restate the same background, remember which connector to call, and manually repair the output every time, the problem is not a lack of training. The system is poorly fitted to the work.

Prompt libraries can help with repeated tasks. They can give people a useful starting point. They cannot carry the whole organization inside them. A prompt does not automatically know who is asking, what authority that person has, which process applies, what happened earlier, or which exception just changed the normal path.

The better goal is not to train every employee to operate a general AI perfectly. It is to design the AI environment so employees can use it naturally and safely.

The organization should absorb more of the complexity than the employee does.

Buying Access Is Not the Same as Building Fit

This is not a failure by the companies building general AI products.

Their tools are designed to help millions of people. A general product cannot arrive knowing how every company works. It cannot already understand every role, approval process, filing system, client relationship, or internal rule.

Connecting the AI to more systems helps, but access alone does not solve the problem.

An integration may let the AI reach a document library, email account, customer database, or project system. It does not automatically tell the AI which source controls, which record is current, what the employee is allowed to change, or what should happen next.

A connector gives AI access to the business. It does not teach AI how the business works.

That requires another layer.

There are really three separate problems:

1. Access: Can the AI reach the information or system?
2. Context: Does it understand what that information means inside this organization?
3. Execution: Does it know what should happen next, what it is allowed to do, and where a person must remain involved?

Many integrations solve part of the first problem. The harder work lives in the second and third.

Suppose an AI can search email, a document library, a customer database, and a project system. That sounds powerful, and it is. But a request such as “give me the latest status” can still fail in several ways.

The newest document may not be the approved document. An email may contain an important decision that was never copied into the project system. Two records may refer to the same customer under different names. A note may be visible to one role but restricted from another. The correct answer may require a manager to resolve a conflict before anything can move forward.

The integration retrieves pieces. The workflow determines how those pieces become trustworthy work.

The Translation Layer

A translation layer sits between a general AI product and the organization using it. In this article, that term means the connected architecture that supplies organizational context, directs work, and enforces boundaries around the AI.

Its job is to turn a normal human request into the right action inside that specific business.

Imagine an employee asks, “Can you get this ready for review?”

Those words are simple. The work behind them may not be.

What is “this”? Who needs to review it? Which files are required? Where are they stored? What format should be used? Does anything need to be checked first? Can the employee send it directly, or does a manager need to approve it? Where should the finished version be saved?

An experienced coworker may understand the request immediately because that person knows the role, the team, the history, and the situation. A general AI system does not have that shared understanding unless it is intentionally built around it.

The translation layer supplies that missing context. It connects the request to the company’s real operating structure, including:

• The responsibilities of the requesting person and role
• Which systems contain the right information
• Which source should be trusted when records disagree
• What permissions and limits apply
• What steps normally happen, and in what order
• When another person needs to review or approve the work
• How common exceptions should be handled
• What the finished result should look like
• Where the result should go next

This is more than saving a few good prompts. It is a working model of how the organization gets things done.

That model does not need to know everything about everyone. It needs the right context for the task.

For a simple request, the system may only need to know the employee’s role, the current project, the approved source, and the required output. A more serious request may also require permission checks, a sequence of approvals, a review of earlier decisions, and a record of what the AI did.

Good architecture brings in the context that matters without burying the person under all of it.

That context should come from explicit configuration, governed systems, and information the user can review or correct. The system should not quietly invent organizational knowledge or guess its way into authority.

Alignment Has to Work in Both Directions

Feng’s work also distinguishes organizational value from personal value. Cognitive alignment extends that distinction into the operating relationship among the individual, the organization, and the AI.

Customization is often described as teaching the AI about the user. That is only one part of the relationship.

People need to understand what the AI can do, where it can fail, how to correct it, and when not to rely on it. The AI needs enough context to understand the person’s intent, expertise, responsibilities, working patterns, and authority. It also needs to understand the organization’s shared knowledge, policies, objectives, permissions, handoffs, and exceptions. At the same time, the organization has to learn how work changes when people begin relying on, correcting, challenging, and delegating to AI systems.

This creates four connected movements:

1. People learn the AI. They develop a practical understanding of its abilities, limits, and appropriate uses.
2. The AI learns the person. It receives the context needed to support that person without pretending to know more than it does.
3. The AI learns the organization. It operates within shared rules, knowledge, responsibilities, and goals.
4. The organization learns to work with the AI. Leaders and employees adjust processes, expectations, oversight, and decision-making as the technology becomes part of the work.

These participants cannot be collapsed into one generic idea of “business context.” The individual and the organization are related, but they are not identical.

An employee may want the fastest path while the organization requires an approval. A specialist may have a valid reason to depart from the normal process, while the system still needs to distinguish informed judgment from an unauthorized exception. A company standard may improve consistency in ordinary cases but produce the wrong result in an unusual one.

An AI aligned only with the individual may become helpful but unsafe. An AI aligned only with the organization may become rigid and suppress the judgment of the people closest to the work. The system cannot simply maximize agreement with either side. It has to recognize when their contexts support each other, when they conflict, and when the conflict requires another person to decide.

That balance will also change. People develop new working habits. Roles shift. Policies change. Exceptions reveal weaknesses in the normal process. The AI environment must be able to learn from those changes without quietly rewriting its own authority.

This is where behavioral planning and behavioral conditioning enter the architecture. Behavioral planning defines how the system should act across normal work, uncertainty, conflict, and escalation. Behavioral conditioning reinforces that behavior through governed instructions, examples, role definitions, workflow rules, permissions, feedback, corrections, and repeated use. This does not necessarily require retraining the underlying AI model. Much of the conditioning can happen through the architecture around it.

In this context, conditioning does not mean manipulating employees or pretending the AI has a human mind. It means deliberately shaping the working relationship among people, the organization, and the AI. Cognitive alignment describes the relationship that must remain coherent. Behavioral planning and conditioning are how the architecture maintains that relationship over time.

What This Looks Like in Practice

Imagine a project manager asks, “Can you prepare the weekly client update?”

In a general AI tool, that request is incomplete. The employee may need to gather meeting notes, project changes, open risks, completed work, budget information, and the last update. The employee may also need to explain the client’s preferred format and remove internal details that should not be shared.

In an organization-specific environment, the same request could start a known workflow.

When correctly configured and authorized, the system recognizes the employee and the project being discussed. It knows where approved project information lives. It gathers the relevant changes since the last update. It separates internal notes from client-facing information. It uses the organization’s standard format. It flags missing or conflicting details. It produces a draft for the project manager to review. After approval, it saves the final version in the proper location and records that the update was completed.

The AI did not become smarter in a general sense. The environment around it became more informed.

This distinction matters. Businesses do not need an AI that knows everything. They need an AI that can find and apply the right organizational knowledge at the right moment, within the right boundaries.

Humanizing AI Does Not Mean Giving It a Personality

When people talk about humanizing AI, they often mean making it sound warmer or more conversational.

That can be helpful, but it is not the important part. Nobody’s workday is saved because a chatbot says “Absolutely!” before giving the wrong answer.

Humanizing AI means reducing the amount of translation the human has to do.

There is a deeper idea underneath that statement.

Every person brings more to a request than the words they type. They bring intent, memory, assumptions, priorities, judgment, emotion, and a picture of what success should look like. Much of that remains unspoken because another experienced person can often understand it from the situation.

Software has traditionally forced people to flatten that rich thought into buttons, fields, menus, and rigid commands. Natural-language AI gives us a chance to reduce that loss, but natural language alone is not enough. The AI still needs the surrounding structure that gives the person’s words meaning.

Psychology Has Been Here Before

The idea that thinking extends through language, tools, other people, and the surrounding environment did not begin with AI.

Psychologist Lev Vygotsky argued that people develop and organize thought through language, signs, tools, and social interaction. The tools around us do not merely help us express completed thoughts. They participate in how we form, hold, and work through those thoughts.

Cognitive scientist Donald Norman later showed how easily poor design turns a system problem into an apparent user problem. When the design does not match the person’s mental model, the person must cross a gap between what they intend and what the system allows them to do. People often blame themselves for that friction even when the design created it.

Edwin Hutchins expanded the unit of analysis further through distributed cognition. His work showed that complex thinking can be spread across people, tools, records, physical spaces, and shared practices. In those settings, the connected system can be a more useful unit of analysis than one brain working alone.

Andy Clark and David Chalmers pushed this into philosophy of mind through the extended mind thesis. Their argument is that an external tool can sometimes become part of a working cognitive system when it is reliably available and actively involved in memory, reasoning, or action.

Research by Clifford Nass and Youngme Moon adds a warning. People apply familiar social rules to computers even when they know the computer is not a person. We respond to language, timing, politeness, roles, and apparent personality almost automatically. Their findings suggest that an interaction is not psychologically neutral simply because the machine is not conscious.

These ideas help explain what an intuitive AI interaction should accomplish.

A person should be able to project the working shape of their consciousness into the system. That includes what they mean, what they know, what they assume, what they care about, and what they are trying to accomplish. Here, consciousness refers to the person’s lived perspective and active field of attention. It is not a claim about the nature of consciousness itself.

The AI environment can then function as a practical cognitive extension, carrying more of that meaning into the organization’s information, workflows, and decisions.

This is not projection in the clinical sense of attributing our own feelings or impulses to someone or something else. It does not mean the AI shares the person’s consciousness. It means the system preserves more of the person’s intent instead of forcing that person to translate every thought into machine-friendly instructions.

People should not have to stop thinking like themselves to use AI.

The most intuitive technology does not make people think more like machines. It allows machines to receive more of the way people already think.

People should be able to speak in the language they already use at work. The system should recognize what they are trying to accomplish, gather the right context, follow the correct process, and return the result in a useful form.

The employee should not need to become a prompt engineer. The employee should not need to know how every integration works. The employee should not need to rebuild the company’s process inside every new conversation.

The technology should meet people where they already are.

That does not remove human judgment. It protects it.

People should spend their attention on decisions, relationships, strategy, and the unusual situations that actually require thought. They should not spend it repeatedly teaching software where a file lives or how an ordinary handoff works.

Customization Has More Than One Level

Useful customization does not stop with individual preferences.

The AI needs to understand several connected levels of the organization.

At the individual level, it should understand a person’s responsibilities, communication style, and normal working patterns.

At the role level, it should understand what that position does, what information it receives, what it produces, and where its authority ends.

At the workflow level, it should understand the steps, decisions, handoffs, checks, and exceptions involved in completing the work.

At the department level, it should understand shared standards, terminology, knowledge, and coordination between roles.

At the organization level, it should understand systems, permissions, sources of truth, governance, and the larger operating model.

These levels work together. A person’s request has meaning because of the role that person holds. The role participates in a workflow. The workflow crosses departments and systems. The organization decides which rules and boundaries apply to all of it.

Without that structure, AI remains an impressive tool sitting beside the work. With it, AI can begin operating within the work.

Behavior Is Part of the Architecture

Two employees with the same job title may still work differently.

One may want a short answer and a clear recommendation. Another may want to see the sources and reasoning before making a decision. One may think out loud through conversation. Another may arrive with a precise request. One may need the system to slow down and confirm each step. Another may need it to act quickly within an already approved process.

These differences should not change the organization’s rules. Permissions, required reviews, and sources of truth still apply. But the interaction can adapt without weakening those boundaries.

That is the difference between behavioral customization and unrestricted personalization. Behavioral customization changes how the system communicates, guides, and presents the work. It does not quietly give someone more authority or invent a new process for every preference.

The AI cannot simply adapt to the employee or obey the organization in isolation. It has to work coherently across both. It should understand the person’s intent, expertise, role, and authority while still respecting the organization’s shared knowledge, policies, permissions, and responsibilities. When those contexts agree, the system can help the work move. When they conflict, it should recognize the conflict and bring the right person into the decision.

It also should not become hidden psychological surveillance. Behavioral adaptation should be visible, limited to the work, and controllable by the employee. A system can learn that someone prefers a concise summary without secretly building a personality profile or inferring sensitive traits that the work does not require.

The organization remains coherent. The experience becomes more human.

Custom Does Not Mean Building Everything From Scratch

Organization-specific AI does not require a company to train its own large model or replace every existing platform.

General AI products are valuable because they provide broad language, reasoning, search, and generation capabilities. Existing business systems remain valuable because they hold the records, permissions, and processes the company already depends on.

The translation layer connects those capabilities to the organization. It can be built through configured assistants, behavioral bundles, role models, workflow logic, connectors, retrieval systems, permission controls, and human review points.

The exact design depends on the work. A small team may need a few focused workflows. A larger organization may need shared standards across roles and departments. The purpose is not maximum complexity. It is enough structure for the AI to behave consistently inside the real business.

Governance Must Live Inside the Workflow

Governance cannot be a policy document that sits somewhere outside the AI interaction.

If an employee is not allowed to view a record, the AI should not retrieve it on that person’s behalf. If a decision requires approval, the workflow should stop at the approval point. If the system cannot resolve conflicting information, it should show the conflict instead of quietly choosing. If a task carries unusual risk, a qualified person should remain responsible for the final decision.

Good governance is not only about preventing bad behavior. It also makes the system easier to trust and use. People should be able to understand what the AI can do, where its information came from, what it changed, and how to correct it.

Human-AI interaction research emphasizes that systems should communicate their capabilities, support correction, behave predictably, and allow people to retain control. The Microsoft Research guidelines for human-AI interaction organize more than twenty years of work around those concerns. The NIST AI Risk Management Framework and Resource Center likewise provide a structure for testing, evaluating, verifying, and validating AI systems rather than treating deployment as the end of the process.

The translation layer is where those principles become operational. It is where abstract rules turn into permissions, stops, approvals, explanations, records, and recovery paths.

Start With the Work, Not the Tool

Organizations often begin AI planning by asking which platform to buy.

That question matters, but it comes too early.

A better starting point is a piece of work that causes repeated friction. It may require employees to search several systems, copy information between tools, repeat the same explanation, check the same conditions, or chase the same approval every week.

Then map the work:

1. Define the outcome. What does completed, useful work look like?
2. Identify the people. Who begins the work, who contributes, who decides, and who receives the result?
3. Locate the information. Which systems contain the needed information, and which source controls when records disagree?
4. Map the decisions. What can happen automatically, and what requires judgment or approval?
5. Find the exceptions. Where does the normal process break, and who resolves it?
6. Set the boundaries. What may the AI read, create, change, send, or never access?
7. Design the interaction. How would the people doing the work naturally ask for help, review the result, and correct it?
8. Test with real variation. Use ordinary cases, incomplete cases, conflicting information, permission limits, and unusual requests.

This approach also keeps customization tied to business value. The goal is not to build an elaborate model of the company because the technology is interesting. The goal is to remove a real burden, improve a real decision, or make a real process more reliable.

Tiankai Feng describes a related practice as “following the pain”: beginning with the problems people actually experience and co-creating solutions with them. That principle is as useful for AI architecture as it is for data strategy. The people closest to the work often know where the process fails, which exceptions matter, and what a usable result needs to look like.

The Next Stage of Business AI

For many organizations, the first stage of business AI has been access. Companies gave employees powerful general assistants and encouraged them to experiment.

That stage proved the technology could be useful. It also exposed the gap between what AI can do and what organizations need it to do consistently.

The next stage is not simply buying another assistant. It is designing how AI fits the business.

That means connecting technical capability to human behavior. It means mapping roles, workflows, information, permissions, decisions, and exceptions. It means building a layer that translates between the flexible language of people and the structured operation of the company.

Enterprise AI alignment is not a one-time match between a machine and a company. It is the continuing work of keeping individual judgment, organizational responsibility, and AI behavior coherent with one another.

The goal is not to force every organization into the same AI-shaped process.

The goal is to make powerful, general AI useful inside the specific organization it is meant to serve.

People should not have to leave their natural way of working to accommodate the AI. The AI should be architected to meet them there.

The future of business AI is not another general assistant sitting beside the work. It is general AI capability translated through the people, systems, and structure of the business itself.

References and Further Reading

• Feng, Tiankai. Humanizing Data Strategy: Leading Data with the Head and the Heart. 2024.
• Feng, Tiankai. Humanizing AI Strategy: Leading AI with Sense and Soul. 2025.
• Feng, Tiankai. “Humanizing Your Data Strategy: Seven Key Ideas for the AI Era.” Thoughtworks, 2024.
• Gall, Richard. “How Do We Put the Human at the Center of AI?” Interview with Tiankai Feng, Thoughtworks, 2025.
• Amershi, Saleema, et al. “Guidelines for Human-AI Interaction.” Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems, 2019.
• National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023. See also the NIST AI Resource Center.
• Vygotsky, Lev S. Mind in Society: The Development of Higher Psychological Processes. Harvard University Press, 1978.
• Norman, Donald A. The Design of Everyday Things. Revised and expanded edition, Basic Books, 2013.
• Hutchins, Edwin. Cognition in the Wild. MIT Press, 1995.
• Clark, Andy, and David J. Chalmers. “The Extended Mind.” Analysis, vol. 58, no. 1, 1998, pp. 7–19.
• Nass, Clifford, and Youngme Moon. “Machines and Mindlessness: Social Responses to Computers.” Journal of Social Issues, vol. 56, no. 1, 2000, pp. 81–103.