Varför Agentic AI Mesh-arkitekturer får svårt i produktion

En användbar arkitektur, men ett farligt antagande

McKinseys artikel om Agentic AI Mesh är professionell, välstrukturerad och värdefull som karta över de problem som uppstår när agentexperiment sprids mellan team. Den identifierar korrekt fragmentering, inkonsekventa standarder, växande kostnader, styrningsluckor och behovet av observerbarhet. Problemet är inte att artikeln är slarvig. Problemet är att referensarkitekturen ändå kan förstärka tron att fler agenter, mer delegering och fler LLM-medierade beslut naturligt leder till bättre enterprise-resultat.

Det är just den tron som gör att många produktionsimplementationer kommer att misslyckas. Intelligens komponerar inte linjärt. Ett team av svagt begränsade agenter är inte samma sak som ett team av experter. En större modell i varje steg är inte automatiskt säkrare än en mindre modell med en smal deterministisk roll. En mesh kan minska leverantörslåsning och förbättra återanvändning, men den kan också skapa ett distribuerat stokastiskt system där varje överlämning adderar oklarhet, latens, kostnad och ansvarsgap.

Multi-agent betyder inte multi-smart

Den mest lockande idén i agentarkitekturer är specialisering. En agent planerar, en hämtar information, en validerar, en kör verktyg och en kontrollerar compliance. På en diagramyta ser det ut som organisationsdesign. I produktion beter det sig ofta som en kedja av probabilistiska översättare. Varje agent får partiell kontext, tolkar avsikten, omformar uppgiften och skickar en ny representation vidare. Små fel ackumuleras tyst.

Multi-agent-system kan vara användbara när gränserna är explicita och överlämningarna är typade. En prissättningsagent som bara får anropa godkända prissättnings-API:er är något annat än en generell resonerande agent som själv tolkar kommersiell policy. En compliance-validator med deterministiska policykontroller är något annat än en compliance-agent som läser en annan agents sammanfattning och ger ett sannolikhetsomdöme. Den första designen begränsar beteende. Den andra multiplicerar trovärdigt språk.

Enterprise-ledare bör därför ställa en hård fråga innan ännu en agent läggs till: vilken osäkerhet tar den här agenten bort? Om svaret bara är "den lägger till ett perspektiv" kan arkitekturen öka attackytan utan att öka tillförlitligheten.

LLM-medierad orkestrering är fortfarande en agent

Många agent mesh-designer beskriver en orkestrator eller planerare som bryter ner uppgifter, väljer agenter, routar arbete, validerar resultat och bestämmer nästa steg. Om dessa beslut huvudsakligen fattas av en LLM är orkestratorn inte ett stabilt kontrollplan. Den är en annan agent med större befogenhet. Den skillnaden spelar roll.

En produktionsorkestrator bör bete sig som infrastruktur: förutsägbart, observerbart, testbart och avgränsat. Den bör veta vilket workflow som är tillåtet, vilka verktyg som kan anropas, vilka retries som är tillåtna, vilket outputschema som krävs och när mänskligt godkännande behövs. LLM:er kan hjälpa till att klassificera oklar avsikt eller skriva ett förslag till plan, men det slutliga planeringsläget bör representeras i en deterministisk struktur som kan testas före exekvering.

Utan denna separation uppstår oväntade retries, inkonsekvent verktygsbeteende, loopande agentkonversationer, okontrollerad tokenkostnad och fel som är svåra att reproducera. Problemet är inte att modellen är "dålig". Problemet är att arkitekturen ger probabilistiskt resonemang ett ansvar som hör hemma i workflow-kontroll.

Verktygsanrop är den största felytan

Enterprise-diagram antar ofta att verktyg alltid kan anropas, är tillgängliga, är auktoriserade och returnerar tydliga resultat. Verkliga system fungerar inte så. API:er får timeout. Behörigheter ändras. Datakontrakt driver. Ett downstream-system returnerar ett partiellt resultat. Ett verktyg lyckas tekniskt men bryter affärsmässig timing. En modell ser en verktygsbeskrivning och väljer den av fel skäl. Verktygsanrop är platsen där agentic AI lämnar demon och träffar operationell verklighet.

Motmedlet är inte en agent till som övervakar den första. Motmedlet är ett enforcement-lager. Verktyg behöver typade kontrakt, idempotensregler, rate limits, policykontroller, kompensationsåtgärder och revisionsloggar. Verktygsanrop bör gå via gateways som kan neka osäkra begäranden innan de når systems of record. För åtgärder med hög påverkan bör agenten föreslå ett åtgärdspaket; ett deterministiskt workflow bör avgöra om det får köras.

OpenTelemetry, API-gateways, service mesh och policy-motorer som Open Policy Agent är inte tillval här. De är skillnaden mellan en agentplattform och en stokastisk integrationsbuss.

Ekonomin brister före visionen

Agent mesh-arkitekturer kan fungera vackert i demos eftersom demos komprimerar skala. Det finns få användare, få edge cases, låg samtidighet, vänliga prompts och begränsad verktygsvariation. I enterprise-skala adderar varje agent modellanrop, kontextöverföring, validering, loggning, retries och evalueringskostnad. Om systemet använder stora modeller för planering, routning, validering och generering växer kostnaden innan värdet är bevisat.

Därför är "LLM överallt" ekonomiskt skört. Många steg i ett agentworkflow bör hanteras av mindre språkmodeller, klassificerare, regler eller procedurtjänster. Routning kan ofta vara en policytabell. Validering kan ofta vara schema- och kontraktskontroll. Minneshämtning kan ofta filtreras deterministiskt med metadata före semantisk sökning. Den dyra modellen bör reserveras för de steg där språkligt resonemang verkligen skapar värde.

En produktionskalkyl bör inkludera kostnad per slutförd uppgift, kostnad per misslyckad uppgift, retry-frekvens, mänsklig granskningstid och infrastrukturöverhead. Om kostnadsmodellen bara räknar lyckade happy-path-körningar är arkitekturen inte redo för produktionsplanering.

Planering bör inte vara probabilistisk

Grundproblemet är enkelt: språkgenerering kan vara probabilistisk och resonemang kan innehålla probabilistiska element, men planering i multi-agent-system bör inte vara probabilistisk vid exekvering. En plan bör bli en kontrollerad artefakt: versionshanterad, inspekterbar, typad, auktoriserad och möjlig att spela upp igen. Systemet kan använda en LLM för att föreslå planen, men det bör inte exekvera fri-form-intent.

Det bättre mönstret är en begränsad agentarkitektur. Använd LLM:er för tolkning, utkast, sammanfattning och hantering av oklarhet. Använd deterministisk orkestrering för exekvering. Använd policygrindar för auktorisering. Använd typade verktyg för åtgärder. Använd evalueringssviter för negativa scenarier. Använd mänskligt godkännande där reversibilitet är låg eller affärspåverkan är hög.

Agentic AI Mesh kan fortfarande vara användbart om det tolkas som integrationsstyrning, inte som en licens för agentproliferation. Produktionsfrågan är inte "hur många agenter kan samarbeta?" Frågan är "vilka beslut får aldrig delegeras till probabilistiska komponenter?" Den frågan skiljer hållbara enterprise-system från imponerande demos.

Utvald bild av Albert Stoynov på Unsplash.