I det växande fleragentslandskapet är agenter mest effektiva när de tilldelas specifika, detaljerade uppgifter. Detta kräver ett brett nätverk av återanvändbara, specialiserade agenter. Huvudutmaningen är dock att samordna dessa många heterogena aktörer, som kan komma från olika källor, för att effektivt samarbeta mot gemensamma verksamhetsmål. Utan en enhetlig plattform leder denna komplexitet till agentspridning och en kritisk brist på styrning.

Dessa AI-agenter förökar sig snabbt, inbäddade i SaaS-plattformar, utvecklade internt eller paketerade med populära LLM. Denna multiplikation resulterar i frånkopplade organisationssilor. En agent optimerar uppgifter i sina inbyggda program, men saknar ofta en helhetssyn på företaget. Denna brist på synlighet förhindrar agenter från att effektivt orkestrera, säkra och styra åtgärder över olika domäner och system.

MuleSoft Agent Fabric hanterar utmaningen att hantera "agentsprawl" och möjliggöra sömlös orkestrering av olika agenter, oavsett deras ursprung. Den etablerar rekommenderade metoder för arkitektur och tillhandahåller det verktyg som behövs för att skapa Agentnätverket. Ett agentnätverk refererar till en samordnad samling AI-agenter, verktyg och resurser som arbetar tillsammans för att utföra komplexa verksamhetsprocesser i flera steg.

MuleSoft Agent Fabric är en enhetlig plattform som ger varje företag ett enkelt sätt att upptäcka, orkestrera, styra och observera alla agenter oavsett var de är byggda.

Upptäck: Agentregistret tillhandahåller en centraliserad katalog över alla AI-agenter och verktyg i hela organisationen. Det möjliggör upptäckt och återanvändning av internt byggda, SaaS-inbäddade och externa tillgångar. Genom att tillhandahålla en enda källa till sanning för alla agenttillgångar eliminerar agentregistret överflödighet och säkerställer att utvecklare kan utnyttja befintliga kapaciteter i stor skala.

Orkestrera: MuleSoft Agent Broker är en intelligent dirigeringslösning som dynamiskt matchar uppgifter till den agent eller det verktyg som passar bäst. Drivs av en LLM som du väljer och koordinerar mellan agenter och verktyg för att säkerställa att komplexa begäranden i flera steg och verksamhetsprocesser utförs med hög tillförlitlighet och spårbara resultat.

Styr: MuleSoft Agent Governance använder Flex Gateway och dess stöd för protokollen Modellsammanhang (MCP) och Agent2Agent (A2A). Med Flex Gateway kan företag tillämpa säkerhets- och efterlevnadspolicyer för varje interaktion mellan agent och agent och verktyg.

Observera: Agentvisualiseraren ger observerbarhet i realtid genom en dynamisk, interaktiv karta över agentinteraktioner. Den följer beslut, övervakar systemhälsan och möjliggör därmed kontinuerlig optimering och tillförlitlig översikt av hela agentens ekosystem.

Agent Fabric förespråkar en YAML-metod (specifikation-first) där användare definierar agentnätverk genom en metadatadeskriptor ("YAML-filen"). Denna YAML-fil är agnostisk mot MuleSoft och den kopplar bort definitionen av agentnätverket från utförandet.

Varje agentnätverk (YAML) definierar ett specifikt funktionsområde med sina agenttillgångar, inklusive deras operativa regler och policyer. YAML används för att aktivera de fyra Agent Fabric-pelarna:

1. Upptäck: Fyll i agentregistret med befintliga agenttillgångar, till exempel:
   1. Agenter distribuerade över olika plattformar (MuleSoft eller andra)
   2. MCP-servrar
   3. LLM-leverantörer
2. Orkestrera: Skapa agentmäklare för orkestrering
3. Styr: Tillämpa policyer för tillgångar för säkerhet och styrning
4. Observera: Definiera och återanvänd anslutningar till de definierade tillgångarna. Möjligheter till observation och övervakning finns även för agentnätverk.

Användarresan börjar i Anypoint Code Builder. Använd det nya kommandot som är tillgängligt via kommandopaletten “MuleSoft: Skapa ett Agentnätverksprojekt” för att skapa ett nytt projekt. Detta kommando skapar ett nytt projekt (‘Agentnätverk’) som innehåller två filer.

• agent-network.yaml: Denna fil definierar konfigurationen för fleragentssystemet och aktiverar orkestrering av AI-agenter med externa verktyg (via MCP) och agenter (via A2A-protokoll). Detta format ger ett deklarativt sätt att definiera agentkapacitet, beroenden och integreringar.

• exchange.json: Alla agentnätverksprojekt har även en exchange.json-fil. Denna fil innehåller tillgångsmetadata som är tillgängliga i Anypoint Exchange efter att dina agentnätverkstillgångar har publicerats.

Utvecklingen av ditt agentnätverk följer en standardlivscykel för programvaruutveckling (SDLC) som innefattar fyra huvudsteg:

1. Miljökonfiguration: Konfigurera runtimemiljö och gateways
2. Projektskapande och design: Skapa projektspecifikation för Agentnätverk
3. Byggande och publicering: Bygg och publicera tillgångar till agentregistret
4. Distribuering: Distribuera eller befordra agentnätverket till en given miljö

När du har byggt projektet och skapat det MuleSoft-program och tillgångar som behövs, gör dem tillgängliga i Exchange. I Anypoint Code Builder, utlös bygg- och publiceringsprocessen med hjälp av “MuleSoft: Kommandot Publicera Agent Broker-projekt till Exchange” är tillgängligt via kommandopaletten.

Publiceringssteget transformerar varje agenttillgång i YAML-filen till en A2A-, MCP- eller LLM-specifikation och publicerar den till Exchange.

Systemet publicerar även YAML till Exchange med hjälp av en ny agentnätverkstillgångstyp. Du kan visa denna tillgång i Agentregistrets användargränssnitt och söka efter den via Exchange API.

Hänvisa till en agentnätverksfil som definierar ett agentnätverk för ett företag. Detta agentnätverk aktiverar nätverket för orderuppfyllande över Salesforce, Stripe, en annan agent för orderuppfyllande och lager-MCP-server med en enskild, policystyrd upplevelse.

• Upptäck
  Publicera befintliga agenter och verktyg (som Salesforce, Stripe, Orderuppfyllande och Lager) som Exchange-tillgångar för återanvändning. Även orderuppfyllandedefinitionen (YAML) som är versionerad och delningsbar, vilket möjliggör snabb anpassning för roller, regioner eller dotterbolag utan att bygga om flöden.
• Orkestrera
  En agentmäklare använder en LLM för att dela upp orderuppfyllandeprocessen i en sekvens av uppgifter, som att verifiera kunddetaljer, allokera lager och beräkna leveranskostnader. Den kör sedan detta arbetsflöde genom att anropa MCP- och A2A-agenter, vilket säkerställer att mänskliga-i-slingan-godkännanden begärs vid behov.
• Regering
  Anypoint Flex Gateway tillämpar autentisering, åtkomst med minst behörighet och skyddsräcken. API Manager-policyer säkerställer enhetliga kontroller över alla anrop och datautbyten.
• Observera
  Övervakning och spårning ger fullständig insyn i förlopp, fel och latens. Visualisering visar vilka agenter som interagerade och var flaskhalsar inträffade.
• Trust and Compliance
  Centraliserade inloggningsuppgifter, granskningsloggar och policyarv har stöd för krav på säkerhet, sekretess och föreskrifter (PII-hantering, godkännanden och separation av uppgifter).

Diagrammet visar de olika noderna i agentnätverket (metadata) som definieras i YAML.

• Syfte: Exchange är katalogen för agenter, verktyg och andra tillgångar. Dess primära mål är att lösa "agentsprawl" genom att tillhandahålla en enda, styrd katalog för upptäckt, kurering och livscykelhantering av heterogena agenter. Det låter utvecklare hitta och återanvända agenter, plattformsägare för att upprätthålla synlighet och orkestrerare för att upptäcka kapacitet.
• Heterogen efter design: Anypoint Exchange har nu stöd för tre nya tillgångar - Agenter, MCP och LLM. Exchange är utformat för att vara en universell katalog, för att registrera och hantera alla typer av agenter. Den har stöd för A2A-kompatibla agenter, MCP-servrar och LLM-leverantörer från alla källor, inklusive agenter från tredje part, Agentforce och egna MuleSoft.
• Huvudmetadata: Varje registrerad tillgång har en grundläggande uppsättning oföränderliga metadata, inklusive Unikt namn och version, Ägarskap och Utgivare. Livscykellägen (utveckling, fasning, produktion, föråldrad) spåras också.
• Upptäckt:
  • Designtid: Utvecklare kan upptäcka registrerade agenter antingen genom det befintliga Exchange-gränssnittet eller via sökning på naturligt språk med Vibes i Anypoint Code Builder.
• Taggning och klassificering: Tillgångar kan klassificeras efter typ (agent, MCP, LLM, mäklare) och domän (till exempel HR, väder) genom att använda ett grundläggande taggningssystem för nyckelvärden, vilket möjliggör dynamiska länknings-, sök- och urvalspolicyer.
• Katalog: Arkivet har stöd för både privata och interna katalogmodeller för att dela agenter inom en organisation.
• Visualisering: Ger ett visuellt verktyg för att stödja nätverksvyer, som visar anslutningar för enskilda tillgångar eller hela kartan över noder och länkar i organisationen, med filtreringsmöjligheter.

Mäklare inom ett agentnätverk kan referera registrerade agenter, MCP-servrar och LLM-leverantörer som lagras i Anypoint Exchange. Men om de inte redan är registrerade kan de deklareras i metadata för Agent Network (YAML) och de registreras automatiskt. I exemplet deklareras och registreras flera agenter, MCP-servrar och LLM-leverantörer i Anypoint Exchange.

En agentmäklare är en intelligent dirigeringsagent som koordinerar uppgiftsdelegering mellan specialiserade agenter i ett företag. Den definieras av de agenter och MCP-servrar som den använder för att utföra uppgifter.

En mäklare är en specialiserad agent som visas i Anypoint Exchange efter att en agentnätverkstillgång har publicerats och återanvänts av andra mäklare.

Mäklare definieras i sektionen Mäklare i YAML. De definierade mäklarna ”kompileras” transparent till ett program, utan att kräva någon tidigare Knowledge om Mule. Detta skapade program distribueras till CloudHub 2.0 (CH2) och använder den robusta CH2-infrastrukturen.

Detta innebär att Agentmäklarna drar nytta av CloudHub 2.0:s etablerade prestandaegenskaper, inklusive dess loggnings- och måttkapacitet. Operativa aspekter, som "Kostnad att arbeta" och "Övervakning/Varning/Verktyg", är samma som andra arbetsbelastningar.

För scenarion som kräver mänskligt ingripande (Human-in-the-Loop) upprätthålls statusen för varje interaktion genom att använda MuleSoft Object Store, en distribuerad lösning utformad för effektiv tillståndshantering i mycket samtidiga miljöer.

En mäklardefinition består av två sektioner: kort och specifikation.

Kortsektionen följer Agent-till-agent-specifikationen (A2A). Den beskriver bland annat agentens kontrakt, kompetens och kapacitet. Kortets url fylls i automatiskt med värdet ${ingressgw.url}/broker-name. Vid distribuering ersätts platshållaren ${ingressgw.url} automatiskt med url:en för Anypoint Flex Gateway som frontar begäran om agentintrång.

Specifikationssektionen konfigurerar "källkoden" för mäklaren. Här kan utvecklaren specificera LLM att använda, instruktioner, tillgängliga verktyg, felhantering och viktigast av allt, de olika agenter och MCP-verktyg som är tillgängliga för denna mäklare.

LLM-leverantörer

Denna sektion är en del av specifikationen för varje förmedlare. Detta är en referens till en av de LLM som definieras i sektionen tjänster. Vi kan välja om vi vill dela en LLM mellan alla mäklare, eller om det behövs låta olika mäklare använda den LLM som passar dess uppgifter bättre.

Mäklare kan peka till LLM-leverantörer. Vi kan välja modeller av dessa leverantörer beroende på våra behov.

Instruktioner

Denna sektion är valfri och du kan använda den för att specificera instruktioner som är specifika för denna agent. Dessa instruktioner fokuserar ofta på specifika verksamhetsorienterade problem. Tänk dig till exempel en kundserviceagent som koordinerar hanteringen av kundrapporterade incidenter:

Observera att det inte finns något behov av att ge uttryckliga instruktioner—som "dela upp uppmaningen i uppgifter" eller "välj det bästa verktyget"—eftersom mäklaren hanterar detta på egen hand. Dessa instruktioner behövs endast för att beskriva specifika verksamhetsprocesser.

Verktygskonfiguration

Verktyg ger agenter externa kapaciteter. När en förmedlare behöver åtkomst till ett externt system (som inte är en annan agent, till exempel en befintlig API eller en SaaS-tjänst) når den ut till en MCP-server (Model Context Protocol):

MCP-servern refereras av namnet på utbytestillgången. Anslutningsdetaljerna för den specificeras i sektionen Tjänster.

Som standard har mäklaren åtkomst till alla verktyg som är tillgängliga i MCP-servern. Enligt vår observation kan de modernaste LLM endast hantera runt 20 - 25 verktyg per sammanhang innan de börjar skapa felaktigheter (eller förlora sammanhanget). Av denna anledning är det i allmänhet en god praxis att begränsa de tillgängliga verktygen till det absolut nödvändigaste. Du kan tillämpa denna filtrering genom de tillåtna listorna.

Agentlänkar

Detta avsnitt är den viktigaste delen av hela definitionen. Sektionen Länkar aktiverar kommunikation och orkestrering mellan agenter. Detta innebär att denna mäklare förlitar sig på att agenterna som länkas här utför lämpliga åtgärder för att slutföra användarens mål.

I själva verket definierar denna sektion ett agentnätverk för samarbete.

Agentstyrning är en viktig pelare för agentväven, grundläggande för att bygga ett pålitligt agentnätverk och säkerställa säkerhet och efterlevnad.

För styrning krävs totalt två Flex Gateways (1 ingress och 1 egress) inom ditt privata utrymme.

Styrning etablerar de strukturer, kontroller och bevis som behövs för att säkert skala upp hela Agentutvecklingslivscykeln (ADLC). Specifikt implementerar styrning nyckelprocesser som agentcertifiering, katalogisering, livscykelbeslut och tillämpning av runtimepolicyer.

• Katalogisering:
  • Exchange: Stöder registrering av agentsyften, ägare, miljöer och data- och klassificeringsgränser. Den registrerar även kapacitet, verktyg, resurser, uppmaningar och externa beroenden med versioner.
• Versionering och livscykel:
  • Dokumentera och hantera semantisk versionshantering av agenter, verktyg och tillgångar under hela livscykeln för agentutveckling.
  • Versionshantering hjälper till att hantera tidslinjer för agentavskrivning och har stöd för dubbla körningar (där så är möjligt) för att säkerställa smidiga migreringar.
• Policytillämpning:
  • Agentisk AI-arkitektur utökar attackytan (konversationsgränssnitt, uppmaningar och nya protokoll som MCP). Alla kompromisser med några komponenter kan leda till kaskadeffekter till flera system som tillhandahåller komponenter som protokoll, uppmaning, API eller verktyg.
  • Att säkra företagets agentiska AI-distribueringar kräver en specialiserad metod, eftersom dessa autonoma och oförutsägbara miljöer i sig breddar attackytan genom agent-till-agent-interaktioner. Befintliga säkerhetsverktyg för statiska system är viktiga, men de är inte längre tillräckliga på egen hand. Företag måste proaktivt planera och implementera fyra specifika säkerhetslösningar, var och en direkt för att hantera en viktig verksamhetsrisk som är associerad med agentisk AI.
  • Flex Gateway: All A2A- och MCP-trafik dirigeras genom Flex Gateway, även om målsystemet inte är säkert, för att säkerställa att policyer tillämpas för varje slutpunkt. Denna dirigering är avgörande för att säkra agentkommunikation och integrera med auktoriseringsservrar.
  • Policypaket: Användare kan definiera och tillämpa paket med fördefinierade policyer för arbetsflöden innan de körs, vilket upprätthåller en enhetlig uppsättning säkerhets- och driftspolicyer.
  • Typer av policyer: Plattformen har stöd för olika inkommande och utgående policyer, inklusive:
    • A2A-policyer: Agentkort, PII-detektor, Uppmaningsinredare, Schemavalidering.
    • MCP-policyer: Attributbaserad åtkomstkontroll, Schemavalidering, MCP-stöd.
    • LLM/AI-policyer: AI-uppmaningsdekoratör, AI-uppmaningsvakt (filtrerar skadligt innehåll), AI-uppmaningsmall (tillämpar fördefinierade mallar), AI-grundläggande begränsning av tokenfrekvens.
    • Telemetripolicyer: A2A och MCP Telemetry för att utöka Open Telemetry-lösningar för insamling och export av loggdata.
• Logga: Tack vare automatisk spårning är loggar över agentnätverket tillgängliga för att följa varje agentinteraktion, förklara beteenden och bygga Trust.

Exemplet visar en policy för meddelandeloggning, som konfigureras genom att använda agentnätverksmetadata. Orderfullfillment-mäklare refererar till en befintlig agent som heter Salesforce-agent och policyn för meddelandena konfigureras genom att använda metadata. Observera att Agent Fabric automatiskt konfigurerar alla policyer som nämns under avsnittet "specifikation" i Flex Gateway. Du behöver inga extra steg.

Med tanke på den icke-deterministiska karaktären och komplexiteten hos LLM-agenter och distributioner av flera agenter är observerbarhet och övervakning avgörande.

• Grundläggande loggar och spår: Resonemang och verktygskörningsspårning tillhandahålls genom loggar. Loggar och spårningar från arbetsflödeskörningar går att se efter körningen i Runtime Manager.
• Mått: I den inledande fasen publicerar plattformen a2a_total_calls och mcp_total_calls som räknare med etiketter (som väg, status, metod, verktyg) för att avgöra totalt, framgångsrika och misslyckade samtal. Dessa mått publiceras från policykod genom att använda Envoys (Flex Gateway) inbyggda statistikgränssnitt, helst via befintliga policyer som mcp_support_policy och a2a_agent_card_policy.
• Utökad observerbarhet (framtid): Planerna inkluderar att använda Open Telemetry för distribuerad spårning i framtida versioner. Mer avancerad observerbarhet inkluderar:
  • Detaljerad begäranspårning: Få fullständig insyn i begäranden, inklusive uppmaningar, planerarprocesser, åberopade åtgärder och interaktioner med underagenter.
  • Hälsoövervakning för agenter: Bevaka agenters upptid, svarslatens, genomströmning, felfrekvenser och underliggande resursanvändning (CPU, minne, nätverk, GPU).
  • Övervakning av koordination för flera agenter: Samla in framgångs- och felfrekvenser för agent-till-agent-interaktioner, upptäcka cirkulära åberopningsmönster (loopar) och följa mått per agent, som slutförande av uppgifter och åberopning.
  • Kostnadsspårning: Spåra tokenanvändning och associerade kostnader för varje LLM-samtal, helst per agent, med instrumentpaneler och varningar.
  • Kognitiv spårning: Samla in och visa en detaljerad spårning av en agents session, inklusive interna tankeprocesser och alla verktygsanrop, som fungerar som en oföränderlig granskningslogg.
  • Uppspelning av agentsession: Ett användargränssnitt som tillåter visuell "repris" av en agents kognitiva spårning steg-för-steg för djup felsökning.
  • DAG-visualisering: Ger en visualisering med Directed Acyclic Graph (DAG) av agentens arbetsflödesutförande för komplexa interaktioner med flera agenter.

Agentvisualiseraren används för att identifiera delarna i ditt agentnätverk och se hur de fungerar tillsammans.

• Skilj på nodtyper (agenter och MCP-servrar).
• Visa kanterna för att se deklarerade interaktioner och runtimeinteraktioner.
• Använd lager för att fokusera vyer på specifika miljöer
• Öppna detaljkort för att inspektera metadata och mått för noder och åtkomstloggar och spårningar
• Gå igenom styrningsindikatorer som skydd för Flex Gateway och tillämpade policyer.

Detaljer om komponenterna i Agent Visualizer hittar du här.

Med dessa fyra pelare tillsammans utökar MuleSoft Agent Fabric säkerheten och kontrollen till alla agenter med inbyggd styrning. Det låter agenter agera var som helst genom att använda nya protokoll som A2A (agent till agent) och MCP (sammanhangsprotokoll för modeller) för att bygga och utöka verksamhetsprocesserna. Vi ansluter allt – program, data och system – för att stärka och styra agenter när de agerar i hela verksamheten. Intelligent verktyg stöder skapandet och utvidgningen av verksamhetsprocesser eller API:n genom att använda AI inbyggt, eller genom att hämta AI-verktyg från tredje part.

Att använda alla fyra pelarna tillsammans är inte obligatoriskt, men rekommenderas. Du kan välja pelare oberoende efter behov. Du kan till exempel använda Agenttyg för register och styrning, utan att använda orkestreringslagret. På samma sätt kan du använda mäklaren för att orkestrera agenter som styrs via en annan plattform.

Diagrammet visar hur alla fyra komponenter interagerar med varandra:

1. Publicera de agentiska tillgångarna till Anypoint Exchange för upptäckt och återanvändning efter att du har definierat agentnätverket (mäklare, agenter, MCP-servrar) i agentnätverkets YAML i Anypoint Code Builder.
2. Distribuera agenttillgångarna till CloudHub 2.0 (hanterat i Runtime Manager).
3. Tillämpa policyer för inkommande trafik till nätverket med en inkommande Flex Gateway, som sitter framför broker- och API-slutpunkter.
4. Tillämpa policyer, hantera anslutningar och skicka ut telemetridata med en Flex Gateway. Denna gateway finns på utgående vägar från förmedlare och agenter till externa tjänster.
5. Samla in loggar, mått och spår från Flex Gateway och körtider i Anypoint Monitoring.

Det är frestande att göra alla specialiserade agenter omedelbart tillgängliga i en platt, obegränsad arkitektur, med en enskild orkestrerare som kan hantera alla uppgifter genom att ha åtkomst till alla tillgängliga AI-tillgångar. Detta tillvägagångssätt visar sig dock snabbt inverka negativt på det övergripande systemets effektivitet och pålitlighet. Precis som med principen för överskott av individuella verktyg, medför många agentalternativ betydande brus och komplexitet för den centrala mäklaragenten (eller orkestreraren). Denna ökade komplexitet leder direkt till en märkbar minskning av både precisionen i mäklarens beslutsfattande (att välja rätt agent för jobbet) och determinismen i systemets svar (förutsägbara, enhetliga resultat för liknande sökfrågor). Brokeragenten lider effektivt av alternativförlamning, vilket leder till långsammare och mindre pålitlig dirigering.

Istället för en platt struktur förespråkar vi starkt en hierarkisk metod i flera nivåer för att strukturera agentnätverket. Denna organisationsprincip erbjuder många viktiga fördelar. För det första gynnar det i sig spårbarhet och förvaltning. En hierarkisk struktur återspeglar etablerade rekommenderade metoder för organisationen, vilket gör det enklare att granska flödet för en begäran, felsöka problem genom att hitta fellagret och hantera distribuering och tillbakadragande av specifika agenter eller undernätverk.

För det andra, och framför allt i sammanhanget med stora språkmodeller (LLM) som driver dessa agenter, hjälper en hierarki dramatiskt till att hålla sammanhangsstorlekarna i schack. Genom att segmentera agentlandskapet överväger agenten vid ett givet lager endast den begränsade uppsättningen agenter eller undermäklare direkt under det. Denna struktur förhindrar att den primära orkestreraren läser in beskrivningen, kapaciteten och det historiska sammanhanget för varje agent i sitt arbetsminne, vilket undviker risken att snabbt överskrida gränserna för LLM:s sammanhangsfönster och drabbas av oöverkomliga kostnader och latens.

Agentnätverket kan implementeras på flera sätt. Två av dem är:

1. Conways lag - Intuitivt sätt att mappa den till den verkliga hierarkiska strukturen.
2. Domändriven design - Mer fokuserat på affärsdomäner

Alternativ 1: Mappning med verklig hierarkisk struktur

I en hierarkisk organisation flödar kommunikation vertikalt - från chefer till underordnade - och beslut är ofta centraliserade. Enligt Conways lag:

• De system eller programvaruarkitekturer som byggs av sådana organisationer tenderar också att vara skiktade och hierarkiska.
• Varje team tenderar att utforma delsystem som återspeglar dess egna gränser och befogenheter.
• Gränssnitten mellan systemen återspeglar kommunikationskanalerna mellan avdelningarna.

Agentnätverket kan även intuitivt mappas till den verkliga hierarkiska strukturen i ett stort företag enligt Conways lag.

• Konceptuell modell: Precis som ett företag har olika avdelningar, avdelningar och ledningsnivåer (till exempel C-suite, VP:er, direktörer, chefer) kan ett agentnätverk som arbetar inom en specifik domän modelleras som ett parallellt organisationsschema.
• Noder och löv: I denna hierarki:
  • Löv i trädstrukturen är specialistagenter eller MCP. De är de funktionella enheter som utför det faktiska arbetet (till exempel en "Databasfrågeagent", en "Kundautentiseringsagent", en "Känsloanalysagent"). De representerar de enskilda medarbetare eller arbetsenheter i organisationen.
  • Alla andra noder i hierarkin, inklusive rot- och mellanlager, är brokeragenter (eller underorkestrerare). Dessa agenter utför inte den slutgiltiga uppgiften men är ansvariga för dirigering, delegering, aggregering och konfliktlösning inom deras specifika domän eller lager. En mäklare på hög nivå delegerar en uppgift till en "Försäljningsdomänmäklare", som i sin tur delegerar till en "Säljprojekthanteringsmäklare", som utför uppgiften via en "Säljprojektstatusuppdateringsagent" (bladet).

Denna struktur säkerställer att komplexitet hanteras lokalt, att sammanhanget hålls och att systemet kan skalas upp på ett förutsägbart och tillförlitligt sätt. Du kan introducera nya specialistagenter i specifika, lämpliga grenar av organisationsträdet.

Tänk på analogin av ett organisationsschema för digitalt arbete. Varje YAML-fil representerar var och en av de interna organisationerna (Medarbetarframgång, Säkerhet, Ekonomi och så vidare). Inom varje organisation (agentnätverk) kan du ha en hierarkisk struktur som aktörer samarbetar genom, jobb delas upp i uppgifter och tilldelas. I föregående diagram flödar kommunikationen uppifrån och ner. Och löven är inte begränsade för konsumtion endast av en uppsättning agenter.

Modellering av agentnätverk baserat på det mänskliga organisationsschemat medför risk för att kräva frekvent omarkitektur, särskilt i företag som ofta omorganiseras. En alternativ metod är att organisera agenter efter funktionell domän. Denna gruppering kan kräva att man överskrider traditionella mänskliga organisationsgränser. Anta till exempel att nyanställdas introduktion innefattar IT-operationer för hårdvara och användarprovisionering, medan en säljrörelse kräver både operation och marknadsföring.

Nikhil Aggarwal är chefsarkitekt på Salesforce, där han leder arkitektur för MuleSoft och Salesforce Automation Clouds. Nikhil har över 18 års erfarenhet av att leverera storskaliga produkter och brinner för skalbar arkitektur, intuitiva utvecklarupplevelser och att bygga högpresterande team. Innan Salesforce ledde han flera initiativ i Microsoft Power Platform, Dataverse och Office 365 från koncept till lansering. Hans arbete fortsätter att forma hur moderna företag ansluter system, automatiserar arbetsflöden och frigör affärsvärde i den AI-första eran.

Mariano Gonzalez började på MuleSoft i början av 2011, specialiserad på verksamhetskritiska distribuerade system, integration, PaaS och molntjänster. Idag fokuserar Mariano på att utveckla AI-plattformar, med särskild uppmärksamhet på styrning, orkestrering, upptäckt och observerbarhet. Med över 20 år i IT-branschen har Mariano arbetat som programvaruarkitekt och teamledare och designat och levererat BPM-, ERP- och integrationslösningar inom jordbruks-, energi-, myndighets-, IT-, telekom- och innehållshanteringssektorerna.

Pedro Colunga är arkitekt inom programvaruteknik på Salesforce, specialiserad på API och metadataarkitektur. Med fokus på hela plattformens livscykel spelar Pedro en nyckelroll i att forma hur organisationer interagerar med systemintelligens, semantik och metadatadrivna lösningar. Pedros 20-åriga karriär, som inkluderar entreprenörserfarenhet, sträcker sig över företag som Fuego, BEA Systems, Oracle och TekGenesis, ett företag som senare förvärvades av MuleSoft, där han konsekvent har drivit plattformsvis arkitektur, med djup expertis inom områden som BPM, RAD och integrationer.

Gulal Kumar är arkitekt inom programvaruteknik på Salesforce, med fokus på data- och integrationsarkitektur. Med över 20 års erfarenhet av integrering och API, moderniseringsprogram, säkerhet och AIML-initiativ bidrar han med en mängd expertis. Gulal har engagerat sig i att främja initiativ för verksamhetstransformation, förbättra säkerhet och motståndskraft, främja arkitekturexcellens och leda AIML-initiativ över olika domäner.