AI agent architecture: building blocks, multi-agent orchestration, events and governance

Most early generative AI projects in business were assistants that answer questions. They are useful, but they have two clear limits: they only act when someone writes to them, and their memory is restricted to what fits in the conversation. An AI agent goes further: it reasons about a goal, plans the steps, consults the organisation's information and carries out actions in other systems. Once several agents work together, the architecture matters as much as the model.

This article covers the design decisions that determine whether an agent system will be maintainable and scalable, or a prototype that never makes it into production.

The four building blocks of an agent

An agent orchestrates four elements:

Block	What it provides	Example
Reasoning model	Interprets intent, makes decisions and plans the sequence of actions	A general-purpose language model
Instructions	Define the specialism, tone, limits and what to do when in doubt	"Payroll agent", "regulatory compliance agent"
Knowledge	Conversation memory and access to internal documentation through semantic search (RAG)	Internal policies, procedures, collective agreements
Tools	Connectors to query and change real systems	ERP, CRM, HR system

The last block carries the most risk: as soon as an agent can change the state of a system (create an order, amend a contract, send an email), it stops being an experiment and becomes an application with consequences. That is why each agent should have a small, well-defined set of tools.

Multi-agent systems: specialise and coordinate

A single agent that knows everything and can do everything is hard to test and hard to fix. The alternative is to decompose by domain: in HR, for example, one agent for annual leave, another for payroll and another for onboarding, each with its own instructions, knowledge and permissions.

Above them, an orchestrator agent receives the request, works out which agents need to take part, in what order and with what dependencies, and assembles the final answer. There are two ways to orchestrate:

• Sequential: the flow is defined in advance. This is the right choice for processes with mandatory steps and compliance requirements, such as onboarding in a regulated sector or a financial review.
• Autonomous: the model decides the flow as it goes, based on context and on each agent's partial results. It is more flexible but less predictable, and it demands more traceability and more testing.

In practice, many systems combine both: a sequential backbone for whatever must always happen, and autonomous stretches where variability is acceptable.

Event-driven architecture: genuine autonomy

If an agent only acts when someone writes to it, it is still reactive. Real autonomy comes when it reacts to what happens in the business: an invoice is issued, an email reaches a mailbox, stock of an item falls or a deadline expires. Event-driven architecture (EDA) provides that capability.

Three advantages make it almost essential for agent systems:

1. Automatic triggers. Agents subscribe to events and act without human intervention: preparing a payment reminder, opening a ticket or raising an alert.
2. Real-time response. The agent acts when the event occurs, not when someone checks an inbox.
3. Resilience. Because components are decoupled, one agent failing does not bring the whole system down: the event waits in the queue and is processed once the component recovers.

Interoperability protocols: MCP and A2A

Two standards are bringing order to an ecosystem that until recently was a collection of bespoke integrations:

• MCP (Model Context Protocol): a common layer for offering tools and context to any agent. A tool published via MCP can be reused by agents built on different platforms.
• A2A (Agent-to-Agent): an emerging standard for secure communication between agents built on different platforms and in different languages.

Adopting them from the outset reduces dependence on a single vendor and avoids rebuilding integrations every time the model or platform changes.

Governance, security and monitoring

An agent in production needs the same rigour as any critical application, plus some specific controls:

• A dedicated identity per agent. Each agent is registered with the identity provider with least-privilege access to data and APIs, and its actions are logged under its own name. Major providers such as Microsoft Entra already offer identities designed for agents.
• Human in the loop. Non-standard or high-risk decisions (approving credit, changing a contract, any irreversible action) require explicit human approval.
• Compliance enforced at platform level. Information protection policies and the obligations of the GDPR and the EU AI Act are applied centrally, not agent by agent.
• End-to-end traceability. Every step (orchestrator, agent, tool, response) is recorded with observability tools such as OpenTelemetry or Azure Monitor. Without that trail, debugging an error or answering an audit is almost impossible.
• Continuous evaluation. Because responses are not deterministic, faithfulness to sources and content safety are tested automatically and regularly, not just at go-live.

Choosing a platform

There is no one-size-fits-all answer. The choice balances development speed, technical control and integration with what is already in place:

Platform	Development	Integration	Deployment	Best suited to
Copilot Studio	Low-code, visual	Microsoft 365 and Power Platform	Managed cloud	Rapid prototypes and flows built by business users
Microsoft Foundry (formerly Azure AI Foundry)	Pro-code (Python, C#)	Azure ecosystem	Containers, Kubernetes	Critical systems with compliance requirements
n8n	Low-code, visual	Vendor-neutral, with MCP support	Cloud or self-hosted	Complex integrations and portability
LangChain, LlamaIndex	Python libraries	Generic APIs	Containers, Kubernetes	Experimentation and open models

A dual architecture for Microsoft environments

In organisations already working with Microsoft, a combination that works well is:

1. In front, Copilot Studio, as the conversational face and high-level orchestration. Business users can build and adjust flows without coding.
2. Behind, Microsoft Foundry, as the engine for the complex work: advanced RAG, fine-tuned models, evaluation and controlled deployment.
3. For custom-built agents, an SDK such as Semantic Kernel (now part of Microsoft Agent Framework), model-agnostic and supporting the open protocols.

The principle is simple: the front layer handles the user experience; the back layer guarantees security, scalability and compliance for critical operations.

Six checks before production

If a system fails any of them, its maintainability in the medium term is at risk:

1. Modularity: does each agent have a single role and a limited set of tools?
2. Decoupled infrastructure: does it use events, and can it scale horizontally with containers as triggers and demand grow?
3. Standard protocols: does communication between agents and tools use MCP or A2A?
4. Identity and access: does each agent have its own identity with least-privilege access to data and APIs?
5. Traceability: is every step of the orchestrator and the agents recorded?
6. Automated evaluation: are there regular tests of faithfulness and content safety?

Where to start

Success depends less on technology than on applying a handful of principles with discipline: modularity, governance, observability and compliance. A sensible path:

1. Pick one or two use cases with clear value and controlled risk.
2. Define identities, permissions and human approval points from the start.
3. Build a proof of concept in a controlled environment, with traceability from day one.
4. Scale gradually, with quality metrics that are reviewed continuously.

At Bidatia we help design this kind of architecture and take it into production with the right controls in place.