KI & Experimente

Wöchentlicher KI-Briefing-Agent: Was mein Filter wirklich braucht

Ein wöchentliches Briefing spart mir das tägliche Scrollen. Brauchbar wurde es erst, als leere Abschnitte, Quellen und ein 30-Minuten-Test zum System gehörten.

Mein KI-Briefing-Agent läuft seit Monaten. Vier Stunden Einrichtung. Jeden Sonntagabend landet er auf meinem Handy: vier Fragen, sauberes Layout, gefiltert durch meine tatsächliche Arbeit.

Die erste Version war technisch nach einem Nachmittag fertig. Brauchbar war sie noch lange nicht.

Phone on a dark desk showing a notification card, cup of black coffee beside it
Das Sonntagabend-Signal: vier Fragen, eine Benachrichtigung.

Im laufenden Workflow startet ein Cron-Trigger eine Serverless Function. Sie ruft ein Modell mit Web- und X-Suche auf und verschickt das Ergebnis per Push. Das ist der einfache Teil. Die schwierige Arbeit steckt im Filter, und die hat vier Prompt-Fassungen gekostet.

Warum es am Ende nicht n8n wurde

Im ersten Entwurf hatte ich n8n vorgesehen. Gutes Tool, visuelle Workflows, kostenloser Einstieg. Ich habe es ausprobiert. Funktioniert. Aber für diesen Fall blieb am Ende weniger übrig:

  1. Quellen durchsuchen.
  2. Treffer gegen meinen Arbeitskontext filtern.
  3. Ergebnis mit Quellen verschicken.

Dashboard, Datenbank und verzweigtes Regelwerk wären dafür überflüssig. Eine Serverless Function, ein API-Aufruf, ein Push-Kanal. Bei einem beobachteten Lauf vergingen etwa 90 Sekunden. Das ist mein Messwert, kein Plattformlimit. Prompt ändern, neu deployen, drei Sekunden, ganz ohne Klickstrecken oder Abo.

Die Lektion: Nimm das Tool, das zur Form des Problems passt. Der Briefing-Agent ist im Kern nur ein Skript, das auf einem Timer läuft. Behandle ihn auch so.

Split-screen: complex workflow diagram vs. simple terminal code
Zwei Wege zum gleichen Briefing. Der einfachere ist live gegangen.

Das Schwierigste ist nicht die Technik

Das hat mich überrascht. Erwartet hatte ich, dass die Integration der knifflige Teil wird: API-Anbindung, Push-Zustellung, Deployment. An einem Nachmittag war das alles erledigt.

Der schwierige Teil war der Prompt. Und das blieb er über vier Iterationen.

Jede Nachricht wirkte wichtig

Das Modell wollte mich beeindrucken. In den ersten Durchläufen erklärte es mir in polierten Absätzen, wie revolutionär jede Veröffentlichung sei. Ich musste explizit schreiben: Schreib wie ein Reporter unter Zeitdruck. Kurze Sätze. Kein Marketing-Deutsch. Du darfst kritisch sein. Der Ton kippte von Hype zu Signal, sobald diese Anweisung drinstand.

Die Flughöhe stimmte nicht

Die erste funktionierende Version lieferte mir Produkt-Updates. „Cloudflare hat AI Search mit Storage gelauncht.“ Technisch korrekt, komplett nutzlos. Mich interessierte der größere Wandel: „Cloudflare verschiebt sich von Stateless Compute zu Agent-nativer Infrastruktur.“ Gleiche Nachricht, andere Flughöhe. Drei Prompt-Rewrites, bis das Modell den Unterschied verstanden hat.

Leere Abschnitte wurden aufgefüllt

Wenn es in einem Abschnitt nichts Echtes gab, hat das Modell irgendeine Randnotiz aufgeblasen, damit es reinpasst. Ich musste ausdrücklich erlauben, Abschnitte leer zu lassen. „Diese Woche nichts Relevantes“ ist ein gültiges Ergebnis. In den meisten Wochen bleibt mindestens ein Abschnitt leer. Genau daran erkenne ich, dass der Filter arbeitet.

Quellen wurden erfunden

Zweimal. Falsche URLs, falsche Paper-IDs. Beide Male, weil ich den Filter zu eng geschnürt hatte: Wenn die Kriterien zu scharf waren und kaum echte Treffer übrig blieben, hat das Modell lieber fabriziert als nichts zurückzugeben. Die Lösung war nicht „halluziniere nicht“, diese Anweisung ignorieren Modelle. Geholfen haben lockerere Kriterien und eine klare Präferenz: Zwei prüfbare Treffer schlagen drei vollständige Abschnitte.

Dazu eine Formvorschrift. Jede Ausgabe muss Quell-URL, Abrufdatum und Modellkennung mitführen. Der Push ist nur die Zustellung; das gespeicherte Ergebnis bleibt das Prüfprotokoll.

Die eigentliche Arbeit an solchen Systemen ist fast nie die Technik. Es ist der Prompt. Und der Prompt wird erst gut durch Iteration gegen echten Output.

Close-up of a prompt being iterated in a code editor
Vier Neuschriften, bis der Output aufgehört hat, nutzlos zu sein.

Die vier Fragen im Briefing

Heute folgt jede Ausgabe demselben Raster:

  1. Was hat meine aktuelle Arbeit konkret verbessert? Dinge, die heute in meinen bestehenden Stack passen.
  2. Was macht etwas Neues möglich? Neue Fähigkeiten, keine Produkt-Launches.
  3. Was ist diese Woche Hype? Namentlich genannt, damit ich dieselben Tweets nicht fünfmal lesen muss.
  4. Was teste ich 30 Minuten lang? Eine konkrete Aktion, mit Link.

Dazu ein paar Einzeiler unter „Quick Hits“ und eine einzelne Fußnote für alles, was außerhalb des Zeitfensters liegt und in seinem Bereich trotzdem führend ist.

Aus dem Briefing soll keine weitere Leseliste werden. Deshalb muss der Kandidat aus der vierten Frage gegen echte Aufgaben antreten, nicht gegen die Demo des Anbieters.

Und der Kanal zählt. Nimm den, in dem du Nachrichten reflexartig öffnest. Kein Twitter, kein Newsletter. Zehn Minuten lesen, vielleicht ein Link geöffnet, dann weiterarbeiten.

Phone mockup showing a structured AI briefing in dark mode
Das Format, das übrig geblieben ist. Leere Abschnitte sind gültiger Output.

Drei Filter, die auch ohne diesen Agenten funktionieren

1. Relevanz kommt vor Neuigkeit

Für den Filter genügen abstrahierte Angaben zu Rolle, Werkzeugen und wiederkehrenden Aufgaben. Ein Release ist interessant, wenn es darin etwas messbar verbessert oder eine bisher unmögliche Handlung erlaubt. Alles andere darf bis zur nächsten Woche warten.

2. Der 30-Minuten-Realitätscheck

Für einen Kandidaten nehme ich echte Prompts aus meiner Arbeit und vergleiche die Ergebnisse direkt mit dem bestehenden Setup. Drei Fragen reichen:

  • Ist der Output bei meiner Aufgabe besser?
  • Ist der Unterschied den Wechselaufwand wert?
  • Löst das Werkzeug ein Problem, das ich gerade wirklich habe?

Ein Benchmark kann den Test begründen, aber nicht ersetzen.

3. Benchmark-Ergebnis ist nicht Arbeitsfortschritt

Ein besserer Wert in einem Test ist zunächst genau das: ein besserer Testwert. Arbeitsfortschritt entsteht erst, wenn eine neue Fähigkeit oder eine deutliche Qualitätsänderung im eigenen Ablauf ankommt. Diese Trennung nimmt vielen Ankündigungen die künstliche Dringlichkeit.

Was es kostet, und wo ich mich verrechnet hatte

Fast nichts. Aber nicht so wenig, wie ich hier ursprünglich geschrieben hatte.

Zuerst der Stand der Technik, denn der altert schnell: Das von mir eingesetzte grok-4-1-fast-reasoning wurde am 15. Mai 2026 eingestellt; xAI leitet alte Requests auf grok-4.3 mit niedriger Reasoning-Stufe um.1 Stand 15. August 2026 führt xAI grok-4.20-0309-reasoning beziehungsweise den Alias grok-4.20-reasoning mit 1,25 US-Dollar pro Million Input- und 2,50 US-Dollar pro Million Output-Tokens bei kurzen Kontexten. Web Search und X Search kosten zusätzlich 5 US-Dollar je 1.000 Tool-Aufrufe.23

Genau an diesen Tool-Aufrufen lag mein Fehler. Ich hatte hier „unter zwei Cent im Monat“ stehen und dabei nur Tokens gezählt. Die Suchen, die das Modell abfeuert, um das Web überhaupt zu scannen, waren nicht in der Rechnung.

Rechne ich meine gemessene Größenordnung von etwa 12.000 Input- und 4.000 Output-Tokens bei acht Suchanfragen gegen die heutigen Preise:

  • Input: rund 1,5 Cent
  • Output: rund 1 Cent
  • acht Tool-Aufrufe: 4 Cent

Macht etwa 6,5 Cent pro Durchlauf, wöchentlich also knapp 30 Cent im Monat. Reasoning-Tokens sind darin nicht enthalten, der echte Wert liegt darüber. Das ist eine Beispielrechnung mit offengelegten Annahmen, keine Abrechnung.

Die Zahl selbst ist unspektakulär. Interessant ist ihre Verteilung: Die Suche kostet mehr als das Denken. Rund 60 Prozent der Kosten entstehen, bevor das Modell den ersten Satz schreibt. Wer bei so einem Agenten sparen will, dreht an der Anzahl der Suchanfragen, nicht am Modell.

Illustration im Offsetdruck-Raster: eine weit geöffnete Einlassöffnung zieht eine große, dunkle Materialmasse ein und verjüngt sich zu einem winzigen Auslass, aus dem ein einzelner violetter Faden austritt
Viel Einzug, wenig Ausstoß. Der Aufwand liegt im Sammeln, nicht im Formulieren.

Deshalb protokolliere ich pro Lauf Modellkennung und Datum, Input-, Output-, Reasoning- und Cache-Tokens, die Anzahl der Web- und X-Tool-Aufrufe sowie Laufzeit, Fehlerstatus und Push-Status. „Tokens rein, Tokens raus“ reicht für eine Kostenangabe nicht.

Ein Wort zum Modell selbst, und das ist ausdrücklich mein Eindruck aus dem Betrieb, keine Messung: Das kleinere Reasoning-Modell hat für diesen Zweck immer gereicht. Ein Grund dürfte im Quellmaterial liegen. Grok durchsucht X über seine eingebauten Tools, und Posts dort sind kurz, pointiert und von den Verfassern selbst schon komprimiert. Das Modell muss sich nicht durch lange Artikel graben. Die zusätzliche Tiefe eines Flaggschiff-Modells rechtfertigt für ein wöchentliches Briefing den Aufpreis nicht.

Was schiefgehen kann

Arbeitskontext kann schnell zu viel verraten. Mein Prompt braucht deshalb keine Namen, Kundendaten oder internen Dokumente. Rollen, Werkzeuge und Aufgabentypen genügen. API-Schlüssel liegen als Serverless Secrets vor und gehören weder in den Client noch in den Prompt.

xAI dokumentiert für API-Anfragen und Antworten standardmäßig eine verschlüsselte Speicherung von bis zu 30 Tagen und kein Training ohne ausdrückliche Erlaubnis. Zero Data Retention verändert diese Speicherung, schränkt aber bestimmte zustandsbehaftete Funktionen ein.4 Wer einen anderen Anbieter nutzt, muss dessen Regeln separat prüfen.

Auch die Zustellung ist nicht garantiert. Der Ablauf braucht einen sichtbaren Fehlerstatus für API-Ausfall, Quota, fehlende Treffer und fehlgeschlagenen Push. Bei einem Fehler bleibt die letzte Ausgabe stehen; das System erfindet keinen Ersatz und verschweigt keinen ausgefallenen Lauf.

Was sich für mich verändert hat

Zwei Dinge.

Ich öffne X nicht mehr absichtlich. Das war keine Frage der Disziplin. Der Drang ist verschwunden, weil es jetzt einen festen Zeitpunkt und einen nachvollziehbaren Auswahlprozess gibt. Nicht weil der Agent garantiert alles findet, sondern weil ich weiß, wann ich das nächste Mal hinschaue.

Und ich teste mehr. Mit der vierten Frage liegt schon ein Kandidat bereit. Ich muss nicht erst nach Tools zum Ausprobieren suchen. Die Reibung sinkt fast auf null, und genau dann bleibt die Gewohnheit hängen. Genau dort wird aus Nachrichtensichtung eine Arbeitsentscheidung.

Wenn du deinen eigenen aufsetzen willst

  • Halte die Pipeline einfach: Timer, Suche, Filter, Push. Kein Dashboard, keine Datenbank.
  • Iteriere den Prompt gegen echten Output. Speichere jeden Durchlauf als Datei und vergleiche die Diffs. Die ersten drei Versuche sehen miserabel aus. Ab Iteration fünf hast du etwas, dem du vertraust.
  • Lass Abschnitte leer. Das ist das stärkste Qualitätssignal. Meldet dein System nie „diese Woche nichts“, ist der Filter kaputt. Dann wird aufgefüllt statt gefiltert.
  • Starte täglich, dann wechsle auf wöchentlich. Täglich gibt dir sieben Datenpunkte in sieben Tagen statt einem.
  • Abstrahiere den Arbeitskontext. Keine Namen, keine Kundendaten, keine Secrets.
  • Speichere Quellen, Modell, Zeitstempel und Kosten pro Lauf. Und lass fehlgeschlagene Läufe sichtbar bleiben.
Person walking down a quiet city street at dawn
Ein fester Termin ersetzt das ständige Nachschauen.

Das ist das ganze Ding. Ein kleines Stück Software und ein sorgfältig geschliffener Prompt. Eine Nachricht pro Woche. Der Wert entsteht durch die Entscheidung, was gar nicht erst in der Nachricht landet.

Es kommen nicht weniger Neuigkeiten. Ich schaue nur seltener hin.

Quellen & Referenzen

🌐