Steuert ein KI-Agent LinkedIn über einen Browser, rät er Pixel. Steuert er es über eine API, führt er einen Vertrag aus. Dieser Unterschied entscheidet, ob deine Automatisierung den ersten Monat übersteht. Hier steht die technische Begründung: Determinismus, strukturierte Fehler, sichtbare Rate Limits und Events machen Agenten verlässlich, und all das liefert nur eine API.
Was kaputtgeht, wenn ein Agent den Browser bedient
Alles, was ein Browser-Agent über eine Seite weiß, hat er erschlossen: welches Element das Nachrichtenfeld ist, welcher Button absendet, ob der Klick funktioniert hat. Garantiert ist davon nichts. LinkedIn ändert seine Oberfläche laufend, und jede Änderung macht Selektoren, Layouts und Abläufe ungültig, auf die deine Automatisierung baut. Ohne Warnung.
Einen Menschen kostet ein verschobener Button eine Sekunde Suchen. Einen Agenten kostet er den ganzen Lauf. Er klickt das falsche Element oder gar keins, bekommt keinen Fehler, den er deuten kann, und macht mit einer falschen Annahme weiter. Die Fehler stapeln sich: Schritt zwölf scheitert, weil Schritt drei still nichts getan hat. Wer Automatisierung über den Bildschirm je produktiv betrieben hat, kennt die Wartungsmühle, die dann folgt.
Dazu kommt ein leiseres Problem: Ein Browser sagt dem Agenten nichts Ehrliches über Limits. Drosselt eine Seite oder lädt sie nur halb, sieht der Agent HTML-Brei statt eines maschinenlesbaren Grunds. Er kann „langsames Netz“ nicht von „hör für eine Stunde auf“ unterscheiden. Also versucht er es erneut, und genau das ist falsch.
Was ein Vertrag dem Agenten gibt und ein Browser nicht
Vier Eigenschaften, alle mechanisch, keine davon kann ein Browser bieten.
Typisierte Anfrage, typisierte Antwort. Ein API-Aufruf gelingt mit einer dokumentierten Struktur oder scheitert mit einer dokumentierten Struktur. Nichts wird erraten. Curviate beschreibt seine gesamte Oberfläche, darunter rund 130 LinkedIn-Aktionen, in einem OpenAPI-3.1-Dokument, das eine Maschine lesen kann. Dein Agent oder sein Build-Schritt kennt jeden Parameter und jedes Antwortfeld vor dem ersten Aufruf.
Fehler, auf die man verzweigen kann. Ein Curviate-Fehler trägt einen stabilen Code und Felder, die genau die Fragen des Agenten beantworten: Kann der Nutzer das beheben? Lohnt ein neuer Versuch? Wie lange soll ich warten? So wird ein Fehler zur Entscheidung statt zur Sackgasse.
Rate Limits als Daten. Jede erfolgreiche und jede gedrosselte Antwort trägt standardisierte RateLimit-Header: Kontingent, Rest und Zeitpunkt des Resets. Ein gedrosselter Aufruf liefert zusätzlich einen strukturierten retry_hint mit der genauen Wartezeit in Millisekunden. Der Agent liest diese Zahlen und taktet sich exakt, statt Limits erst zu bemerken, wenn er darüber stolpert.
Events statt Polling. Nimmt jemand eine Vernetzungsanfrage an oder kommt eine Nachricht, liefert ein Webhook das Event an deinen Endpunkt, HMAC-signiert, ausgewählt aus 40 Event-Typen. Ein Browser-Agent müsste dafür ständig Seiten neu laden. Das kostet Ressourcen und bricht leicht.
- „dieser Pixelbereich ist wohl der Senden-Button“
- Klick → keine Bestätigung, wird schon geklappt haben
- gedrosselt? halb geladen? So oder so HTML-Brei
- Seiten-Update geht live → Selektoren sterben still
- POST /chats/{id}/messages → 200, dokumentierte Struktur
- 429 → retry_hint.delay_ms: 37000, exakt zurückhalten
- RateLimit-Header bei jedem 2xx und 429
- connection.accepted → an deinen Endpunkt gepusht
Was die offizielle LinkedIn API kann und was nicht
Sie ist der offiziell vorgesehene Weg. Wenn du ins Partnerprogramm von LinkedIn kommst und die Berechtigungen deinen Fall abdecken, nimm sie. Die ehrlichen Grenzen: Der Zugang läuft über einen Partnerantrag mit Prüfung, und das Programm öffnet weder Sales Navigator noch Recruiter. Curviate gibt es für die Entwickler, die dort abgewiesen werden: Zugriff pro Konto über ein Konto, das dir gehört, mit eigenen Aktionen für genau die beiden Premium-Bereiche, die die offizielle API auslässt.
Wo Browser-Automatisierung völlig in Ordnung ist
Den eigenen Feed checken, an einem Nachmittag eine Idee ausprobieren, eine selbst gebaute Oberfläche testen: alles vernünftig. Eine Browser-Erweiterung erbt jede Schwäche der Seite. Sie passt zu einem Menschen, der zuschaut, nicht zu einem Agenten, der allein läuft. Browser-Automatisierung scheitert genau dort, wo Agenten sie am meisten brauchen: unbeaufsichtigt, wiederholt und dort, wo jeder Schritt stimmen muss. Schaut ohnehin ein Mensch auf den Bildschirm, reicht der Browser. Läuft ein Agent die Schleife, braucht er den Vertrag.
So sieht das in der Praxis aus
Eine minimale Agenten-Schleife gegen einen Vertrag: Personen zu einem Profil suchen, die Treffer sortieren, eine persönliche Vernetzungsanfrage senden und einen Webhook die Schleife schließen lassen, sobald jemand annimmt.
# Suchen, Treffer als NDJSON streamen, nur behalten, was der Agent braucht
curviate core search people --keywords "platform engineer" --all --fields id,full_name
# Den Schreibvorgang ansehen, bevor er rausgeht
curviate connect https://www.linkedin.com/in/example-profile \
--note "Dein Beitrag zu typisierter Infrastruktur hat mir gefallen." --preview
Die Annahme kommt später als Webhook connection.accepted an deinem Endpunkt an. Dein Agent pollt nicht und rät nicht. Dieselbe Schleife läuft über die REST-API, das TypeScript-SDK, die CLI oder den MCP-Server, je nachdem, welche Schnittstelle dein Agent schon spricht. Und willst du die Schleife gar nicht selbst betreiben, fahren Curviates Motions sie als Sequence ab: Profilbesuch, Vernetzungsanfrage, auf die Annahme warten, Nachricht. Angelegt und beobachtet über dieselbe API.