Perplexity API: 7 wichtige Folgen für KI-Agenten

Eine Produktmail klingt selten nach Nachrichtenlage. Diese hier schon: Perplexity schreibt API-Nutzenden, dass ihre Sonar-Workloads besser auf der Agent API laufen sollen. Mehr Genauigkeit, weniger Kosten pro Recherche, mehr Kontrolle. Klingt nach Vertrieb. Ist aber auch ein ziemlich guter Hinweis darauf, wohin KI-Recherche gerade kippt.

Auch wir bei digital-magazin.de lassen einen Teil unserer Recherchen über ein Agentensystem laufen, das Sonar Pro einbindet. Nicht als Ersatz für Redaktionsarbeit, sondern als Vorfilter: Quellen finden, Gegenargumente sammeln, ältere Behauptungen abklopfen, technische Dokumentationen querlesen. Genau deshalb ist Perplexitys Vorstoß interessant. Wenn ein Anbieter seinen klassischen Such-Chat in Richtung Agentenlaufzeit schiebt, betrifft das nicht nur Entwickelnde. Es betrifft alle, die KI-Recherche produktiv einsetzen.

Der Satz aus der Mail ist der Knackpunkt: „Your Sonar workload runs better on Agent API.“ Perplexity verkauft die Agent API nicht als hübschere Oberfläche für Sonar, sondern als neue Arbeitsebene für Recherche-Workflows. Die klassische Logik war: Prompt rein, Websuche läuft, Antwort raus. Die neue Logik lautet eher: Aufgabe rein, Agent plant, sucht, ruft URLs ab, nutzt Werkzeuge, kann bei Bedarf Code ausführen und liefert danach eine Antwort samt Spuren. Das ist ein anderer Zuschnitt.

In der offiziellen Migrationsdokumentation beschreibt Perplexity die Agent API als Upgrade der Sonar Chat Completions. Sonar bleibt zwar unterstützt, neue Projekte sollen aber auf die Agent API gehen. Das ist ungewöhnlich deutlich. Anbieter lassen alte APIs normalerweise lange höflich nebenher laufen. Hier ist die Richtung klar: Wer Recherche ernsthaft automatisiert, soll agentisch bauen.

Perplexity API: warum der Wechsel mehr ist als ein neuer Endpoint

Technisch wirkt die Migration erst einmal harmlos. Aus `messages` wird `input`, aus Chat Completions wird eine Responses-artige Ausgabe. Der Endpoint wechselt, die Antwortstruktur ebenfalls. Fertig? Leider nein. Genau dort liegt die Falle.

Sonar war für viele Teams bequem, weil die Suche im Paket steckte. Sie formulieren eine Frage, Perplexity zieht Webquellen heran, das Modell schreibt eine Antwort. Für einfache Aufgaben ist das wunderbar. „Was hat Firma X gerade angekündigt?“ „Welche Quellen nennen Preis Y?“ „Gibt es eine aktuelle API-Doku?“ Solche Fragen brauchen nicht zwingend einen Agenten, sie brauchen gute Suche und saubere Quellenangaben.

Bei echten Rechercheketten wird es ungemütlicher. Eine Anfrage kann mehrere Teilfragen enthalten, Quellen widersprechen sich, eine Pressemitteilung sagt etwas anderes als die Doku, Preise hängen an Nutzungsarten, Benchmarks sind Anbieterangaben. Wer solche Aufgaben über Sonar löst, baut außen herum oft selbst einen kleinen Agenten: erst Suche, dann URL-Fetch, dann zweite Suche, dann Vergleich, dann Zusammenfassung, dann Plausibilitätscheck. Die Agent API zieht diesen Ablauf näher an Perplexity heran.

Perplexity nennt als Bausteine unter anderem Websuche, URL-Abruf, Sandbox, MCP-Anbindung, Finanzsuche und Presets für unterschiedliche Intensitäten. Für Unternehmen, die agentische Workflows nicht nur ausprobieren, sondern betreiben wollen, ist das der eigentliche Punkt: weniger Klebeband zwischen den Schritten.

Sonar API bleibt, aber sie rutscht in eine andere Rolle

Perplexity schreibt nicht: Sonar ist tot. In der Doku steht ausdrücklich, dass Sonar Chat Completions weiter unterstützt werden. Trotzdem ist die Empfehlung für neue Anwendungen eindeutig. Die Agent API soll der Standard werden, während Sonar eher das direkte, kompakte Suchmodell bleibt.

Das passt zu einer breiteren Verschiebung. KI-Suche war anfangs vor allem ein besserer Antwortkasten. Eine Frage, eine Antwort, ein paar Quellen. Heute geht es häufiger um Aufgaben: Finde die Primärquelle, prüfe die Preistabelle, lies die Migration Notes, vergleiche Benchmarks, sortiere Marketingbehauptungen aus, fasse das Ergebnis für ein Team zusammen. Das ist keine Suche mehr im alten Sinn. Das ist Recherchearbeit mit Werkzeugkette.

Die Search API positioniert Perplexity selbst für rohe, gerankte Web-Ergebnisse. Für LLM-generierte Zusammenfassungen verweist die Doku auf die Agent API; Sonar bleibt verfügbar, aber laut Doku im Wartungsmodus. Diese Formulierung ist nicht spektakulär, aber sie ist deutlich genug. Wer heute neu baut, sollte nicht mehr aus Gewohnheit bei Sonar starten.

Für Redaktionen, SEO-Teams und technische Produktteams heißt das: Sonar ist weiterhin praktisch für schnelle Antworten. Sobald Sie aber mit mehreren Quellen, eigenen Prüfregeln und wiederkehrenden Workflows arbeiten, wird die Agent API spannender. Nicht wegen des Namens. Wegen der Kontrollpunkte.

KI Agenten brauchen keine bessere Antwort, sondern bessere Spuren

Mein erster Reflex bei solchen Anbieter-Mails ist Misstrauen. Natürlich behauptet ein API-Team, die neue API sei besser. Überraschung. Aber die technische Richtung ist plausibel, weil sie ein reales Problem trifft: KI-Recherche scheitert selten an einem einzelnen schlechten Satz. Sie scheitert daran, dass niemand mehr sauber nachvollziehen kann, wie die Antwort entstanden ist.

Ein Agent, der fünf Suchen ausführt, drei URLs liest, eine Tabelle extrahiert und danach eine Empfehlung schreibt, ist nur dann nützlich, wenn seine Arbeit prüfbar bleibt. Perplexity betont in der Migration, dass die Agent-API-Antwort nicht nur den finalen Text enthält, sondern eine strukturierte Ausgabe mit Zwischenschritten, Suchergebnissen und Tool-Resultaten liefern kann. Das klingt trocken. Für produktive Systeme ist es Gold wert.

Warum? Weil Auditierbarkeit im Alltag zählt. Wenn eine Preisangabe falsch ist, wollen Sie wissen, ob der Fehler aus der Quelle, aus der Extraktion oder aus der Zusammenfassung kam. Wenn ein Agent eine alte Dokumentation gelesen hat, muss das sichtbar sein. Und wenn ein Workflow Geld kostet, braucht das Team nicht nur Tokenzahlen, sondern Toolkosten pro Schritt.

Genau hier unterscheiden sich einfache KI-Antworten von belastbaren Rechercheläufen. In unserem Blick auf die Orchestrierung von KI-Agenten ging es bereits um die Frage, wie mehrere Teilschritte sauber zusammenarbeiten. Perplexitys Agent API greift dieselbe Grundidee auf, nur stärker auf Recherche und Webdaten zugeschnitten.

Search as Code: der eigentliche Strategiewechsel

Das spannendste Stichwort in Perplexitys Doku ist nicht „Agent API“. Es ist „Search as Code“. Dahinter steckt die Idee, Suche nicht mehr als starres Frage-Antwort-Werkzeug zu behandeln, sondern als programmierbare Abfolge aus Teiloperationen. Ein Modell kann Suchläufe planen, Anfragen auffächern, Ergebnisse filtern, URLs abrufen, Duplikate wegwerfen und erst danach die wirklich relevanten Informationen in den Kontext geben.

Perplexity beschreibt Search as Code in einem eigenen Research-Beitrag als neue Referenzarchitektur für agentische Suche. Der Gedanke ist bestechend einfach: Statt ein Modell mit zehn unaufgeräumten Suchtreffern zu füttern, lässt man es den Suchprozess selbst strukturieren. Das kann Token sparen, Halluzinationen reduzieren und bei breiten Rechercheaufgaben helfen.

Der Haken: Solche Systeme sind schwieriger zu testen. Ein klassischer API-Call ist relativ gut reproduzierbar. Ein agentischer Lauf kann je nach Prompt, Toolauswahl, Preset und Suchergebnis anders aussehen. Das ist kein Ausschlusskriterium. Aber es verlangt mehr Disziplin: Logs speichern, Quellen prüfen, Kosten messen, Grenzfälle definieren.

Für Entwickelnde ist das ein vertrautes Muster. Erst wirkt ein neues Abstraktionslevel wie Zauberei, dann merkt man, dass die eigentliche Arbeit in den Leitplanken steckt. Welche Domains darf der Agent bevorzugen? Wie alt dürfen Quellen sein? Wann muss er Primärquellen lesen? Wann reicht eine Snippet-Antwort nicht? Die Agent API nimmt Arbeit ab, aber sie nimmt Ihnen nicht das Denken ab. Schön wär’s.

Perplexity nennt starke Benchmarks, aber man sollte sie richtig lesen

In der Mail nennt Perplexity zwei Zahlen, die hängen bleiben: ungefähr doppelte Genauigkeit auf DSQA zum gleichen Preis und etwa siebenfacher Vorsprung auf BrowseComp gegenüber Sonar Pro, jeweils bei den genannten Presets und Kostenpunkten. In der öffentlichen Benchmark-Seite formuliert Perplexity vorsichtiger, aber in dieselbe Richtung: Die Agent-API-Preset-Kurve liege bei den eigenen Benchmarks oberhalb der Sonar-Modelle, besonders bei schweren Multi-Step-Aufgaben wie BrowseComp und WideSearch.

Das ist interessant. Es ist aber Anbieter-Benchmarking. Lesen Sie solche Zahlen wie Leistungsversprechen, nicht wie Naturgesetze. DSQA, BrowseComp und WideSearch messen unterschiedliche Fähigkeiten: tiefe Suchfragen, agentisches Browsen, breite Ergebnislisten. Sie sind nützlich, aber kein Ersatz für Ihren eigenen Testlauf mit echten Aufgaben.

Ich würde deshalb nicht fragen: „Ist die Agent API siebenmal besser?“ Die bessere Frage lautet: „Wo verlieren wir heute Zeit, Geld oder Vertrauen, weil unser Rechercheworkflow zu viele lose Schritte hat?“ Wenn die Antwort lautet: bei mehrstufiger Webrecherche, bei Quellenketten, bei Kostenkontrolle oder bei Audit-Trails, dann wird die Agent API relevant.

Wenn Sie dagegen nur kurze, aktuelle Antworten in ein internes Tool einbauen, kann Sonar weiterhin reichen. Nicht jeder Nagel braucht einen autonomen Hammer. Manchmal reicht eine gute Suche.

Die Kostenfrage: billiger wird es nicht automatisch

Perplexity wirbt mit geringeren Kosten pro Anfrage. Das kann stimmen, wenn ein Agent-Run weniger Kontextmüll produziert, weniger Folgeaufrufe braucht oder mit einem passenden Preset arbeitet. Die Preislogik bleibt trotzdem eine Rechenaufgabe.

Laut Perplexitys Pricing-Seite rechnet die Agent API Modellkosten nach Anbieterpreisen ohne Aufschlag ab. Werkzeuge kommen separat hinzu: `web_search` kostet 0,005 US-Dollar pro Aufruf, `fetch_url` 0,0005 US-Dollar, die Sandbox 0,03 US-Dollar pro Sitzung plus Suchkosten aus der Sandbox heraus. Sonar wiederum kombiniert Tokenkosten mit einer Anfragegebühr, die von Modell und Suchkontext abhängt.

Das ist kein triviales Preismodell. Ein schlecht gebauter Agent kann teurer werden als Sonar, weil er zu oft sucht, unnötig URLs abruft oder bei jeder Kleinigkeit die Sandbox startet. Ein gut gebauter Agent kann günstiger werden, weil er Suchschritte bündelt und nur geprüfte Ergebnisse in den Modellkontext schiebt.

Die Praxisregel ist simpel: Messen Sie pro Workflow, nicht pro API. Ein einzelner Anfragepreis sagt wenig, wenn Ihre Anwendung im Hintergrund fünf weitere Schritte ausführt. Speichern Sie Toolaufrufe, Token, Laufzeit und Ergebnisqualität zusammen. Sonst optimieren Sie am Ende eine Zahl, die mit Ihrem eigentlichen Problem wenig zu tun hat.

Was bedeutet das für SEO und KI-Suche?

Für SEO-Teams ist Perplexitys Schritt doppelt interessant. Erstens zeigt er, dass KI-Suche selbst agentischer wird. Zweitens zeigt er, dass Quellenqualität maschinell verwertbarer werden muss. Wenn ein Agent Suchergebnisse nicht nur liest, sondern sortiert, filtert und verknüpft, gewinnt Content, der eindeutig, aktuell und sauber zitierbar ist.

Das passt zu dem, was wir bei digital-magazin.de seit Monaten beobachten: KI-Suche ist kein hübscher Zusatzkanal mehr. Perplexity, ChatGPT, Google AI Overviews und ähnliche Systeme entscheiden immer häufiger, welche Quellen überhaupt noch sichtbar werden. Wer dabei auftauchen will, braucht nicht nur Keywords, sondern belastbare Struktur. Klare Überschriften. Primärquellen. Aktualisierte Daten. Keine Nebelmaschinen-Texte.

Unser Artikel über KI-Suche statt klassischer Google-Navigation beschreibt diesen Wechsel aus Nutzerperspektive. Die Agent API zeigt nun die Entwicklerseite derselben Bewegung: Suchsysteme werden nicht nur gesprächiger, sondern handlungsfähiger.

Wie eine Migration sinnvoll aussieht

Perplexity bietet eine Migrationsanleitung an, die technisch recht direkt wirkt: Endpoint ändern, `messages` zu `input` mappen, Ausgabe anders lesen, Websuche als Tool konfigurieren, Sonar-Modelle auf Agent-Presets übertragen. Das ist der leichte Teil.

Der schwierigere Teil beginnt vorher. Welche Ihrer Sonar-Anfragen sind überhaupt Recherche-Workloads? Welche sind nur schnelle Lookup-Fragen? Wo brauchen Sie Quellenketten? Wo reicht eine Antwort mit Zitaten? Und wo wäre ein Agent sogar gefährlicher, weil er zu viel interpretiert?

Ich würde eine Migration in vier Schritten angehen. Erstens: zehn bis zwanzig echte Produktionsfragen sammeln, nicht Demo-Prompts. Zweitens: Sonar und Agent API parallel laufen lassen. Drittens: Qualität, Kosten und Prüfbarkeit vergleichen. Viertens: nur die Workflows migrieren, bei denen die Agent API wirklich gewinnt.

Das klingt langsamer als „einfach den Endpoint tauschen“. Ist es auch. Aber ein Research-Agent ist kein Theme-Update. Wer hier blind migriert, tauscht eine bekannte Fehlerklasse gegen drei neue.

Wo die Agent API stark sein dürfte

Die stärksten Einsatzfelder liegen dort, wo Recherche nicht linear ist. Marktanalysen, technische Doku-Vergleiche, Wettbewerbsbeobachtung, Finanzdaten-Recherche, regulatorische Updates, journalistische Vorrecherche, Produktmonitoring. Alles, was mehr verlangt als „Suche X und fasse zusammen“.

Ein Beispiel: Ein Team will prüfen, ob ein Anbieter seine API-Preise geändert hat. Sonar kann die aktuelle Seite finden und zusammenfassen. Ein Agent kann zusätzlich die Preisseite abrufen, relevante Tabellen extrahieren, ältere Changelog-Einträge suchen, Widersprüche markieren und die eigene Ausgabe mit Quellen versehen. Ob das immer klappt? Nein. Aber genau für solche Ketten wurde die Architektur gebaut.

Ein zweites Beispiel: Content-Teams, die Themen recherchieren. Ein Agent kann nicht nur Suchtreffer einsammeln, sondern Primärquellen priorisieren, alte Artikel im eigenen Archiv berücksichtigen und am Ende offene Fragen ausgeben. Das ist näher an einem echten Recherchebriefing als an einer Chatantwort.

Damit sind wir wieder bei unserem eigenen Workflow. Wenn unser Agentensystem mit Sonar Pro recherchiert, ist der nützlichste Teil selten der schön formulierte Absatz. Nützlich ist die Roharbeit: Welche Quellen gibt es? Welche Aussage ist nur Marketing? Wo widerspricht die Doku der Mail? Was muss ein Mensch prüfen? Eine Agent API, die diese Schritte besser abbildet, ist für Redaktionen spannender als ein weiteres „noch schlaueres“ Modell.

Wo Vorsicht nötig bleibt

Agentische Recherche klingt nach Fortschritt. Sie kann aber auch sehr überzeugend Unsinn produzieren, nur mit mehr Zwischenschritten. Das macht sie gefährlicher, nicht harmloser. Ein sauberer Tool-Trace hilft nur, wenn ihn jemand liest oder automatisch prüft.

Drei Risiken bleiben. Erstens: Quellenqualität. Ein Agent kann schlechte Quellen schneller finden als ein Mensch. Zweitens: Kostenkontrolle. Viele kleine Toolaufrufe wirken einzeln harmlos und summieren sich dann still. Drittens: Verantwortlichkeit. Wenn ein Agent selbst entscheidet, welche Quellen er liest, müssen Teams definieren, welche Quellen tabu, bevorzugt oder zwingend sind.

Gerade für europäische Unternehmen kommt noch Datenschutz hinzu. Perplexity bietet Werkzeuge wie MCP-Anbindung und externe Toolintegration an. Das ist stark, aber private Daten, interne Dokumente und Kundendaten gehören nicht gedankenlos in jeden Recherchelauf. Wer Agenten baut, braucht Rollen, Protokolle und klare Grenzen.

Die gute Nachricht: Diese Probleme sind lösbar. Die schlechte: Sie lösen sich nicht durch ein besseres Preset.

Was bleibt?

Perplexitys Mail ist mehr als ein Upsell. Sie ist ein kleines Signal dafür, wie die nächste Generation von KI-Recherche aussehen dürfte: weniger Chatfenster, mehr Agentenlaufzeit; weniger einzelne Antwort, mehr nachvollziehbarer Rechercheprozess; weniger „frag mal das Modell“, mehr „baue einen prüfbaren Workflow“.

Für Sonar-Nutzende heißt das nicht: morgen alles umbauen. Es heißt: die eigenen Workloads sortieren. Kurze Antworten können bei Sonar bleiben. Mehrstufige Recherche gehört auf den Prüfstand. Und wer gerade neu baut, sollte die Agent API zumindest als Standardkandidatin betrachten.

Mein persönlicher Verdacht: In einem Jahr reden wir weniger darüber, welches KI-Modell „die beste Suche“ hat. Wir reden darüber, welches System die besten Rechercheläufe organisiert, protokolliert und bezahlbar hält. Das ist weniger glamourös. Aber sehr viel nützlicher.