Vezetői összefoglaló
Az AI ágensek egyedül is hasznosak — de együtt exponenciálisan erősebbek. Ahogy a microservice-ek forradalmasították a szoftverfejlesztést, az Agent-to-Agent (A2A) kommunikáció forradalmasítja az AI alkalmazásokat. De hogyan beszéljenek egymással az ágensek? Milyen protokollon? Ki dönt, ha két ágens ellentmondó javaslatot ad?
Ez a whitepaper három réteget vizsgál:
- Az A2A protokoll — a Google által 2025-ben publikált nyílt szabvány, ami az ágensek közötti kommunikáció HTTP-je akar lenni
- Az MCP (Model Context Protocol) — az Anthropic szabványa, ami az ágensek és a külső eszközök közötti kapcsolatot definiálja
- A gyakorlati multi-ágens architektúra — hogyan működik egy produkciós rendszer, ahol több ágens-szerepkör együttműködik
A whitepaper egy valós, multi-tenant SaaS rendszer implementációján keresztül mutatja be az elveket — kódrészletekkel, konfigurációs példákkal és architekturális döntésekkel.
1. A probléma: miért kell az ágenseknek „beszélniük"?
1.1 Az egyedülálló ágens korlátai
Egy tipikus AI ágens jól csinál egy dolgot: válaszol az ügyfélnek, vagy elemzi az emaileket, vagy feladatokat generál. De az üzleti valóságban a feladatok nem izoláltak:
Bejövő email: "Sziasztok! Holnap szeretnék időpontot a szokásos kezelésre."
Szükséges akciók:
1. Email értelmezése (intent detection) → Nyelvi ágens
2. Ügyfél azonosítása (CRM lookup) → CRM ágens
3. Szabad időpont keresése (calendar) → Naptár ágens
4. Foglalás létrehozása → Booking ágens
5. Megerősítő email küldése → Kommunikációs ágens
6. Bevétel-predikció frissítése → Analitikai ágens
Ha egyetlen „szuperágens" csinálja mindezt, az:
- Túl komplex system prompt-ot igényel (10+ oldalnyi instrukció)
- Nem skálázható (egy ágens nem tudhat mindent)
- Nem moduláris (nem tudod kicserélni a naptár-ágensre, ha jobb érkezik)
- Nehezen debuggolható (melyik rész hibázott a 6-ból?)
1.2 A microservice-analógia
A multi-ágens rendszer pontosan azt csinálja az AI-val, amit a microservice-ek csináltak a backend-del:
1.3 De hogyan kommunikáljanak?
Ha van 5 ágens, azoknak valahogy koordinálniuk kell. Két fő kérdés:
- Protokoll: Milyen formátumban küldjenek üzenetet egymásnak?
- Orchestráció: Ki dönt, mikor melyik ágens lép?
Erre ad választ az A2A és az MCP — de mást-mást.
2. Az A2A protokoll — a Google válasza
2.1 Mi az A2A?
Az Agent-to-Agent (A2A) protokoll a Google által 2025 áprilisában publikált nyílt szabvány. Célja: lehetővé tenni, hogy különböző fejlesztők, különböző platformokon futó AI ágensek szabványos módon kommunikáljanak egymással.
Az A2A az ágensek közötti kommunikáció „HTTP-je" akar lenni — ahogy a REST API-k szabványosították a service-ek közötti kommunikációt, az A2A az ágensek közöttit szabványosítja.
2.2 Az A2A alapfogalmai
2.3 Az Agent Card — az ágens „OpenAPI spec"-je
Minden A2A-kompatibilis ágens publikál egy Agent Card-ot (JSON):
{
"name": "CRM Agent",
"description": "Manages customer relationships, contacts, deals, and tasks",
"url": "https://api.example.com/agents/crm",
"version": "1.0.0",
"capabilities": [
{
"name": "lookup_customer",
"description": "Find customer by name, email, or phone",
"inputSchema": {
"type": "object",
"properties": {
"query": { "type": "string" }
}
}
},
{
"name": "create_deal",
"description": "Create a new sales deal",
"inputSchema": {
"type": "object",
"properties": {
"title": { "type": "string" },
"value": { "type": "number" },
"contactId": { "type": "string" }
}
}
}
],
"authentication": {
"type": "bearer",
"tokenUrl": "https://auth.example.com/token"
},
"protocol": "a2a/1.0"
}
Ez teszi lehetővé, hogy egy ismeretlen ágens is meg tudja szólítani a másikat: elolvassa az Agent Card-ot, megérti a képességeit, és szabványos formátumban küld kérést.
2.4 Az A2A task lifecycle
Client Agent Server Agent
│ │
│── POST /tasks/create ──────────────▶ │
│ { capability: "lookup_customer", │
│ input: { query: "Kiss Anna" } } │
│ │
│◀── 202 Accepted ─────────────────── │
│ { taskId: "task-42", │
│ status: "in_progress" } │
│ │
│── GET /tasks/task-42 ──────────────▶ │
│ │
│◀── 200 OK ───────────────────────── │
│ { status: "completed", │
│ artifacts: [ │
│ { type: "customer_data", │
│ content: { name: "Kiss Anna",│
│ deals: [...], ... } } │
│ ] } │
│ │
A task állapotai: pending → in_progress → completed / failed / cancelled
2.5 Streaming és hosszú futásidejű feladatok
Az A2A támogatja a Server-Sent Events (SSE) alapú streaming-et hosszú feladatoknál:
Client Agent Server Agent
│ │
│── POST /tasks/create ──────────────▶ │
│ { capability: "analyze_emails", │
│ streaming: true } │
│ │
│◀── SSE stream ───────────────────── │
│ event: status │
│ data: { status: "analyzing" } │
│ │
│ event: progress │
│ data: { percent: 45 } │
│ │
│ event: artifact │
│ data: { type: "summary", ... } │
│ │
│ event: complete │
│ data: { taskId: "task-42" } │
│ │
2.6 Miben más, mint a REST API?
A legfontosabb különbség: egy REST API-nál a kliens pontosan megmondja, mit csináljon a szerver. Az A2A-nál a kliens ágens célt fogalmaz meg, a szerver ágens maga dönt a végrehajtás módjáról.
3. Az MCP — az ágens és a világ között
3.1 MCP vs. A2A: nem ellenfelek, hanem komplementerek
A két protokoll együttes használata az igazán erős:
┌─────────────────────────────────────────────┐
│ Orchestrátor Ágens │
│ │
│ ┌──────────┐ A2A ┌──────────────┐ │
│ │ CRM Ágens│◄────────►│ Email Ágens │ │
│ └────┬─────┘ └──────┬───────┘ │
│ │ MCP │ MCP │
│ ┌────▼─────┐ ┌──────▼───────┐ │
│ │ CRM DB │ │ Gmail API │ │
│ │ (tool) │ │ (tool) │ │
│ └──────────┘ └──────────────┘ │
└─────────────────────────────────────────────┘
MCP: ágens ↔ külső eszköz (Gmail, Calendar, CRM)
A2A: ágens ↔ ágens (CRM ágens ↔ Email ágens)
3.2 A gyakorlatban: MCP tool-ok mint ágens-képességek
Egy valós rendszerben az MCP tool-ok gyakran az ágens képességeit definiálják. A connector-ok (Gmail, Calendar, Számlázz.hu) MCP tool-okat publikálnak, amiket az ágens használhat:
// Gmail connector — MCP tool-ok regisztrálása
getTools() {
return [
{
definition: {
type: 'function',
function: {
name: 'gmail_send',
description: 'Email küldése Gmail-en keresztül',
parameters: {
properties: {
to: { type: 'string', description: 'Címzett email címe' },
subject: { type: 'string', description: 'Tárgy' },
body: { type: 'string', description: 'Üzenettörzs' },
cc: { type: 'string', description: 'CC' }
},
required: ['to', 'subject', 'body']
}
}
},
execute: async (args) => this._mcpSendEmail(args)
}
];
}
Ezek a tool-ok dinamikusan regisztrálódnak — az ágens runtime-ban fedezi fel, milyen MCP eszközök elérhetők:
async function getProviderMCPTools(providerId) {
const configs = await prisma.connectorConfig.findMany({
where: { providerId, isEnabled: true }
});
for (const config of configs) {
const connector = new ConnectorClass(providerId);
const tools = connector.getTools();
}
}
Ez azt jelenti: ha egy szolgáltató bekapcsolja a Gmail connector-t, az AI ágens automatikusan „megtanulja", hogy most tud emailt küldeni. Ha kikapcsolja, a képesség eltűnik. Nincs újradeployment, nincs kódváltozás.
4. Multi-ágens architektúra: a valóság
4.1 Az orkesztrációs pattern-ek
Három fő megközelítés létezik arra, hogyan dolgozik együtt több ágens:
1. Hierarchikus (Orchestrator pattern)
┌──────────────┐
│ Orchestrátor │ ← Fő döntéshozó
│ Ágens │
└──────┬───────┘
┌─────┼──────┐
▼ ▼ ▼
┌────┐┌────┐┌────┐
│CRM ││Mail││Cal │ ← Specializált ágensek
└────┘└────┘└────┘
- Az orchestrátor delegál a specializált ágenseknek
- Előny: egyértelmű kontroll, könnyű debuggolás
- Hátrány: az orchestrátor SPF (single point of failure)
2. Piaci (Marketplace/Auction pattern)
┌────┐ ┌────┐ ┌────┐
│ A1 │ │ A2 │ │ A3 │
└─┬──┘ └─┬──┘ └─┬──┘
│ │ │
▼ ▼ ▼
┌──────────────────┐
│ Task Board │ ← Közös feladat-tábla
└──────────────────┘
- A feladatok egy közös „piacon" jelennek meg
- Az ágensek „licitálnak" — amelyik a legalkalmasabb, az veszi el
- Előny: decentralizált, skálázható
- Hátrány: komplex koordináció, lassabb
3. Pipeline (Chain pattern)
Input → [Ágens 1] → [Ágens 2] → [Ágens 3] → Output
Elemzés Döntés Végrehajtás
- Fix sorrend, minden ágens a saját feladatát végzi
- Előny: egyszerű, kiszámítható
- Hátrány: nem rugalmas, nehéz visszalépni
4.2 A gyakorlati megvalósítás: Evaluator-Executor minta
A valós produkciós rendszerek gyakran a hierarchikus modell egy pragmatikus változatát implementálják, ahol nem fizikailag különálló ágensek vannak, hanem logikai ágens-szerepkörök egyetlen rendszeren belül:
┌──────────────────────────────────────────────────────┐
│ Agent Loop │
│ │
│ ┌─── Trigger Layer ───┐ │
│ │ Event: email arrived │ │
│ │ Scheduled: 15min tick│ │
│ └──────────┬──────────┘ │
│ ▼ │
│ ┌─── Evaluator Agent ──┐ (LLM: GPT-4o-mini, T=0.3)│
│ │ „Mi történt?" │ │
│ │ „Mit kellene csinálni?"│ │
│ │ „Mennyire vagyok biztos?"│ │
│ └──────────┬──────────┘ │
│ ▼ │
│ ┌─── Autonomy Gate ────┐ │
│ │ notify_only → log │ │
│ │ suggest_and_wait → ⏳ │ │
│ │ act_and_report → ▼ │ │
│ └──────────┬──────────┘ │
│ ▼ │
│ ┌─── Executor Agent ───┐ │
│ │ create_task │ │
│ │ send_email (MCP) │ │
│ │ create_event (MCP) │ │
│ │ update_contact │ │
│ │ flag_attention │ │
│ └──────────────────────┘ │
└──────────────────────────────────────────────────────┘
Ez az Evaluator-Executor minta:
- Az Evaluator az „agy": LLM-alapú, alacsony hőmérséklettel (0.3) a determinisztikus döntésekért
- Az Executor a „kéz": determinisztikus kód, ami végrehajtja az Evaluator döntéseit
- Az Autonomy Gate a „felettes": eldönti, hogy a döntés kell-e emberi jóváhagyás
4.3 Az Evaluator Ágens részletesen
Az Evaluator a rendszer legkritikusabb komponense. Két módban működik:
Event mód — amikor valami történik (email, webhook, CRM esemény):
const EVAL_CONFIG = {
provider: 'openai',
model: 'gpt-4o-mini',
maxTokens: 1024,
temperature: 0.3
};
async function evaluateEvent(providerId, triggerData) {
const eventContext = await buildEventContext(
providerId,
triggerData.source,
triggerData.eventType,
triggerData.eventId,
triggerData.eventData
);
const ragContext = await retrieveRAGContext(providerId, eventContext);
const recentActions = await getRecentActions(providerId, 5);
const response = await adapter.chat([
{ role: 'system', content: evaluatorPrompt },
{ role: 'user', content: contextMarkdown }
], EVAL_CONFIG);
return parseEvalResponse(response.content);
}
Scheduled mód — 15 percenként proaktív ellenőrzés:
async function evaluateScheduledTick(providerId) {
const suggestions = await generateSuggestions(providerId);
await expirePendingActions(providerId);
const events = await getUpcomingEvents(providerId);
const deals = await getDealsSummary(providerId);
return evaluate(contextMarkdown);
}
A válasz strukturált JSON:
{
"actions": [
{
"type": "create_task",
"params": {
"title": "Follow-up: Kiss Anna 30+ napos deal",
"description": "A Premium csomag deal 35 napja NEGOTIATION fázisban áll.",
"priority": "HIGH",
"dueDate": "2026-03-31"
},
"confidence": 0.85
}
],
"reasoning": "A stale deal magas értékű, és a lejárt feladatok azonnali figyelmet igényelnek.",
"confidence": 0.88
}
4.4 Az Executor Ágens: MCP mint „kéz"
Az Executor nem gondolkodik — végrehajtja, amit az Evaluator eldöntött. Minden akció handler egy tiszta, determinisztikus függvény:
async function execute(action, providerId) {
switch (action.type) {
case 'create_task':
return executeCreateTask(action.params, providerId);
case 'send_email':
return executeMCPTool('gmail_send', action.params, providerId);
case 'create_event':
return executeMCPTool('calendar_create_event', action.params, providerId);
case 'update_contact':
return executeUpdateContact(action.params, providerId);
case 'flag_attention':
return executeFlagAttention(action.params, providerId);
}
}
8 akciótípus — mindegyik pontosan definiált bemenettel és kimenettel:
4.5 A harmadik ágens: a Chat Agent
Az Evaluator és az Executor mellett van egy harmadik „ágens": a Chat Agent — az, amelyikkel a felhasználó közvetlenül beszél:
async function sendMessage(providerId, userId, providerName, { conversationId, message }, settings) {
const systemPrompt = buildSystemPrompt(providerName, customPrompt, knowledgeContext, mcpPromptSection);
const ragResult = await retrieveRAGContext(providerId, message);
while (iterations < 3) {
response = await adapter.chat(llmMessages, { tools: allTools });
if (!response.toolCalls?.length) break;
for (const toolCall of response.toolCalls) {
const result = await executeTool(toolCall.function.name, args, providerId);
llmMessages.push({ role: 'tool', content: JSON.stringify(result) });
}
}
}
A Chat Agent más modellt, más hőmérsékletet, és más tool-készletet használ, mint az Evaluator:
4.6 Az ágensek közötti kommunikáció
A három ágens nem közvetlenül „beszél" egymással — hanem közös adatrétegen keresztül koordinálnak:
┌──────────────────┐
│ Knowledge Graph │
│ + CRM DB │
│ + Action Log │
└────────┬─────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Chat │ │ Evaluator│ │ Executor │
│ Agent │ │ Agent │ │ Agent │
└──────────┘ └──────────┘ └──────────┘
▲ │ │
│ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ User │ │ BullMQ │ │ MCP │
│ (SSE) │ │ Queue │ │ Tools │
└──────────┘ └──────────┘ └──────────┘
A kommunikáció módjai:
- Event-based (BullMQ queue): Az ingestion pipeline trigger-t küld az agent-tasks queue-ba → az Evaluator feldolgozza
- Shared state (PostgreSQL): Mindhárom ágens ugyanazt az adatréteget olvassa/írja
- Implicit (RAG): A Chat Agent szemantikus kereséssel „látja" az Evaluator/Executor korábbi akcióit
Ez a shared state modell egyszerűbb, mint az A2A-style direkt kommunikáció, és produkciós környezetben megbízhatóbb — nincs hálózati latency az ágensek között, nincs message loss kockázat.
5. Tool Calling mint proto-A2A
5.1 A tool calling gondolat
Az LLM-ek tool calling (function calling) képessége a multi-ágens kommunikáció csírája. Amikor az LLM „tool-t hív", lényegében delegál egy másik rendszernek:
Felhasználó: "Milyen időpontjaim vannak holnap?"
LLM gondolkodás: "Naptár-adatra van szükségem → hívom a get_upcoming_events tool-t"
Tool hívás:
→ get_upcoming_events({ days: 1 })
← [{ summary: "Hajvágás - Kiss Anna", start: "2026-03-31 10:00" }, ...]
LLM válasz: "Holnap egy időpontod van: 10:00-kor hajvágás Kiss Annával."
5.2 A multi-iterációs tool calling loop
A valós rendszerünk max 3 iterációban oldja meg a tool calling-ot:
Iteráció 1:
LLM: "Keresem Kiss Annát a CRM-ben"
→ Tool: search_knowledge("Kiss Anna")
← Eredmény: { contacts: [{ id: 15, name: "Kiss Anna", lifecycle: "LOYAL" }] }
Iteráció 2:
LLM: "Meg akarom nézni az ő deal-jeit és időpontjait"
→ Tool: get_entity_connections({ nodeId: "client_15" })
← Eredmény: { deals: [...], appointments: [...], invoices: [...] }
Iteráció 3:
LLM: "Most már van elég információm a válaszhoz"
→ Nincs tool hívás → természetes nyelvi válasz
Ez a ReAct (Reasoning + Acting) pattern: az LLM gondolkodik, cselekszik, megfigyeli az eredményt, és ismét gondolkodik.
5.3 A dinamikus tool registry
A tool-ok nem statikusak — futásidőben detektálódnak az aktív connector-ok alapján:
async function getAllTools(providerId) {
const crmTools = [
{ name: 'search_knowledge', ... },
{ name: 'get_recent_emails', ... },
{ name: 'get_upcoming_events', ... },
{ name: 'get_entity_connections', ... },
{ name: 'list_deals', ... },
{ name: 'get_dashboard_stats', ... },
{ name: 'create_task', ... },
{ name: 'create_deal', ... }
];
const { definitions: mcpTools } = await getProviderMCPTools(providerId);
return [...crmTools, ...mcpTools];
}
Ez az A2A Agent Card gondolat egyszerűsített, pragmatikus változata: nem külső JSON manifest, hanem futásidejű felfedezés. A koncepció ugyanaz — az ágens képességei dinamikusan bővülnek.
6. Az Adapter Pattern — provider-agnosztikus ágensek
6.1 Miért kritikus?
Ha az ágens egyetlen LLM provider-hez van kötve, vendor lock-in jön létre. Az adapter pattern lehetővé teszi, hogy az ágens logikája független legyen a mögöttes LLM-től:
┌──────────────┐
│ Agent Logic │ ← Nem tudja, melyik LLM fut mögötte
└──────┬───────┘
│ adapter.chat(messages, options)
▼
┌──────────────┐
│ Adapter Layer │ ← Strategy Pattern
└──┬────┬────┬─┘
│ │ │
▼ ▼ ▼
OpenAI Claude Gemini
6.2 Az adapter implementáció
Minden adapter ugyanazt az interface-t valósítja meg. A kihívás: a három LLM provider eltérő formátumot használ:
Az adapter réteg transzformálja ezeket egyetlen egységes formátumra:
class AnthropicAdapter extends BaseAdapter {
async chat(messages, options = {}) {
const systemMessages = messages.filter(m => m.role === 'system');
const conversationMessages = messages.filter(m => m.role !== 'system');
const anthropicTools = options.tools?.map(t => ({
name: t.function.name,
description: t.function.description,
input_schema: t.function.parameters
}));
const response = await this.client.messages.create({
model: this.model,
system: systemMessages.map(m => m.content).join('\n'),
messages: this._convertMessages(conversationMessages),
tools: anthropicTools,
max_tokens: options.maxTokens
});
return {
content: response.content.find(c => c.type === 'text')?.text,
toolCalls: response.content.filter(c => c.type === 'tool_use')
.map(c => ({ id: c.id, function: { name: c.name, arguments: c.input } })),
usage: { input: response.usage.input_tokens, output: response.usage.output_tokens }
};
}
}
6.3 Per-tenant modellválasztás
A multi-tenant rendszerben minden szolgáltató más LLM-et használhat:
model AiSettings {
providerId Int @unique
provider String @default("openai")
model String @default("gpt-4o-mini")
temperature Decimal @default(0.7)
maxTokens Int @default(2048)
systemPrompt String?
}
Az egyik szolgáltató GPT-4o-t használ, a másik Claude-ot, a harmadik Gemini-t — ugyanaz a rendszer, ugyanaz az ágens-logika. Csak az adapter cserélődik.
7. Biztonsági architektúra: a multi-ágens rendszer kontrolljai
7.1 Miért kell extra biztonság?
Egy multi-ágens rendszerben az „AI hibázhat" kockázat exponenciálisan nő: ha az Evaluator rosszul dönt, az Executor rossz akciót hajt végre, az MCP tool rossz emailt küld. A kaszkád-hiba megelőzése a rendszer legfontosabb tulajdonsága.
7.2 Az Autonomy Gate — háromszintű kontroll
async function processAction(action, providerId, config) {
if (config.blockedActions.includes(action.type)) return;
if (config.allowedActions.length > 0 &&
!config.allowedActions.includes(action.type)) return;
const todayCount = await getTodayActionCount(providerId);
if (todayCount >= config.dailyActionLimit) return;
switch (config.autonomyLevel) {
case 'notify_only':
await logAction({ ...action, status: 'notified' });
break;
case 'suggest_and_wait':
await logAction({ ...action, status: 'pending', expiresAt: +24h });
await sendNotification(providerId, 'Új AI javaslat');
break;
case 'act_and_report':
const result = await executor.execute(action, providerId);
await logAction({ ...action, status: 'executed', output: result });
break;
}
}
7.3 A napi korlát mechanizmusa
Max 50 akció naponta — ez megakadályozza, hogy egy rosszul konfigurált ágens „elszálljon" és ezernyi emailt küldjön vagy feladatot hozzon létre.
7.4 Az audit trail — mindent logolunk
Minden ágens-akció az AiActionLog táblába kerül:
Ez a granularitás lehetővé teszi:
- Post-mortem elemzés: Miért küldött az AI rossz emailt?
- Teljesítmény-mérés: Az akciók hány %-a volt jóváhagyva?
- Optimalizáció: A 0.6 alatti confidence akciók 80%-a rejected → emeljük a threshold-ot
7.5 Az Evaluator max 3 akciója
Az Evaluator legfeljebb 3 akciót javasolhat egyetlen kiértékelésben. Ez megakadályozza a „túlbuzgó" AI-t:
function parseEvalResponse(content) {
const parsed = JSON.parse(content);
const validActions = parsed.actions.filter(a =>
VALID_ACTION_TYPES.includes(a.type)
);
return validActions.slice(0, 3);
}
8. A connector mint „külső ágens"
8.1 A connector mint A2A-analógia
A connector-ok (Gmail, Google Calendar, Számlázz.hu) lényegében külső rendszerek ágenseiként működnek. Nem LLM-alapúak, de az interakciós mintájuk A2A-szerű:
8.2 A Normalized Event mint ágens-üzenet
Minden connector egy egységes formátumra konvertálja a külső rendszer adatait:
{
source: 'gmail',
eventType: 'email.received',
externalId: 'msg-abc123',
timestamp: new Date(),
entities: [
{ type: 'email', externalId: 'msg-abc123', label: 'Re: Időpont', content: '...' },
{ type: 'client', externalId: 'contact-456', label: 'Kiss Anna', properties: { email: 'anna@...' } }
],
edges: [
{ fromExternalId: 'msg-abc123', toExternalId: 'contact-456', type: 'SENT_BY' }
],
textContent: 'Email body for embedding',
rawData: originalGmailPayload
}
Ez a normalizálás az A2A Part és Artifact gondolatának pragmatikus megvalósítása — az ágens a saját formátumában kapja az adatot, és szabványos formátumban adja tovább a rendszernek.
8.3 A BaseConnector mint „ágens-interface"
class BaseConnector {
async handleWebhook(payload) // Webhook → NormalizedEvent[]
async poll(since) // Incremental sync → NormalizedEvent[]
async fullSync() // Full sync → NormalizedEvent[]
getTools() // → [{ definition, execute }]
async authorize(authData) // OAuth2 setup
async refreshToken() // Token refresh
}
Ez az interface az A2A Agent Card imperatív megfelelője: nem JSON manifest, hanem kód-szintű kontraktus.
9. Jövőkép: az A2A a produktumban
9.1 Ma: belső multi-ágens rendszer
A jelenlegi architektúra zárt, belső multi-ágens rendszer: az Evaluator, a Chat Agent, az Executor és a Connector-ok egyazon infrastruktúrán belül kommunikálnak.
9.2 Holnap: A2A-kompatibilis ágensek
Az A2A protokoll lehetővé teszi, hogy az ágensek rendszerhatárokon átívelve kommunikáljanak:
Mai architektúra:
[AIMY Evaluator] ──shared DB──▶ [AIMY Executor] ──MCP──▶ [Gmail]
Jövőbeli A2A architektúra:
[AIMY CRM Agent]
│ A2A
▼
[Partner Booking Agent] ← Egy másik cég ágense
│ A2A
▼
[Payment Agent] ← Harmadik fél fizetési ágense
│ A2A
▼
[Notification Agent] ← Kommunikációs ágens
Konkrét szcenáriók:
1. Cross-business foglalás — Az ügyfél orvosi AI asszisztense kéri a fodrász AI-ját: „Kiss Anna holnap 14:00-kor ér rá". A fodrász AI visszaadja a szabad időpontot, mindkét rendszer naptárja frissül.
2. Supply chain koordináció — A raktárkészlet-ágens jelzi a hiányt, a beszerzési ágens A2A-n keresztül megrendeli a szállítótól, a pénzügyi ágens jóváhagyja.
3. Ügyfél-transzfer rendszerek között — A kozmetikus AI ágense „ügyfélkártyát" küld a fodrász AI-nak, aki javasol időpontot.
9.3 A technikai átmenet
Az átmenet a belső multi-ágens rendszerről az A2A-kompatibilis rendszerre fokozatos:
A legnagyobb kihívás nem a protokoll implementálása — hanem a trust framework: hogyan döntöd el, hogy egy ismeretlen ágens kérése legitim?
10. Gyakorlati döntési mátrix CTO-knak
10.1 Mikor kell multi-ágens architektúra?
10.2 Mikor kell A2A protokoll?
10.3 A technológia-választás döntési fája
Kell-e több „intelligens" komponens a rendszerben?
│
├─ Nem (1 ágens, 1-5 tool) → Egyetlen ágens, tool calling
│
└─ Igen → Különböző feladatok, különböző konfigurációval?
│
├─ Igen → Multi-ágens, Evaluator-Executor minta
│ │
│ └─ Az ágensek egy infrastruktúrán belül?
│ │
│ ├─ Igen → Shared state (DB + Queue)
│ │
│ └─ Nem → A2A protokoll
│
└─ Nem → Egyetlen ágens, moduláris tool-készlettel
11. Összefoglalás: a multi-ágens rendszer rétegei
┌──────────────────────────────────────────────────────────────┐
│ Felhasználó (Chat / Push / Dashboard) │
├──────────────────────────────────────────────────────────────┤
│ Chat Agent (LLM, T=0.7, streaming, tool calling) │
├──────────────────────────────────────────────────────────────┤
│ Evaluator Agent (GPT-4o-mini, T=0.3, structured JSON) │
│ Trigger: event (webhook) + scheduled (15min tick) │
├──────────────────────────────────────────────────────────────┤
│ Autonomy Gate (notify / suggest_and_wait / act_and_report) │
│ Safety: daily limit (50), allowed/blocked actions, 24h expiry│
├──────────────────────────────────────────────────────────────┤
│ Executor Agent (deterministic, 8 action types) │
│ CRM actions + MCP tools (Gmail, Calendar) │
├──────────────────────────────────────────────────────────────┤
│ Adapter Layer (OpenAI / Anthropic / Gemini) │
│ Per-tenant model selection, unified interface │
├──────────────────────────────────────────────────────────────┤
│ Knowledge Layer │
│ Knowledge Graph (pgvector) + RAG Pipeline + Connectors │
├──────────────────────────────────────────────────────────────┤
│ Infrastructure │
│ PostgreSQL + Redis + BullMQ + Firebase │
└──────────────────────────────────────────────────────────────┘
A legfontosabb tanulságok
-
Evaluator ≠ Executor: A döntéshozó ágens és a végrehajtó ágens szét kell váljon. Ez lehetővé teszi a jóváhagyási workflow-kat, az audit trail-t, és a különböző autonomia-szinteket.
-
Az MCP és az A2A komplementerek: Az MCP az ágens és az eszközök között (Gmail, Calendar), az A2A az ágensek között. Mindkettő kell — különböző szinten.
-
A shared state egyszerűbb, mint a közvetlen kommunikáció: Amíg az ágensek egy infrastruktúrán belül vannak, a PostgreSQL + BullMQ megbízhatóbb és egyszerűbb, mint az ágensek közötti közvetlen üzenetváltás.
-
A dinamikus tool registry az A2A csírája: Ha az ágens futásidőben fedezi fel a képességeit, az ugyanaz a gondolat, amit az A2A Agent Card formalizál. Az átmenet fokozatos.
-
A biztonság nem opcionális: Autonomia-szintek, napi korlát, akció-szűrés, 24 órás jóváhagyási ablak, teljes audit trail — ezek nélkül a multi-ágens rendszer veszélyes.
-
Különböző ágensekhez különböző LLM-konfiguráció: A Chat Agent kreatívabb (T=0.7), az Evaluator determinisztikusabb (T=0.3). A provider-agnosztikus adapter pattern lehetővé teszi, hogy minden ágens a számára optimális modellt használja.
-
Az A2A akkor kell, amikor az ágensek kilépnek a rendszerből: Amíg belső ágensekről van szó, a shared state elegendő. Amikor más szervezetek ágenseivel kell kommunikálni, az A2A szabvány lesz a közös nyelv.
Tervez multi-ágens architektúrát vagy AI integrációt?
Az Atlosz csapata segít az ágensek közötti kommunikáció, az Evaluator-Executor minta, az MCP integrációk és a biztonsági kontrollok megtervezésében és implementálásában — az Ön rendszeréhez szabva.
Beszéljünk az AI stratégiájáról →