The Next AI Interface Isn’t Chat

Introduction

The conversation surrounding AI user interfaces has largely focused on the chat window. At the same time, a new generation of interaction models is rapidly emerging. Generative user interfaces dynamically construct screens based on context. Prompt-first interfaces allow users to begin with an objective rather than a menu. Adaptive layouts reorganize information according to the task at hand. Conversational canvases combine dialogue with visual workspaces, while multimodal interfaces blend voice, text, images, and touch into a single experience. Taken individually, these appear to be different interface trends, but it points to something much larger.

The next generation of enterprise software is not simply replacing buttons with prompts or graphical interfaces with chat. It is changing the relationship between people, software, and enterprise execution. The interface is becoming increasingly adaptive because the enterprise is assuming greater responsibility for understanding intent and coordinating work on behalf of the user.

This paper argues that the most significant transformation is not the interface itself, but the architectural changes taking place beneath it.

From Systems of Record to Systems of Intent

Enterprise Systems Are Entering a New Interaction Era

Enterprise software has never evolved separately from the way people interact with it. Each major step in computing changed the practical relationship between people, software, and work. Batch processing organized computing around prepared jobs. Command-line systems made interaction immediate. Graphical user interfaces made software visible and navigable. The web connected people to information and applications across organizations. Mobile computing moved interaction into the context of daily work.

Each generation made software more accessible. But one assumption remained largely intact: people were still responsible for translating objectives into procedures that software could execute. Whether approving a purchase, onboarding an employee, scheduling a shipment, or closing a financial period, users learned the structure of applications. They selected functions, completed transactions, followed workflows, and handled exceptions inside systems designed in advance.

Artificial intelligence is beginning to challenge that assumption. The significance of conversational AI is not that it replaces graphical interfaces, web applications, dashboards, or mobile apps. Its significance is that it gives people a practical way to begin with intent. A user can start with an objective rather than with the structure of an application.

That difference matters because enterprise systems have always required translation. The first translation happens during design time and build. Business leaders define objectives. Business architects describe capabilities and operating models. Analysts document requirements. Enterprise and solution architects design systems. UX teams create navigation and interaction models. Developers encode those decisions into applications, workflows, integrations, and data structures. Months, and often years, are spent converting organizational knowledge into software that can run reliably at scale.

The second translation happens during runtime. Once software is deployed, users still convert business objectives into the correct sequence of applications, screens, transactions, approvals, and exceptions. Enterprise systems execute efficiently, but people often remain responsible for deciding how work should be performed within the organization’s digital landscape.

AI changes the economics of this relationship. It lowers the cost of encoding, evolving, and operationalizing enterprise knowledge. Product managers can prototype capabilities more quickly. Analysts can generate process models and user stories. Developers can produce code, tests, documentation, APIs, and integrations with far less manual effort. In other cases, AI agents can orchestrate existing enterprise capabilities without requiring new software at all. The result is not simply faster development. It is a gradual movement of formulation from design time into runtime.

Enterprise software is therefore evolving from systems that execute predefined workflows toward systems that continuously formulate and coordinate business objectives. The visible interface may be conversational, graphical, mobile, or embedded in another system. The deeper change is that interaction is becoming the point where enterprise systems begin to understand what people are trying to accomplish.

Historically, people learned how to navigate enterprise software. Intent-based systems increasingly require enterprise software to navigate the enterprise on behalf of people.  That is the architectural shift explored in this paper.

Interaction Has Always Shaped Software

As Dr. Jakob Nielsen argued throughout his work on usability and interaction design, interaction models do more than make software easier to use. They shape how people understand, learn, and operate software by aligning technology with human cognition rather than requiring users to adapt to the technology itself. Different interaction paradigms also reflect different conceptual models for organizing software. The user interface is therefore more than a presentation layer; it embodies how a system is structured from the user's perspective.

This paper extends that principle. As interaction evolves from navigation toward intent, the interaction model no longer influences only how software is experienced. It becomes an organizing principle for how enterprise capabilities are discovered, coordinated, and executed. User experience is no longer confined to the surface of the application. It increasingly shapes the orchestration of services, business processes, governance, and enterprise architecture beneath it.

Batch computing required users to define complete jobs before execution. Command-line systems introduced a feedback loop: the user issued an instruction, the machine responded, and the user adjusted the next instruction. Graphical interfaces introduced a different mental model. Files, folders, windows, icons, menus, and buttons gave people a visual representation of the system. The computer's internal structure was translated into objects people could see and navigate.

The graphical user interface was powerful because it aligned software with human perception. People could see, point, select, drag, open, close, and organize. The interface did not remove the need for applications, data, operating systems, or workflows. It made those capabilities accessible through representation.

The web and mobile computing extended the same principle. Browsers gave organizations a common environment for accessing distributed applications and information. Mobile devices allowed interaction to occur where work was happening. Across each generation, the interface reduced a different barrier to participation. Yet the dominant interaction model remained navigational. Users still moved through the system to locate functionality before they could accomplish work.

Intent-based interaction begins from a different premise. Instead of first representing the system, it gives people a way to express what they want to accomplish. Conversation matters because humans naturally use language to describe goals, constraints, priorities, uncertainty, and trade-offs. But conversation is only one modality. Intent can also be expressed through goal cards, templates, dashboards, forms, voice, APIs, events, alerts, or other intelligent systems.

The key distinction is not chat versus graphical interfaces. The key distinction is navigation versus intent. A navigation-based interface assumes the user understands enough of the application's structure to choose the correct path. An intent-based interaction assumes the enterprise can interpret an objective, clarify it when necessary, and coordinate the capabilities required to achieve it.

This fundamentally changes the interaction loop. Traditional interfaces follow a pattern of action → response: click, result; click, result. Intent-based systems introduce a richer sequence: objective → clarification → confidence → formulation → orchestration → execution → assurance → learning. Interaction is no longer limited to operating software. It becomes the mechanism through which the enterprise understands requests, objectives, and coordinates work to improve outcomes.

Reducing Barriers to Participation: Lessons from M-Pesa

The relationship between interaction and participation is not unique to AI. One of the clearest examples appeared more than a decade ago with M-Pesa in Kenya.

At the time or our work on M-PESA G2, much of the population had limited access to formal banking infrastructure. Traditional banking assumed bank accounts, branches, documentation, identity processes, and enough financial literacy to navigate established procedures. For millions of people, those assumptions were not small inconveniences. They were barriers to participation in the financial system.

M-Pesa approached the problem differently. It did not try to reproduce banking on a mobile device. It simplified interaction around the user’s primary objective: send and receive money. A person did not need to understand cash management, agent commissions, transaction processing, account statements. Those responsibilities were still real. They were simply moved behind the interaction.

The device mattered because the device fit the environment. A simple feature phone could reach people who did not have computers, broadband, smartphones, or bank accounts. The interface was not rich in the graphical sense, but it was rich in usefulness. It matched the way people already thought about money like a telephone call and a phone number: I need to send cash to this person. I need this person to receive it. I need to know it happened.

The system also depended on human infrastructure. Agents were not incidental to the design. They were part of the execution layer. A local shopkeeper, a kiosk operator, or a woman holding cash in a pouch became the trusted bridge between digital value and physical cash. The confirmation message on the phone mattered, but so did the person at the other end who could actually disperse the funds. Digital coordination and human trust worked together.

While working on the evolution of Vodafone’s second-generation M-Pesa platform, the mobile phone was only the medium. The more enduring lesson was how much participation could expand when a system reduced the effort required to express a simple intent. The user’s objective was direct: send money. The system handled the complexity that made the outcome possible.

At the interaction level, the complexity of completing the transaction was hidden. Multiple ledgers, parties, reconciliation processes, fraud controls, and real-time settlement mechanisms operated behind the scenes. For the user, that hidden complexity created trust. Sending and receiving money felt simple, immediate, and reliable.

M-Pesa succeeded because it reduced the cognitive, financial, and infrastructure barriers between intent and participation. It did not make the financial system less sophisticated. It made participation in that system easier for people who had previously been excluded from it.

Intent-based enterprise systems pursue a similar principle in a different domain. They do not remove the complexity of enterprise operations. They move more of that complexity behind the interaction so people can begin with the work they are trying to accomplish.

From Imperative to Declarative to Intent

The shift toward intent-based interaction is easier to understand as part of a longer progression in how software accepts responsibility for defining and carrying out work.

Imperative systems require people or developers to specify how work should be performed. The user selects commands, completes forms, follows a sequence, or invokes a predefined workflow. The software executes a procedure that has already been designed and encoded.

Declarative systems shift part of that responsibility into software. A developer, administrator, domain specialist, or user describes a desired state, rule, query, constraint, or policy, while the system determines the steps required to satisfy it. SQL, policy engines, configuration management, infrastructure-as-code, and intent-based networking all follow this broad pattern. They do not require every procedural step to be specified, but they still require someone to formulate the desired state with enough precision for the system to interpret and execute.

The distinction is not command line versus graphical interface, or code versus conversation. A command-line interface can invoke either imperative or declarative operations. A form, API, or graphical workflow can do the same. The more important distinction is whether the procedure is specified directly or derived from a sufficiently precise declaration.

Declarative systems still depend on structure. They require syntax, schemas, configuration, rules, policies, or other formal representations. They generally do not determine for themselves what the desired state should be, and they do not learn from the outcome unless feedback mechanisms have been deliberately designed around them.

Intent-based systems begin before a precise declaration exists. The user may understand the business objective without knowing the technical state, workflow, data requirements, system boundaries, or sequence of actions needed to achieve it. A business leader may say that cloud costs are too high. A restaurant may ask whether enough produce will be available for tomorrow. An employee may say that a new hire must be ready to work on Monday. Each request expresses an objective, but none provides a complete specification.

The system must therefore participate in formulation. It must interpret the objective, retrieve relevant context, identify uncertainty, ask for clarification where necessary, recognize constraints, define what success should mean, and translate the resulting understanding into declarative goals and executable actions.

This is where AI becomes significant. Declarative computing is not new. What is new is the practical ability to formulate and adapt declarations from incomplete, ambiguous, and naturally expressed business objectives. AI does not eliminate the declarative or imperative layers. It helps produce, refine, and coordinate them.

‘Vibe’ coding illustrates this shift during software creation. A person can begin with a partially formed idea rather than a complete specification, allow the system to propose an implementation, observe the result, and refine both the software and the objective through interaction. Specification, design, implementation, and testing begin to overlap.

Agentic AI extends the same principle into operational systems. An agent may interpret an objective, decompose it into tasks, retrieve information, select tools, call services, inspect intermediate results, and revise its plan. The procedure does not always exist as a complete workflow before execution begins. Parts of it can be composed and adjusted as the work proceeds.

The surrounding architecture supports this process. Vector databases provide semantically relevant context from unstructured information. Knowledge graphs represent entities, relationships, policies, and organizational meaning. APIs and MCP servers expose enterprise data, tools, and services in forms that AI systems can discover and use. Models interpret and formulate, while agents coordinate planning and execution.

Intent-based systems are therefore not merely conversational interfaces wrapped around existing workflows. Conversation may initiate the process, but formulation is the architectural responsibility that makes intent operational.

The progression can be articulated this way:

·        Imperative systems execute specified procedures.

·        Declarative systems resolve specified states.

·        Intent-based systems help formulate the states, constraints, plans, and actions required to pursue an objective.

The design question is no longer only how people operate software or how developers define desired states. It becomes: how should people and systems share responsibility for formulation, reasoning, execution, assurance, and learning?

Design Time Meets Runtime

Enterprise software has traditionally treated design, build and operation as separate phases. During design and build time, the enterprise determines how work should be performed. During runtime, users and systems operate within the processes, applications, rules, data structures, and controls that were implemented.

This separation reflected the economics of software development. Translating enterprise knowledge into software required specialized labor, large projects, significant funding, and long implementation cycles. Business change became software change. Software change became a project. Each project required requirements, architecture, design, development, testing, deployment, adoption, and support.

In practice, much of the cost of enterprise software came from converting business intent into operational structure before the system could be used.

Imperative and declarative paradigms have traditionally operated largely within this design-and-build environment. Developers specify procedures. Architects define components and integrations. Administrators configure desired states. Domain specialists translate policies into rules. Business analysts document processes and requirements. By the time the system reaches runtime, the available workflows, states, controls, and interaction patterns have mostly been established.

Users may select among functions, provide information, trigger workflows, and handle exceptions, but they generally operate within a solution designed in advance. AI begins to compress and partially redistribute this cycle.

It can reduce the cost of converting business knowledge into software artifacts, configurations, integrations, policies, and orchestrated services. A product manager may prototype a workflow. A business analyst may generate process documentation or structured requirements. A developer may produce code, APIs, tests, and technical documentation more quickly. An AI agent may coordinate existing enterprise capabilities without requiring a new application or permanently encoded workflow.

The deeper change is not only that design and development become faster. Some activities that traditionally belonged to design and build can increasingly continue during runtime.

An intent-based system may receive an objective that has not yet been fully specified. While the business is operating, it may clarify the request, retrieve current context, identify applicable policies, formulate a temporary desired state, select available capabilities, construct a plan, and adapt execution as conditions change. Runtime is no longer only where predefined software executes. It also becomes a place where parts of the solution are formulated and composed.

This does not mean that design time disappears or that enterprise systems should redesign themselves without constraint. Formal architecture, security review, testing, approvals, deployment discipline, and operational controls remain necessary. Public companies, regulated industries, and mission-critical environments cannot allow unrestricted reformulation or execution.

The boundary instead becomes more fluid. The enterprise still defines its durable foundations during design time: business capabilities, operating models, policies, data standards, security controls, approval structures, decision rights, service boundaries, and acceptable risk. But these artifacts increasingly become active runtime resources. They help the system determine how an objective should be interpreted, which information is authoritative, which capabilities may be used, what approvals are required, and whether execution should proceed.

Policies, processes, controls, and organizational knowledge therefore become more than documentation or configuration created for deployment. They become part of the operational context through which an intent-based system reasons and acts.

In systems integration practice, this separation is often described through terms such as plan, build, run; design, build, operate; or, in enterprise platforms such as SAP, discover, prepare, explore, realize, deploy, and run. The terminology varies, but the underlying structure is familiar.

During design and build, organizations translate business objectives into operating models, process designs, configurations, integrations, data structures, controls, and user experiences. After go-live, those decisions move into runtime, where users operate the system, transactions execute, exceptions arise, and the organization enters business-as-usual operation.

What is changing is not that these phases disappear. Some formulation that historically belonged to requirements, blueprinting, design, and build can increasingly continue during run.

Enterprise systems can interpret objectives, apply current business context, assemble existing capabilities, generate declarative specifications, invoke imperative operations, and adapt execution while the business is operating. In traditional systems integration terms, AI begins to blur the boundary between change-the-business and run-the-business.

This is the economic reason intent-based systems are becoming practical now. The concept of intent is not new. What has changed is the cost of translating intent into operational form.

AI makes it possible to move more formulation into runtime without abandoning the architecture, governance, and control required to operate safely. Design time becomes more continuous, and runtime becomes more capable of participating in design.

Designing from Intent: A Different Starting Point

The influence of intent-based design becomes clearest when a business does not yet have mature systems in place – especially for small businesses or start-ups. They typically lack the resources to invest in robust management systems, thus opting for renting software and infrastructure instead.

Consider a small food distribution startup that connects fresh-cut produce from local farms with restaurants. The work is simple to describe and hard to run. Farmers harvest and box produce. The restaurant orders, the farmer picks and cuts, the distributor picks up fresh vegetables and delivers them daily to restaurants. Restaurants ask what is available, place orders, receive deliveries, and expect accurate invoices. Credits are issued when quality or quantity falls short. Payments have to be recorded. Inventory, availability by season, delivery schedules, customer records, invoices, credits, and bookkeeping all need to stay aligned.

The people doing the work may have very limited resources. Some farmers may have little digital literacy. Some may have limited language reading and writing ability. The business may not have the budget, staff, or time to implement anything that resembles a traditional enterprise system. But the business still needs enterprise discipline as it grows. Orders have to be right. Deliveries have to happen. Money has to be collected. Credits have to be fair. Records have to be trusted.

A conventional approach would begin by selecting software for each function. The company might subscribe to an accounting package, an inventory system, a customer management tool, a logistics platform, and payment software. Then it would connect them through spreadsheets, exports, manual reconciliation, and human coordination. That pattern is familiar because many small businesses operate this way. The tools are accessible, but the cognitive burden remains high during onboarding, configuring, and learning the software

An intent-based approach starts with what the business is trying to coordinate. A farmer signals through chat  what produce will be available for harvest. A restaurant says what it needs for tomorrow through chat. A driver confirms pickup and delivery through chat.  A customer approves an invoice or reports that a crate was short. These interactions can remain close to the natural communication already occurring in the business.

Behind those conversations, AI-assisted services interpret availability, structure operational data, coordinate deliveries, generate schedules, maintain customer records, reconcile inventory, prepare invoices, and support bookkeeping. The underlying capabilities still exist. They simply do not appear to every participant as separate applications.  A single developer could develop an automated system that collects all the communication data and connect the underlying processes and cloud applications to orchestrate and record the transactions.  Of course, this is a highly skilled developer with discipline in problem solving skills.

This startup does not avoid structure. It still needs data quality, accurate records, controls, payment discipline, auditability, and financial reporting. The difference is where that structure is introduced. Rather than forcing farmers, restaurants, drivers, and staff into rigid workflows from the first day, the system captures how work actually occurs and progressively formalizes it into repeatable operational capabilities.

This illustrates a broader principle. Intent-based systems do not eliminate enterprise applications. They reduce the need for people to understand them. They reduce the friction and investment required to combine design, operation, and improvement while the business is running. A farmer with limited literacy does not want to learn inventory software. A driver does not need to understand accounting categories. A restaurant operator does not need to know which back-office system creates the credit. They can use natural language or simple guided interactions to trigger agents that orchestrate, record, and report the work.

As the business grows, new capabilities can be added without changing the simplicity of the first interaction. The enterprise becomes more sophisticated while the interface remains close to the work people are trying to coordinate. That is the point. Not less structure. More structure behind a simpler path from intent to outcome.

Intent Formulation as an Architectural Responsibility

Traditionally, a business objective could not be executed directly. Before work could begin, someone in the organization had to determine what the objective actually meant, what context applied, which policies governed the decision, which enterprise capabilities were involved, and ultimately how success would be measured.

Enterprise architecture addressed this through a clear separation of concerns. Systems of Engagement captured interaction. Systems of Record executed transactions and maintained authoritative business data. Between them sat a less visible, but equally important layer: human formulation.

Business analysts translated objectives into requirements during implementation. Enterprise architects and developers transformed those requirements into applications, workflows, integrations, and data models. At runtime, managers interpreted corporate policy, employees navigated enterprise applications, and experienced staff resolved the countless exceptions that software could not. The enterprise depended on people to bridge the gap between interaction and execution.

As enterprise systems became more sophisticated, that cognitive burden grew with them. A procurement manager no longer worked inside a single application. They coordinated ERP systems, supplier portals, contracts, spreadsheets, email, collaboration tools, dashboards, approval workflows, and organizational policies. The systems became more capable, but people increasingly became the orchestration layer responsible for deciding how work should be performed.

That is the gap AI begins to change. The shift is already visible. Microsoft Copilot retrieves information across Microsoft 365 before helping users create documents or answer questions. GitHub Copilot translates programming intent into executable code. Customer service assistants summarize conversations, retrieve knowledge articles, recommend next actions, and draft responses. Enterprise AI platforms increasingly call APIs, retrieve organizational knowledge, invoke business services, and coordinate work across multiple systems instead of simply generating text.

These examples may appear different on the surface, but architecturally they share the same pattern. The system is beginning to participate in the formulation of work before execution begins. This introduces a new architectural responsibility: Intent Formulation.

Intent formulation is the process through which an ambiguous business objective becomes an executable enterprise objective. It sits between interaction and execution. It interprets intent, resolves ambiguity, requests clarification when necessary, evaluates alternatives, applies enterprise context, and determines how the organization should respond before operational work begins.

This represents an evolution of the traditional Separation of Concerns. I think one of the architectural mistakes emerging today is treating the language model as though it were the entire application—expecting a single prompt to perform interaction, business logic, data retrieval, security, workflow orchestration, and execution simultaneously. The result is often an opaque system where responsibilities become tightly coupled, governance becomes difficult, and enterprise behavior becomes increasingly difficult to reason about.

Instead, reasoning should remain distinct from execution. The System of Intent is responsible for formulation, not for bypassing enterprise controls. Existing enterprise systems continue to enforce security, data ownership, approvals, compliance, and transactional integrity. AI expands the architecture by introducing a new reasoning responsibility; it does not replace the responsibilities that already exist beneath it.

Emerging technologies illustrate how this separation is beginning to take shape. Tool-calling frameworks, retrieval systems, policy engines, agent orchestration platforms, and protocols such as the Model Context Protocol (MCP) provide mechanisms for connecting reasoning systems with enterprise capabilities while preserving governance and security boundaries. They are implementation approaches that support this architectural pattern, not the pattern itself.

Consider a request such as: "Find out why our cloud costs spiked last week and alert the DevOps lead if immediate action is required."

No predefined workflow may exist for this request. Before anything can execute, the enterprise must determine what "cloud costs" refers to, which cloud providers and billing systems should be consulted, what constitutes a meaningful increase, who the appropriate DevOps lead is, whether the user has permission to access financial information, and what threshold justifies generating an alert.

The role of intent formulation is to resolve those questions before execution begins. It gathers the necessary enterprise context, applies organizational policies, composes the capabilities required to accomplish the objective, and produces a governed plan that existing enterprise systems can safely execute.

The significance of intent formulation is not that AI replaces enterprise applications. It is that enterprise systems can increasingly share responsibility for the cognitive work that has traditionally belonged to people. As more of that formulation moves into runtime, the cognitive distance between human intent and enterprise outcomes continues to shrink, while the enterprise retains the governance, security, and control required to operate safely at scale.

Enterprise Knowledge Becomes Operational

Intent requires context. AI does not inherently know how an organization operates, what policies govern its decisions, who has authority, which controls apply, or what trade-offs the enterprise is willing to accept. That knowledge belongs to the enterprise, not the model.

Historically, enterprise knowledge has been created during design time and distributed across applications, workflows, policy manuals, operating procedures, architecture documents, training materials, and, perhaps most importantly, the experience of employees. Much of it has never existed as something software could directly use. It lived in documents, spreadsheets, email threads, presentations, and the judgment of experienced people.

That was acceptable because people were responsible for interpretation. Enterprise systems executed transactions. People interpreted the enterprise. Experienced account managers knew when to make an exception for an important customer. Procurement teams understood which suppliers could still be trusted during a shortage. Finance managers recognized when a payment should be held despite meeting normal approval rules. Operations teams saw patterns that rarely appeared in documented procedures. The organization functioned because people continuously supplied the context that software lacked.

Intent-based systems create a different expectation. Business capability models, organizational policies, master data, approval authorities, regulatory obligations, risk tolerances, customer commitments, operational history, and institutional knowledge increasingly become runtime assets that inform formulation while the business is operating. Rather than existing solely as documentation for people, they become knowledge that enterprise systems can reason over before execution begins.

Consider a simple request: "Expedite order #402." The request itself is straightforward. The appropriate response may not be. 

In one organization, the order can simply be prioritized for shipment. In another, expediting freight above a certain value requires management approval. A healthcare provider may reserve inventory for critical hospitals. A manufacturer may prohibit changes once production has begun because contractual commitments have already been made.  The words are identical. The enterprise knowledge surrounding them is completely different. That difference is what intent formulation must resolve.

The quality of an intent-based system therefore depends less on the sophistication of its language model than on the quality of the enterprise knowledge surrounding it. A frontier AI model may understand language exceptionally well, but it does not understand how your enterprise operates until that knowledge is made available in a structured, governed, and operational form.

Organizations with well-defined business capabilities, trusted master data, explicit policies, mature governance, and clear decision models will have a significant advantage over organizations whose knowledge remains fragmented across documents, spreadsheets, email, collaboration platforms, and individual experience. The intelligence of the enterprise increasingly depends not only on the AI it adopts, but on the quality of the organizational knowledge it can reason over.

This expands the role of enterprise architecture. Historically, enterprise architecture has focused on designing systems, integrations, processes, and information structures that enable the business to operate. That responsibility remains. What changes is that many of the architectural artifacts created during design time increasingly become operational assets during runtime.

Business capability models provide reasoning context. Policies become executable constraints. Master data provides enterprise context. Decision authorities define governance boundaries. Organizational knowledge informs formulation before execution begins. Enterprise architecture is therefore expanding from designing systems to designing both the systems and the enterprise knowledge those systems can reason over while the business is running.

Enterprise Requirements Define the Boundaries of Intent

Intent-based systems do not reduce the importance of enterprise requirements. They make them more operational.  An AI system cannot determine how an enterprise should operate. Approval authorities, financial controls, accounting policies, cybersecurity rules, privacy obligations, delegated authority, regulatory requirements, risk tolerances, and organizational priorities remain business decisions. AI may help formulate objectives and coordinate execution, but the enterprise must still define the boundaries within which those decisions are allowed to occur.

This distinction becomes more important as formulation moves into runtime. Traditional enterprise software embedded many business rules directly inside applications and workflows. Intent-based systems increasingly interpret objectives dynamically. That flexibility does not eliminate governance. It increases the need for clearly defined enterprise requirements that guide formulation before execution begins.

The requirements differ dramatically by organization. A local produce distributor may require practical controls around orders, deliveries, customer credits, payments, and bookkeeping. The operating model can remain relatively lightweight because the business is small, changes frequently, and the consequences of failure are limited.

A publicly traded corporation operates under very different conditions. Financial reporting must comply with accounting standards. Internal controls may need to satisfy SOX requirements. Segregation of duties, delegated authority, cybersecurity policies, privacy obligations, auditability, and industry-specific regulations become part of the enterprise's operating behavior. The objective is no longer simply completing work. The enterprise must also demonstrate that work was performed according to defined controls.

To the user, the interaction may appear almost identical. "Expedite this order."  "Approve this payment." "Prepare next quarter's forecast."  The objective is expressed in natural language.  What differs is the enterprise context that surrounds it.

The same request may be executed immediately in one organization, require executive approval in another, or be prohibited entirely in a third. The difference is not the intelligence of the AI. It is the requirements that define appropriate enterprise behavior.

This is why intent-based systems should not be viewed as generic AI applications. Their behavior is shaped by the enterprise they represent. Designing them requires more than selecting a capable language model. It requires understanding business capabilities, enterprise policies, operational constraints, decision authorities, data governance, and organizational objectives well enough that they can guide formulation before execution begins.

The quality of an intent-based system ultimately depends on two complementary foundations. Enterprise knowledge provides the context required to understand the business. Enterprise requirements define the boundaries within which that understanding may be transformed into action.

From Systems of Record to Systems of Intent

Enterprise architecture has long distinguished between systems that serve different responsibilities within the organization. Geoffrey Moore's concepts of Systems of Record and Systems of Engagement remain valuable because they describe two fundamental architectural concerns that have shaped enterprise software for decades.

Systems of Record establish authoritative business truth. ERP, financial management, CRM, HR, manufacturing, and operational systems maintain transactions, master data, compliance, and auditability. Their primary responsibility is to execute business operations and preserve the integrity of enterprise information.  Their central question is: What happened?

Systems of Engagement changed how people interact with those enterprise capabilities. Web applications, mobile platforms, collaboration tools, customer portals, and digital workplace technologies reduced the effort required to access information and perform work. They improved usability, participation, and communication without fundamentally changing how enterprise decisions were formulated.  Their central question became: How do people engage with the enterprise?

Intent-based systems introduce a different architectural responsibility. As organizations increasingly operate through AI-assisted reasoning, enterprise knowledge, and dynamic coordination, the enterprise must formulate objectives before execution begins. Objectives must be interpreted within business context, constrained by enterprise requirements, coordinated across capabilities, and adapted as conditions change.

That responsibility does not naturally belong to either Systems of Engagement or Systems of Record.

It belongs to what is described here as a System of Intent.  A System of Intent is not the authoritative source of enterprise data, nor is it simply another user interface. It is the reasoning layer that connects business objectives with enterprise execution. It interprets intent, applies operational enterprise knowledge, evaluates enterprise requirements, formulates an executable objective, coordinates the capabilities required to accomplish it, and continuously learns from the outcomes.

Unlike a System of Record, it does not own business truth. Unlike a System of Engagement, it does not primarily manage interaction.  Its responsibility is formulation.

Whether Systems of Intent ultimately emerge as a distinct enterprise platform or become embedded within existing software remains an open question. Different vendors will almost certainly implement these responsibilities differently. Some may introduce dedicated reasoning and orchestration platforms. Others may embed formulation directly within ERP, CRM, workflow, collaboration, or industry-specific applications. Emerging protocols such as the Model Context Protocol (MCP) may provide one mechanism for connecting reasoning systems with enterprise capabilities, but they are implementation approaches rather than the architectural pattern itself.

Enterprise software is evolving beyond systems that record information and systems that facilitate interaction. It is beginning to include systems that formulate objectives, reason over enterprise knowledge, coordinate capabilities, and continuously reduce the cognitive distance between human intent and enterprise outcomes.

A Conceptual Architecture for Intent-Based Systems

Intent-based systems should be understood as a set of architectural responsibilities rather than a prescribed technology stack. Every organization will implement these responsibilities differently depending on its size, industry, regulatory environment, and operating model. Some may combine them within a single platform. Others may distribute them across dozens of enterprise applications, AI services, integration platforms, and operational systems.  What remains consistent is not the implementation, but the responsibilities that must exist somewhere within the architecture.

The interaction responsibility captures intent. It may appear through chat, voice, dashboards, forms, mobile applications, APIs, collaboration tools, or other intelligent interfaces. Its purpose is not simply to collect data for a predefined transaction, but to understand what a person or another system is trying to accomplish.

The intent formulation responsibility transforms that expressed objective into an executable enterprise objective. It resolves ambiguity, requests clarification when necessary, evaluates alternatives, determines confidence, applies enterprise requirements, and formulates a governed objective before operational work begins.

The operational enterprise knowledge responsibility provides the context required for formulation. Business capabilities, operating models, policies, organizational structures, master data, decision authorities, regulatory obligations, security rules, and institutional knowledge become runtime assets that allow the enterprise to reason consistently during operation.

The enterprise coordination responsibility determines how the objective should be fulfilled. Existing enterprise applications, AI agents, services, workflows, APIs, human approvals, and external platforms are coordinated around the objective rather than exposed to users as separate systems they must navigate individually.

The execution responsibility performs the operational work. Transactions are processed, records are updated, workflows advance, notifications are delivered, approvals are enforced, and Systems of Record remain the authoritative source of enterprise truth.

The assurance and learning responsibility closes the loop. It validates whether the intended business outcome was achieved, monitors execution, detects exceptions, applies ongoing governance, and continuously improves future formulation through operational feedback.

Together, these responsibilities form a closed-loop enterprise architecture.

Conclusion: The Interface Is Only the Beginning

The conversation about AI has understandably begun with chat. It is the most visible expression of this new generation of computing, and for many people it represents their first experience with intent-based interaction. Asking a question, expressing an objective, or describing a problem in natural language feels fundamentally different from navigating menus, completing forms, or learning the structure of an application. But chat is only the beginning.

Enterprise software has always evolved through interaction. Batch processing organized work into jobs. Command-line systems introduced immediate feedback. Graphical interfaces made software navigable through visual representation. The web broadened access to enterprise capabilities. Mobile computing brought interaction into the context of everyday work.

Intent-based interaction continues that progression, but it changes something more fundamental. Rather than requiring people to understand how software works, enterprise systems are increasingly expected to understand what people are trying to accomplish. The challenge is no longer simply designing better interfaces. It is designing systems that can formulate objectives, reason over enterprise knowledge, coordinate capabilities, and execute work while remaining governed by enterprise policy. That shift reaches far beyond user experience.

Enterprise knowledge is becoming operational. Business capabilities, policies, master data, decision authorities, governance, and organizational context are no longer confined to documents, implementations, or individual experience. They increasingly become runtime assets that guide formulation before execution begins. Enterprise architecture therefore expands beyond designing applications and integrations. It increasingly concerns the design of the knowledge, context, and decision boundaries that intelligent systems can reason over while the business is operating.

Existing enterprise systems remain essential. Systems of Record continue to preserve authoritative business truth. Systems of Engagement continue to facilitate interaction. Enterprise applications continue to execute transactions and business processes. Systems of Intent introduce a complementary architectural responsibility: transforming human objectives into governed, executable enterprise action.

History suggests that the most important technology shifts are rarely remembered for the interfaces they introduced. They are remembered for the barriers they removed.

Graphical interfaces reduced the barriers to personal computing. The web reduced the barriers to information. M-Pesa reduced the barriers to financial participation by allowing millions of people to move money without understanding the underlying financial infrastructure. Intent-based systems have the potential to reduce another barrier: the cognitive distance between what people are trying to accomplish and what the enterprise is capable of achieving.

Chat may be what introduces most people to this transformation. It is simple, familiar, and remarkably effective at capturing intent. But the lasting significance of this moment will not be the chat interface itself. It will be the enterprise architectures that emerge behind it.

If this trajectory continues, the next generation of enterprise systems will not be remembered because they introduced another interface. They will be remembered because they operationalized enterprise knowledge, reduced the cognitive burden between intent and execution, and enabled organizations to think, coordinate, and act with a level of agility that traditional software architectures could never achieve.