TL;DR

Zbudowałem autorską mapę tego, co nazywa się "agentic AI" w 2026 roku. Osiem warstw, od modelu językowego po sieci autonomicznych agentów między firmami. Warstwy 1-4 umiemy już budować w produkcji. Warstwa 5 (protokół A2A) dostała stabilny standard produkcyjny pod Linux Foundation. Warstwy 6-8 to teren, gdzie w tej chwili wszystko się dzieje: identyfikacja agentów, negocjacje między nimi, płatności, marketplace. Model jest moją autorską syntezą kilkunastu istniejących opracowań, a nie oficjalnym standardem branżowym. Publikuję ją, bo mnie pomogła uporządkować chaos, w którym każdy używa słowa "agent" inaczej.

Skąd wziął się ten model

Siedziałem trzeci wieczór z rzędu nad rozmową z klientem o "wdrożeniu agenta AI dla firmy". Klient chciał "agenta". Ja chciałem zapytać, o który poziom "agenta" chodzi, bo w tym samym tygodniu miałem trzy inne rozmowy, gdzie "agent" znaczył trzy zupełnie różne rzeczy.

Raz to był chatbot z GPT-4 pod spodem i dwoma tools. Raz to była orkiestracja piętnastu wywołań LLM, które kończyły się dokumentem PDF. Raz to był workflow oparty o LangGraph, gdzie sześć agentów spierało się między sobą, zanim wypluło końcową rekomendację.

I ostatni klient chciał "coś więcej", ale też nie wiedział co.

Postanowiłem to sobie poukładać. Zrobiłem mapę warstw, zacząłem sprawdzać źródła. Okazało się, że branża w 2026 pisze o tym w dziesiątkach różnych sposobów, ale nikt (chyba) nie zebrał tego w jeden ośmiowarstwowy model, który idzie od modelu językowego aż po ekonomię agentów między firmami.

Ten wpis to ten model.

Ważna uwaga na wejściu: traktuj ten model jako moją autorską syntezę, a nie standard techniczny. Jeżeli czytasz to pod kątem akademickim, oprzyj się na źródłach, które linkuję niżej, a nie na samej numeracji warstw.

Model ośmiu warstw. Widok z lotu ptaka

Warstwa	Nazwa	Co robi	Status 2026
L1	Model	LLM / VLM / reasoning models	Dojrzała, komercyjna i open source
L2	Tools & Context	MCP, API, dane, pamięć	MCP jako de facto standard
L3	Agent	goal, state, reasoning, akcja	Frameworks dojrzałe (LangGraph, ADK, OpenAI Agents SDK)
L4	Orchestration	supervisor, handoff, swarm, workflow	Dobrze rozumiane wzorce, produkcyjnie stabilne
L5	Interoperability	A2A Protocol, agent do agenta	A2A 1.0 pod Linux Foundation, 150+ organizacji
L6	Discovery & Trust	Agent Cards, registry, identity, delegacja	Drafty IETF, brak jednego standardu
L7	Transactions	contracts, negocjacje, płatności, SLA	Wczesna faza. Google UCP, OpenAI+Stripe ACP
L8	Agentic Web	autonomiczne sieci agentów ludzi i firm	Koncept, dopiero się rodzi

Warstwy 1-4 są dziś dostępne dla każdego. Warstwa 5 właśnie stała się rozsądnym punktem oparcia. Warstwy 6-8 zmienią sposób, w jaki firmy istnieją w internecie. I to jest teza całego tego tekstu.

Przejdźmy przez każdą po kolei.

L1. Model

Fundament, oczywistość, nie ma tu dużo do dodania. GPT-5, Claude Sonnet 4.5, Gemini 2, Qwen 32B, DeepSeek, Bielik. Modele językowe, wizyjne, rozumujące. Chmurowe lub lokalne.

Ważne co się zmieniło w ostatnim roku: rozmiar przestał być jedynym parametrem, który się liczy. Dobrze wytrenowany model 32B na własnym sprzęcie potrafi w wielu zadaniach agentowych dogonić frontier (patrz mój wpis o Qwenie i Bieliku prowadzących agencję - Qwen 32B AWQ przetrwał 20/20 symulacji na moim GX10 lokalnie, koszt 1 zł prądu).

Dla warstwy L1 istotne jest tylko jedno: czy model wypełnia kontrakt, którego wymaga twoja warstwa L3. Reszta to detale infrastruktury.

L2. Tools & Context (MCP)

Rok 2025 dał nam Model Context Protocol od Anthropic, który w 2026 stał się de facto standardem komunikacji między agentem a narzędziami. Wszyscy główni gracze (OpenAI, Anthropic, Google, Microsoft) obsługują MCP jako sposób podłączenia agenta do baz danych, kalendarzy, plików, API firm trzecich.

Co to praktycznie znaczy: piszesz jeden serwer MCP dla swojego CRM, a każdy agent, obojętnie od jakiego dostawcy, może go użyć bez przepisywania. To tak jak z USB dla urządzeń peryferyjnych.

W kontekście naszego modelu MCP to warstwa narzędzi i kontekstu. Agent (L3) potrzebuje dostępu do danych i akcji. MCP jest standardem, którym mu to dostarczasz.

Uwaga terminologiczna, którą wielu myli: MCP to nie A2A. MCP odpowiada na pytanie "jak agent używa narzędzia?". A2A odpowiada na pytanie "jak agent współpracuje z innym agentem?". Twórcy A2A opisują je jako technologie uzupełniające się, nie konkurencyjne.

A2A Agent ↔ Agent ↓ ↓ MCP MCP ↓ ↓ narzędzia narzędzia

Docelowa architektura używa obu warstw jednocześnie.

L3. Agent

Agent to program, który ma:

cel (goal)
stan (state, zwykle jakaś pamięć)
zdolność rozumowania (reasoning, dziś przez LLM)
narzędzia (przez MCP lub bezpośrednio)
pętlę wykonania (obserwuj, rozważ, zdecyduj, działaj)

W 2026 mamy dojrzałe frameworki agentowe: LangGraph (Anthropic-partner), Google ADK, OpenAI Agents SDK, Microsoft AutoGen, CrewAI. Każdy ma swoje idiomy, ale koncepcyjnie robią to samo.

Agent na tym poziomie to nadal jednostka. Sam. Jedna świadomość, jeden kontekst, jedna pętla wykonania.

Ciekawy problem: im dłuższy horyzont zadania, tym gorzej działa reasoning. Badania nad "over-planning collapse" ( arxiv 2602.19281 ) pokazują, że małe modele mają intrinsic upper bound na skuteczny reasoning horizon. To dlatego w mojej symulacji Bielik 11B przegrał z Qwenem 32B po 90 dniach decyzji.

Jeżeli twoje zadanie wymaga długiego łańcucha decyzji, jeden agent to za mało. Wchodzimy w L4.

L4. Orchestration

Tu robi się interesująco. Kiedy jeden agent nie wystarcza, spinasz kilku. Ale jak?

Branża w 2026 wyłoniła sześć głównych wzorców orkiestracji:

Wzorzec 1: Agent jako narzędzie

User ↓ Agent główny ├→ Agent SEO ├→ Agent WordPress ├→ Agent Ads └→ Agent Analytics

Agent główny wywołuje innych agentów tak, jak wywołałby funkcję. OpenAI nazywa to "agents as tools". Manager zachowuje kontrolę i składa końcową odpowiedź. Proste do kontrolowania, jeden punkt bezpieczeństwa, łatwe logowanie. Wada: manager staje się wąskim gardłem.

Wzorzec 2: Handoff

User → Agent recepcjonista → "to sprawa WordPress" → Agent WordPress → User

Agent A mówi w praktyce "od teraz prowadzi cię agent B". OpenAI Agents SDK ma to bezpośrednio jako handoff. Przydaje się w supportcie, sprzedaży, obsłudze różnych działów.

Wzorzec 3: Supervisor (Manager-Worker)

Supervisor / | \ research coder reviewer \ | / wynik

Supervisor rozbija problem, wybiera agentów, rozdziela zadania, zbiera wyniki, decyduje kiedy kończymy. Dziś jeden z najbardziej praktycznych wzorców. Wszystkie duże frameworki mają swoje warianty.

Wzorzec 4: Pipeline

brief → analiza → UX → copy → WordPress → QA

Deterministycznie. "Po wykonaniu A zawsze uruchom B." Google ADK ma gotowe SequentialAgent, ParallelAgent, LoopAgent. Często bezpieczniejsze i tańsze niż autonomiczne multi-agent.

Wzorzec 5: Parallel / fan-out

┌→ agent A zadanie ───┼→ agent B ├→ agent C └→ agent D ↓ agregator

Rozbijasz zadanie, puszczasz równolegle, agregujesz. LLM-y są wolne, więc równoległość mocno skraca czas wykonania. Google używa tego wzorca do incident response i dużych migracji kodu.

Wzorzec 6: Debate / jury / evaluator

Generator → Critic → Generator → Reviewer → wynik

Albo kilka agentów rozwiązuje ten sam problem, a inny wybiera najlepsze rozwiązanie. Bardzo dobre do kodu, analiz, researchu. Koszt tokenów potrafi rosnąć absurdalnie.

Wzorzec 7: Swarm

Agent A ↔ Agent B ↕ ↕ Agent C ↔ Agent D ↕ ↕ Agent E ↔ Agent F

Nie ma centralnego szefa. Każdy agent zna swoje kompetencje, może przekazać zadanie dalej, może poprosić o pomoc. LangGraph ma dedykowany "swarm" model. Elegancko wygląda w prezentacji, w produkcji trudne do debugowania, przewidywania kosztów i ustalenia odpowiedzialności.

Wzorzec 8: Blackboard / shared state

Agenci nie rozmawiają bezpośrednio. Mają wspólną tablicę (Postgres, Redis, event log, state graph). Agent A dopisuje, agent B widzi, agent C reaguje. Bardzo sensowny model dla agentów działających godzinami albo dniami.

Wzorzec 9: Event-driven

CRM event "nowy klient" ↓ Sales Agent ↓ event Web Agent ↓ event Ads Agent

Agenci nie muszą się nawet znać. Kafka, RabbitMQ, Redis Streams, NATS. Przypomina mikroserwisy. Moim zdaniem ten kierunek będzie ogromny.

Kiedy który wzorzec wybrać - to jest osobny wpis. Skrót:

Krótkie zadanie z znaną strukturą → pipeline
Zadanie z niepewnością, ale wiadomo kto co umie → supervisor
Bardzo szeroki research → parallel + aggregator
Krytyczna decyzja z ryzykiem → debate
Dłuższe procesy między systemami → event-driven
Odpowiedź musi być "dobra", nie szybka → debate + jury

Wszystkie te wzorce zamykają się w jednej organizacji, jednym stacku, jednej firmie. Wchodzimy w warstwę wyżej.

L5. Interoperability (A2A Protocol)

I tutaj wchodzimy w 2026.

Do niedawna każda organizacja robiła swoich agentów po swojemu. Jeżeli chciałeś, żeby twój agent CRM porozmawiał z agentem księgowości innej firmy, musiałeś to zintegrować ręcznie, projekt po projekcie.

Kwiecień 2026: Agent2Agent Protocol (A2A) osiąga wersję 1.0 pod egidą Linux Foundation. Ponad 150 organizacji wspiera standard. Google, Microsoft, AWS, Salesforce, ServiceNow. Deep integration na trzech największych chmurach. Produkcyjne wdrożenia w łańcuchu dostaw, usługach finansowych, ubezpieczeniach, IT operations.

A2A to specyfikacja odpowiadająca na jedno pytanie: jak dwóch agentów, których nie wolno ci znać z kodu, może współpracować przez internet w bezpieczny, powtarzalny sposób?

Agent Card

Każdy agent A2A publikuje "wizytówkę" w formie JSON-LD:

{ "name": "WebDeveloperAgent", "skills": ["wordpress", "woocommerce", "dns", "analytics"], "auth": ["OAuth2"], "interfaces": ["REST", "gRPC", "JSON-RPC"], "endpoint": "https://chcedointernetu.pl/.well-known/agent-card.json" }

Agent Card zawiera tożsamość, endpoint, capabilities, wymagania uwierzytelniania i dostępne skills. Jest publiczna. Może być podpisana kryptograficznie.

Task lifecycle

A2A nie jest zwykłym request/response. Ma pojęcie Task:

Agent A → Task #9384 → working → working → input-required → working → completed → Artifacts

Zadanie może trwać sekundy albo godziny. Może wymagać uzupełnienia danych w środku. Rezultatem jest Artifact (raport, JSON, dokument, kod, wygenerowany plik). Protokół obsługuje streaming, webhooki, push notifications.

To już zaczyna przypominać API dla cyfrowych pracowników.

Trzy bindingi

A2A można używać przez JSON-RPC 2.0, gRPC lub HTTP+JSON. Standard jest transportowo-neutralny. To realistyczne dla różnych stacków technicznych.

Źródło: A2A one year milestone (Linux Foundation, kwiecień 2026) , Wikipedia: Agent2Agent .

L6. Discovery & Trust

Załóżmy, że dwie firmy mają agentów wystawionych przez A2A. Skąd agent mojej firmy ma wiedzieć, że istnieje agent twojej firmy? I skąd ma wiedzieć, że mu można zaufać?

To warstwa 6. I tutaj nie ma jednego standardu.

A2A daje trzy sposoby odkrywania: well-known URI (/.well-known/agent-card.json), katalogi/registry i konfiguracja bezpośrednia. Podstawy są. Ale reszta to teren, który dopiero się formuje.

W tej chwili w IETF (Internet Engineering Task Force) leży kilka aktywnych draftów, które próbują to uporządkować:

draft-kiliram-agent-trust-auth-framework - trust i autentykacja między domenami. Mówi wprost, że sam protokół komunikacyjny nie wystarcza, trzeba jeszcze weryfikowalnej tożsamości, delegowania uprawnień, autoryzacji, revocation, audytu.
draft-cui-dmsc-agent-cdi - cross-domain interoperability framework. Identity federation, trust establishment, policy harmonization.
draft-diaconu-agents-authz-info-sharing - dzielenie się informacją autoryzacyjną między agentami.
draft-yl-agent-id-requirements - wymagania dotyczące identyfikacji agenta.
draft-yu-ai-agent-ipv6-networking-considerations - problemy sieciowe przy komunikacji między agentami z różnych domen.
draft-reece-wimse-cross-org-delegation - delegacja uprawnień workload i agentów między organizacjami.

Ilość aktywnych draftów pokazuje, że problem jest realny i pilny. Odpowiedzi jeszcze nie ma.

Co to znaczy praktycznie: jeżeli dziś budujesz agenta A2A między firmami, musisz sam zdecydować, czy ufasz drugiej stronie na podstawie certyfikatu, OAuth2, tokenu z registry, czy podpisu na Agent Card. Za rok albo dwa dostaniesz na to standard. Dziś improwizujesz.

L7. Transactions

Załóżmy dalej, że agent mojej firmy znalazł agenta twojej firmy i mu ufa. Chcą razem coś zrobić. Kto komu ile płaci? Na jakich warunkach? Kto ponosi odpowiedzialność za wynik?

To warstwa transakcyjna. I tutaj w 2026 mamy dwie duże inicjatywy, które próbują ją standaryzować:

Google Universal Commerce Protocol (UCP)

Ogłoszony na NRF 2026. Współtworzony z Shopify, Walmart, Target, Wayfair, Etsy, ponad 20 endorserów. Cel: uniwersalny protokół agentowego handlu, w którym agent kupujący może zrealizować transakcję u agenta sprzedawcy bez ręcznego integrowania z każdą platformą.

OpenAI + Stripe Agentic Commerce Protocol (ACP)

Węższy focus, otwarty na licencji Apache 2.0. Koncentruje się na checkout i płatności. Pozwala agentowi kupującemu bezpiecznie zapłacić agentowi sprzedawcy przez Stripe, bez przekazywania danych karty i bez pełnej integracji sklepowej.

Cztery protokoły w 2026 Q1 mają meaningful adoption: MCP, A2A, ACP, UCP. Każdy rozwiązuje inny problem:

MCP - dostęp do narzędzi (L2)
A2A - koordynacja agenta z agentem (L5)
ACP - transakcje checkout/płatności (L7)
UCP - pełny handel agent-agent (L7)

Pełny enterprise stack agentowy w 2026 używa wszystkich czterech.

Czego jeszcze nie ma standaryzacji na L7

Reputacja agentów. Który agent zrobi robotę dobrze?
Negocjacje cen. Agent A prosi o wykonanie X za 500 zł, agent B odpowiada "800 zł, terminem", agent A "kompromis 650 zł". Możliwe technicznie już dziś, brak standardu.
SLA. Co jeżeli agent obiecał 2h i nie wyrobił?
Rozwiązywanie sporów. Kto arbitruje?

Klasyczna literatura wieloagentowa nazywa to "contract net", aukcjami, mechanism design. Technicznie umiemy to od dwudziestu lat. Standaryzacyjnie na poziomie internetowym - nie.

L8. Agentic Web

I tu dochodzimy do tezy tego całego tekstu.

Kiedy warstwy 1-7 dojrzeją, powstanie coś, co można nazwać agentic web: sieć autonomicznych agentów wystawionych przez firmy i osoby, komunikujących się między sobą przez A2A, znajdujących się nawzajem przez discovery, ufających sobie przez trust framework, negocjujących i transakcjonujących przez UCP/ACP.

Porównaj:

Internet 1: człowiek → strona WWW Internet 2: aplikacja → API → aplikacja Agentic Web: agent → discovery → agent → negocjacja → wykonanie → rozliczenie

Dziś firma publikuje chcedointernetu.pl/oferta. W ciągu kilku lat może publikować równolegle:

chcedointernetu.pl/.well-known/agent-card.json

I agent klienta nie będzie musiał czytać strony. Zapyta wprost:

"Potrzebuję strony WordPress dla kancelarii prawnej, budżet do 12 000 zł, GA4 z Consent Mode, termin 30 dni."

Mój agent odpowie:

"Mogę wykonać. Cena: 9 800 PLN. Termin: 21 dni. Potrzebuję: logo, dane firmy, dostęp do domeny."

Agent klienta:

"Czy obejmuje sklep WooCommerce?"

Mój agent:

"+2 800 PLN, +5 dni."

Agent klienta:

"Akceptuję."

I dopiero wtedy człowiek dostaje powiadomienie:

"Znalazłem wykonawcę. Oferta 12 600 zł. Termin 26 dni. Zatwierdzić?"

To zmienia sens posiadania strony WWW, katalogów firm, marketplace'ów, częściowo SEO i być może nawet wyszukiwarek. Nie jutro. Ale w ciągu 5-10 lat, obserwując tempo dojrzewania warstw 1-5, to jest realistyczny horyzont.

Co branża już opisała, a co nie

Uczciwość akademicka jest ważna, szczególnie jak ktoś to czyta jako kontekst do własnej pracy.

Warstwy 1-4 są już opisywane jako Agentic AI Reference Architecture. Kanoniczny model (Rana 2026) wyróżnia siedem "planes": User Intent, Policy & Access, Reasoning & Planning, Knowledge & Memory, Execution & Tool, Verification & Guardrail, Delivery & Audit. Aimultiple w tym samym roku pisze o "7 layers of Agentic AI Stack". O'Reilly ma "AI Agents Stack (2026 Edition)". Ich modele są głównie o pojedynczym systemie agentowym, nie o komunikacji między nimi.

Warstwa 5 to A2A, opisana wprost przez Linux Foundation i standard IETF-adjacent. Świetnie udokumentowana.

Warstwa 6 to obecnie obszar aktywnych draftów IETF (linkowane wyżej), plus prace akademickie jak "A Layered Protocol Architecture for the Internet of Agents" (arxiv, listopad 2025) i "Infrastructure for the Agentic Web: Gap Analysis and Architecture from the Agentverse Platform" (arxiv 2026). Fragmentaryczna standaryzacja.

Warstwa 7 dostała w 2026 dwa protokoły (Google UCP, OpenAI+Stripe ACP) i szereg pomysłów akademickich ( AIP: Agent Identity Protocol for Verifiable Delegation , 2026), ale całościowego frameworku jeszcze nie ma. Teleperson w maju 2026 opublikował "Architecture of Agent-to-Agent Commerce: A Field Map" pokazujący pięć warstw ekosystemu handlowego (Protocols and standards / Identity and trust / Payments / Agents / Marketplaces).

Warstwa 8 to koncepcyjna nadbudowa. Termin "Agentic Web" jest używany, ale różne osoby przypisują mu różne zakresy.

Czego nie znalazłem: jednej, spójnej ośmiowarstwowej mapy, która idzie od modelu językowego po sieci autonomicznych agentów między firmami. Dlatego zbudowałem swoją. Jeżeli znasz istniejący model, który to spina, napisz mi na ratunku@chcedointernetu.pl, chętnie dodam odniesienie i przyznam autorstwo tam, gdzie się należy.

Ograniczenia mojego modelu

Trzy rzeczy, których nie ma sensu udawać.

Po pierwsze, warstwy nie są ostrymi granicami. LangGraph miesza L3 i L4. MCP dotyka L2 i częściowo L6 (przez auth). A2A dotyka L5, ale też L6 i L7. Model warstwowy w sieciach (OSI) też miał ten problem.

Po drugie, numeracja jest arbitralna. Można to samo opisać jako sześć warstw albo dziesięć. Wybrałem osiem, bo tyle mieści się w głowie i tyle miałem realnych "poziomów problemu", które chciałem oddzielić.

Po trzecie, warstwy 6-8 to prognoza, nie inwentaryzacja. Może się okazać, że ekonomia agentów wyewoluuje inaczej. Może okazać się, że dojrzały A2A i MCP wystarczą, i warstwy 7-8 będą tylko konkretnymi produktami budowanymi na nich, a nie osobnymi standardami.

Ale nawet w tej niepewności, model jest przydatny. Bo pomaga rozmawiać o "agentach" konkretnie: na której warstwie działam, co próbuję dodać, gdzie jest luka?

Co to zmienia dla właściciela małej firmy w Polsce w 2026

Dwa konkretne wnioski, które sam wciągam do swojej praktyki.

Wniosek pierwszy: warstwy 1-4 to twój natychmiastowy biznes. LLM lokalnie na własnym sprzęcie (patrz mój wpis o GX10 i Bieliku vs Qwen ), MCP do twojego CRM, agent który obsługuje maile, prosty pipeline który tworzy ci treści na social media. To wszystko możesz mieć w 2026 bez ryzyka i bez wielkich kosztów. Warto zacząć.

Wniosek drugi: warstwy 5-8 to twoja dwuletnia strategia. Jeżeli twoja firma istnieje w internecie tylko przez stronę WWW, myśl już teraz o tym, jak jej strona ma opisywać się dla agentów. Na razie przez llms.txt i schema.org. Za rok, dwa - przez Agent Card zgodny z A2A. Za trzy lata być może przez dedykowaną wystawkę pod agentic commerce.

Pierwszy raz od dwudziestu lat mamy sytuację, w której sposób opisywania firmy w internecie zmienia się fundamentalnie, bo zmienia się główny odbiorca tego opisu. Dziś ktoś czyta twoją stronę. Za pięć lat czyta ją głównie agent innej firmy, który podejmuje decyzję zakupową w imieniu człowieka.

Firmy, które to zrozumieją wcześniej, wygrają. Nie przez wyższą inteligencję, tylko przez dostosowanie formatu opisu do formatu odbiorcy.

Weź jak swoje

Osiem warstw: Model → Tools & Context → Agent → Orchestration → Interoperability (A2A) → Discovery & Trust → Transactions → Agentic Web.
Warstwy 1-4 umiemy budować dziś, produkcyjnie, na własnym sprzęcie, bez płacenia OpenAI za każdy token.
Warstwa 5 (A2A) dojrzała w kwietniu 2026 (Linux Foundation, 150+ organizacji, produkcja u Google, Microsoft, AWS, Salesforce). To jest już stabilny punkt oparcia.
Warstwy 6-7 są w budowie: kilka draftów IETF na trust framework, dwa protokoły komercyjne na transakcje (Google UCP + OpenAI+Stripe ACP), Teleperson field map z maja 2026.
Warstwa 8 to teza: agentic web zmieni sposób istnienia firm w internecie w ciągu 5-10 lat.
MCP ≠ A2A. MCP mówi jak agent używa narzędzia. A2A mówi jak agent współpracuje z innym agentem. Docelowo używamy obu.
Nie każdy "agent" znaczy to samo. W 2026 warto pytać: "który poziom modelu?" zanim wpłacisz komuś za "wdrożenie AI".
Twoja strona WWW za dwa lata będzie miała drugą wersję dla agentów. Zacznij od llms.txt i schema.org. Potem Agent Card.

Powiązane materiały

Standardy i specyfikacje:

IETF drafts (aktywne w 2026):

Prace akademickie:

Reference architectures:

Commerce protocols:

Moje wcześniejsze wpisy:

Konrad Krawczuk, ChceDoInternetu.pl. Wpis powstał z rozmowy z klientem, który chciał "agenta AI dla firmy" i nie wiedział którego, plus czterech godzin sortowania własnych notatek. Jeżeli piszesz doktorat albo pracę magisterską w pokrewnym temacie, i chcesz omówić dokładniej któryś fragment tego modelu, napisz na ratunku@chcedointernetu.pl.