Dette lærte vi av å lansere med ChatGPT Apps SDK

• Apps SDK er et praktisk valg hvis du snart trenger en arbeidsflyt i ChatGPT, eller hvis du vil prøve verktøyene dine der før du investerer i en egen agentplattform. Hvis du må styre hvert trinn i agentens atferd, er det vanligvis ikke det.

• Velg Apps SDK når ChatGPT skal være hovedgrensesnittet, og du vil ha verktøy og noen små UI-elementer uten å bygge et fullverdig chatteprodukt. Velg din egen agentplattform når du trenger stram kontroll over flyt, minne, prompter og skriveoperasjoner.

• Apps SDK passer for produkter som kombinerer chat med noen få, korte UI-trinn. Du lanserer raskere, men gir avkall på noe kontroll.

• Det som fungerte for oss, var tydelige verktøy, tydelig widgetatferd og tydelige neste trinn. Vi baserte flyten på disse, ikke på LLM-en. Modellen var mest nyttig når den forklarte resultater systemet allerede hadde valgt.

• Nedenfor ser vi først på hvordan du velger, og deretter på hva som fungerte og ikke fungerte.

De fleste team kjører fortsatt KI-piloter eller bruker KI til mindre sentrale formål med lav risiko og begrenset gevinst. Få lanserer et virksomhetskritisk produkt som brukerne benytter hver uke. ChatGPT Apps SDK er én måte å tette dette gapet på hvis målet er å være tilgjengelig i ChatGPT fremfor å bygge hele assistenten selv.

Erfaringene våre kommer fra et kundeoppdrag der kravene tilsa ChatGPT som hovedgrensesnitt og en rask vei fremover uten at kunden måtte finansiere et komplett, skreddersydd chatteprodukt.

Apps SDK passet til dette oppdraget fordi kunden trengte:

• Ingen egen chatløsning å bygge og drifte – de ønsket rekkevidde i ChatGPT, ikke enda et frittstående assistentgrensesnitt.

• Chat kombinert med et lite, oppgavespesifikt grensesnitt – noen få målrettede widgettrinn, ikke et nytt fullverdig produkt i arbeidsflyten.

• Backendfunksjonalitet tilgjengelig gjennom MCP-verktøy – standard verktøykall, ikke et skreddersydd agentkjøremiljø de selv eide fra ende til ende.

• Synlighet i ChatGPT – brukerne skulle møte arbeidsflyten der de allerede jobbet.

Vi kvalitetssikret disse valgene med kunden underveis i utviklingen. Avveiningen gjelder likevel: Når ChatGPT er vert for økten, eier du ikke det ytre kjøremiljøet. Du veileder det, men har ikke full kontroll.

En Apps SDK-app kobler sammen tre ting:

1. Agentkjøremiljøet i ChatGPT

2. MCP-verktøyene dine

3. Widgetgrensesnittet ditt

Slik fungerer flyten i praksis:

1. Brukeren ber ChatGPT om noe.

2. ChatGPT kan kalle et av MCP-verktøyene dine.

3. Serveren din returnerer et strukturert verktøyresultat.

4. ChatGPT leser resultatet og bestemmer neste trinn: flere verktøykall, et svar til brukeren eller begge deler. Hvis du har knyttet en widget til verktøyet, kan den vises i denne runden.

5. Brukeren fortsetter i chatten eller widgeten (med oppfølgingstekst, et valg eller et verktøykall utløst av widgeten). Da oppdateres tråden. ChatGPT kjører en ny runde, og trinn 2–4 gjentas til oppgaven er fullført.

Poenget er nettopp denne kombinasjonen av chat, backendhandlinger og korte UI-trinn. Det betyr også at de sårbare delene er overgangene mellom chat, verktøy og grensesnitt.

Du slipper å bygge chattegrensesnitt, verktøyintegrasjon, autentiseringsmønstre og widgetrammeverk fra bunnen av. For mange produkter reduserer dette utviklingstiden betydelig, slik at du kan fokusere på domenelogikk og sikkerhetsmekanismer.

Å bygge i ChatGPT er ikke det samme som å kjøre din egen agent. Det vanskelige i prosjektet var ikke prompt-triks. Utfordringen var å gjøre verktøyene, widgetene og de neste trinnene tydelige nok til at modellen og grensesnittet forble samkjørte.

Apps SDK gir en annen type produkt enn et vanlig frontendgrensesnitt, så det er viktig å vite hvilke bruksområder det passer best for.

Bruk Apps SDK når du vil

• Lansere en arbeidsflyt i ChatGPT raskt.

• La ChatGPT være vert for samtalen.

• Kombinere naturlig språk med noen få målrettede UI-trinn.

• Slippe å bygge eget chattegrensesnitt, egen agentplattform og egen synlighetsmekanisme.

Det siste punktet er viktig når brukerne dine allerede arbeider i ChatGPT.

Bygg din egen agent når du trenger

• En fast trinnvis flyt som du kan håndheve i kode.

• Et skreddersydd grensesnitt og en bekreftelsesflyt du eier fra ende til ende.

• Din egen modell for minne og tilstand.

• Atferd som må være forutsigbar ved hver kjøring.

• Sporing, logger og måledata for agenten.

Hvis planleggeren, systempromptene og hele arbeidsflyten utgjør produktet ditt, passer en skreddersydd plattform vanligvis bedre.

I oppdraget vårt var kontroll det tilbakevendende temaet: På den ene siden hastighet og en kjent plattform, på den andre siden bare delvis eierskap til kjøremiljøet. Dette var avveiningen kunden godtok da de prioriterte å møte brukerne i ChatGPT fremfor å eie hele plattformen.

Standardflyten høres enkel ut: Brukeren spør, verktøyet kjører, dataene kommer tilbake, og widgeten vises når brukeren må velge.

I praksis var overgangene utfordringen. En widget er ikke pynt. Når den vises på skjermen, endrer den hva modellen ser og gjør videre. Behandle widgethandlinger som navngitte hendelser, ikke som ustrukturert chat.

Teknologistakken i oppdraget var enkel: FastMCP, Pydantic, React og TypeScript. Det var uproblematisk å integrere disse. Arbeidet besto i å få modellen, verktøyene og grensesnittet til å være enige om hva som skulle skje videre.

Gjør hver overgang tydelig

Vi sluttet å behandle verktøyresultater som rå nyttelast fra backend. Hver retur ble en overgang.

Et godt verktøyresultat:

• Gir widgeten det den trenger for å gjengi innholdet.

• Gir ChatGPT strukturerte fakta å basere svaret på.

• Angir ved behov hva som skal skje videre, slik at modellen slipper å gjette.

Widgethandlinger bør ikke sende vag prosa tilbake til tråden. De bør angi hva brukeren gjorde, og hva som skal skje videre.

Påliteligheten økte da overgangene ble tydelige.

Modellen følger korte og tydelige instruksjoner når de ligger i verktøyutdataene og widgethandlingene.

Nedenfor vises en liten Pydantic-struktur vi brukte. Feltet output inneholder de strukturerte dataene widgeten trenger når den vises, samt faktaene ChatGPT skal bruke i økten. Feltet agent_directions inneholder en kort linje som angir hva assistenten skal gjøre videre. Reason er valgfritt.

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

Hold widgetene små

Widgetene som fungerte, håndterte én beslutning og ga deretter kontrollen tilbake. Korte lister, bekreftelser eller et avgrenset kontrollskjermbilde fungerte bedre enn å gjøre widgeten til en miniapp. Litt logikk i widgeten, for eksempel enkel validering eller et fast neste trinn, var likevel nyttig når vi ønsket en mer deterministisk flyt.

Tredjeperson i widgetmeldinger

Vi sluttet å skrive widgetoppfølginger som om de var chatmeldinger fra brukeren («Jeg valgte…», «Jeg bekreftet…»). Vi skrev dem som korte rapporter om hva brukeren hadde gjort («Brukeren valgte…», «Brukeren bekreftet…»). Vi prøvde denne tilnærmingen fordi ChatGPT la inn widgetmeldinger som verktøymeldinger i stedet for brukermeldinger.

Direkte handlinger når neste trinn er opplagt

Hvis en knapp tydelig tilsier det neste verktøykallet, fungerte det bedre å la widgeten utløse det direkte enn å kreve enda en chatterunde. Dette gjelder bare hvis det neste verktøykallet ikke trenger inndata fra ChatGPT.

Dette gjorde det enklere å håndheve deterministiske flyter og reduserte forsinkelsen ved å unngå en ny chatterunde.

Feilhåndtering

Når et verktøykall mislyktes, returnerte vi riktige MCP-feilkoder og korte, enkle meldinger fra verktøyet. Da hadde ChatGPT reell informasjon å lese ved mislykkede kall, slik at det kunne forklare problemet for brukeren og/eller velge et fornuftig neste trinn.

Håndtering av verktøykontekst

Vi oppbevarte økttilstanden på serveren vår. ChatGPT sender øktavgrenset kontekst med verktøykall. I FastMCP ga vi hvert verktøy en Context-parameter, slik at behandleren kunne lese og oppdatere tilstanden.

• Stabile ID-er og tidligere resultater ble lagret i økten i stedet for at ChatGPT måtte sende dem på nytt som verktøyargumenter ved hvert kall.

• Når det oppsto løkker med verktøykall, kunne vi fange opp duplikater og returnere en tydelig feil gjennom verktøyresultatet.

• Øktloggene ble værende hos oss for feilsøking og brukerstøtte.

I starten viste vi en widget, antok at modellen «forsto det», og ventet på det riktige oppfølgende verktøykallet. Noen ganger skjedde det. Ofte gjorde det ikke det.

Uten en tydelig overgang kunne ChatGPT oppsummere når vi ønsket en handling, be brukeren gjenta et valg eller fortsette planleggingen når det skulle ha stoppet.

Løsningen var å angi neste trinn uttrykkelig i strukturerte utdata og widgetnyttelaster, ikke å håpe at modellen ville utlede det.

Vi forsøkte å være smarte med hvordan svarene ble fordelt mellom verktøyutdata, skjulte metadata og chattetekst, slik Apps SDK-dokumentasjonen beskriver. Men vi kunne ikke lese skjulte metadata i widgetene. Derfor kunne vi ikke bruke dette.

Dokumentasjonen for Apps SDK beskriver verktøy som kan holdes utenfor agentens verktøyliste, slik at agenten ikke velger dem, men som fortsatt kan kalles fra widgeten. Da vi satte synligheten til bare appen, ble disse verktøyene utilgjengelige også fra widgeten, ikke bare fra agenten. Vi fikk aldri til et oppsett der agenten ikke kunne se et verktøy, mens widgeten fortsatt kunne det.

Stillhet eller en generell «vellykket»-melding når ingenting nyttig hadde skjedd, var verre enn en tydelig feil. Derfor behandlet vi feil i verktøy og widgeter som selvstendige utdata: Hvis et trinn ikke kunne fortsette, sa vi det klart og returnerte en uttrykkelig feil, fremfor å la brukerne stirre på en widget som ble gjengitt uten å føre dem videre. Dette forbedret brukervennligheten og gjorde modellens atferd mer pålitelig.

Hvis målet er en arbeidsflyt i ChatGPT med mindre skreddersydd plattformarbeid, er Apps SDK en praktisk vei dit. Du bytter bort noe kontroll mot høyere hastighet og muligheten til å møte brukerne der de allerede jobber.

Hvis du må eie hver gren av flyten, grensesnittet og beslutningen om hvert trinn, bør du planlegge for din egen agentplattform fra starten. Du vil sannsynligvis vokse fra en løsning som bare bygges i ChatGPT.

Du kan også bruke Apps SDK til å kjøre MCP-serveren din i ChatGPT før du selv bygger chat, autentisering og agentinfrastruktur, og deretter gå over til din egen plattform når produktet krever det.

Neste steg for team i samme situasjon er å velge én arbeidsflyt med et tydelig resultat, beskrive overgangene mellom chat, verktøy og widgeter og deretter stressteste nye forsøk og feil før dere bruker mye tid på promptjustering.