Five Agents, One Orchestrator, 70 Percent Less Routine Work

In a demo, an AI agent quickly looks confident. It gets a task, accesses information, takes actions and delivers exactly the result you want to see. A proof of concept can also show convincingly that an idea works technically. Whether it becomes a reliable working system in enterprise operations is still an open question.

There the model meets grown processes, permission logic, legacy landscapes, compliance requirements and countless undocumented exceptions that still apply every day. This friction decides whether an agent becomes productive or disappears into a drawer after the pilot.

So before asking which agent to deploy, a more uncomfortable question has to be answered: what specific work should an AI system take on, under which conditions, with what knowledge behind it and with what responsibility? For us, “AI agent” is the umbrella category. Depending on the process, it becomes a single agent, a multi-agent system or a combination of AI, conventional software and human approvals. The architecture follows the process.

Why an LLM is not yet an enterprise agent

A common mistake in AI initiatives is the reflex to add a language model to an existing application and call the result an agent. A document goes to an LLM, the model returns a summary, perhaps with a RAG layer and a few API calls. For a proof of concept that is often enough. An enterprise system, however, has to handle reality reliably every day: varied inputs, changing responsibilities, exceptions and dependencies on other systems.

A production agent therefore has to recognise which information is relevant, which step comes next, which component is responsible, which data it may use and when a human takes over. On top of that come questions that rarely surface in demos:

• How is the state of a case maintained across several steps?
• What happens when a system is unavailable or an agent cannot solve a task reliably?
• How are permissions enforced?
• How can you trace why the system made a particular decision?

The LLM is only one of several components. What separates a simple GPT wrapper from a tailored agent architecture is the system logic around the model: orchestration, responsibilities, control mechanisms and handovers to other systems or people. An enterprise agent above all has to work reliably, traceably and controllably. That is a different design task from optimising model output.

Process analysis before prompt engineering

Our first step is therefore a thorough analysis of the process. What actually happens day to day? Who gathers which information, which systems get opened, and who decides at which point? What is documented, and what exists only as the experience of individual employees? And above all: which parts can sensibly be automated with a probabilistic system, and which are better kept in deterministic logic?

That last point is often underestimated, because not every process step needs an LLM:

The architecture emerges from this split. Only once it is clear which tool does which task best can you decide where an agent is needed, where conventional software is enough and where a person carries responsibility. The question then becomes: how do I model this work process as a system in which people, software and AI work together sensibly? A single agent can use several tools, and a complex process can require several specialised agents. What matters is that the architecture maps the process reliably and responsibilities are clear. Our How we work page describes how we approach this analysis.

A real example: five agents for one business process

RPP Group works at the intersection of policy, politics and communication. Access to a powerful LLM was never the problem. The real problem: highly qualified analysts spent a lot of time on predictable, recurring work such as analysing extensive documents, structuring policy information and preparing communication material. These tasks require domain understanding and still follow recurring patterns, which made them good candidates for systematic automation.

Policy documents often run to a hundred pages or more. Content has to be extracted, structured, cross-checked and put into a communicable context. On top of that came a hard constraint that rules out many standard solutions: confidential political documents must not be processed on an arbitrary external cloud.

A single chatbot could only have covered part of this. Together with Policy-Insider.AI, we built ChatRPP, a multi-agent system with five specialised agents, an orchestrator and RPP Group’s existing infrastructure. The number five came from the division of labour. The orchestrator routes each request to the right specialist, for document analysis, drafting, strategic planning or policy research, and provides the context and tools needed. Dedicated QA agents check the results against internal standards.

Why specialisation matters in multi-agent systems

The more complex a process, the more carefully you should check whether a single universal agent is the right architecture. A system that analyses documents, searches the web, interprets internal data, drafts content, follows compliance rules and checks results can technically be built as one agent. When the tasks need different contexts, tools, permissions or controls, splitting them across specialised agents is often the better choice. Multi-agent is one possible architecture decision among several.

Specialised agents separate tasks and responsibilities cleanly. The orchestrator coordinates, the specialists handle clearly defined steps, data sources are connected in a controlled way, and interim results can be checked, supplemented or discarded along the way. Quality is then measured less by a single LLM’s benchmark score and more by how robustly the whole chain of routing, retrieval, processing, generation and control holds up in daily production.

For ChatRPP we combined multi-agent orchestration, several LLMs, RAG, document processing and conventional Python logic, integrated the specialist service Policy-Insider.AI and ran everything in GDPR-compliant infrastructure. What runs in production is a custom AI architecture in which specialised agents work together with conventional software, data sources and governance. Our article on multi-agent systems covers architecture patterns, protocols and governance in more depth.

The data question belongs in the architecture

In demos, integration is often presented as a convenience: the agent connects to Slack, CRM, calendar and document storage. In the enterprise, access is almost always a governance question. What may an agent read? Which information may it link across system boundaries? What may it change itself, and what does it put to a person for approval? And how is it logged who triggered what and when, so that a result is still traceable weeks later?

These questions belong in the design from the start. Agents work within defined permissions, pause on sensitive actions, wait for approvals and, when in doubt, do too little rather than too much. A generic governance model rarely suffices: an agent drafting a blog post needs different approval logic from one working with confidential financial data or changing records in a production system. Custom architecture therefore also means custom governance.

Legacy integration is the real architecture test

Demos work best where every system has clean APIs. In the enterprise, data sits in many applications, some modern and documented, others grown over ten or fifteen years and understood by only a handful of people in-house. Permission models rarely match, and a good share of process work still runs through emails, Excel attachments and manual handovers. These seams show whether an agent really takes over work.

A custom solution therefore has to settle far more than the model’s output:

• Which system is the leading source for which information?
• When must information be retrieved live, and when may it be cached?
• How is the state of a multi-step process maintained?
• What happens with contradictory data or a failed tool call, and which steps can be rolled back?
• Where is a person involved, and which actions must be auditable?

These are classic architecture questions. What is new is that they now arise inside probabilistic systems whose behaviour can no longer be captured fully in a truth table. In AI engineering it is therefore not enough to connect interfaces. You also have to define how a system deals with uncertainty, errors and decisions. Our article integrating AI into SAP, Microsoft 365 and Jira shows what the connection looks like in practice.

The business value lies in capacity gained

At RPP Group the goal was never to shine with especially impressive answers. Senior analysts were to be relieved of work that eats time without needing their expertise. The case study puts this at around 70% less time spent on routine manual tasks, and the results flow straight into the analysts’ daily workflows.

That is a different metric from the LLM benchmarks the trade press likes to quote. Whether a model scores two points higher or lower on MMLU is secondary for a CTO. It gets interesting when a real business process changes structurally. Less routine means capacity gained, and RPP Group now invests it in strategic, client-facing work.

Custom means choosing the right level of abstraction

“Custom AI” is sometimes taken to mean training a separate foundation model for every company. Our approach means something else: the freedom to choose the right level of abstraction for each problem. The base model can come from an external provider, RAG is often the pragmatic choice, existing APIs stay in service, and ready-made components for document processing or orchestration are used when they fit. The solution becomes custom where these building blocks are assembled into a system that maps exactly the processes that matter in-house.

The engineering work therefore lies in process design, system architecture, orchestration, data access, state management, governance, integration into the IT landscape and, often most underestimated, evaluation. That is why process analysis is a step of its own. It decides what should be built, and in many cases also what is not worth building.

From feature to infrastructure

When companies embed custom AI systems into real processes, a new layer emerges between people and enterprise software. ERP, CRM, DMS, collaboration tools and databases keep running, and above them a process layer moves information between these systems and coordinates tasks across applications.

Standardised agents are a good choice for many generic tasks. When company-specific knowledge, proprietary processes, sensitive data and a grown system landscape come together, a custom-designed solution becomes the lever. Not every process needs five agents for that, and some need none at all:

• Some things stay deterministic, because a probabilistic system adds nothing there.
• Others benefit from a single, clearly bounded AI step in an otherwise conventional application.
• Still other processes only reach their potential when several specialised agents work together under an orchestrator.

The key skill is judging honestly, for each process, which of these architectures brings the company the most. That is exactly how every engagement with theBlue.ai begins: with an analysis of how the work really runs, which decisions are made, which systems are involved and where human expertise remains indispensable. More on our multi-agent development page.

Frequently asked questions