book

Multi-Agent AI Engineering

Name: Multi-Agent AI Engineering
ISBN: 9781806690879

by Dr. Xiao Ma, Dr. Chi Wang

September 2026

824 pages

29h 28m

English

Packt Publishing

Read now

Unlock full access

Preface
A note on the authors' interestsDownload the bonus contentFree benefits with your book
Part 1: Foundations
Chapter 1: Introduction to Multi-Agent Systems
Evolution from generative AI systems to multi-agent systemsSymbolic AI and expert systemsNeural networksThe generative AI eraAgentic AIMulti-agent systemsWhy structure when models scale?Why interaction helps: The causal mechanismCharacteristics and benefits of multi-agent systemsWhat is an agent, anyway?The agenticity spectrumComponents of an agentCharacteristics of multi-agent systemsRole specialization: from general intelligence to organized intelligenceInter-agent communication: intelligence as dialogueue, not monologueueAutonomy and distributed control: sustaining intelligence over timeWhen should you use multi-agent systems?Challenges and risks of multi-agent systemsTechnical overhead: The 'chatty' problemThe infinite loop trapNon-determinism and debugging nightmaresAlignment and goal driftSecurity implicationsEvaluation complexityMicroservices versus multi-agent systems: a familiar analogySummary
Chapter 2: Principles of Multi-Agent Systems
Principle 1: Bounded autonomyWhy bounded autonomy mattersThe five-component autonomy contractBest practicesExample: an experiment-proposer in a different domainStacking contracts in a teamPrinciple 2: Collective alignmentThe core problem: Local rationality, global incoherenceDesigning coordinationConflict resolutionBest practicesPrinciple 3: ResilienceSilent failure and the three modelsMAS-specific resilience mechanismsOne failure, three model drifts, five mechanismsBest practicesPrinciple 4: LearnabilityBest practicesExample: Adaptable research assistant, learnability feedback loopPrinciple 5: Modular composabilityWhy agent coupling is harder to contain than service couplingThe distributed monolith anti-patternDesigning modular agent interfacesBest practicesExample: The running research assistant as a modular pipelineCounter-example: The silent breakPrinciple 6: Safety and trust by designThe empirical baselineLeast-privilege tool accessInter-agent trust scopeExample: Prompt injection via tool outputBlast radius containmentExample: Cascading trust exploitHuman-in-the-loop escalation as a design primitiveEmergent safetyBest practicesPrinciple 7: Observability and evaluationWhat MAS observability and evaluation add above the classical pillarsObservability and evaluation stack for MASObservability and evaluation: The feedback mechanism for all other principlesBest practicesExample: Missing decision traceExample: Cross-agent correlation, locating a failure across three hopsExample: Sutando, same observability requirements at single-user scalePrinciples in tensionAutonomy versus collective alignmentResilience versus learnabilityModular composability versus performanceSafety and trust versus capabilityObservability and evaluation versus privacyLearnability versus stabilityA worked trade-off decisionWhat the tensions tell youDiagnostic checklistCapstone: All seven principles in one systemThe minimum viable design reviewSummary
Chapter 3: Frameworks and Mental Models
The role of frameworks in multi-agent systemsWhy not build from scratch?What a framework provides, and what it decides for youFrameworks as embodied principlesThe framework landscapeEvaluating framework maturityThe cost of choosing wrongCommon abstractions across frameworksAbstraction 1: The agentAbstraction 2: Messages and communicationAbstraction 3: Tools and actionsAbstraction 4: Memory and stateAbstraction 5: OrchestrationThe abstraction stackIntroduction to AG2From AutoGen to AG2Core concepts in AG2Synthesis: from frameworks to constructionPortability checklistSummary
Chapter 4: Constructing Your First Agents
Anatomy of an agentRoleGoalBrainToolsMemoryHow the components interactWhat happens when a component is missingAgents are not promptsReasoning and decision makingThe observe–think–act cycleReasoning strategiesChain-of-Thought (CoT)ReAct (Reasoning + Acting)ReflexionTree of Thoughts (ToT)Choosing a reasoning strategyImplementing reasoning in codeTool use, memory, and environment interactionDesigning effective tools: Capability governanceTool-design principle 1: Single responsibilityTool-design principle 2: Clear tool descriptionsTool-design principle 3: Typed schemasTool-design principle 4: Graceful error handlingTool-design principle 5: Safety boundariesImplementing tools in PythonMemory: from conversation history to state managementEnvironment interaction: the agent runtimeA research assistant agent: From scratch to AG2Stage 0: The task contract drives component choicesStage 1: The minimal loopStage 2: Adding toolsStage 3: A minimal test harnessThe same agent in AG2Adding a second agentAbstraction thinking: inputs, outputs, and behaviorsAgents as functionsThe agent contractWhy explicit contracts pay offBuilding robust agents: practical considerationsError handling and recoveryBudget and resource managementObservability minimaThe agent construction checklistSummary
Part 2: Building Multi-Agent Systems
Chapter 5: Agent Communication
From human teams to agent teamsThree failure modes that start at the boundaryWhat a boundary has to settleMessage design: Contracts, formats, and routingThe handoff contractThe envelope: Identity and lineageHow much structure a message needsRouting: Direct, topic, and broadcastValidating at the boundaryTiming and delivery semanticsSynchronous versus asynchronous patternsThe lifecycle of a communicated taskDeadlines that survive the tripDuplicates, idempotency, and stalenessWhat this layer owns, and what it does not ownPutting it all together: A reliable handoffThe failure trace: Ambiguous delegationThe repaired exchangeContract testsThe communication design checklistSummary
Chapter 6: Design Patterns for Multi-Agent Collaboration
The role of patterns in multi-agent systemsWhy patterns matterPattern forces: What drives the choiceThe pattern selection frameworkRole vocabulary: Initiator, worker, aggregator, critic, and routerThe topology lens: How patterns relate to familiar team shapesOne problem, four patterns: A comparison sketchConcurrent specialistsThe intuitionThe structureImplementationAggregation strategiesWhen to use concurrent specialistsSequential workflowsSequential cascadeThe intuitionThe structureImplementationStrengths and weaknessesRelay handoffThe intuitionThe structureImplementationWhen to choose cascade versus handoffTask decompositionThe intuitionThe structureImplementationThe decomposition quality problemThe MetaGPT standard operating procedure (SOP) variantWhen to use task decompositionDebate and reflectionThe intuitionThe debate patternImplementationDebate for the running research assistantThe reflection patternSelf-critique is hard; peer-critique is tunableConvergence and cost controlWhen to use debate and reflectionMixture of expertsThe intuitionThe structureImplementationRouter quality and fallbackWhen to use mixture of expertsComposing patternsWhy single patterns are rarely enoughComposition strategiesNestingChainingConditional selectionRuntime adaptationA compositional grammarA decision framework for pattern selectionAnti-patterns to avoidModern frameworks and their built-in primitivesThe failure signature of each patternDesign checklist: Collaboration patternsSummary
Chapter 7: Context and Memory Management
Role and types of memory in multi-agent systemsWhy memory is an architectural decisionA taxonomy of memoryMemory in multi-agent systemsWhat crosses the agent boundaryWhat each memory strategy costs per dayLLM-visible context versus runtime contextShort-term versus long-term memoryShort-term memory: the conversation windowContext failure modesManaging short-term memoryLong-term memory: persistence across sessionsThe memory lifecyclePersistent knowledge storageLayer 1: Structured fact storageWhat the running research assistant storesLayer 2: Semantic memory with vector searchLayer 3: Episodic memoryShared memory in multi-agent systemsMemory hierarchy: Tiers, not just namespacesLightweight alternative: The memory tool primitiveWhere the memory research agreesEvaluating agent memoryMemory metrics to monitor in productionRetrieval and forgetting mechanismsRetrieval strategiesRetrieval-augmented context assemblyThe case for forgettingForgetting mechanismsGovernance: provenance, privacy, and complianceDiagnosing memory failuresMemory consolidation: The dream passPutting it all together: A memory-aware agent architectureThe life of a factDesign checklist: Memory managementSummary

Chapter 8: Orchestrating Agent Teams
What is orchestration?Human organizations solved this firstWhy orchestration needs its own layerThe orchestration layerOrchestrator-worker at production scaleCentralized versus decentralized orchestrationCentralized orchestrationDecentralized orchestrationChoosing your topologySequential, concurrent, and aggregated flowsSequential pipelinesConcurrent fan-out / fan-inResult aggregationHybrid patterns: DAG-based orchestrationCombining flow types: A worked research workflowScheduling and prioritizationReliability and failure handlingIdempotency firstRetry strategiesWhen the call itself is wrongFallback and hedgingVerification: Gating progress on a judgeCircuit breakersGraceful degradationDurable workflow stateOrchestrating long-running agentsThe horizon where reliability dropsThe session handoffWhat the scaffold costsService-level objectives and adaptive orchestrationError budgetsOrchestrators that learnPutting it all together: A reliability-composed research orchestratorDesign checklist: Orchestrating agent teamsSummary
Chapter 9: Unified Abstractions and Protocols for Agent Collaboration
The interoperability ladderStandardized agent abstractions for interoperabilityThe problem: Agents as black boxes with incompatible interfacesThe agent as a service contractThe unified task envelopeFrom contracts to registriesDesign principles for unified abstractionsProtocols for agent communicationThe protocol landscape: A center and an edgeMCP: The tool integration layerWhen to use MCPKey production considerationWhat MCP does not solveA2A: The task delegation layerWhen to use A2AWhat A2A does not solveAdjacent and emerging protocols: ACP, ANP, and the legacy layerAgntcy: The infrastructure layerAAIF: Neutral governance for the stackA calculated bet, not a settled outcomeHow the protocols composeProtocol selection guideCross-boundary orchestrationThe adapter interfaceTrace context across boundariesStreaming is a deliberate omissionThe protocol-aware orchestratorPutting it all together: A cross-boundary workflowMinimum viable adoption: What to do firstWhere the cost actually lives, and who pays for itCentralized, decentralized, hybrid: what changes across boundariesVersioning and evolutionSecurity across protocol boundariesLayer-boundary glossarySynthesis: From protocols to frameworksDesign checklist: Cross-boundary interoperabilitySummary
Chapter 10: Comparative Survey of Frameworks
Why compare frameworks?Framework selection as investmentWhat a good comparison looks likeCapabilities to evaluate when the workflow needs themDeep dive into AG2ArchitectureUserProxyAgent: The human (or execution) seat at the tableOrchestration modelTool integrationMemoryProduction readinessMapping to MAS collaboration patternsRecent directionWhere this framework fits bestReviewing general-purpose MAS frameworksLangGraph: Workflow as explicit programContext noteRecent directionWhere this framework fits bestCrewAI: The organizational metaphorContext noteRecent directionWhere this framework fits bestOpenAI agents SDK: Thin runtime with safety primitivesContext noteRecent directionWhere this framework fits bestClaude agent SDK: Protocol-native developmentContext noteRecent directionWhere this framework fits bestSmolagents: radical minimalismContext noteRecent directionWhere this framework fits bestMetaGPT: Standard operating procedures as codeContext noteRecent directionWhere this framework fits bestEvaluating enterprise and emerging toolsMicrosoft: The Azure agent stackContext noteRecent directionWhere this framework fits bestStrands Agents: AWS-native, model-agnosticContext noteRecent directionWhere this framework fits bestGoogle ADK: The Gemini ecosystemContext noteRecent directionWhere this framework fits bestCross-framework comparisonOrchestration philosophyTool integration and protocol supportMemory architectureProduction characteristicsModel dependenceFramework vocabulary, mapped to the abstractionsFramework selection decision guideScenario-based selection cardsRegulated financial workflow (trade review, fraud adjudication, compliance audit)Exploratory research assistant (literature review, hypothesis generation, market intelligence)Internal developer platform (code review assistant, CI/CD orchestration, PR triage)Customer support triage (intent classification, specialist routing, escalation handling)Coding agent (autonomous feature implementation, test generation, bug reproduction)Cross-organizational agent marketplace (multi-vendor agent discovery, delegation, revenue tracking)Step 1: Classify your orchestration needsStep 2: Assess your ecosystem constraintsStep 3: Match production requirements to framework capabilitiesStep 4: Consider your teamStep 5: Plan for evolution and avoid irreversible lock-inComposition recipesCommon pitfalls in framework evaluationPitfall 1: Conflating demo quality with production fitnessPitfall 2: Overweighting GitHub starsPitfall 3: Ignoring the migration taxPitfall 4: The single-framework fallacyPitfall 5: Choosing for today's problem, not tomorrow'sThe convergence trendSummary
Part 3: Evaluating, Observing, Evolving, and Securing Multi-Agent Systems
Chapter 11: Evaluating the Performance and Behaviors of Multi-Agent Systems
Setting evaluation goals across multiple dimensionsSingle-turn LLM evaluation versus multi-agent system evaluationBeyond task completionThe five evaluation dimensionsThe agent development life cycle: Which evals at which stageHow evals fit with the rest of agent assessmentGrading mechanisms: code, LLM-as-judge, humanHow multi-agent systems failThe four phases of agentic failureInterpretation failuresReasoning failuresAction failuresPerception failuresMulti-agent amplificationDesigning your eval suiteWhy you cannot ship a MAS without an eval suiteProperties of a good eval suite: SHARPDesigning your eval suite: the six stepsStep 1: Define the task distribution and behavioral coverageStep 2: Create gold-standard outputsStep 3: Build reproducible test scenariosStep 4: Instrument the systemStep 5: Run with repetition, and match trial count to the decisionStep 6: Analyze trajectories, not just outcomesDiscovering unknown unknownsSimulation-based evaluationPublished benchmarks: A shared form of eval suiteWhy these cannot be the primary instrumentHuman evaluation and LLM-as-judgeWhy metrics alone are not enoughStructured human evaluationRubric designPartial credit for multi-component tasksInter-rater reliabilityLLM-as-judgeThe calibration procedureKnown judge biasesThe cost problem and the specialist-evaluator responseWhen to schedule a human evaluation passBuild versus buyKeeping the judge alive: Evolving LLM judgesMeasuring resource efficiency, robustness, and coordinationResource efficiency metricsRobustness metricsCoordination metricsTesting whether coordination helpedPutting it all together: The evaluation report and release cardEvaluating cost and unit economicsThe unit that matters is cost per successful outcome, not cost per tokenCost attribution turns a bill into a fixCost regressions gate like quality regressionsEvaluation is itself a cost line item, and a growing oneFeeding evaluation results into continuous improvementWhat production evaluation producesMeasure or shape, never bothThe evaluation-improvement loopThe regression gateTwo practices that decay quietly: eval-set hygiene and meta-evaluationEval-set contaminationThe harness itself is now an attack surfaceMeta-evaluation, or who tests the testersThe cost of not climbingThe maturity model for MAS evaluationStarting from zero: A one-engineer-week kitDesign checklist: MAS evaluationSummary
Chapter 12: Observability for Agentic AI
Why agent observability is a different problemThe question being askedNon-determinism and emergenceCost and resource economicsThe shape of the dataThe people who read itConnecting agent telemetry to the systems underneathHow OpenTelemetry worksWhy OpenTelemetryOTel vocabulary before the codeCollecting telemetry: The OpenTelemetry CollectorWhich platform receives your OTel data?Instrumentation with OpenTelemetryThe gen_ai.* namespace: key-naming conventionsSignal categoriesWhat the newer conventions record about agentsSetting up the foundationInstrumenting agent executionInstrumenting orchestrationFramework-level instrumentationFramework-native OpenTelemetry supportCross-framework auto-instrumentation: OpenLLMetry and OpenInferenceWhen to use framework-native, auto-instrumentation, or ObservableAgentWhat application-layer tracing cannot seeManaged agent runtimes: instrumentation is a deployment settingWhat to observeDimensions are orthogonal to signalsThe four observation dimensionsDimension 1: Behavior, what are agents doing?Dimension 2: Performance, how fast and reliable is the system?Dimension 3: Cost, how much are we spending?Dimension 4: Quality, how good are the outputs?Sampling and data managementTokenomics and cost observabilityPricing a call from its usage recordAttributing cost across agentsWhere a workflow's tokens goCost per outcome and the tailCoding and cowork agentsAI infrastructure observabilityThe model gatewayThe inference tierThe retrieval tierJoining the tiers to the tracePrivacy, security, and compliancePrivacy as an architectural decisionRedact at the Collector, not at the backendReasoning traces are a separate, harder problemMemory and replay privacyTenant isolation in multi-tenant trace storesThe regulatory floorThe incident canon for trace storesWhat is still unsolvedReconstruction and failure classificationReconstructing the workflowFailure reconstruction: a worked exampleClassifying the failureClassification is not attributionPublic incident canonDashboards, alerting, and acting on signalsLayered diagnostic dashboardsTiered alerting on symptomsFrom signal to decisionA worked example: cost-per-workflow triplesOTLP-compatible backends: Picking what receives your telemetryRuntime agent control and guardrailsMaking the policy gate affordableGuardrail librariesAgent control platformsBuilding it, buying it, or bothDesign checklist: Observability for multi-agent systemsSummary
Chapter 13: Self-Evolving Multi-Agent Systems
From improvement loop to evolution loopA Tuesday morning retrospectiveThis is MAPE-K in human formThe same loop, written downControlled adaptation versus open-ended self-modificationWhat separate ownership addsProposal work can shift, accountability does notWhat can change: Surfaces and timescalesFour months on the wrong surfaceWhat "learnable surface" precisely meansThe seven surfacesThe eval suite as companion surfaceA cost order, not a risk orderSignals, experience, and credit assignmentThe 98% pass-rate paradoxThree primary signal sourcesThree dimensions of signal qualityGoodhart's law in MASHuman feedback taxonomyCredit assignment across independently changing boundariesData governance for the experience loopHuman-agent team learning and knowledge distillationA Tuesday night incidentConversation here means collaborative work, not chatThe learning is bidirectionalRaw conversation is evidence: The durable artifact is distilled knowledgeThe six-step distillation pipelineKnowledge must be scoped, not globalThe handoff to the Evolution ContractIf you do one thing tomorrowMatching the fix to the causeReflection and self-critiqueAutomated prompt optimizationMemory and retrieval curationSkill and tool updatesOrchestration and routing policy updatesImitation learning and SFTPreference-based fine-tuningPopulation and team-level evolutionTechnique-to-surface matrixOperating the evolution loop safely: the Evolution ContractA silent JSON bugThe operating agreement framingThe seven clausesA worked contractThe four gates the Contract operationalizesFailure modes the Contract guards againstChanges that pass alone and fail togetherEvaluation-as-gateFrom trace to change: A worked governance pathMaturity model and investment decisionsThe maturity model as change-agent migrationWhat never migratesWhen to invest, and at what shapeThe contract scales with maturityDesign checklist: Self-evolving multi-agent systemsSummary
Chapter 14: Security and Privacy for Multi-Agent Systems
Why MAS security is still an emerging disciplineSecurity as authority architecture, not a bolt-on filterThree tiers of generative AI securityTier 1: Generation (the model produces text and nothing acts)Tier 2: Effects (the agent acts in the world and keeps state)Tier 3: Collaboration (work, context, and authority cross a boundary)Tier recap: what changed and where the mitigation livesThe OWASP Top 10 as a coverage mapAttack stories and the minimum viable baselineAttack story 1: Poisoned document to tool misuse to inter-agent propagationAttack story 2: Spoofed endpoint and protected signing boundaryAttack story 3: Shared memory poisoning to privileged agent actionTrust boundaries and authority boundariesMinimum viable MAS security baselineArchitectural mitigations: security in the shape of the systemAM1: Capability tokens for sub-agentsAM2: Non-human identity and the agent identity life cycleAM3: Dual-LLM / CaMeL partitioningAM4: Plan-then-Execute as a security propertyAM5: Signed inter-agent messagesAM6: Memory write-time provenance and ACLsAM7: Sandboxed untrusted regionsHow the spine composesOnline guardrails: Runtime patterns, not vendor catalogsRG1: Tool-call mediator (enforces AM1)RG2 (MAS-specific): Inter-agent message validation at the bus (enforces AM5)RG3: Runtime memory write-check (enforces AM6)RG4 and RG5: Pre-LLM input filter and post-LLM output filterRG6: In-loop classifierRG7: Programmable railsComposing the runtime stackWhen a control is unavailableVendors, by categoryRed-teaming for multi-agent systemsHarnesses and adaptive attack generationBenchmarks are calibration anchors, not substitutesRed-team finding triageContaining a compromised agentWhen a collective is the attackerPublic incident canon as red-team curriculumOpen frontier in red-teamingPrivacy in multi-agent systemsPrivacy as appropriate information flowHow multi-agent structure amplifies the problemDesigning for privacyStandards and regulationOWASP Top 10 for agentic applicationsCSA AAGATE / Agentic AI RMF alignmentEU AI Act high-risk agentic provisionsMITRE ATLASDesign checklist: MAS security and privacySummary
Chapter 15: Deploying and Scaling Multi-Agent Systems
What deploying a multi-agent system actually changesFrom prototype to productionBuy separation where the boundaries differDeployment environmentsContainerization and the service wrapper, brieflyThe security floorRunning your own modelsChoosing an inference serverWhat actually drives throughputScaling the GPU tierScaling the agent fleetScale on the queue, not the CPUChoosing a message brokerTask queue with worker pools, and the durable-execution pattern beneath itAutoscaling the worker poolCoordinating the rate limit across the fleetExternalizing stateCancellation, supersession, and the client that went awayAgent discovery in a distributed systemTokenomics and cost engineeringWhy token cost is nonlinearCapacity planning: from workload to budgetPrompt caching: the highest-leverage leverThree levels of cost controlAttribution and multi-tenancyBuild versus buyRisk and ownershipObservability for deployment and scalingThe version fingerprint: attribution after a deployScaling signals: Telemetry as the autoscaler's inputCanary gates: Behavioral and cost metrics, not just error ratesCost drift and runaway detectionCI/CD, versioning, and rollbackVersioning the release manifestRollback as a first-class capabilityBreaking the runtime on purposeCommitting to a service level you can keepDesign checklist: Deploying and scaling multi-agent systemsSummary
Part 4: Practice and Outlook
Chapter 16: Case Studies from Real-World Applications
Case study 1: Platform engineering, CAIPE and the agentic internal developer platformThe problemGive each control plane its own agentRetire a boundary once its reason has expiredRebuild around configured agentsMove policy to a gateway that fails closedSeparate what outlives the topology from what dies with itResults and lessons learnedCase study 2: Scientific research, Denario and the autonomous discovery pipelineThe problemArchitectureDesign patterns and trade-offsContext, memory, and structured handoffsEvaluation, honesty, and limitationsResults and lessons learnedCase study 3: VLSI hardware design, autonomous agents across the EDA flowThe problemA series, not a one-shotArchitecture: One framework, three knobsDesign patterns and trade-offsContext, memory, and groundingVerification and self-improvementResults and lessons learnedCase study 4: Enterprise customer support, from triage to resolutionThe problemArchitectureDesign patterns: One owner per clockResults and lessons learnedWhat the cases show togetherSummary
Chapter 17: Emerging Research and Industry Trends
The frontier is relocating agencySelf-evolving agentic systemsWhat acts, and what the update changesCredit assignment is the research bottleneckThe environment is part of the training methodDoes RL expand capability, or redistribute search?Long-horizon agencyWhy small errors dominate long executionReduce the effective horizonWorld models as an operational loopDurable execution and honest completionCoordination becomes a learned social capabilityWhat has to be learnedFailures that look like teamworkBeat the strongest memberThe authority plane: From identity to accountable actionFrom principal to effectAuthorization is not intentAuthority has privacy and incident costsThe human-agent interfaceInput and output as one control surfaceA trusted host around an adaptive surfaceThe interface is also a learning boundaryThe interface can corrupt the signalWhen should the agent ask?Agent infrastructure becomes a systems layerThe planes around a durable runA different resource shapeOverload is an agency problemSoftware for two constituenciesWhat an agent-facing surface must stateCapacity and support at machine pacePricing and SKU design move with the unit of valueAgent ecosystems become marketsMachine-speed markets have different failure modesMechanism design becomes part of engineeringWhat survives model progressThe assumption registerVolatile implementation, durable obligationsSummary
Chapter 18: Conclusions and Future Outlook
The last architecture reviewKey lessons from the bookSafety, ethics, and societal impactEngineering decisions are also ethical decisionsThe safety challenge at scaleEngineering obligationsSocietal impact: The broader pictureFuture outlookNext steps for readersSummary
Other Books You May Enjoy
Index

Content preview from Multi-Agent AI Engineering

12 Observability for Agentic AI

You cannot fix what you cannot see.

An observable system is how a collective sees itself. Human institutions rely on minutes to record decisions, censuses to count populations, case law to preserve precedent, audits to enforce accountability, and alarms to signal trouble. Observability is the machine-readable counterpart: understanding a system's internal state by examining its external outputs, which for an agentic system means traces, logs, metrics, correlated decision and evaluation records, redaction evidence, and alerts. OpenTelemetry provides the production vocabulary for that perception layer.

Chapter 11 established how to judge whether multi-agent behavior is good enough; observability supplies the evidence ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781806690879

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Multi-Agent AI Engineering

by Dr. Xiao Ma, Dr. Chi Wang

12

Observability for Agentic AI

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.