Architektura stosu ChatGPT Apps

1. Wprowadzenie

Jeśli patrzeć na ChatGPT App po prostu jak na „kolejny serwer web”, bardzo szybko zaczyna się architektoniczny chaos: tu Next.js, tam serwer MCP, gdzie indziej agent, jeszcze gdzie indziej backend commerce — i to wszystko w głowie zlewa się w jeden wielki „serwer”.

Dużo korzystniej jest od razu przyjąć, że to warstwowy tort:

• na górze — ChatGPT UI, którego nie kontrolujemy, ale do którego się dostosowujemy;
• pod nim — nasz widżet na Apps SDK (Next.js 16, React 19), który jest renderowany w czacie;
• niżej — serwer MCP z narzędziami (tools/resources/prompts);
• opcjonalnie — warstwa agentów, która orkiestruje złożone scenariusze;
• i na samym dole — twoje „przyziemne” serwisy: baza danych, zewnętrzne API, commerce/ACP (protokół dla scenariuszy commerce) itp.

W konspekcie kursu tę ścieżkę można narysować jako łańcuch:

User → ChatGPT Widget → Apps SDK → MCP Gateway (Auth) → Agent Service → ACP / Stripe.

Naszym zadaniem jest teraz zamienić ten łańcuch w zrozumiały model mentalny.

2. Ogólny schemat stosu

Najpierw spójrzmy na obraz całościowy, potem przejdziemy warstwa po warstwie.

flowchart TD
    U[Użytkownik w ChatGPT] --> C["ChatGPT UI czat + panel Apps"]
    C --> W["Widżet twojej aplikacji (Apps SDK, Next.js)"]
    W --> M["Serwer MCP (tools/resources/prompts)"]
    M --> AG["Agent(y) (Agents SDK, orkiestracja)"]
    AG --> B["Backendy i ACP Baza danych, serwisy, płatności"]

Warto zauważyć kilka rzeczy.

Po pierwsze, użytkownik widzi tylko dwie warstwy: ChatGPT UI i twój widżet. Wszystko poniżej to „kulisy”.

Po drugie, protokół MCP to nie przypadkowy skrót, lecz oficjalny standard, przez który Apps SDK rozmawia z twoimi narzędziami: serwer musi umieć wyliczać tools, przyjmować żądania call_tool i zwracać link do zasobu UI do renderowania w ChatGPT.

Po trzecie, oddzielne warstwy Agents i ACP są formalnie opcjonalne, ale w realnych, komercyjnych aplikacjach pojawiają się niemal zawsze: czasem trzeba zaplanować wieloetapowy scenariusz, czasem — przyjąć płatność.

Teraz przeanalizujmy każdą warstwę osobno.

Insight: ChatGPT to framework

Integracja z ChatGPT nie jest w jednym miejscu — jest rozsmarowana po wielu punktach integracji. Dla programisty najbardziej przypomina to pracę z frameworkiem. Framework sam decyduje, kiedy i gdzie wywołać twój kod; ty jedynie dopisujesz właściwe elementy we właściwych miejscach.

Z ChatGPT jest dokładnie tak:

• widżety — rejestrowane przez mcp-resources, GPT sam decyduje, kiedy je pokazać
• mcp-tools — GPT sam decyduje, kiedy je wywołać
• product feed — można dodać do modelu przez mcp‑tool, ale standardowa ścieżka to przez site register merchant
• ACP/InstantCheckout — oddzielne API
• Autoryzacja — osobny serwer mcp auth.

3. Warstwa 1 — ChatGPT UI: nasz „host”

ChatGPT UI to przeglądarkowy (i mobilny) interfejs OpenAI, w którym użytkownik prowadzi główny dialog. Jest tu znane pole wprowadzania, historia wiadomości, przyciski wyboru modelu i karta z aplikacjami (Store/Composer).

Tej warstwy nie programujemy. Nie mamy dostępu do jej kodu, DOM ani stylów. Ale to ona wyznacza ramy:

• to tutaj użytkownik „wybiera” twoją aplikację jawnie (przez Store/Composer) lub niejawnie (model sam zaproponuje App);
• to tutaj ChatGPT decyduje: odpowiedzieć po prostu tekstem, wywołać twój tool, wyrenderować widżet albo zrobić wszystko naraz;
• to tutaj żyją podstawowe wzorce UX: widżet inline, tryb pełnoekranowy, okno PiP itd. (szczegóły w module 8).

Z praktycznego punktu widzenia warto pamiętać: ChatGPT UI to nasze host‑aplikacja. Wbudowujemy się do niej, a nie odwrotnie. Serwer GPT załaduje kod twojego widżetu do siebie, oczyści z nadmiarów i dopiero potem będzie ładować go do swojego czatu ze swojej domeny.

4. Warstwa 2 — Apps SDK i widżet (Next.js 16 w czacie)

Kolejna warstwa to twój kod UI napisany w React/Next.js z użyciem Apps SDK.

Model mentalny jest prosty: to jak mini‑SPA renderowane jako osadzony widżet w czacie. Ale z zastrzeżeniami:

• twój kod działa w piaskownicy: ograniczony DOM, własne zasady zapytań sieciowych, specjalny obiekt window.openai do komunikacji z ChatGPT (o tym będzie osobny wykład);
• widżet nie kontroluje przepływu dialogu: użytkownik pisze w ogólnym czacie, model decyduje, kiedy zawołać twój App, a ty odpowiadasz tylko w swojej „ramce”;
• Apps SDK bierze na siebie wszystko: synchronizację stanu widżetu z historią dialogu, obsługę wyników narzędzi, pracę z MCP itp.

Z perspektywy developera Next.js wygląda to dość znajomo: masz strony/komponenty, hooki, propsy. Ale zamiast klasycznego fetch('/api/...') częściej będziesz polegać na narzędziach (tools) opisanych w serwerze MCP oraz na specjalnych hookach Apps SDK (o nich później w kursie).

Aby trochę skonkretyzować rozmowę, przypomnijmy nasz projekt — umowny GiftGenius. To aplikacja pomagająca dobierać prezenty według parametrów: dla kogo, w jakim budżecie, z jakiej okazji itd.

Mini‑fragment przyszłego UI (na razie bez specyfiki SDK, tylko koncepcja):

// GiftSummary.tsx — prosty komponent React naszej aplikacji
type GiftIdea = {
  id: string;
  title: string;
  price: number;
};

interface GiftSummaryProps {
  ideas: GiftIdea[];
}

export function GiftSummary({ ideas }: GiftSummaryProps) {
  return (
    <ul>
      {ideas.map((idea) => (
        <li key={idea.id}>
          {idea.title} — ${idea.price}
        </li>
      ))}
    </ul>
  );
}

Później ten komponent będzie otrzymywał ideas nie z powietrza, lecz z wyniku narzędzia serwera MCP (ToolOutput), ale na poziomie architektury ważniejsze jest co innego: cały taki kod żyje w „drugiej warstwie” i zajmuje się wyłącznie prezentacją stanu.

5. Warstwa 3 — serwer MCP: świat narzędzi i danych

Teraz schodzimy niżej — do części serwerowej.

Model Context Protocol (MCP) to standard opisujący, jak klient LLM (ChatGPT, Apps SDK, Agents) komunikuje się z twoim serwerem. Określa, jakie narzędzia są dostępne, jakie mają schematy wejścia/wyjścia, jak je wywoływać i jakie inne zasoby/prompt‑y można podładowywać.

Minimalny serwer MCP dla Apps SDK powinien umieć trzy rzeczy:

• zwracać listę narzędzi (List tools) z ich JSON Schema i metadanymi;
• obsługiwać wywołania narzędzi (Call tools) — przyjmować żądanie call_tool, wykonywać logikę biznesową i zwracać ustrukturyzowany wynik;
• zwracać html, js, css,... — opcjonalnie, jeśli tool jest powiązany z konkretnym widżetem, który trzeba wyświetlić.

Ważny punkt: MCP to protokół niezależny od transportu. Dla ChatGPT Apps interesuje nas jego wariant HTTP z realizacją strumieniową/streamable, ale szczegóły transportu i format wiadomości to temat modułu MCP (poziom 6). Na tym etapie wystarczy rozumieć, że Apps SDK „od dołu” rozmawia właśnie z serwerem MCP, a nie z dowolnymi endpointami REST.

Architektonicznie warstwa MCP często wygląda jak osobny mikroserwis:

flowchart LR
    subgraph App["Twój ChatGPT App"]
      W["Widżet (Next.js + Apps SDK)"]
      M["Serwer MCP (@modelcontextprotocol/sdk)"]
    end

    W <-- JSON-RPC over HTTP/SSE --> M
    M --> DB[(Katalog prezentów)]
    M --> EXT[Zewnętrzne API]

Wewnątrz serwera MCP piszesz już zwykły kod TypeScript/Node, używasz baz danych, kolejek, zewnętrznych API itd. Oficjalny TypeScript SDK dla MCP bierze na siebie serializację JSON‑RPC, walidację schematów i trasowanie wywołań.

Dla naszego GiftGenius jedno z narzędzi MCP może nazywać się np. search_gifts. Na poziomie TypeScript może to wyglądać jak zwykła funkcja:

// Pseudo‑kod: logika biznesowa wewnątrz serwera MCP
export async function searchGifts(params: {
  recipient: string;
  budget: number;
}) {
  // tutaj odwołujesz się do bazy/katalogu
  const items = await findGiftsInCatalog(params);
  return items.slice(0, 10);
}

Później owiniemy ją w MCP‑tool z opisem schematu, ale najważniejsze: ta warstwa to twój „normalny” backend, tylko mówiący ze światem przez MCP.

6. Warstwa 4 — Agents SDK: mózg złożonych scenariuszy

Nie wszystkie aplikacje potrzebują agentów, ale gdy tylko scenariusz przestaje być „jedno wywołanie narzędzia — jedna odpowiedź”, warstwa agentowa staje się bardzo przydatna.

Agent to w istocie sterowalny proces LLM, który:

• czyta zapytanie użytkownika i fakty z historii dialogu;
• planuje sekwencję kroków: które narzędzia wywołać, w jakiej kolejności, z jakimi argumentami;
• analizuje wyniki, może podjąć decyzję „wywołać tool ponownie”, „poprosić użytkownika o doprecyzowanie”, „zbudować bardziej złożoną odpowiedź”;
• czasem przechowuje stan między krokami (pamięć, sesje, checkpointy — to już poziom 12).

Agents SDK daje ustrukturyzowany sposób opisywania takich scenariuszy: jakie narzędzia są dostępne agentowi, jak przechowywać i odtwarzać stan, jak ograniczać pętle itp. Agenci uruchamiani są wewnątrz backendu i pozwalają użyć mocy OpenAI tak, jak chcesz: bez ograniczeń widżetów ChatGPT Apps.

W kontekście naszego stosu agent zwykle siedzi w backendzie pomiędzy warstwą MCP a twoimi domenowymi API. Może używać zewnętrznych API, wewnętrznych funkcji i MCP‑tools jako „rąk”, a sam zajmuje się „mózgiem”.

Przykładowo, scenariusz GiftGenius może wyglądać tak:

1. Użytkownik pisze „dobierz prezent dla mamy do 50 $”.
2. ChatGPT wywołuje narzędzie search_gifts twojej aplikacji.
3. Za search_gifts w backendzie odpowiada Agent, który decyduje się najpierw doprecyzować kilka szczegółów (zainteresowania, okazja).
4. Użytkownik dopisuje dodatkowe życzenia.
5. ChatGPT ponownie wywołuje search_gifts w twojej aplikacji z dodatkowymi argumentami.
6. Agent na serwerze może wywołać dodatkowe narzędzia (np. sprawdzanie dostępności).
7. Zwraca do ChatGPT przygotowane propozycje i ewentualnie link do widżetu do wizualizacji.

Później w kursie szczegółowo rozbierzemy run‑cycle agenta, idempotencję i bezpieczeństwo, ale dla ogólnej architektury istotne jest: warstwa agentowa to opcjonalny, lecz bardzo mocny „mózg”, zdejmujący z ciebie część trudnej orkiestracji.

7. Warstwa 5 — ACP/Backend: pieniądze, dane i przyziemne troski

Najniższa warstwa to twoje zwykłe serwisy:

• bazy danych (katalogi produktów, użytkownicy, zamówienia);
• zewnętrzne API (dostawcy płatności, logistyka, zewnętrzne SaaS);
• specjalistyczne protokoły, takie jak ACP (Agentic Commerce Protocol) dla scenariuszy commerce i Instant Checkout.

ACP opisuje, jak ChatGPT i agenci rozmawiają z twoim backendem commerce: zapytania o dobór SKU, tworzenie koszyka, składanie zamówienia, zwroty, webhooki o powodzeniu/niepowodzeniu operacji itd.

Dla GiftGenius będzie to mniej więcej tak:

• MCP‑tool search_gifts czyta z feedu produktowego/bazy;
• agent, wybierając konkretny produkt, inicjuje intent commerce (przez ACP);
• twój backend zgodny z ACP mówi do PaymentService: „pobieramy środki”, informuje ChatGPT o statusie;
• użytkownik widzi w ChatGPT, że zamówienie zostało złożone, bez przechodzenia na zewnętrzną stronę.

Skoro przebiegliśmy warstwy, spójrzmy teraz na konkretny scenariusz end‑to‑end.

8. Scenariusz end‑to‑end: jak zapytanie użytkownika przechodzi przez wszystkie warstwy

Weźmy zapytanie: „Dobierz prezent dla mamy do 50 $, lubi czytać i herbatę”.

Rozłóżmy to na kroki.

1. Użytkownik pisze tekst w ChatGPT. To pierwsza warstwa — ChatGPT UI. Dla użytkownika wszystko wygląda jak zwykły czat.
2. Model czyta historię dialogu, metadane twojej aplikacji (opisy, kategorie, uprawnienia) i decyduje, że GiftGenius jest właściwym kandydatem. Zgodnie z zasadami discovery w Apps SDK model uwzględnia zarówno opisy tekstowe tools, jak i wcześniejsze użycia, kontekst, a nawet wzmianki o marce.
3. ChatGPT albo:
   • od razu wywołuje narzędzie twojej aplikacji bez UI (scenariusz tool‑first);
   • albo proponuje w odpowiedzi: „Mogę użyć GiftGenius, aby pomóc w wyborze prezentu” i wywołuje twój tool.
4. ChatGPT wysyła do serwera MCP żądanie call_tool dla narzędzia search_gifts. Serwer MCP wykonuje logikę biznesową: sięga do bazy/feedu, filtruje po budżecie i preferencjach i zwraca JSON z listą pasujących produktów.
5. Wynik narzędzia wraca do ChatGPT. Może:
   • po prostu użyć go jako danych do odpowiedzi tekstowej („Oto 3 pomysły na prezent...”), bez pokazywania widżetu;
   • albo wyświetlić widżet, przekazując ToolOutput do twojego komponentu, aby wyrenderować karty produktów.
6. I dopiero w tym momencie uruchamia się twój widżet GiftGenius (Apps SDK) i twój kod Next.js jest renderowany wewnątrz czatu. Widżet może np. pokazać formularz z dodatkowymi polami: „Dla kogo prezent?”, „Budżet”, „Zainteresowania”. Użytkownik może klikać przyciski lub po prostu dalej pisać w czacie — model będzie to synchronizował z aplikacją.
7. Gdy widżet potrzebuje realnych danych (katalog prezentów), nie robi fetch('https://my-backend/gifts') bezpośrednio. Zamiast tego sam inicjuje wywołanie narzędzia MCP: ChatGPT ponownie wysyła do serwera MCP żądanie call_tool dla narzędzia search_gifts.
8. Jeśli scenariusz jest wieloetapowy (trzeba prosić o doprecyzowanie, robić ranking, dodatkowo sprawdzać dostępność, proponować alternatywy), warstwa agentowa bierze na siebie planowanie, zarządzanie workflow i orkiestrację agentów.
9. Gdy użytkownik decyduje się „kupić” konkretny produkt, ChatGPT inicjuje zakup przez protokół ACP. Backend commerce przez ACP i Instant Checkout przeprowadza operację, odpowiada statusem, wywołuje webhooki, a ChatGPT pokazuje użytkownikowi finalny status („Zamówienie złożone, oto paragon”).

Z punktu widzenia developera świetne jest to, że na każdym poziomie są jasne granice odpowiedzialności. A jednocześnie wszystkie warstwy łączą nowe znormalizowane protokoły (MCP, ACP), a nie stare, oklepane zapytania REST.

To wszystko to obraz logiczny: jakie warstwy istnieją i jak przez nie przepływa zapytanie. Dalej będzie nas interesować strona fizyczna: jak dokładnie te warstwy mogą być wdrożone w kodzie i infrastrukturze — jednym monolitem Next czy kilkoma serwisami (nie chodzi o spór monolit vs mikroserwisy).

9. Monolit Next.js vs architektura rozdzielona

Teraz logiczne pytanie: „Czy to wszystko musi być zbiorem oddzielnych serwisów? Czy mogę po prostu zrobić jeden monolit Next.js i mieć spokój?”

Odpowiedź: możesz. W kursie będziemy iść od prostego do złożonego. Na start jak najbardziej ok zebrać „prawie wszystko” w jednym repozytorium, a nawet jednym runtime:

flowchart LR
    U[ChatGPT] --> W["Next.js App (Apps SDK)"]
    W --> M["MCP endpoint (w tym samym Next.js)"]
    M --> DB[(Baza danych/katalog)]

Czyli twój serwer Next.js (trasy API albo osobny serwer) jednocześnie:

• serwuje UI‑widżet (strony/komponenty Apps SDK),
• realizuje endpoint MCP (JSON‑RPC ponad HTTP),
• sięga do bazy danych/zewnętrznych API.

To wygodne w trybie deweloperskim i dla pierwszych wersji aplikacji: mniej ruchomych części, prostsze wdrożenie.

Jednak wraz ze wzrostem funkcjonalności pojawiają się powody, by rozdzielić warstwy:

• serwer MCP trzeba skalować osobno (dużo ciężkich narzędzi);
• backend finansowy żyje na własnej domenie, jest zarządzany przez inne zespoły, wymaga szczególnego bezpieczeństwa;
• logika agentowa może zostać wydzielona do osobnej aplikacji z własnym monitoringiem i SLA.

Wtedy obraz zaczyna wyglądać bliżej tego, co już widzieliśmy:

flowchart TD
    U[ChatGPT] --> W[Next.js + Apps SDK]
    W --> MG[MCP Gateway]
    MG --> M1[MCP Gifts Server]
    MG --> M2[MCP Analytics Server]
    M1 --> AG[Agent Service]
    AG --> ACP[Commerce/ACP Backend]

Dochodzi pojęcie MCP Gateway — wspólne wejście dla ChatGPT. Trasuje wywołania do różnych serwerów MCP, pracuje z REST API, zarządza autoryzacją, limitami zapytań (rate limiting) itp.

Zaczniemy pisać przykłady od bardziej monolitycznego scenariusza, ale od początku będziemy organizować kod tak, by dało się go względnie bezboleśnie rozciąć na części.

10. Gdzie dokładnie będziesz pisać kod (a co delegujesz innym)

Skoro zarysowaliśmy, jak warstwy mogą być złożone w monolit lub architekturę rozdzieloną, warto jasno zaznaczyć, w których miejscach będziesz pisać kod, a co pozostanie po stronie innych serwisów/zespołów.

Z perspektywy developera TypeScript/Next.js warto wprost oznaczyć, które strefy kontrolujesz.

W widżecie (Apps SDK + Next.js) ty:

• piszesz komponenty React, które prezentują stan narzędzi i dane wejściowe użytkownika;
• używasz hooków Apps SDK, by czytać ToolInput/ToolOutput i stan widżetu (widget state);
• konfigurujesz tryb wizualny (inline/fullscreen/PiP, motywy, rozmiary — to będzie na poziomie 8);
• komunikujesz się z ChatGPT przez window.openai dla bardziej zaawansowanych scenariuszy (osobny moduł kursu).

W serwerze MCP ty:

• opisujesz tools/resources/prompts za pomocą MCP SDK;
• realizujesz logikę biznesową narzędzi (w istocie zwykłe funkcje TypeScript, które sięgają do baz, API itd.);
• optymalizujesz schematy i odpowiedzi, aby modelowi łatwiej było je czytać (mniej halucynacji, więcej struktury).

W warstwie agentowej (jeśli używasz Agents SDK) ty:

• opisujesz, jakie narzędzia są dostępne agentowi i jakie ma cele;
• konfigurujesz run‑cycle, pamięć, kontrolę pętli;
• dbasz o to, by agent nie robił głupstw i nie wpadał w nieskończone planowanie.

W ACP/backendach ty:

• albo integrujesz się z istniejącymi usługami commerce (Stripe, własny sklep z product feedem itp.);
• albo projektujesz nowy backend, który rozumie ACP i potrafi przyjmować oraz zwracać zamówienia.

Ważne: rzadko ta sama osoba w dojrzałym produkcie w pełni posiada wszystkie warstwy. Ale na etapie prototypu (i w tym kursie) liczymy, że przynajmniej będziesz rozumieć, w którym miejscu jaki kod żyje.

11. Jak architektura wpływa na UX i politykę platformy

Choć temat UX i polityk to osobne moduły, już na poziomie architektury ważne jest rozumieć, jak wybrany podział warstw odbije się na UX i wymaganiach platformy. Zróbmy więc kilka uwag z wyprzedzeniem.

Po pierwsze, sandbox. Widżet nie może bezrefleksyjnie buszować po internecie i zbierać danych użytkownika — wszystko idzie przez kontrolowane narzędzia i opisane w MCP/Store uprawnienia. Platforma oczekuje, że uczciwie opiszesz, jakie dane i działania są potrzebne twojej aplikacji, i będzie na tych opisach opierać discovery/propozycje App.

Po drugie, przepływ UX. Ponieważ model może chwilowo „zapomnieć” o twojej aplikacji lub przeciwnie — zbyt agresywnie ją proponować, architektura powinna być przyjazna przerwaniom: jeśli agent nie zdążył zakończyć długiego workflow, a użytkownik zmienił temat, aplikacja powinna to znieść bez bólu. Wieloetapowe scenariusze i orkiestracja workflowów w kursie będą budowane właśnie na MCP‑tools i warstwie agentowej.

Po trzecie, sprzedaż. Gdy tylko twoja aplikacja zaczyna pobierać opłaty, wchodzą dodatkowe wymagania bezpieczeństwa, logowania, kontraktów ACP itp. To, jak podzielisz warstwy (UI, MCP, Agents, ACP/Backend), mocno wpłynie na to, jak bardzo będzie bolał przegląd w Store i audyt bezpieczeństwa.

Pierwsze podsumowanie

Mam nadzieję, że zbudowałeś w głowie mapę przeglądową:

• górne warstwy (ChatGPT UI + Apps SDK) określają, jak użytkownik widzi i odczuwa twoją aplikację;
• warstwa środkowa (MCP) — to standardowy sposób dawania modelowi narzędzi i danych;
• warstwy agentowa i commerce czynią twoją aplikację nie tylko „przeglądarką danych”, lecz pełnoprawnym produktem z logiką i pieniędzmi.

Na poziomie drugim zaczniemy od najciekawszego: pobierzemy oficjalny szablon Apps SDK na bazie Next.js, uruchomimy go lokalnie i podłączymy do ChatGPT w Trybie Dev. Czyli w pierwszej kolejności pomacamy warstwę Apps SDK/widżetu, a MCP/agenci na razie będą żyć jako atrapy lub wbudowany backend.

Ale trzymanie obecnego schematu w głowie jest ważne już teraz: to jak patrzeć na monorepo i rozumieć, że folder apps/ — to UI, services/mcp — protokół, services/agent — orkiestrator, a services/commerce — pieniądze.

12. Typowe błędy w rozumieniu architektury stosu

Błąd nr 1: uważać, że ChatGPT App = po prostu „webhook do mojego REST API”.
Tak można zrobić z przyzwyczajenia ze świata „botów”: niby model po prostu wysyła POST na mój URL, a dalej jakoś to będzie. W rzeczywistości między modelem a twoim kodem stoją Apps SDK i MCP. Musisz opisać narzędzia, ich schematy i zachowanie, a nie tylko „słuchać” dowolnych żądań HTTP.

Błąd nr 2: mieszanie poziomów UI i logiki biznesowej.
Popularny antywzorzec — wciągać złożoną logikę domenową prosto do widżetu, a warstwę MCP robić cienką przekładką. W efekcie UI staje się ciężkie, trudno testowalne i mało przydatne do ponownego użycia poza ChatGPT. O wiele stabilniej trzymać reguły i dostęp do danych na poziomie MCP/agenta, a widżetem zajmować się wyłącznie prezentacją i prostą interakcją.

Błąd nr 3: ignorować MCP i pisać „własny protokół”.
Czasem kusi: „po co mi MCP, będę po prostu zwracać JSON, a model sam zrozumie”. W krótkich demach może to „działać”, ale natychmiast tracisz standardowe możliwości discovery, inspekcji, autoryzacji i wieloklientowego wsparcia, które MCP i Apps SDK dają „z pudełka”.

Błąd nr 4: budować całą aplikację wokół jednej warstwy.
Ktoś robi „wszystko w agencie”, ładując go masą odpowiedzialności. Ktoś inny próbuje upchnąć wszystko w MCP‑tools. Ktoś buduje gigantyczny monolit Next.js. Lepiej przyjąć, że każda warstwa ma swoją strefę odpowiedzialności: UI — prezentacja, MCP — dostęp do danych/akcji, agent — orkiestracja, ACP/Backend — inwarianty domenowe i pieniądze.

Błąd nr 5: nie doceniać wpływu architektury na przegląd w Store i bezpieczeństwo.
Jeśli masz jeden serwer, który jednocześnie jest endpointem MCP, zasobem ACP, trzyma sekrety i zapisuje wszystko do logów „jak leci”, — przegląd bezpieczeństwa i polityk treści może być długotrwały. Architektura rozdzielona, z jasnymi granicami i protokołami, mocno upraszcza życie na późniejszych etapach.