The future of point-of-sale may not be a choice between one large application and hundreds of small services, but a governed set of retail capabilities that AI can understand and orchestrate.
Anyone who has spent long enough around retail software will recognize a strange architectural rhythm. A new POS generation is designed around one strong idea, the product grows, the weaknesses of that idea become increasingly painful, and eventually the next generation is announced with an architecture that looks almost like the opposite of the one before it. A tightly integrated application becomes a collection of services because the old system was too difficult to change, then the collection of services becomes so difficult to operate, coordinate and understand that the next redesign starts bringing things together again. I have watched variations of this cycle for decades, and the longer I observe it, the less convinced I am that the real problem was ever the choice between monolithic and modular architecture.
The architecture pendulum
The dilemma is real because both directions solve a problem and create another one. A large, integrated solution gives developers one transaction boundary, fewer network dependencies, simpler testing in many scenarios and a system that can often be understood as one product. As the codebase and organization grow, however, coupling can make changes slower and releases riskier. Microservices and other fine-grained approaches move the boundaries outward, allowing services to evolve and deploy independently, but the complexity does not disappear; it moves into the network, service contracts, data consistency, versioning, observability and operations. Martin Fowler described this as a “microservice premium,” while Microsoft’s current architecture guidance makes the same point more formally: each service may be simpler, while the system as a whole becomes more complex because there are more moving parts, more inter-service communication and more difficult consistency and management problems.
This is one reason I am cautious when architecture discussions become almost ideological. A monolith is not automatically bad, and a microservice landscape is not automatically modern. A badly structured monolith can become impossible to change, but badly chosen service boundaries can create what is essentially a distributed monolith with all the operational cost of distribution and very little independence. Even AWS guidance explicitly warns about a “microservice Death Star,” where highly interdependent components become as rigid and fragile as the monolith they were supposed to replace.
The same is true for deployment, which is often mixed into the architecture discussion even though it is a different decision. A system can be deployed in the cloud and still behave like one large tightly coupled application, while a retailer can run several independently designed components locally in a store. Moving software from an on-premise server to the cloud changes where it runs; it does not by itself change the architectural paradigm.
Retail was never really monolithic
There is also a retail-specific reason why I think the classic monolith-versus-microservices discussion is incomplete. A POS can be packaged as one application, but the retail process around it is almost never one application. Payments, inventory, product data, order management, loyalty, workforce functions, peripherals, e-commerce, accounting and increasingly fiscal or invoicing systems all cross the transaction boundary. GS1’s current point-of-sale guidance describes the POS host as interacting with hardware such as scanners, scales and receipt printers, payment processing and broader data-sharing standards, with regulatory requirements continuing to create new data needs.
This means that retail architecture is modular whether we like it or not; the real choice is where we draw the boundaries, how stable those boundaries are, and how much complexity we force every participant to understand. A POS vendor can put more functionality into one deployable product, or split it into many services, but the retailer still has to connect the transaction to an ecosystem that is bigger than the POS itself. Globalization makes this even more visible because the same commercial action can trigger different payment, tax, fiscalization, receipt, invoicing and data-retention obligations depending on the country and business model.
The first conflict therefore sits in an uncomfortable place. We want the simplicity of one coherent product and the flexibility of many independent capabilities at the same time. For years we have tried to solve that tension mainly by changing the size and location of software components, and then we have been surprised when the complexity simply reappears somewhere else.
AI creates a new architectural temptation
Now AI is entering this already complicated landscape, and the first instinct is understandably to add it as one more module. The POS gets a copilot, an assistant or an agent, this component receives access to existing APIs, and the rest of the architecture remains largely unchanged. We can already see this pattern in the market: Salesforce, for example, has connected retail agents to product, inventory, order and customer data and is positioning Agentforce Commerce across B2C, B2B, point of sale and order management.
There is nothing wrong with this approach, and it can create useful functionality quickly, but architecturally it is conservative. If an existing system already has difficult boundaries, duplicated logic and too many integrations, adding an intelligent component on top does not remove those problems. The AI has simply become another consumer of them, and in the worst case it creates one more orchestration layer that has to understand all the historical complexity underneath.
This is the second conflict, because the technology that promises to simplify the interaction with software can easily make the software architecture itself more complicated when it is treated only as another feature. The interesting alternative is to reverse the relationship and stop thinking about AI as something embedded in the POS, because the more radical possibility is that the POS functionality becomes embedded in an AI-driven interaction and orchestration layer.
The POS can become a set of capabilities rather than one application
I do not mean that an LLM should contain the pricing engine, calculate tax from memory or invent the logic for a return. I mean that the POS of the future could increasingly be expressed as a set of explicit retail capabilities that an AI agent is allowed to call: identify a customer, find an item, calculate an offer, reserve stock, create a basket, apply an authorized promotion, accept a tender, issue a return, create a fiscal transaction, generate a receipt or initiate fulfillment. The human-facing POS screen would then be one consumer of these capabilities, while an associate assistant, a self-checkout interface, an e-commerce journey or an external shopping agent could be another.
This is no longer a theoretical direction. OpenAI and Stripe introduced the Agentic Commerce Protocol in 2025 to let AI agents interact programmatically with merchant commerce systems, while Google introduced the Universal Commerce Protocol in 2026 as a common language for platforms, agents and businesses from discovery through checkout and beyond. Google’s specification is deliberately designed to work with existing retail infrastructure and can expose capabilities through APIs, Agent2Agent and the Model Context Protocol. At a lower technical level, function calling and MCP already provide general mechanisms for models to invoke external tools rather than trying to perform every task inside the model itself.[8][9][10][11]
For me, this is where the architectural discussion becomes much more interesting. Once capabilities are defined through stable contracts and clear semantics, the physical implementation behind them can change without forcing every consumer to change with it. A retailer may decide that pricing belongs inside a modular application, that inventory availability is a remote service, that payment is provided by an external platform and that fiscalization must run locally in one country but centrally in another. The agent does not need to know whether each capability is a microservice, a module inside a larger executable or a third-party system; it needs to know what the capability does, what inputs it accepts, what state it can change and what evidence comes back.
That changes the architecture question from “How many services should the POS have?” to something much more durable: “What are the retail capabilities, what are their contracts, and which system has the authority to execute each one?” The implementation can then become more or less distributed over time without changing the conceptual model of the retail transaction. In my view, this has a better chance of breaking the old pendulum because logical modularity no longer has to be identical to physical distribution.
The AI cannot become the transaction authority
There is, however, a third conflict that is even more important. If AI becomes the orchestration layer, it becomes tempting to let the model decide too much, and that is precisely where an AI-native architecture can become dangerous. NIST’s Generative AI Profile explicitly identifies confabulation as a risk, describing cases in which generative systems can confidently produce erroneous or false content, which is particularly relevant in consequential decisions. Retail transactions contain many areas where “probably correct” is not a sufficient technical standard, especially when money, payment authorization, tax, fiscalization, accounting records or legally required documents are involved.[12]
The architecture therefore needs a strong separation between intelligence and authority. The AI can understand intent, interpret language, choose the next appropriate capability and coordinate a process, but deterministic systems must still validate the transaction, enforce business rules and legal constraints, authorize money movement and produce the evidence required later. This is already visible in the direction taken by payment networks: Mastercard’s Agent Pay emphasizes registered agents, tokenized credentials, verified user intent and traceability, and in May 2026 Mastercard announced what it described as Germany’s first live authenticated agentic transaction, where an AI agent completed a booking and payment under an explicit mandate and with full traceability.
I believe compliance will become one of the most important examples of this separation. An agent should be able to understand that a transaction needs to be fiscalized or that an invoice is required, but the legal decision should not depend on whether the language model happens to remember the rule correctly. The relevant requirements, country logic, versions, validations and evidence need to exist in structured and governed form, so that the AI can call them as authoritative capabilities rather than improvise them. In such an architecture, AI makes the system easier to use and more adaptive, while the deterministic policy layer keeps the transaction explainable and auditable.
AI may make the old architecture argument less important
My conclusion after watching this architectural cycle for so long is therefore not that monoliths were wrong or that microservices were wrong. Both are implementation strategies with real strengths and real costs, and both can be designed well or badly. The more important mistake was treating the physical decomposition of software as if it automatically created good boundaries.
AI gives POS vendors a chance to rethink those boundaries from a completely different starting point. If AI is added as one more module to an already difficult architecture, we will probably continue the same cycle and simply add another layer of complexity. If, however, the POS is redesigned as a set of machine-understandable and governable retail capabilities, with AI handling intent and orchestration while deterministic services retain authority for transaction logic, payments and compliance, then the architecture can become flexible without requiring every function to become an independently deployed microservice.
The future POS may therefore be less recognizable as a single application. It may become a retail capability platform that can be used by a cashier, a mobile associate, a self-checkout, an e-commerce channel or an AI agent, all working with the same underlying commercial rules and the same evidence. That would not eliminate architectural complexity, because retail will never become simple, but it could finally place the complexity where it belongs and make the old swing between one big solution and hundreds of small components far less relevant.
For me, that is the real opportunity created by AI in POS architecture: not another intelligent feature inside the existing system, but a reason to redefine what the system itself actually is.
Sources and references
All factual claims in the article were checked against the sources below. Vendor sources are used to verify their own products, protocols and technical documentation; architectural conclusions and future-looking statements are the author’s analysis. Accessed 20 September 2026.
[1] Martin Fowler, “Microservice Trade-Offs,” 1 July 2015. https://martinfowler.com/articles/microservice-trade-offs.html
[2] Microsoft Azure Architecture Center, “Microservices architecture style,” updated 11 July 2025. https://learn.microsoft.com/en-us/azure/architecture/microservices/
[3] AWS Well-Architected Framework, “REL03-BP01 Choose how to segment your workload,” including the warning about a highly interdependent “microservice Death Star.” https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_service_architecture_monolith_soa_microservice.html
[4] Oracle, “Retail Xstore Office Cloud Service 26.1.301.0 – Get Started,” describing Xstore’s flexible store deployment model and central cloud services. https://docs.oracle.com/en/industries/retail/retail-xstore-cloud/26.1.301.0/
[5] Oracle, “Omnichannel Order Maintenance,” Xstore Point of Service 25.0, describing integration with Order Orchestration Cloud Service and cross-channel inventory. https://docs.oracle.com/en/industries/retail/retail-xstore-point-of-service/25.0/rpxmo/order-options.htm
[6] GS1, “2D Barcodes at Retail Point-of-Sale Implementation Guideline,” version 1.1.0, 22 December 2025. https://ref.gs1.org/guidelines/2d-in-retail/
[7] Salesforce, “Salesforce Releases Agentforce Commerce,” 24 June 2026; and “Salesforce Unveils Agentforce for Retail, Retail Cloud POS,” 10 January 2025. https://www.salesforce.com/news/stories/agentforce-commerce-announcement/
[8] OpenAI, “Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol,” 29 September 2025. https://openai.com/index/buy-it-in-chatgpt/
[9] Stripe, “Developing an open standard for agentic commerce,” 29 September 2025. https://stripe.com/blog/developing-an-open-standard-for-agentic-commerce
[10] Google Developers, “Under the Hood: Universal Commerce Protocol (UCP),” 11 January 2026. https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/
[11] Anthropic, “Model Context Protocol (MCP),” documentation; and Google Developers, “Announcing the Agent2Agent Protocol,” 9 April 2025. https://docs.anthropic.com/en/docs/mcp
[12] NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile,” NIST AI 600-1, 26 July 2024, updated 8 April 2026. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
[13] Mastercard, “Mastercard Agent Pay,” describing registered agents, network tokens and verifiable intent for agentic payments. https://www.mastercard.com/us/en/business/artificial-intelligence/mastercard-agent-pay.html
[14] Mastercard Newsroom, “Deutschlands erste agentische Transaktion,” 13 May 2026. https://www.mastercard.com/news/europe/de-de/newsroom/pressemitteilungen/de-de/2026/deutschlands-erste-agentische-transaktion/
