I det utviklende landskapet for flere agenter er agenter mest effektive når de tildeles spesifikke, detaljerte oppgaver. Dette krever et mangfoldig nettverk av gjenbrukbare, spesialiserte agenter. Kjerneutfordringen er imidlertid å koordinere disse mange, heterogene agentene, som kan komme fra forskjellige kilder, for å samarbeide effektivt mot felles forretningsmål. Uten en forent plattform fører denne kompleksiteten til agentenes spredning og et kritisk mangel på styring.

Disse AI-agentene multipliseres raskt, bygges inn i SaaS-plattformer, utvikles internt eller pakkes med populære LLM-er. Denne multiplikasjonen fører til frakoblede organisasjonsenheter. En agent optimaliserer oppgaver i sine innebygde programmer, men mangler ofte en helhetlig forretningsoversikt. Denne mangelen på synlighet hindrer agenter i å effektivt orkestrerer, sikrer og styrer handlinger på tvers av forskjellige domener og systemer.

MuleSoft Agent Fabric løser utfordringen med å håndtere "agentspredning" og muliggjøre en sømløs orkestrering av ulike agenter, uavhengig av opphav. Den etablerer anbefalte arkitektoniske fremgangsmåter og gir de nødvendige verktøyene for å opprette Agent-nettverket. Et agentnettverk henviser til en koordinert samling AI-agenter, -verktøy og -ressurser som arbeider sammen for å utføre komplekse, flertrinns forretningsprosesser.

MuleSoft Agent Fabric er en forent plattform som gir alle virksomheter en enkel måte å oppdage, orkestrere, styre og observere alle agenter uansett hvor de er bygd.

Oppdag: Agentregister har en sentralisert katalog over alle AI-agenter og -verktøy i hele organisasjonen. Den aktiverer oppdagelse og gjenbruk av internt bygde, SaaS-innebygde og eksterne aktiva. Ved å tilby en enkelt sannhetskilde for alle agentiske aktiva eliminerer Agentregister overflødighet og sikrer at utviklere kan benytte eksisterende funksjoner i stor skala.

Orkestrat: MuleSoft Agent Broker er en intelligent rutingsløsning som dynamisk samsvarer oppgaver med agenten eller verktøyet som passer best. Drives av en LLM du velger, koordineres det på tvers av agenter og verktøy for å sikre at komplekse forespørsler med flere trinn og forretningsprosesser utføres med høy pålitelighet og sporbare utfall.

Regjeringen: MuleSoft Agent Governance benytter Flex Gateway og dens støtte for Model Context Protocol (MCP) og Agent2Agent (A2A) protokoll. Med Flex Gateway kan virksomheter håndheve sikkerhets- og samsvarspolicyer for hver agent-agent- og agent-verktøy-interaksjon.

Observer: Agent Visualizer gir observasjon i sanntid via et dynamisk, interaktivt kart over agentinteraksjoner. Den sporer beslutninger, overvåker systemtilstanden og muliggjør dermed kontinuerlig optimalisering og pålitelig oversikt over hele agentøkosystemet.

Agent Fabric støtter en YAML-tilnærming (spesifikasjon først) der brukere definerer agentnettverk via en metadatadeskriptor (YAML-filen). Denne YAML-filen er agnostisk for MuleSoft, og den kobler definisjonen av agentnettverket fra utførelsen.

Hvert agentnettverk (YAML) definerer et bestemt funksjonelt område med sine agentiske aktiva, inkludert sine driftsregler og policyer. YAML brukes til å aktivere de fire Agent Fabric-stolpene:

1. Oppdag: Fyll ut agentregisteret med eksisterende agentaktiva, som:
   1. Agenter distribuert på tvers av ulike plattformer (MuleSoft eller andre)
   2. MCP-servere
   3. LLM-leverandører
2. Orchestrate (Orkestrer): Opprette agentmeglere for orkestrering
3. Administrer: Bruk policyer på aktivaene for sikkerhet og styring
4. Observer: Definer og gjenbruk tilkoblinger til de definerte aktivaene. Observabilitet og overvåkingsfunksjonalitet er også tilgjengelig for agentnettverk.

Brukerreisen starter i Anypoint Code Builder. Bruk den nye kommandoen som er tilgjengelig via kommandopaletten kalt MuleSoft: Opprett et Agent-nettverksprosjekt" for å opprette et nytt prosjekt. Denne kommandoen oppretter et nytt prosjekt (Agentnettverk) som inneholder to filer.

• agent-network.yaml: Denne filen definerer konfigurasjon for fleragentsystemet og aktiverer orkestrering av AI-agenter med eksterne verktøy (via MCP) og agenter (via A2A-protokoll). Dette formatet gir en deklarativ måte å definere agentfunksjoner, avhengigheter og integrasjoner på.

• exchange.json: Alle agentnettverksprosjekter har også en exchange.json-fil. Denne filen inneholder aktivummetadata som er tilgjengelig i Anypoint Exchange etter at agentnettverksaktiva har blitt publisert.

Utviklingen av agentnettverket følger en standard livssyklus for programvareutvikling (SDLC) som involverer fire hovedfaser:

1. Miljøoppsett: Konfigurere kjøretidsmiljø og gatewayer
2. Prosjektoppretting og utforming: Opprette agentnettverksprosessspesifikasjon
3. Bygging og publisering: Bygge og publisere aktiva i Agent-registeret
4. Distribusjon: Distribuere eller promotere agentnettverket til et gitt miljø

Når du har bygd prosjektet og generert det nødvendige MuleSoft-programmet og -aktivaene, gjør du dem tilgjengelig i Exchange. I Anypoint Code Builder utløser du bygg- og publiseringsprosessen ved å bruke MuleSoft: Publiser Agent Broker Project to Exchange"-kommandoen er tilgjengelig via kommandopaletten.

Publiseringstrinnet transformerer hvert agentisk aktivum i YAML-filen til en A2A-, MCP- eller LLM-spesifikasjon og publiserer det til Exchange.

I tillegg publiserer systemet YAML til Exchange ved å bruke en ny aktivumtype agent-nettverk. Du kan vise dette aktivumet i Agentregister-grensesnittet og søke etter det via Exchange API.

Se en Agentnettverk-fil som definerer et agentnettverk for et foretak. Dette agentnettverket aktiverer nettverket for bestillingsinnfrielse på tvers av Salesforce, Stripe, en annen bestillingsinnfrielsesagent og MCP-server for lagerbeholdning med en enkelt, policyadministrert opplevelse.

• Oppdag
  Publiser eksisterende agenter og verktøy (som Salesforce, Stripe, Bestillingsinnfrielse og Lagerbeholdning) som Exchange-aktiva for gjenbruk. Også bestillingsinnfrielsesdefinisjonen (YAML) som er versjonert og kan deles, og som muliggjør rask tilpassing for roller, regioner eller underordnede uten å bygge flyter på nytt.
• Orkestret
  En agentmegler bruker en LLM til å dele opp bestillingsinnfrielsesprosessen i en sekvens av oppgaver, som å bekrefte kundedetaljer, tildele lagerbeholdning og beregne fraktkostnader. Den utfører deretter denne arbeidsflyten ved å kalle opp MCP- og A2A-agenter, slik at det blir bedt om godkjenninger av personer i sløyfe når det er nødvendig.
• Govern
  Anypoint Flex Gateway håndhever godkjenning, tilgang med færrest rettigheter og vakthull. API Manager-policyer sikrer konsistente kontroller på tvers av alle samtaler og datautvekslinger.
• Observer
  Overvåking og sporing gir ende-til-ende-synlighet til fremdrift, feil og latens. Visualisering viser hvilke agenter som samhandlet og hvor flaskehalser oppstod.
• Trust and Compliance
  Sentralisert legitimasjon, revisjonsspor og arv av policyer støtter sikkerhet, personvern og lovpålagte krav (Håndtering av PII, godkjenninger og separasjon av oppgaver).

Diagrammet viser de forskjellige nodene i Agent-nettverket (metadata) som er definert i YAML.

• Formål: Exchange er katalogen for agenter, verktøy og andre aktiva. Dens primære mål er å løse "agentutvidelse" ved å tilby en enkelt, styrt katalog for oppdagelse, kurering og livssyklusbehandling av heterogene agenter. Den gir utviklere mulighet til å finne og gjenbruke agenter, plattformeiere for å opprettholde synlighet og orkestrerere for å oppdage funksjoner.
• Heterogene etter design: Anypoint Exchange støtter nå tre nye aktiva - Agenter, MCP-er og LLM-er. Exchange er utformet for å være en universell katalog for registrering og behandling av alle typer agenter. Den støtter A2A-kompatible agenter, MCP-servere og LLM-leverandører fra alle kilder, inkludert tredjeparts agenter, Agentforce og tilpassede MuleSoft-agenter.
• Kjernemetadata: Hvert registrerte aktivum har et grunnleggende sett med uforanderlige metadata, inkludert unike navn og versjon, eierskap og publisering. Livssyklustatuser (utvikling, oppstilling, produksjon, forhindret) spores også.
• Oppdagelse:
  • Designtid: Utviklere kan oppdage registrerte agenter enten via det eksisterende Exchange-grensesnittet eller via søk med naturlig språk med Vibes i Anypoint Code Builder.
• Koding og klassifisering: Aktiva kan klassifiseres etter type (agent, MCP, LLM, megler) og domene (for eksempelHR, vær) ved å bruke et grunnleggende nøkkelverdikodesystem som aktiverer dynamisk lenking, søk og utvelgelsespolicyer.
• Katalog: Oppbevaringsstedet støtter både private og interne katalogmodeller for delingsagenter i en organisasjon.
• Visualisering: Gir et visuelt verktøy for å støtte nettverksvisninger, som viser tilkoblinger for enkeltaktiva eller hele kartet over noder og lenker på tvers av organisasjonen, med filtreringsfunksjoner.

Meglere i et agentnettverk kan referere til registrerte agenter, MCP-servere og LLM-leverandører som er lagret i Anypoint Exchange. Men hvis de ikke allerede er registrert, kan de deklareres i metadataene i Agentnettverk (YAML) og de blir registrert automatisk. I eksemplet er flere agenter, MCP-servere og LLM-leverandører erklært og registrert i Anypoint Exchange.

En agentmegler er en intelligent rutingsagent som koordinerer oppgavedelegering på tvers av spesialiserte agenter i et foretak. Den defineres av agentene og MCP-serverne som den bruker til å utføre oppgaver.

En megler er en spesialisert agent som vises i Anypoint Exchange etter publisering av et agentnettverksaktivum og gjenbruk av andre meglere.

Meglere er definert i delen meglere i YAML. De definerte meglere er gjennomsiktig "kompilert" i en applikasjon, uten å kreve noen forutgående Knowledge om Mule. Dette genererte programmet distribueres til CloudHub 2.0 (CH2) og benytter den robuste CH2-infrastrukturen.

Det betyr at agentmeglere drar nytte av CloudHub 2.0s etablerte ytelsesegenskaper, inkludert dens loggings- og målingsfunksjoner. Driftsaspekter, som "Kostnad for drift" og "Overvåking/Varsler/Verktøy", er de samme som alle andre arbeidsbelastninger.

For scenarier som krever menneskelig intervensjon (Menneske i sløyfe), opprettholdes tilstanden til hver interaksjon ved å bruke MuleSoft Object Store, en distribuert løsning utformet for effektiv tilstandsbehandling i svært samtidige miljøer.

En meglerdefinisjon består av to deler: kort og spesifikasjoner.

Kortdelen følger Agent-til-agent-spesifikasjonen (A2A). Den beskriver blant annet megleragentens kontrakt, kvalifikasjoner og funksjoner. Kort-URL-adressen fylles automatisk ut med verdien ${ingressgw.url}/broker-name. Ved distribusjon erstattes ${ingressgw.url}-plassholderen automatisk med URL-adressen til Anypoint Flex-gatewayen som frontlegger forespørslene om agentinntak.

Spesifikasjonsdelen konfigurerer "kildekoden" til megleren. Her kan utvikleren angi LLM som skal brukes, instruksjoner, tilgjengelige verktøy, feilhåndtering og viktigst av alt de ulike agentene og MCP-verktøyene som er tilgjengelig for denne megleren.

LLM-leverandører

Denne delen er en del av spesifikasjonen i hver megler. Dette er en referanse til en av LLM-ene som er definert i tjenestedelen. Vi kan velge om vi vil dele én LLM på tvers av alle meglerne, eller om nødvendig få forskjellige meglere til å bruke LLM som passer bedre til oppgavene.

Meglere kan peke til LLM-leverandører. Vi kan velge modeller av disse leverandørene avhengig av våre behov.

Instruksjoner

Denne delen er valgfri, og du kan bruke den til å angi instruksjoner spesielt for denne megleragenten. Disse instruksjonene fokuserer ofte på spesifikke forretningsorienterte bekymringer. Tenk deg for eksempel en kundeserviceagent som koordinerer administrasjonen av kunderapporterte hendelser:

Legg merke til at det ikke er nødvendig å gi eksplisitte instruksjoner, som "oppdel ledeteksten i oppgaver" eller "velg det beste verktøyet", da megleren håndterer det alene. Disse instruksjonene er bare nødvendige når du beskriver bestemte forretningsprosesser.

Verktøykonfigurasjon

Verktøy gir agenter ekstern funksjonalitet. Når en megler trenger tilgang til et eksternt system (som ikke er en annen agent, for eksempel en eksisterende API eller en SaaS-tjeneste), kontakter den en MCP-server (Model Context Protocol):

Det refereres til MCP-serveren med navnet på bytteaktivumet. Tilkoblingsdetaljene for den er angitt i tjenestedelen.

Som standard har megleren tilgang til alle verktøyene som er tilgjengelig på MCP-serveren. Ifølge vår observasjon kan de mest moderne LLM-ene bare håndtere rundt 20-25 verktøy per kontekst før de begynner å generere unøyaktigheter (eller miste kontekst). Derfor er det generelt en god fremgangsmåte å begrense tilgjengelige verktøy til det minste som er nødvendig. Du kan bruke denne filtreringen gjennom de tillatte listene.

Agentlenker

Denne delen er den viktigste delen av hele definisjonen. Lenkedelen aktiverer interagentkommunikasjon og orkestrering. Det betyr at denne megleren er avhengig av agentene som er koblet til her, for å utføre de riktige handlingene for å fullføre brukerens mål.

Denne delen definerer faktisk et agent-nettverk for samarbeid.

Agentstyring er en viktig søyle for Agentfabrikk, som er grunnleggende for å bygge et klarert agentnettverk og sikre sikkerhet og samsvar.

For styring kreves det totalt to Flex-gatewayer (1 inngang og 1 utgang) i det private området.

Styring etablerer de nødvendige strukturene, kontrollene og bevisene for å skalere hele agentutviklingslivssyklusen (ADLC) sikkert. Spesifikt implementerer styring viktige prosesser som agentsertifisering, katalogisering, livssyklusbeslutninger og håndheving av kjøretidspolicyer.

• Katalog:
  • Exchange (Bytte): Støtter opptak av agentformål, eiere, miljøer og grenser for data og klassifisering. Den registrerer også funksjoner, verktøy, ressurser, ledetekster og eksterne avhengigheter med versjoner.
• Versjoner og livssyklus:
  • Dokumenter og behandle semantisk versjonsbehandling av agenter, verktøy og aktiva i løpet av den fullstendige livssyklusen for agentutvikling.
  • Versjoner bidrar til å behandle agentforhindringstidslinjer og støtter dobbelt kjøring (der det er mulig) for å sikre problemfrie overføringer.
• Policy Enforcement:
  • Agentisk AI-arkitektur utvider angrepsflaten (samtalegrensesnitt, ledetekster og nye protokoller som MCP). Eventuell kompromiss med komponenter kan føre til gjennomgripende effekter på flere systemer som leverer komponenter som protokoll, ledetekst, API eller verktøy.
  • Sikring av agentiske AI-distribusjoner krever en spesialisert tilnærming fordi disse autonome og uforutsigbare miljøene i utgangspunktet utvider angrepsflaten gjennom agent-til-agent-interaksjoner. Eksisterende sikkerhetsverktøy for statiske systemer er viktig, men de er ikke lenger tilstrekkelige alene. Virksomheter må proaktivt planlegge og implementere fire spesifikke sikkerhetsløsninger, som hver tar direkte hånd om en kritisk forretningsrisiko knyttet til agentisk AI.
  • Flex Gateway: All A2A- og MCP-trafikk rutes via Flex Gateway, selv om målsystemet ikke er sikret, for å sikre at policyer brukes på hvert endepunkt. Denne rutingen er avgjørende for å sikre agentkommunikasjon og integrering med godkjenningsservere.
  • Policy-pakker: Brukere kan definere og bruke pakker med forhåndsdefinerte policyer på arbeidsflyter før de utføres, og håndheve et konsistent sett med sikkerhets- og driftspolicyer.
  • Typer poliser: Plattformen støtter ulike innkommende og utgående policyer, inkludert:
    • A2A-policyer: Agentkort, PII-detektor, Ledetekstdekorator, Skjemavalidering.
    • MCP-policyer: Attributtbasert tilgangskontroll, Skjemavalidering, MCP-støtte.
    • LLM/AI-policyer: AI-ledetekstdekorator, AI-ledetekstvakter (filtrering av skadelig innhold), AI-ledetekstmal (ved bruk av forhåndsdefinerte maler), AI Basic Token Rate Limiting.
    • Telemetripolicyer: A2A- og MCP-telemetri for å utvide Open Telemetry-løsninger for loggdatainnsamling og -eksport.
• Logge: Takket være automatisk sporing er logger på tvers av Agent-nettverket tilgjengelig for å spore hver agentinteraksjon, forklare virkemåter og bygge Trust.

Eksempelet viser en policy for meldingslogging, som konfigureres ved å bruke metadata fra agentnettverket. Orderfullfillment-megler refererer til en eksisterende agent kalt Salesforce-agent, og policyen for meldingene konfigureres ved å bruke metadataene. Vær oppmerksom på at Agent Fabric automatisk konfigurerer alle policyene som er nevnt under spesifikasjonsdelen i Flex Gateway. Du trenger ikke noen ekstra trinn.

Gitt den ikke-deterministiske naturen og kompleksiteten til LLM-agenter og distribusjoner med flere agenter, er observabilitet og overvåking avgjørende.

• Grunnleggende logger og sporinger: Årsaker og sporing av utførelse av verktøy gis via logger. Logger og sporinger fra arbeidsflytutførelser kan vises etter utførelse i Kjøretidsbehandling.
• Målinger: I den første fasen publiserer plattformen a2a_total_calls og mcp_total_calls som teller med etiketter (som bane, status, metode, verktøy) for å bestemme antall, vellykkede og mislykkede samtaler. Disse målingene publiseres fra policykode ved å bruke Envoy (Flex Gateway)-grensesnittet for innebygd statistikk, fortrinnsvis via eksisterende policyer som mcp_support_policy og a2a_agent_card_policy.
• Forbedret observabilitet (fremtid): Planene inkluderer å bruke Åpen telemetri til distribuert sporing i fremtidige versjoner. Mer avansert observabilitet inkluderer følgende:
  • Detaljert forespørselssporing: Få slutt-til-slutt-synlighet i forespørsler, omfattende ledetekster, planleggingsprosesser, kallede handlinger og interaksjoner med underagenter.
  • Agenttilstandsovervåking: Overvåker agentoppetid, responslatens, gjennomløp, feilfrekvenser og utnyttelse av underliggende ressurser (CPU, minne, nettverk, GPU).
  • Multiagent Coordination Monitoring: Registrer vellykkede og mislykkede interaksjoner mellom agenter, oppdag sirkulære oppkallsmønstre (sløyfer) og spor målinger per agent, som antall fullførte oppgaver og antall kall.
  • Kostsporing: Spor tokenbruk og tilknyttede kostnader for hvert LLM-kall, ideelt per agent, med kontrollpaneler og varsler.
  • Kognitive sporing: Registrering og visning av et detaljert spor av en agents økt, inkludert interne tankeprosesser og alle verktøykall, som fungerer som et uforanderlig revisjonsspor.
  • Agentsession-avspilling: Et brukergrensesnitt som gir mulighet til å visuelt "gjengi" en agents kognitive sporing trinn for trinn for dyp feilsøking.
  • DAG Visualisering: Tilby en Directed Acyclic Graph (DAG)-visualisering av agentarbeidsflytutføringen for komplekse interaksjoner med flere agenter.

Agentvisualisering brukes til å identifisere deler av agentnettverket og se hvordan de fungerer sammen.

• Skill nodetyper (agenter og MCP-servere).
• Vis kantene for å se erklærte og kjøretidsinteraksjoner.
• Bruk lag til å fokusere visninger på bestemte miljøer
• Åpne detaljkort for å inspisere metadata og målinger for noder og tilgangslogger og sporinger
• Se gjennom styringsindikatorer som Flex Gateway-beskyttelse og brukte policyer.

Finn detaljer om komponentene i Agent Visualizer heri.

Med disse fire stolpene samlet utvider MuleSoft Agent Fabric sikkerheten og kontrollen til alle agenter med innebygd styring. Den gir agenter mulighet til å handle hvor som helst ved å benytte seg av nye protokoller som A2A (agent til agent) og MCP (modellkontekstprotokoll) for å bygge og utvide forretningsprosessene. Vi kobler sammen alt - programmer, data og systemer - for å gi agenter muligheter og styre dem i hele virksomheten. Intelligent verktøy støtter opprettelse og utvidelse av forretningsprosesser eller API-er ved å bruke AI som standard eller ved å ta med AI-verktøy fra tredjepart.

Bruk av alle fire stolpene sammen er ikke nødvendig, men anbefales. Du kan velge stolper uavhengig etter behov. Du kan for eksempel benytte Agent Fabric til registrering og styring uten å bruke orkestreringslaget. På samme måte kan du bruke megleren til å orkestrere agenter som styres via en annen plattform.

Diagrammet viser hvordan alle de fire komponentene samhandler med hverandre:

1. Publiser agentiske aktiva til Anypoint Exchange for oppdagelse og gjenbruk etter at du har definert agentnettverket (meglere, agenter, MCP-servere) i agentnettverket YAML i Anypoint Code Builder.
2. Distribuer agentiske aktiva til CloudHub 2.0 (administrert i Kjøretidsbehandling).
3. Håndhev policyer for innkommende trafikk til nettverket med en Flex Gateway for inngang, som ligger foran megler- og API-endepunkter.
4. Håndhev policyer, behandle tilkoblinger og send ut telemetridata med en utgangs-Flex-gateway. Denne gatewayen ligger på utgående baner fra meglere og agenter til eksterne tjenester.
5. Innhent logger, målinger og sporinger fra Flex Gateway og kjøretider i Anypoint Monitoring.

Det er fristende å gjøre hver spesialisert agent umiddelbart tilgjengelig i en flat, ubegrenset arkitektur, med en enkelt orkestrator som kan takle hvilken som helst oppgave ved å ha tilgang til alle tilgjengelige AI-aktiva. Denne tilnærmingen viser seg imidlertid raskt å være skadelig for systemets generelle effektivitet og pålitelighet. På samme måte som prinsippet som brukes på et overskudd av individuelle verktøy, innfører mange agentalternativer betydelig støy og kompleksitet for sentral megleragent (eller orkestrator). Denne økte kompleksiteten fører direkte til en merkbar nedgang i både nøyaktigheten til meglerens beslutningstaking (velg den riktige agenten for jobben) og determinismen til systemets respons (forutsigbare, konsistente utfall for lignende spørringer). Megleragenten lider effektivt av alternativparalyse som fører til tregere og mindre pålitelig ruting.

I stedet for en flat struktur, foreslo vi sterkt en flernivå hierarkisk tilnærming til struktureringen av Agent Network. Dette organisasjonsprinsippet gir mange viktige fordeler. For det første favoriserer det iboende sporbarhet og styring. En hierarkisk struktur gjenspeiler etablerte anbefalte organisasjonsrutiner, slik at det blir enklere å revidere flyten for en forespørsel, feilsøke problemer ved å finne laget med feil og behandle distribusjon og tilbaketrekking av bestemte agenter eller undernettverk.

For det andre, og avgjørende i sammenheng med store språkmodeller (LLM-er) som driver disse agentene, hjelper et hierarki dramatisk med å holde kontekststststørrelser i kontroll. Ved å segmentere agentlandskapet vurderer megleragenten på et gitt lag bare det begrensede settet agenter eller undermeglere direkte under det. Denne strukturen hindrer at den primære orkestrereren laster inn beskrivelsen, funksjonene og den historiske konteksten til hver agent i sitt arbeidsminne, og unngår risikoen for raskt overskridelse av LLMs kontekstvindugrenser, og medfører prohiberende kostnader og latens.

Agentnettverket kan implementeres på flere måter. To av dem er:

1. Conways lov – Intuitiv måte å tilordne den til den hierarkiske strukturen i den virkelige verden på.
2. Domenestyrt utforming – mer fokusert på forretningsdomener

Alternativ 1: Tilordning med hierarkisk struktur i den virkelige verden

I en hierarkisk organisasjon flyter kommunikasjonen vertikalt – fra ledere til underordnede – og beslutninger sentraliseres ofte. I henhold til Conways lov:

• Systemene eller programvarearkitekturene som bygges av slike organisasjoner, har også en tendens til å være lagdelt og hierarkisk.
• Hvert team har en tendens til å utforme delsystemer som gjenspeiler sine egne grenser og myndigheter.
• Grensesnittet mellom systemer gjenspeiler kommunikasjonskanalene mellom avdelingene.

Agentnettverket kan også intuitivt tilordnes til den virkelige hierarkiske strukturen til en stor bedrift i henhold til Conways lov.

• Konseptmodellen: På samme måte som et firma har forskjellige divisjoner, avdelinger og lederlag (for eksempel C-suite, visedirektører, ledere), kan et agentnettverk som opererer innenfor et bestemt domene, modelleres som et parallelt organisasjonsdiagram.
• Noder og blader: I dette hierarkiet:
  • Bladene i trestrukturen er spesialistagentene eller MCP-ene. De er de funksjonelle enhetene som utfører det faktiske arbeidet (for eksempel en Databasespørringsagent, en Kundegodkjenningsagent, en Stemningsanalyseagent). De representerer de individuelle bidragsyterne eller arbeidsenhetene i organisasjonen.
  • Alle andre noder i hierarkiet, inkludert rot- og mellomlagene, er megleragenter (eller underorkestratorer). Disse agentene utfører ikke den endelige oppgaven, men er ansvarlige for ruting, delegering, aggregering og konfliktløsning innenfor sitt spesifikke domene eller lag. En megler på høyt nivå delegerer en oppgave til en "Sales Domain Broker", som i sin tur delegerer til en "Salgsmulighetsbehandling-megler", som utfører oppgaven via en "Oppdateringsagent for salgsmulighetsstatus" (bladet).

Denne strukturen sikrer at kompleksitet behandles lokalt, kontekst er inneholdt, og at systemet skaleres forutsigbart og pålitelig. Du kan introdusere nye spesialistagenter i bestemte, riktige grener i organisasjonstreet.

Vurder analogien til et organisasjonskart for digitalt arbeid. Hver YAML-fil representerer hver av de interne organisasjonene (ansattes suksess, sikkerhet, økonomi og så videre). I hver organisasjon (agent-nettverk) kan du ha en hierarkisk struktur der aktører samarbeider, jobber deles inn i oppgaver og tildeles. I det foregående diagrammet flyter kommunikasjonen fra øverst til nederst. Og bladene er ikke begrenset til forbruk bare av et sett av megleragenter.

Modellering av agentnettverk basert på det menneskelige organisasjonsdiagrammet medfører risikoen for å kreve hyppig ombygging, spesielt i firmaer som gjennomgår hyppige omorganisasjoner. En alternativ løsning er å organisere agenter etter funksjonelt domene. Denne grupperingen kan kreve å krysse tradisjonelle organisasjonsgrenser for mennesker. Introduksjon av nye ansatte involverer for eksempel IT-operasjoner for maskinvare og brukerklargjøring, mens en salgsbevegelse krever både operasjoner og markedsføring.

Nikhil Aggarwal er hovedarkitekt i Salesforce, der han leder arkitektur for MuleSoft og Salesforce Automation Clouds. Nikhil har over 18 års erfaring med å levere produkter i stor skala, og er opptatt av skalerbar arkitektur, intuitive utvikleropplevelser og å bygge team med høy ytelse. Før Salesforce ledet han flere initiativer i Microsoft Power Platform, Dataverse og Office 365 fra konsept til oppstart. Arbeidet hans fortsetter å forme hvordan moderne virksomheter kobler sammen systemer, automatiserer arbeidsflyter og låser opp forretningsverdi i AI-første æra.

Mariano Gonzalez sluttet seg til MuleSoft tidlig i 2011, og spesialiserte seg på oppgavekritiske distribuerte systemer, integrasjon, PaaS og skydatabehandling. I dag er Marianos fokus på å utvikle AI-plattformer, med spesiell oppmerksomhet på styring, orkestrering, oppdagelse og observasjon. Med over 20 år i IT-bransjen har Mariano fungert som programvarearkitekt og teamleder, og designet og leverte BPM-, ERP- og integrasjonsløsninger på tvers av sektorene landbruk, energi, myndigheter, IT, telekommunikasjon og innholdsbehandling.

Pedro Colunga er Software Engineer Architect på Salesforce, spesialisert seg på API og Metadata Architecture. Med fokus på hele plattformlivssyklusen spiller Pedro en nøkkelrolle i å forme hvordan organisasjoner samhandler med systeminformasjon, semantikk og metadatastyrte løsninger. Pedro's 20-årige karriere, som inkluderer entreprenørerfaring, spenner over firmaer som Fuego, BEA Systems, Oracle og TekGenesis, et selskap som senere ble kjøpt opp av MuleSoft, der han konsekvent har drevet plattformbasert arkitektur, og gir dyp ekspertise innen områder som BPM, RAD og Integrasjoner.

Gulal Kumar er Software Engineering Architect hos Salesforce med fokus på data og integrasjonsarkitektur. Med over 20 års erfaring innen integrasjon og API-er, moderniseringsprogrammer, sikkerhet og AIML-initiativer, har han en rik ekspertise. Gulal har vært forpliktet til å fremme forretningstransformasjonsinitiativer, forbedre sikkerhet og motstandskraft, fremme arkitektonisk dyktighet og lede AIML-initiativer på tvers av ulike domener.