Agent czyta specyfikację API sam i nie ma kogo dopytać

Przez dwie dekady, kiedy jakiś program wołał API, po drugiej stronie zawsze był człowiek. Ktoś wcześniej przeczytał dokumentację, zrozumiał, jak zbudować zapytanie, i zapisał tę logikę w kodzie. Wywołanie było więc przewidywalne: znany kształt zapytania, znane sposoby, w jakie może się wysypać. SD Times w analizie kategorii integracji i API z tegorocznego zestawienia SD Times 100 twierdzi, że ten układ właśnie się kończy, bo po drugiej stronie coraz częściej jest agent AI, który dokumentację czyta sam i na jej podstawie sam decyduje, jak wywołać dane API.

To brzmi jak drobiazg, ale nim nie jest. Agent nie wykonuje z góry napisanego skryptu. Eksploruje, próbuje raz za razem na sposoby, których nikt nie przewidział, i skleja kolejne wywołania w łańcuch na bieżąco, w oparciu o to, co model akurat sobie wyrozumował, a nie o gotową ścieżkę zaplanowaną przez programistę. Cała analiza sprowadza się właściwie do jednego zdania: dwuznaczność, którą człowiek zbyłby wzruszeniem ramion i wyjaśnił sobie krótkim pytaniem na firmowym czacie, dla samodzielnego agenta staje się twardym błędem. Model nie dopyta. Albo specyfikacja mówi mu jednoznacznie, jak nazywa się parametr i co dokładnie oznacza błąd, albo agent skorzysta z API źle i nawet tego nie zauważy.

Dla mnie nowość jest tu wąska, ale prawdziwa. W samych specyfikacjach nie ma nic nowego. Maszynowo czytelne opisy API w rodzaju OpenAPI istnieją od lat. Zmienił się ten, kto je czyta. Kiedyś była to wygenerowana biblioteka klienta, która przy braku danych wywalała się głośno i przewidywalnie. Teraz jest to model, który lukę w opisie obejdzie improwizacją i po cichu zrobi coś nie tak. To awansuje dokumentację i nazewnictwo parametrów z czegoś miłego, ale drugorzędnego, do właściwego interfejsu, przez który agent styka się z systemem.