Det här lärde vi oss av att lansera med ChatGPT Apps SDK

• Apps SDK är ett praktiskt alternativ om du snart behöver ett arbetsflöde i ChatGPT eller vill testa dina verktyg där innan du investerar i en anpassad Agent-stack. Om du behöver styra varje steg i hur din Agent beter sig är det oftast inte rätt val.

• Välj Apps SDK när ChatGPT ska vara huvudgränssnittet och du vill ha verktyg samt mindre UI-inslag utan att bygga en komplett chattprodukt. Välj en egen Agent-stack när du behöver noggrann kontroll över flöde, minne, prompter och skrivåtgärder.

• Apps SDK passar produkter som kombinerar chatt med några korta UI-steg. Du lanserar snabbare, men ger upp en del kontroll.

• Det som fungerade för oss var tydliga verktyg, tydligt widgetbeteende och tydliga nästa steg. Vi förlitade oss på dem för att styra flödet, inte på LLM:en. Modellen var mest användbar när den förklarade resultat som systemet redan hade valt.

• Nedan beskriver vi först hur du väljer och sedan vad som fungerade respektive inte fungerade.

De flesta team kör fortfarande AI-piloter eller använder AI för perifera ändamål med låg risk och begränsad nytta. Få lanserar en verksamhetskritisk produkt som användarna nyttjar varje vecka. ChatGPT Apps SDK är ett sätt att överbrygga det gapet om målet är att finnas i ChatGPT i stället för att bygga hela assistenten själv.

Våra lärdomar kommer från ett kunduppdrag där kraven pekade på ChatGPT som huvudgränssnitt och en snabb väg framåt som inte krävde att kunden finansierade en helt skräddarsydd chattprodukt.

Apps SDK passade uppdraget eftersom kunden behövde:

• Ingen separat chattprodukt att bygga och drifta – de ville nå användare i ChatGPT, inte skapa ännu ett fristående skal för en assistent.

• Chatt plus ett mindre, uppgiftsspecifikt UI – några fokuserade widgetsteg, inte en andra fullskalig produkt inuti arbetsflödet.

• Backendfunktioner exponerade via MCP-verktyg – vanliga verktygsanrop, inte en anpassad Agent-körmiljö som de själva ägde från början till slut.

• Upptäckt i ChatGPT – användarna skulle möta arbetsflödet där de redan arbetar.

Vi validerade dessa val tillsammans med kunden under utvecklingen. Avvägningen kvarstår: när ChatGPT är värd för sessionen äger du inte den yttre körmiljön. Du vägleder den, men har inte full kontroll.

En app byggd med Apps SDK kopplar samman tre saker:

1. ChatGPT:s Agent-körmiljö

2. Dina MCP-verktyg

3. Ditt widgetgränssnitt

Så fungerar flödet i praktiken:

1. Användaren ber ChatGPT om något.

2. ChatGPT kan anropa ett av dina MCP-verktyg.

3. Din server returnerar ett strukturerat verktygsresultat.

4. ChatGPT läser resultatet och väljer nästa steg: fler verktygsanrop, ett svar till användaren eller både och. Om du har kopplat en widget till verktyget kan den visas i den här turen.

5. Användaren fortsätter i chatten eller widgeten med exempelvis en följdfråga, ett val eller ett verktygsanrop som utlöses av widgeten. Det uppdaterar tråden. ChatGPT kör en ny tur och steg 2–4 upprepas tills uppgiften är klar.

Poängen är just kombinationen av chatt, backendåtgärder och korta UI-steg. Det innebär också att de känsliga delarna är överlämningarna mellan chatt, verktyg och UI.

Du behöver inte bygga chattgränssnitt, verktygsintegration, autentiseringsmönster eller widgetskal från grunden. För många produkter förkortar det utvecklingstiden avsevärt, så att du kan fokusera på domänlogik och skyddsräcken.

Att bygga inuti ChatGPT är inte samma sak som att köra en egen Agent. Det svåra i projektet var inte prompttrick. Det var att göra verktyg, widgetar och nästa steg så tydliga att Modellen och gränssnittet förblev samordnade.

Apps SDK ger produkten en annan form än ett traditionellt frontendgränssnitt, och det är viktigt att veta vilka scenarier det passar bäst för.

Använd Apps SDK när du vill

• Lansera ett arbetsflöde i ChatGPT snabbt.

• Låta ChatGPT vara värd för konversationen.

• Kombinera naturligt språk med några fokuserade UI-steg.

• Slippa bygga ett eget chattgränssnitt, en egen Agent-behållare och en egen lösning för upptäckt.

Den sista punkten är viktig när användarna redan tillbringar sin tid i ChatGPT.

Bygg en egen Agent när du behöver

• Ett fast steg-för-steg-flöde som kan upprätthållas i koden.

• Ett anpassat UI och bekräftelseflöde som du äger från början till slut.

• En egen Modell för minne och tillstånd.

• Ett beteende som måste vara förutsägbart vid varje körning.

• Spårning, loggar och mätvärden för din Agent.

Om planeraren, systemprompterna och hela arbetsflödet utgör din produkt passar en anpassad stack oftast bättre.

Under uppdraget återkom vi ständigt till ordet kontroll: snabbhet och en välbekant värdmiljö på ena sidan, delvis ägarskap över körmiljön på den andra. Det var avvägningen kunden accepterade när de prioriterade att möta användarna i ChatGPT framför att äga hela stacken.

Det önskade flödet låter enkelt: användaren frågar, verktyget körs, data kommer tillbaka och widgeten visas när användaren behöver göra ett val.

I praktiken var överlämningarna problemet. En widget är inte en dekoration. När den väl visas påverkar den vad Modellen ser och gör härnäst. Behandla widgetåtgärder som namngivna händelser, inte som löst formulerad chatt.

Stacken i uppdraget var okomplicerad: FastMCP, Pydantic, React och TypeScript. Integrationen av dem gick bra. Arbetet handlade om att få Modellen, verktygen och gränssnittet att vara överens om vad som skulle hända härnäst.

Gör varje överlämning tydlig

Vi slutade behandla verktygsresultat som råa backenddata. Varje retur blev en överlämning.

Ett bra verktygsresultat:

• Ger widgeten det den behöver för att renderas.

• Ger ChatGPT strukturerade fakta att basera svaret på.

• Anger vid behov vad som ska hända härnäst, så att Modellen inte behöver gissa.

Widgetåtgärder bör inte skicka vaga formuleringar tillbaka till tråden. De bör ange vad användaren gjorde och vad som ska hända härnäst.

Tillförlitligheten ökade när överlämningarna blev tydliga.

Modellen följer korta, tydliga instruktioner när de finns i verktygets utdata och i widgetåtgärderna.

Nedan visas en liten Pydantic-struktur som vi använde. Fältet output innehåller de strukturerade data som widgeten behöver när en sådan visas, samt de fakta som ChatGPT ska använda under sessionen. Fältet agent_directions innehåller en kort rad som anger vad assistenten ska göra härnäst. Reason är valfritt.

1from typing import Generic, TypeVar2
3from pydantic import BaseModel4
5T = TypeVar("T")6
7class AgentDirections(BaseModel):8 assistant_instruction: str9 reason: str | None = None10
11class ToolResults(BaseModel, Generic[T]):12 agent_directions: AgentDirections13 output: T

Håll widgetarna små

De widgetar som fungerade hanterade ett beslut och lämnade sedan tillbaka kontrollen. Korta listor, bekräftelser eller en avgränsad granskningsvy fungerade bättre än att göra widgeten till en miniapp. Lite logik i widgeten, som enkel validering eller ett fast nästa steg, hjälpte ändå när vi ville göra flödet mer deterministiskt.

Tredje person i widgetmeddelanden

Vi slutade skriva widgetens uppföljningar som om de var chattmeddelanden från användaren (“I selected…,” “I confirmed…”). Vi skrev dem som korta rapporter om vad användaren hade gjort (“The user selected…,” “The user confirmed…”). Vi testade detta eftersom ChatGPT lade till widgetmeddelanden som verktygsmeddelanden i stället för användarmeddelanden.

Direkta åtgärder när nästa steg är uppenbart

Om det tydligt framgår av en knapp vilket verktygsanrop som ska göras härnäst fungerade det bättre att låta widgeten utlösa det direkt än att tvinga fram ytterligare en interaktion i chatten. Det gäller bara om nästa verktygsanrop inte behöver indata från ChatGPT.

Det gjorde det enklare att upprätthålla deterministiska flöden och minskade fördröjningen genom att undvika ytterligare en interaktion i chatten.

Felhantering

När ett verktygsanrop misslyckades returnerade vi rätt MCP-felkoder och korta, tydliga meddelanden från verktyget. Då fick ChatGPT konkret information om misslyckade anrop och kunde förklara problemet för användaren och/eller välja ett rimligt nästa steg.

Hantering av verktygskontext

Vi lagrade sessionstillståndet på vår server. ChatGPT skickar sessionsspecifik kontext med verktygsanrop. I FastMCP gav vi varje verktyg en Context-parameter så att hanteraren kunde läsa och uppdatera tillståndet.

• Stabila ID:n och tidigare resultat lagrades i sessionen i stället för att ChatGPT skulle behöva skicka dem på nytt som verktygsargument vid varje anrop.

• När loopar med verktygsanrop uppstod kunde vi identifiera dubbletter och returnera ett tydligt fel via verktygsresultatet.

• Sessionsloggarna fanns kvar hos oss för felsökning och support.

I början visade vi en widget, antog att Modellen ”förstod” och väntade på rätt uppföljande verktygsanrop. Ibland hände det. Ofta gjorde det inte det.

Utan en tydlig överlämning kunde ChatGPT sammanfatta när vi ville ha en åtgärd, be användaren upprepa ett val eller fortsätta planera när det borde ha stannat.

Lösningen var att uttryckligen ange nästa steg i Strukturerade utdata och widgetdata, inte att hoppas att Modellen skulle lista ut det.

Vi försökte följa Apps SDK-dokumentationen och på ett smart sätt dela upp svar mellan verktygsutdata, dold metadata och chatttext. Men widgetarna kunde inte läsa den dolda metadatan. Därför kunde vi inte använda den lösningen.

Dokumentationen för Apps SDK beskriver verktyg som kan döljas från Agentens verktygslista så att den inte väljer dem, men som ändå kan anropas från widgeten. När vi ställde in synligheten på app-only blev verktygen otillgängliga även från widgeten, inte bara från Agenten. Vi lyckades aldrig skapa en konfiguration där Agenten inte kunde se ett verktyg men widgeten fortfarande kunde göra det.

Tystnad eller ett allmänt ”lyckades” när inget användbart hade hänt var sämre än ett tydligt fel. Därför behandlade vi fel i verktyg och widgetar som fullvärdiga utdata: om ett steg inte kunde fortsätta beskrev vi det tydligt och returnerade ett uttryckligt fel, i stället för att lämna användaren med en renderad widget som inte förde dem vidare. Det förbättrade användbarheten och gjorde Modellens beteende mer tillförlitligt.

Om målet är ett arbetsflöde i ChatGPT med mindre eget plattformsarbete är Apps SDK ett praktiskt sätt att nå dit. Du byter en del kontroll mot snabbhet och möjligheten att möta användarna där de redan arbetar.

Om du behöver äga varje gren i flödet, gränssnittet och beslutet om varje steg bör du planera för en egen Agent-stack från början. Du kommer sannolikt att växa ur en lösning som endast byggs inuti ChatGPT.

Du kan också använda Apps SDK för att köra din MCP-server i ChatGPT innan du själv bygger chatt, autentisering och Agent-infrastruktur, och sedan gå över till en egen stack när produkten kräver det.

Nästa steg för team i samma situation är att välja ett arbetsflöde med ett tydligt resultat, dokumentera överlämningarna mellan chatt, verktyg och widgetar och sedan stresstesta återförsök och fel innan ni lägger mycket tid på promptjustering.