From spaghetti architecture to agentic AI: The patterns worth knowing

At a project meeting, the business team wants a simple outcome: When a customer places an order, it should reach billing and the warehouse without anyone rekeying it. The technology team starts talking about gateways, brokers, events and application programming interfaces (APIs).

It may not sound like it, but they’re talking about the same problem.

When business and technology teams share a common language, these conversations are far more effective (and not as long!). Requirements don’t get lost in translation, and architecture decisions are always connected to the business problems they’re meant to solve.

Our guide, Building systems that last: The pattern language of the connected enterprise, explores integration, cloud and agentic AI, using Salesforce and MuleSoft to show how these ideas work in practice.

And you don’t need to be a software architect to read — or understand — it.

• ALSO READ: NTT DATA’s Salesforce Agentic Enterprise Report

A 50-year-old idea that still works

Software architects have an advantage when discussing complicated problems: patterns.

A pattern is simply a named problem, a proven solution and an honest account of the trade-offs. Once everyone knows the pattern, a few words can replace pages of explanation.

The idea goes back to building architect Christopher Alexander, whose 1977 book A Pattern Language documented recurring design problems and their solutions. Software engineers subsequently adopted the approach, and the catalog has continued to expand through object-oriented programming, enterprise integration and cloud computing.

Now it’s expanding again for agentic AI, and our guide follows that journey.

6 systems, 15 connections — and a decade of regret

Here’s a familiar scenario for many large organizations: You buy a customer relationship management (CRM) system, then an enterprise resource planning platform, then a warehouse system. Then you acquire another company with its own billing platform. Each new system needs to talk to the ones already there. A decade later, you have hundreds of integrations — some poorly documented and others written by employees who left years ago.

Changing one system means finding out what else might break. That’s integration debt. Keep adding point-to-point connections and you eventually get what architects call spaghetti architecture. With six systems talking directly to one another, you may already have 15 connections. With 20 systems, that number shoots up to 190.

Messaging patterns were developed to solve exactly this problem, and the guide shows how they appear in platforms such as MuleSoft today. But there’s a catch: Using patterns doesn’t automatically give you good architecture.

Every pattern solves something and costs something. Great architects use the fewest patterns necessary and can explain why each one is there.

Then along came the agents

Now imagine deploying a customer-service AI agent to resolve billing disputes. It checks the CRM, gets an ambiguous answer and checks again — and again. Hours later, it has burned through API calls and budget without resolving anything.

That’s not really autonomy. As the guide puts it: “An agent without a stopping condition is unattended, not autonomous.”

This is where the emerging patterns for agents come in: tool use, reflection, planning, human checkpoints, and limits on iterations, spending and time. They also force you to answer some distinctly nontechnical questions: Who pays when the agent gets something wrong? Can you audit what it did? What stops it?

Every architectural choice is ultimately a business choice.

Learn the language behind the decisions

Our guide takes you from the origins of patterns and enterprise integration to cloud resilience and the emerging architecture of agentic AI. Along the way, it explains ideas such as circuit breakers, messaging, sagas, API gateways and human-in-the-loop design without assuming you have a technical background.

If you recognize your own organization in the spaghetti integrations, distributed monoliths or agents that don’t know when to stop, that’s a good place to start.

This isn’t about memorizing impressive-sounding architecture terms. It’s about asking better questions. And once you can name a problem, you can have a much better conversation about how to solve it.

• ALSO READ: Why winning with Agentforce depends on how you operate, not what you buy

What to do next

Download Building systems that last: The pattern language of the connected enterprise and start speaking the same language as the people designing the systems your business depends on.