Multi agent architectures: why infrastructure matters more than the model

An agent answers. A team of agents works. Between these two sentences lies the most important shift enterprise AI is making these days: from chatbot to process.

They're called multi-agent architectures: systems in which several specialized agents coordinate to complete a task, each with its own role, its own knowledge and its own rules. This isn't a lab topic. According to Gartner, enterprise inquiries about multi-agent systems grew by 1,445% in just over a year, and Gartner itself warns that more than 40% of agentic AI projects will be canceled by 2027 due to spiraling costs and unclear value ("Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027", Gartner, https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027).

The two figures together tell the whole story: demand is exploding, yet most projects fail. And they almost always fail for the same reason. Not the model. The lack of infrastructure.

What multi-agent architectures are, without the jargon

Picture an office. Someone greets requests, someone knows the price lists, someone checks the regulations, someone signs off. None of them alone "is" the office: the office is the organization that holds them together. Multi-agent architectures apply the same principle to AI agents. Technical literature has given names to the recurring patterns: the supervisor that receives a request and routes it to the right specialist, the chain in which each agent works on the output of the previous one, the agentic loop in which an agent executes, evaluates the result, corrects and starts again. Even the labs that develop the models use these patterns for their own products: Anthropic described how its research system is built precisely on an orchestrator that coordinates specialized sub-agents ("How we built our multi-agent research system", Anthropic, https://www.anthropic.com/engineering/multi-agent-research-system).

For a company, the difference is between buying an intelligence and organizing a team. And a team can be designed.

The three architectures you can build on AIsuru

On AIsuru, multi-agent architectures are built without writing code. Three types, in order of increasing complexity.

1. Board of Experts: the group chat with agents

You create a "room" agent, invite the already-built experts into it, and the room decides on its own which expert should answer each question. Anyone can build it, in just a few minutes.

A few concrete examples. A single customer desk that routes between the product expert, administration and technical support: the customer asks just one question, and the room figures out whether it's about an invoice or an installation. An internal committee for company policies, where the HR expert, the legal expert and the security expert coexist: an employee asks "can I work from abroad for two weeks?" and whoever needs to answer, answers. A training tutor that coordinates the digital instructors for the different subjects of a course: the student talks to a single interlocutor, but behind the scenes the right instructor handles each topic. A virtual tender office in which the technical, financial and legal experts each contribute their own section of the specification.

The point isn't spectacle: it's that each expert keeps its own knowledge separate, its own tone and its own rules, and the room governs them.

2. Agent calling agent: knowledge no human ever queries

Guide to using the MCP connector «Aisuru MCP Server» on AIsuru.

Through AIsuru's MCP server, a more advanced user can describe another agent's configuration variables in the prompt and make the two talk to each other: one becomes the other's source of knowledge.

Why do this instead of putting all the knowledge into a single agent? For governance. There is knowledge that must never be exposed directly to a human, but only to another AI with stricter rules. The confidential price list that the public sales agent consults to build a proposal, without any visitor ever being able to query it directly. The internal procedures archive that answers only the quality agent, with the obligation to always cite the document's revision. The "master" knowledge maintained in a single language, which feeds the customer agents in all other languages: you update one point, it's distributed everywhere. The complete technical dossier that the first-line agent can only consult in excerpts, while the full version stays behind a rule.

It's the same logic as permissions in information systems, applied to knowledge: not everything needed for the answer has to be readable by whoever asks the question.

3. Agents as MCP servers: the agentic loop with rules

The third architecture is the one that opens the door to truly complex systems. An AIsuru agent can be exposed as an MCP server: at that point it can be used as a tool by other agents, and can in turn coordinate other agents. Including itself.

This is where the agentic loop comes in: execute, evaluate, correct, start again. An agent that rereads its own conversations, spots the questions that went unanswered, and proposes the missing content. A tester agent that every week queries the other agents in the tenant with a battery of test questions and flags where answers are getting worse. A coordinator that receives a goal ("prepare the monthly report on Northeast customers"), uses the team's agents as tools, assembles the result and delivers it. A reviewer that compares the answers given against official documentation and proposes prompt corrections for agents that are drifting.

Literature calls this family of behaviors self-improvement: systems that improve content, functions and instructions based on their own results. And this is exactly the point where the question of governance stops being theoretical: an agent that can modify other agents is extremely powerful and must be chained to rules. On AIsuru, the loop happens within the same infrastructure as always: credentials stay in the vault, every step is tracked, changes are proposed, and the final word remains with a person.

Why infrastructure matters more than the model (even with open models)

There's a misconception that dooms many projects: believing that the accuracy of answers depends on the model. The model matters, of course. But in a well-built multi-agent system, accuracy comes mainly from what surrounds the model.

It comes from curated knowledge: the agent answers based on approved, versioned documents, not on everything it read on the internet. It comes from deterministic functions: the price is given by the ERP, availability by the warehouse system, the date by the calendar; the model orchestrates the sentence, it doesn't make up the number. It comes from guardrails: boundaries of topic, tone and format that apply to the agent and are inherited by the whole team. It comes from routing: the simple task goes to the small, cheap model, the complex one to the large model, and the choice is an infrastructure rule, not chance. It comes from continuous testing: the agent that tests the other agents is preventive quality maintenance. And it comes from traceability: when every step is logged, an error can be found, explained and fixed, instead of silently repeating itself.

This is why well-made infrastructure makes even open models accurate. For many organizations, open models are a strategic choice: cost control, execution in Europe or on-premise, data sovereignty. Their historical limitation, being less brilliant "on their own", is offset precisely by the architecture: the right knowledge in the right context, data coming from systems rather than the model's memory, tasks broken into small steps that even a mid-tier model handles well, downstream verification. In a governed multi-agent architecture, the model becomes a replaceable component: you swap it out when a better or cheaper one comes along, without rebuilding anything. The model passes. The infrastructure stays.

And the numbers show the difference is measurable: organizations that pair agents with structured governance and evaluation practices are up to 12 times more likely to deliver real value ("State of AI Agents", Databricks, https://www.databricks.com/resources/ebook/state-of-ai-agents). Governance isn't the project's brake: it's the reason the project reaches production.

ISO/IEC 42001: why a certification changes vendor choice

This is where we come in. Memori is certified ISO/IEC 42001, the first international standard for AI management systems ("ISO/IEC 42001:2023, Artificial intelligence management system", ISO, https://www.iso.org/standard/81230.html). It's not a badge to collect: it's a management system verified by a third-party body, covering the entire AI lifecycle, from risk and impact assessment to role definition, from monitoring to continuous improvement. And like every real certification, it has to be passed again every year.

Why does it matter specifically for multi-agent architectures? Because every additional agent is more surface area: more knowledge to oversee, more connections to systems, more points where something can go wrong. A vendor can claim to have processes to manage all this; an ISO/IEC 42001-certified vendor has proven it to an external auditor, with evidence, and will keep proving it. And when the architecture includes the agentic loop (that is, agents proposing changes to other agents) the difference between "trust me" and "verified" becomes the difference between a risk and a system.

In our case, ISO/IEC 42001 doesn't stand alone: it adds to certifications on information security and the cloud (ISO/IEC 27001, 27017, 27018), to ISO 9001 on quality, and to NIS2 compliance. It's a combination that very few agentic platform vendors can put on the table, and it's what allows us to say, with arguments rather than slogans, that we are the reference partner for building governed multi-agent architectures: because for us governance isn't an add-on module or a commercial promise, it's how the platform is built and how the company that produces it is run, certified by third parties. Whoever chooses the vendor of a multi-agent system isn't buying brilliant answers: they're entrusting someone with the keys to their own processes. And keys are entrusted to those who can prove how they safeguard them.

Where to start

The sensible path doesn't start from the most complex architecture. It starts from a real process: you pick two or three experts covering real questions, put them in a Board of Experts, and measure. Then you separate confidential knowledge with an agent that only AI's can query. And once the team works, you add the supervisor that keeps it in shape. At every step, the same rules: approved knowledge, credentials in the vault, everything tracked, the final word left to a person.

AI chats are used. Architectures are designed. And they're designed better on an infrastructure built to connect and to govern, not just to chat.

Sources cited in this article