MCP: Gi agenter tilgang til alt de trenger

MCP: Gi agenter tilgang til alt de trenger

Lansert av Anthropic i november 2024, løser Model Context Protocol et grunnleggende problem: hvordan gir du en AI-agent sikker, standardisert tilgang til verktøy, data og arbeidsflyter uten å bygge tilpassede integrasjoner for hver enkelt tilkobling? [1]

MCP opererer på tre kjerneelementer som speiler hvordan menneskelige ingeniører jobber. Verktøy er funksjoner agenten kan kalle - som å kjøre kode, sende e-post eller spørre APIer. Ressurser er datakilder agenten kan lese - databaser, filer, dokumentasjon eller sanntidsfeeder. Prompts er gjenbrukbare maler som standardiserer hvordan agenter tilnærmer seg vanlige oppgaver [3].

Protokollen kjører på JSON-RPC 2.0, som betyr at den er lett, sikker og kjent for enhver utvikler som har bygget webtjenester. Det som gjør den kraftig er toveis tilkoblingsmodellen: agenter kan både be om tilgang til ressurser og motta push-varsler når data endres. Din deployment-agent sjekker ikke bare serverstatus - den får varsel i det øyeblikket noe går galt [1].

Adopsjonstallene forteller historien. Bedrifter konfigurerer MCP-tilkoblinger på 15-30 minutter og lanserer 50+ verktøyintegrasjoner innen 90 dager. Store plattformer som VS Code, AWS, Sourcegraph og Replit har allerede integrert MCP-støtte. I desember 2025 donerte Anthropic protokollen til Linux Foundations Agentic AI Foundation, som signaliserer at dette ikke bare er enda et leverandørspill - det er infrastruktur [4].

Slik ser dette ut i praksis: En kodeassistent-agent bruker MCP for å få tilgang til ditt Git-repository (ressurs), kalle ditt testrammeverk (verktøy) og anvende din kodegjennomgangsmal (prompt). I stedet for tre separate integrasjoner får du én standardisert tilkobling som fungerer på tvers av alle MCP-kompatible systemer.

A2A: Agenter som faktisk samarbeider

Mens MCP håndterer agent-til-verktøy-forholdet, takler Googles Agent-to-Agent Protocol det vanskeligere problemet: hvordan oppdager, kommuniserer og koordinerer autonome agenter med hverandre på tvers av organisatoriske grenser? [2]

A2A, annonsert i april 2025, introduserer Agent Cards - standardiserte profiler som ligger på .well-known/agent.json-endepunkter, likt hvordan nettsteder publiserer robots.txt-filer. Disse kortene annonserer hva en agent kan gjøre, hvilke oppgaver den aksepterer, og hvordan man autentiserer med den. Det er tjenesteoppdagelse for AI-æraen [2].

Protokollens oppgavelivssyklusmodell speiler hvordan ingeniørteam faktisk jobber. Oppgaver beveger seg gjennom tilstander: Innsendt, Arbeider, Fullført. Agenter kan utveksle meldinger, dele artefakter (filer, JSON-data eller rik tekst) og håndtere autentisering gjennom OAuth 2.0 med PKCE. Avgjørende er at A2A støtter asynkrone operasjoner med push-varsler - agenter trenger ikke å konstant polle hverandre for oppdateringer [5].

Støtten er imponerende: 50+ partnere inkludert Salesforce, Accenture, MongoDB, LangChain, SAP, Atlassian, McKinsey og Deloitte. Google flyttet protokollen til Linux Foundation i juni 2025, noe som gjør den til leverandørnøytral infrastruktur [2].

Tenk på et scenario for programvaredistribusjon: Din CI/CD-agent (Agent A) må koordinere med en sikkerhetsskanning-agent (Agent B) og en varslings-agent (Agent C). Med A2A oppdager Agent A de andre agentene via deres publiserte kort, sender inn oppgaver med spesifikke krav og mottar statusoppdateringer etter hvert som arbeidet pågår. Ingen tilpassede APIer, ingen leverandørlåsing, ingen integrasjonshelvete.

Hvordan MCP og A2A fungerer sammen: Den komplette stakken

Magien skjer når du kombinerer begge protokollene. MCP håndterer vertikal integrasjon (agent-til-verktøy), mens A2A håndterer horisontal koordinering (agent-til-agent). Som en ekspert sa det: "MCP handler om å forankre agenter med verktøy og data. A2A handler om å la agenter jobbe sammen på tvers av grenser" [6].

Her er et virkelig eksempel som viser kraften i denne kombinasjonen:

Scenario: Automatisert kundeinnføring

1. Orkestrator-agent mottar en ny kunderegistrering
2. Via MCP: Får tilgang til kundedatabase (ressurs) og valideringsverktøy (verktøy)
3. Via A2A: Oppdager og koordinerer med spesialiserte agenter:
   • Identitetsagent: Oppretter kontoer i auth-systemer (bruker MCP for LDAP/OAuth-verktøy)
   • Provisjoneringsagent: Setter opp infrastruktur (bruker MCP for sky-APIer)
   • Kommunikasjonsagent: Sender velkomst-e-poster (bruker MCP for e-post/SMS-verktøy)
4. Via A2A: Alle agenter rapporterer fremgang tilbake til orkestrator
5. Via MCP: Orkestrator logger fullføring til revisjonssystem

Hver agent er en spesialist med dyp verktøytilgang via MCP, men de koordinerer som et team via A2A. Det er som å ha en senioringeniør som kan bruke hvilket som helst verktøy (MCP) lede et distribuert team på tvers av avdelinger (A2A).

Implementering i virkeligheten: Hva som faktisk fungerer

Etter å ha bygget med begge protokollene, er her hva vi har lært som fungerer - og hva som ikke gjør det.

Start med MCP for enkelt-agent arbeidsflyter. Python SDK-ene er modne, og du kan få en grunnleggende agent tilkoblet dine verktøy på under en time. Vi har sett nordiske selskaper bruke dette mønsteret for stemme-AI-systemer som trenger tilgang til telefoni-APIer, kundedatabaser og varslingstjenester [1].

Legg til A2A for multi-agent koordinering. GitHub-eksemplene er solide, men forvent å bruke tid på orkestreringslageret. Du trenger noe som kan oversette mellom MCP-stil verktøykall og A2A-stil oppgavedelegering. Tenk på det som å bygge "mellomledelse"-laget for agentteamet ditt [2].

Utfordringene er reelle. Latens forsterkes i agentkjeder - en fem-agent arbeidsflyt kan lett nå 10+ sekunder ende-til-ende. Feilsøking av distribuerte agentsystemer er vanskeligere enn feilsøking av distribuerte mikrotjenester fordi agenter tar autonome beslutninger du ikke kan forutsi. Tilstandshåndtering på tvers av asynkrone agentsamtaler blir komplekst raskt [7].

Men verdien er umiddelbar. Et nordisk teleselskap vi jobber med reduserte kompleksiteten i kundeservice-integrasjonen med 70% ved å bruke MCP-tilkoblinger. I stedet for å vedlikeholde 15+ tilpassede API-integrasjoner har de agenter som kan få tilgang til alle kundedata eller utløse enhver arbeidsflyt gjennom standardiserte MCP-ressurser og verktøy.

Den nordiske muligheten: AI-native infrastruktur

Nordiske land har alltid prestert over sin vektklasse i infrastrukturspill - fra Ericssons telekom-dominans til Spotifys streaming-arkitektur. MCP og A2A representerer samme type grunnleggende mulighet i AI-æraen.

Timingen er perfekt. AI-agentmarkedet er anslått å vokse fra 5,9 milliarder dollar i 2024 til 105,6 milliarder dollar innen 2034 - en 38,5% CAGR [4]. Men enda viktigere, 88% av ledere piloterer eller skalerer allerede autonome agenter, og 85% integrerer agenter i kjernearbeidsflyter [4]. Dette er ikke fremtidsteknologi - det skjer nå.

Nordiske selskaper som bygger AI-produkter har en unik fordel: dyp ekspertise innen protokolldesign og distribuerte systemer, kombinert med pragmatiske tilnærminger til standardisering. Selskaper som Telenor kunne bygge agent-orkestreringsplattformer som koordinerer stemme-AI, nettverkshåndtering og kundeservice-agenter på tvers av hele deres infrastruktur.

Post-kode-æraen betyr ikke ingen programmering mer - det betyr programmering på agent-orkestreringsnivet. I stedet for å skrive funksjoner designer du agentteam. I stedet for å feilsøke kode optimaliserer du agent-samarbeidsmønstre. Dømmekraften som kreves er på høyere nivå, men mer virkningsfull.

Hva endres når agenter bygger programvaren

Vi er vitne til fremveksten av det vi kaller "agent-native arkitektur" - systemer designet fra grunnen av for at AI-agenter skal oppdage, koble til og samarbeide. Dette er ikke bare automatisering av eksisterende arbeidsflyter; det er et grunnleggende skifte i hvordan programvaresystemer komponeres og opereres.

Tradisjonell programvareutvikling følger et mønster: krav → design → kode → test → distribuer. Agent-native utvikling følger et annet mønster: kapasiteter → oppdagelse → orkestrering → tilpasning. Du bygger ikke funksjoner - du komponerer agentteam med komplementære kapasiteter som kan tilpasse seg endrede krav i sanntid.

Protokollene gjør dette mulig i stor skala. MCP sikrer at agenter har pålitelig tilgang til verktøyene og dataene de trenger. A2A sikrer at de kan finne og koordinere med andre agenter på tvers av organisatoriske grenser. Sammen skaper de "Internett av agenter" - et distribuert system hvor AI-agenter kan samarbeide like enkelt som mennesker bruker nettlesere.

Implikasjonene er dype. Programvareteam vil skifte fra å skrive kode til å designe agent-orkestreringar. Produktutvikling vil akselerere fordi agenter kan prototype, teste og iterere raskere enn menneskelige utviklere. Men dømmekraften som kreves - å vite hvilke agenter som skal distribueres, hvordan man strukturerer deres samarbeid, og når man skal gripe inn - blir mer kritisk enn noen gang.

Som en ekspert bemerket: "Vi er i begynnelsen av det som føles som HTTP-øyeblikket for AI-agenter" [6]. Akkurat som HTTP muliggjorde nettet ved å standardisere hvordan datamaskiner deler informasjon, standardiserer MCP og A2A hvordan AI-agenter deler kapasiteter. Selskapene som mestrer disse protokollene først vil bygge plattformene som definerer det neste tiåret med programvare.

Kode blir gratis. Dømmekraften til å orkestrere AI-agenter til effektive team - det er der verdien ligger.

Kilder

1. https://www.anthropic.com/news/model-context-protocol
2. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability
3. https://modelcontextprotocol.io/docs/getting-started/intro
4. https://natoma.ai/blog/the-emergence-of-ai-agent-protocols-comparing-anthropic-s-mcp-ibm-s-acp-and-google-s-a2a
5. https://a2a-protocol.org/latest
6. https://dr-arsanjani.medium.com/complementary-protocols-for-agentic-systems-understanding-googles-a2a-anthropic-s-mcp-47f5e66b6486
7. https://www.gravitee.io/blog/googles-agent-to-agent-a2a-and-anthropics-model-context-protocol-mcp
8. https://www.clarifai.com/blog/mcp-vs-a2a-clearly-explained