Production AI Agent Orchestration: Security and Performance

Orchestrating AI Agents: From a Standalone Agent to a Manageable Multi-Agent System

Before you go any further, if you are starting from scratch, begin by creating an AI agent to define the role, the data, and the guardrails.

Once that foundation is in place, orchestrating ai agents becomes the real lever when you need to chain together varied tasks, connect to tools, and meet non-negotiable requirements around quality, security, and traceability.

Do Not Confuse These: Agent, Tool, Workflow, AI Agent Orchestration, and Orchestrator

An agent is an autonomous component that pursues a goal and can decide on actions (often via tool calls). A tool is a non-autonomous capability (API, function, query, export) that the agent invokes. A workflow is a sequence of tasks, typically repeatable, with inputs, outputs, and stopping rules.

Orchestrating ai agents coordinates multiple specialised agents within a unified system so you can achieve complex objectives more effectively than with a single AI, by triggering the right agent at the right time and synchronising their exchanges (IBM). The orchestrator is the layer that runs this steering: either a central agent, or a more distributed mechanism where agents coordinate with one another (IBM).

Why Coordination Becomes a Problem as Soon as Tasks Get Complex (Quality, Cost, Lead Times)

As soon as a single agent accumulates too many tools, too many sources, or too many rules, you create complexity that is hard to test and debug. Microsoft recommends using the lowest level of complexity that reliably meets the need, because each additional layer adds coordination overhead, latency, and cost.

Coordination becomes essential when you need to parallelise work, isolate permissions, or apply structured quality control. It is also a way to reduce the inefficiencies of siloed agents scattered across apps and infrastructure (IBM). And when work is multi-faceted, breaking it into sub-tasks handled by specialists helps limit answers that are "plausible but shallow" (Algos).

Multi-Agent System Architecture: Patterns That Hold Up in Production

In production, you do not choose a multi-agent architecture on instinct. You justify it based on reliability, security, maintainability, and latency constraints. IBM notably distinguishes centralised, decentralised, hierarchical, and federated orchestration patterns, often combined depending on context. Microsoft also proposes practical patterns (sequential, parallel, group chat, handoff) aligned to coordination requirements.

Sequential Orchestration: Pipelines, Validation, and Dependencies

The sequential pattern chains agents in a predefined order: each output becomes the next step’s input (Microsoft). It fits when dependencies are linear, incremental refinement is needed, and you accept that a delay in one step delays the whole flow.

• Typical use cases: draft → review → compliance → formatting; or extraction → normalisation → enrichment.
• Critical risk: avoid "error amplification" if an upstream step produces a weak output without guardrails (Microsoft).
• Good practice: add explicit validations (schema, constraints, checklists) before handing off.

Parallel Orchestration: Parallelisation, Aggregation, and Arbitration

The parallel model runs multiple agents at the same time on the same request (fan-out/fan-in) to speed up execution and broaden perspectives (Microsoft). It is particularly useful when analyses are independent and easy to aggregate.

For aggregation, Microsoft mentions straightforward approaches such as voting, weighted merging, or synthesis via a language model. The goal is not to aggregate "more", but to aggregate "better": the orchestrator must know what to call, when to stop, and how to resolve contradictions.

Hierarchical Orchestration: Supervisor, Sub-Agents, and Controlled Task Planning and Delegation

In a hierarchical setup, a supervisor defines strategy and delegates to specialised sub-agents (IBM). You retain strong control whilst keeping autonomy in execution. The downside is a hierarchy that is too rigid, reducing adaptability as the context evolves (IBM).

1. The supervisor interprets the objective and sets constraints (quality, security, budget).
2. It assigns sub-tasks to "business" or "technical" agents as required (IBM).
3. It consolidates, validates, then decides whether to iterate or escalate.

Debate and Consensus Orchestration: Reducing the Risk of "Plausible" Errors

The "group chat" pattern puts multiple agents into a shared thread and drives a solution through structured discussion (Microsoft). It is well suited to validation and quality control, especially with a maker-checker loop (creator-checker) using acceptance criteria and iteration limits.

Microsoft recommends keeping this format to three agents or fewer to avoid loops and loss of control. This pattern directly addresses a common failure mode: an answer that "sounds right" but collapses under tool-assisted scrutiny. When tasks span multiple domains, specialisation and internal critique reduce that risk (Algos).

Routing, Handoff, and Human Escalation: Choosing the Right Level of Autonomy

Handoff dynamically transfers execution to the most relevant agent, without parallelising (Microsoft). It is useful when you cannot identify the optimal agent upfront, or when the required expertise only emerges mid-process.

• Routing: triage based on signals (request type, risk, available data).
• Handoff: full transfer of control to a specialist.
• Human escalation: triggered by thresholds (ambiguity, missing data, high-impact action, iteration limit reached).

Task Planning, Delegation, and Coordination: Making Agents Useful (and Predictable)

A high-performing multi-agent system depends less on each agent’s isolated quality than on the intelligence of the coordination mechanism (Algos). The operational goal is simple: assign the right task to the right agent, with the right context, at the right moment (Algos). To get there, treat planning like a product: explicit, testable, and versioned.

Break a Goal Into Atomic Tasks, Then Define Stopping Criteria

Decomposition turns a vague objective into verifiable units of work. IBM describes typical stages where the orchestrator decomposes, assigns, manages dependencies, coordinates execution, then continuously optimises. Without stopping criteria, you create expensive loops and non-repeatable outputs.

Choose the Right Roles: Research, Execution, Quality Control, Synthesis

Robust design separates roles, just like a human team. IBM illustrates specialised agents (billing, troubleshooting, NLP, data retrieval) coordinated towards a shared objective. Algos also formalises the idea of an orchestrator that plans, supervises, and synthesises, supported by a critical agent for validation.

• Research agent: collects and cites sources, flags uncertainty.
• Execution agent: calls tools, applies transformations, respects schemas.
• Quality-control agent: checks compliance, consistency, and constraint coverage.
• Synthesis agent: produces the final output, traceable and structured.

Manage Collisions: Priorities, Locks, Queues, and Action Budgets

Collisions appear as soon as multiple agents can modify the same state (case file, database, content, ticket). If you work in parallel, you must prevent uncontrolled concurrent writes and inconsistent decisions. Deloitte recommends borrowing from modern IT architecture best practices (microservices, governance, distributed traceability) to build resilient multi-agent systems.

1. Priorities: define arbitration rules (criticality, impact, risk).
2. Locks: resource locking (pessimistic) or version control (optimistic).
3. Queues: decouple production and consumption, absorb spikes.
4. Action budgets: cap tool calls, tokens, time, writes.

Communication Between Agents: Protocols, Formats, and Synchronisation

Without a clear protocol, agents work against each other or duplicate effort (IBM). Deloitte highlights the rise of inter-agent protocols and the importance of standardised communication for scalability, low latency, negotiation, and conflict resolution. Even if no universal standard has settled, your system must at least enforce testable exchange contracts.

Messages vs Shared State: Strengths, Limits, and Reliability Implications

Two models dominate: message passing (asynchronous) and shared state (read/write to a shared memory). Messaging decouples components and handles spikes better, but makes consistency harder. Shared state simplifies context continuity, but increases collision and corruption risk unless you version it.

• Messages: robust for fan-out/fan-in, retries, event-based traceability.
• Shared state: useful for working memory, decisions, versioned artefacts.
• Hybrid: often the best compromise (events + a "source of truth").

Interface Contracts: Schemas, Validation, and Backwards Compatibility

Algos stresses interoperability via structured formats (for example JSON schemas) so all agents "speak the same language". In production, this translates into versioned contracts, systematic validation, and compatibility management over time (tolerant additions, stable required fields).

Reducing Noise: Avoid "Over-Chatty" Agents and Loops

Loops form when agents bounce messages back and forth without making progress, or when quality control cannot conclude. Microsoft recommends iteration limits and fallback behaviours (human escalation or returning the best result with a warning) for maker-checker loops. Deloitte also notes the value of inter-agent explanatory messages for auditability, but they must remain proportionate.

• Enforce acceptance criteria and stop thresholds.
• Limit the number of agents in debate (Microsoft: three or fewer).
• Standardise short, structured messages (data, decision, evidence, next step).

Multi-Agent Memory and Context Management: Preventing Information Loss… and Contamination

Multi-agent systems rarely fail because they cannot generate text; they fail because context is mismanaged: lost information, contradictions, or polluted memories. IBM cites data sharing and context management as key steps to avoid redundant work and improve accuracy. Deloitte recommends a structured "context layer" (taxonomies, ontologies, modelling) and optimised agent memory management.

What You Should Store: Facts, Decisions, Sources, Constraints, and Task State

Useful memory is not "everything", but what makes execution reproducible and auditable. Aim for steering artefacts, not a raw transcript. Specifically, store what prevents rework, what justifies decisions, and what blocks dangerous actions.

• Facts: stable data, verified values, identifiers.
• Decisions: trade-offs, rationale, assumptions.
• Sources: origin, date, confidence level.
• Constraints: business rules, compliance, security limits.
• Task state: done, in progress, blocked, escalated.

Short-Term vs Long-Term Memory: Retention Rules and Governance

Short-term memory supports "work in progress" (session context) and should expire quickly. Long-term memory helps you retain validated knowledge (rules, preferences, approved history) and needs strict governance. IBM notes that privacy and regulatory constraints make these choices fundamental, especially when unlimited data sharing is not allowed.

Context Strategies: Summaries, Indexes, Windows, and "Single Sources of Truth"

To prevent contamination, do not push all context to every agent. Prefer decision-oriented summaries, indexes (retrieve rather than repeat), and sliding windows (limit history). Deloitte stresses context modelling as an architectural layer in its own right.

1. Summaries: decisions + constraints + open points.
2. Indexes: point to artefacts rather than copying them.
3. Windows: the minimal context needed for the current step.
4. Single sources of truth: one canonical source per data type (avoid duplicates).

Error Handling and Incident Recovery in Multi-Agent Systems: Designing for Failure

IBM explicitly raises the question of fault tolerance: what happens if an agent (or the orchestrator) fails? In multi-agent systems, failure is normal: timeouts, unavailable tools, missing data, non-compliant outputs. The goal is not "zero incidents", but predictable, traceable recovery at a controlled cost.

Incident Types: Timeouts, Unavailable Tools, Missing Data, Non-Compliant Outputs

Start by classifying incidents; otherwise, you will not know how to alert or escalate. IBM highlights coordination, scalability, and security challenges that increase the range of possible failure modes. Each category needs a recovery strategy and a default behaviour.

• Timeouts: tool latency, overload, chained dependencies.
• Unavailable tools: API errors, quota exhaustion, maintenance windows.
• Missing data: inaccessible source, missing field, insufficient context.
• Non-compliant outputs: invalid schema, hallucination, contradiction.

Idempotency, Retries, and Backoff: Avoiding Costly Thrashing

Retries are essential, but risky without guardrails. Implement idempotency for state-changing actions (same request, same effect) and use progressive backoff to avoid thrashing. Deloitte recommends cloud-inspired approaches (distributed traceability, governance, reliability) that translate well here.

Controlled Degradation: Read-Only Mode, Simplification, and Escalation

When a critical tool fails, aim to deliver partial value rather than crash. IBM mentions failover, redundancy, and self-healing mechanisms to improve continuity. In practice, define degraded modes by criticality.

• Read-only: the agent can analyse and recommend, but triggers no actions.
• Simplification: reduce the number of agents called, disable parallelism.
• Escalation: hand off to a human with a pre-structured case file (state, logs, assumptions).

Observability, Traces, Logs, Monitoring: Seeing What Your Agents Actually Do

Without observability, you cannot explain, audit, or optimise. Deloitte emphasises unified platforms and telemetry dashboards for agents (latency, error rates, resource usage, unusual behaviour). Algos also highlights traceability of the reasoning chain as a governance benefit, useful for audit and troubleshooting.

Trace the Full Path: Prompt, Tools Called, Decisions, Outputs, Sources

Capture everything you need to reconstruct "who did what, when, with which data" (Algos). Deloitte expects inter-agent messages and explanations for traceability and audit, particularly to analyse errors and arbitration. Avoid noise, though: store what you need for proof and diagnosis.

• Normalised input + workflow version.
• Prompts and essential parameters (excluding sensitive data).
• Tools called + results + error codes.
• Routing decisions and rationale.
• Sources consulted (where applicable) and confidence level.

Usable Logs: Structure, Correlation, Redaction, Retention

Usable logs are structured, correlatable, and compliant. Deloitte cites centralised logging and distributed tracing as transferable practices. Think "investigation": you must be able to follow a request end-to-end, even if it passes through multiple agents and tools.

Testing and Continuous Evaluation: Case Sets, Regression, Alert Thresholds

Orchestration should be tested like software: case sets, integration tests, and regression testing. Deloitte recommends realistic tests (incomplete data, conflicting goals, adversarial scenarios) before scaling. IBM also stresses rigorous training and testing processes to limit shared vulnerabilities.

1. Build a corpus of real cases (happy path + edge cases).
2. Version agents, prompts, schemas, and rules.
3. Define alert thresholds (quality, errors, cost, latency).
4. Block deployment if regression exceeds the threshold.

Performance Evaluation for Multi-Agent Systems: Metrics That Matter

If you only measure perceived quality, you will miss the real risks: costs, retries, residual human workload, incidents. Deloitte links orchestration to value-creation indicators (faster decisions, better experiences, accelerated innovation). Algos notes that "intelligent" orchestration can reduce total cost of ownership by up to 70% compared with an unoptimised approach that uses general-purpose models in a brute-force way.

Quality: Accuracy, Completeness, Consistency, Output Stability

Quality is multi-dimensional, not a single score. Separate what comes from data, planning, and generation. Algos describes iterative validation with a critical agent and cites a hallucination rate below 1% for its orchestrator, illustrating the value of quality-control loops (as long as they are bounded).

• Accuracy: factual errors detected by tests.
• Completeness: coverage of requirements and constraints.
• Consistency: no internal contradictions.
• Stability: output variance given identical inputs.

Costs and Productivity: Consumption, Retry Rates, Residual Human Load

Cost is not just compute. It includes investigation time, escalations, and maintenance. Deloitte notes that only 12% of surveyed executives believe initiatives combining automation and AI agents could deliver the expected ROI within three years, versus 45% for basic automation. That makes fine-grained steering non-negotiable. Measure what causes drift: retries, loops, unnecessary tool calls.

Reliability: Failure Rate, Time to Recover, Business Impact

Deloitte cites Gartner: more than 40% of agentic AI projects could be cancelled by 2027 due to unexpected costs, scaling challenges, or unanticipated risks (cited by Deloitte). Reliability should therefore be tracked like an SLO: failure rate, recovery time, and process impact. IBM highlights fault tolerance as an expected benefit via redundancy and reducing the impact of a single agent failing.

Scalability and Latency in Multi-Agent Systems: Handling Load Without Hurting the Experience

Multi-agent setups can speed things up (parallelisation) or slow them down (coordination, aggregation, controls). Deloitte stresses the need for unified, scalable platforms with telemetry (latency, resources, anomalies) to keep cost and performance under control. Microsoft also reminds us that complexity adds latency and failure modes: you must prove the reliability or coverage gain justifies the overhead.

Where Latency Comes From: Tool Calls, Dependencies, Serialisation, Controls

Latency rarely comes from the model alone. It accumulates across API calls, sequential dependencies, and quality controls. In sequential flows, latency stacks step by step (Microsoft). In parallel flows, it is driven by the slowest agent plus aggregation cost.

• External tool calls (network, quotas).
• Hard sequential dependencies.
• Serialising heavy context (overgrown memory).
• Late validation (rework).

Concurrency and Parallelism: Practical Limits and Trade-Offs

Parallelism reduces overall time, but increases shared-state conflict risk and resource consumption. Microsoft also notes resource constraints (model quotas) that can make parallel execution counterproductive. The trade-off is straightforward: parallelise what is independent, sequence what depends, and isolate what writes.

Capacity Planning: Quotas, Caching, Batching, Handling Spikes

To handle load, manage quotas and smooth peaks. Deloitte mentions agent registries for reliable discovery and load balancing, and high-throughput, low-latency asynchronous messaging as a key expectation of protocols. In practice, combine guardrails (budgets) and optimisations (cache, batching) where outputs are reproducible.

1. Quotas: cap calls per agent and per time window.
2. Caches: store stable results (e.g., reference data, metadata).
3. Batching: group homogeneous tasks (when safe).
4. Spike handling: queues + priorities + degraded modes.

Securing Secrets and Managing Agent Access: Permission Control and Risk

In multi-agent systems, the attack surface grows mechanically because you multiply identities, tools, and exchanges. Algos recommends a "Security by Design" approach with encryption, strict identity and access management, and isolation. Deloitte also stresses zero-trust security and the digital identity of agents, as well as embedding compliance (including the AI Act) into orchestration platforms.

Secrets Management: Environment Separation, Rotation, Minimisation

An agent should never carry a hard-coded secret. Minimise, segment, and rotate. Algos cites practices such as encrypted communications (e.g., TLS 1.3), encryption at rest (e.g., AES-256), and anonymisation/pseudonymisation where possible.

• Separation: dev, test, prod with distinct vaults.
• Rotation: short-lived secrets with automated renewal.
• Minimisation: one secret per use case, reduced scopes.

Agent Permission Control: What the Agent Can Read, Write, and Trigger

Apply least privilege: a unique identity per agent, minimal rights, and a read/write split. Deloitte expects authentication, secure messaging, and access control mechanisms in inter-agent protocols. In sensitive contexts, segment distinct safety limits per agent, which is also one reason to move to multi-agent setups (Microsoft).

Risk Reduction: Guardrails, Input Validation, Preventing Dangerous Actions

Guardrails must be both technical and organisational. IBM points to shared vulnerability issues when agents rely on the same foundation models, reinforcing the importance of testing and governance. Deloitte recommends fallback procedures and supervision mechanisms, beyond simply "producing an answer".

• Input validation: schemas, allow-lists, malicious instruction detection.
• Action guardrails: permissions, limits, simulation before write.
• Supervision: human-in-the-loop by criticality (Deloitte).

Integrating With Your IT Stack and Analytics: From Prototype to Business Use

Integrating a multi-agent orchestration layer into an IT environment is not just "plugging in a model". IBM describes a structured approach (evaluation, agent selection, orchestration framework implementation, context sharing, continuous optimisation) where initial design is done by humans, then the orchestrator steers in real time. Deloitte reminds us orchestration is an architectural and organisational decision, not merely an assembly of tools.

Fit Into Existing Building Blocks: APIs, Internal Workflows, Governance

In organisations, robust integration requires stable APIs, versioned connectors, and clear governance. Algos recommends building connectors (APIs) to make each agent, model, and source accessible in a stable and secure way, then testing at unit and integration levels. Deloitte advises drawing on microservices thinking: specialised services, registries, distributed observability, zero-trust security.

1. Map source systems and target systems (read vs write).
2. Standardise API contracts (schemas, errors, quotas).
3. Version workflows, schemas, and agents for reproducibility (Algos).
4. Define responsibilities (who approves, who runs, who arbitrates).

Measuring With Google Analytics and Google Search Console: What You Can Actually Attribute

To measure impact, link agent actions to observable change. Google Search Console helps you track impressions, clicks, CTR, and rankings at query and page level, which is useful for attributing gains after an optimisation. Google Analytics helps connect those pages to behaviour (engagement, conversions) depending on your measurement plan.

The key limitation is perfect attribution: in environments where multiple changes happen at once (content, technical, product), you must document interventions and analyse by time windows and page groups. Observability (correlated logs) then becomes the bridge between "agent action" and "analytics signal".

Operational Run: RACI, Runbooks, Audits, Improvement Cycles

Deloitte stresses accountability and governance: without a clear sponsor, objectives, and ownership, you lose control. Practically, move from prototype to operations with a RACI, incident runbooks, and a continuous improvement loop driven by metrics and tests. IBM also mentions ongoing optimisation, with human supervision to adjust strategy, retrain, or change rules.

• RACI: who owns the workflow, who approves, who operates, who audits.
• Runbooks: procedures for timeouts, quotas, tool errors, escalations.
• Audits: periodic review of permissions, secrets, schemas, logs.
• Improvement: regression checks, alert thresholds, planning adjustments.

A Note on Incremys: Orchestrating SEO & GEO Workflows Without Losing Control

When Industrialisation, Traceability, and Prioritisation Become an Operational Advantage

For marketing teams, the challenge is not simply to "produce", but to industrialise with proof: prioritise, trace, measure, and arbitrate. Incremys fits this logic through a SaaS platform that centralises auditing, planning, large-scale production, and reporting, with personalised AI and collaborative workflows, whilst connecting measurement through Google Analytics and Google Search Console. The aim remains practical: keep control over decisions, approvals, and outcomes, rather than stacking opaque automations.

FAQ: Common Questions About AI Agent Orchestration

What is ai agent orchestration?

It is the coordination of multiple specialised AI agents within a unified system so that shared, complex objectives can be achieved more efficiently than with a single general-purpose agent. It covers agent selection, planning, context flow, synchronisation, and result aggregation (IBM).

Why orchestrate multiple ai agents rather than using a single agent?

Because a single agent quickly becomes too complex to tool, secure, and test once the job is multi-faceted. A multi-agent approach brings specialisation, maintainability, the ability to isolate permissions, and parallel execution where appropriate (Microsoft). IBM also highlights better fault tolerance and better interoperability across heterogeneous ecosystems.

What are the main ai agent orchestration architectures?

You will typically see centralised, decentralised, hierarchical, and federated orchestration (IBM). On execution patterns, Microsoft describes sequential and parallel setups, group conversations (including maker-checker), and transfer (handoff), to be chosen based on dependencies, criticality, and latency constraints.

How do you integrate ai agent orchestration into your IT stack and analytics tools?

Integrate through APIs and versioned connectors, standardise contracts (schemas, errors, quotas), and define clear governance. For measurement, use Google Search Console (impressions, clicks, CTR, rankings) and Google Analytics (behaviour, conversions) by correlating these signals with the orchestrator’s logged actions (logs, trace_id). Document changes to reduce attribution bias when initiatives overlap.

How do you secure traceability and observability for ai agent orchestration?

Centralise structured, correlated logs (by request and by agent), and trace tool calls, routing decisions, outputs, and sources (Algos, Deloitte). Redact sensitive data, define retention policies, and run regression tests. Add alert thresholds (latency, errors, cost, quality) and escalation runbooks.

What are the 4 types of agents in AI?

A classic academic classification often distinguishes: simple reflex agents, model-based reflex agents, goal-based agents, and utility-based agents. In modern systems built on language models, these categories tend to map to degrees of decision-making sophistication and the use of memory, tools, and planning.

What is an ai orchestration agent?

It is an agent (or logical layer) whose primary job is not to perform a specific business task, but to run collaboration: break down a request, select specialist agents, plan execution order, manage context sharing, supervise quality, and synthesise a final output (IBM, Algos).

What is the difference between ai orchestration and ai agents?

An AI agent is an autonomous unit that makes decisions and acts to reach a goal. Orchestration is the steering of the collective: task assignment, coordination, communication, aggregation, fault tolerance, and governance. IBM also notes that AI orchestration in the broad sense can include models, data pipelines, and APIs, whereas agent orchestration focuses on coordinating autonomous agents.

What signals show your orchestration is over-engineered (or under-engineered)?

Over-engineered: high latency, rising cost per request, too many iterations, debugging complexity, low marginal value from adding another agent (Microsoft). Under-engineered: one agent overloaded with tools, "plausible" errors, difficulty isolating permissions, inability to parallelise, too many human escalations. In both cases, telemetry (Deloitte) should drive redesign.

How do you prevent infinite loops and cost drift in a multi-agent system?

Set acceptance criteria, iteration limits, and budgets (time, tool calls, cost). In maker-checker loops, define a fallback behaviour (human escalation or best result with a warning) and keep group chat to three agents or fewer (Microsoft). Add cost/latency monitoring and alerts (Deloitte).

What are the minimum best practices for securing secrets and managing agent access?

Separate environments, minimise secrets, automate rotation, and assign a unique identity per agent with least privilege (Algos). Encrypt data in transit and at rest (Algos) and log access. Add a kill switch and validation before any high-impact write.

How do you run a performance evaluation of multi-agent systems without biasing results?

Evaluate on a stable, realistic case corpus; version agents and workflows; and compare like-for-like (same inputs, same constraints). Track quality, cost, and reliability together, otherwise you will optimise one dimension at the expense of the others. Finally, separate the effect of orchestration (planning, aggregation, retries) from the effect of data and tools, because that is often where bias hides.

How do you improve scalability and latency in multi-agent systems without sacrificing quality?

Only parallelise independent tasks (Microsoft), cache what is stable, batch homogeneous tasks where safe, and use queues to absorb spikes. Reduce transmitted context (summaries, indexes) and move validations earlier to avoid rework. Steer using agent telemetry (latency, errors, resources) and alert thresholds (Deloitte).

To explore more topics on agents, measurement, and industrialisation, see the latest posts on the Incremys Blog.