Capstone: ein echter End-to-End-Workflow mit Gemini

Wir bauen eine realistische Lösung von Anfang bis Ende: einen Competitive-Intelligence-Assistenten, der jeden Morgen Ihre Branche liest, Ihre Wettbewerber beobachtet und ein mit Quellen belegtes Briefing in ein Google Doc legt, bevor Sie Ihren Kaffee ausgetrunken haben. Wir treffen die Architekturentscheidungen offen und begründet, damit Sie die Domäne austauschen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen (Legal, Sales, Research, Recruiting) und das Grundgerüst wiederverwenden.

Bei einem Capstone geht es mehr um die Entscheidungen als um die Demo: welche Modellstufe, wo die Arbeit läuft, wie Fakten aktuell bleiben und was das Ganze auslöst. Wenn diese Punkte stimmen, übersteht der Workflow den Kontakt mit der Realität.

Das Szenario und die Rahmenbedingungen

Der Assistent hat an jedem Werktag um 7:00 Uhr vier Aufgaben:

1. Die neuesten Nachrichten und Ankündigungen zu drei benannten Wettbewerbern abrufen.
2. Alle PDFs oder Slide Decks lesen, die Sie gestern in einem Drive-Ordner abgelegt haben (Preislisten, Analystenberichte).
3. Ein einseitiges Briefing mit Quellen zusammenstellen.
4. Es an ein fortlaufendes Doc „Competitive Intel“ anhängen und Ihnen die Highlights per E-Mail schicken.

Rahmenbedingungen, die das Design bestimmen:

• Fakten müssen aktuell und zitierbar sein, nicht halluziniert. Das erzwingt Grounding.
• Die Inputs sind gemischt: Webtext, PDFs, Bilder von Charts. Das erzwingt native Multimodalität.
• Der Workflow muss unbeaufsichtigt nach Zeitplan laufen. Damit scheidet die Chat-App als Engine aus.
• Ein Nicht-Engineer in Ihrem Team soll den Prompt anpassen können. Das verlagert einen Teil der Logik in Richtung Workspace.

Entscheidung 1: Wo läuft das?

Es gibt drei echte Orte für Gemini-Arbeit, und sie sind nicht austauschbar.

• Die Gemini-App und Gems sind für die interaktive Nutzung gedacht. Ein Gem ist eine gespeicherte, instruierte Version von Gemini (eine wiederverwendbare PersonaPersonaEine halb fiktive, forschungsbasierte Darstellung Ihres idealen Kunden: seine Ziele, Frustrationen, Verhaltensweisen und Entscheidungskriterien.Vollständige Definition ansehen → mit festen Anweisungen und Dateien). Ideal für „eine Frage an meinen Research-Assistenten“, nutzlos als Cron-Job um 7 Uhr, weil niemand da ist, der Enter drückt.
• Gemini in Google Workspace läuft *innerhalb* von Docs, Sheets, Gmail und Drive. Hier liegt der Output, und hier kann Apps Script ihn unter Ihrem Workspace-Konto automatisieren.
• Die Gemini API (über Google AI Studio für Prototypen oder Vertex AI für die Produktion) ist die programmierbare Engine: Modellaufrufe, Grounding, strukturierter Output, Scheduling.

Die saubere Aufteilung für dieses Capstone: Apps Script ist der Orchestrator und die Integrationsschicht für Workspace; die Gemini API übernimmt das anspruchsvolle Reasoning und das Grounding. Apps Script bringt einen eingebauten Scheduler mit (zeitgesteuerte Trigger), nativen Zugriff auf Drive/Docs/Gmail und einen Ort, an dem Teammitglieder den Prompt lesen können. Die APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen → gibt Ihnen Kontrolle über das Modell, die Ihre Workspace-Oberfläche nicht bietet, etwa die Grounding-Konfiguration und JSON-Schemas.

Wäre das ein größerer, mehrstufiger Agent mit Tool-Nutzung und Gedächtnis, würden Sie stattdessen zum [Agent Development Kit (ADK)](https://google.github.io/adk-docs/) auf Vertex AI greifen. Auf diese Grenzlinie kommen wir zurück.

Entscheidung 2: Welche Modellstufe?

Sie haben die Stufen Pro und Flash (aktuell die Generation Gemini 3). Der Reflex, überall das größte Modell einzusetzen, ist teuer und langsam. Teilen Sie nach Aufgabe auf.

• Flash für volumenstarke, latenzkritische Arbeit vom Typ „lesen und extrahieren“: jede Nachricht überfliegen, Kernfakten aus einem PDF ziehen. Günstig und schnell, und die Aufgabe verlangt kein schweres Reasoning.
• Pro für den finalen Syntheseschritt: Quellen gewichten, Widersprüche erkennen, das Briefing schreiben. Das ist ein Aufruf pro Tag, das stärkere Modell kostet also fast nichts, und der Qualitätssprung zählt.

Dieses zweistufige Muster (Flash für den Fan-out, Pro für das finale Urteil) ist der wirksamste einzelne Kostenhebel in produktiver Gemini-Arbeit. **Entscheiden Sie die Stufe pro *Aufgabe*, nicht pro *Projekt***.

Modell-IDs ändern sich schneller als Lektionen. Ältere 2.5-Modelle stehen auf Googles Abkündigungsplan. Prüfen Sie daher auf der Modellseite die aktuellen stabilen IDs und halten Sie sie in einer einzigen Config-Konstante, statt sie im Code zu verstreuen.

Entscheidung 3: Wie bleiben Fakten aktuell?

Trainingsdaten sind per Definition veraltet, deshalb nutzt der Schritt für Wettbewerbernachrichten Grounding mit Google Search. Grounding weist das Modell an, echte Suchen auszuführen und Antworten zu liefern, die an Live-Ergebnisse gebunden sind, mit Zitationsmetadaten, die Sie als Links darstellen können.

Sie aktivieren es als Tool im Request. Hier ist der zentrale Syntheseaufruf in Python mit dem `google-genai` SDK, mit aktiviertem Search Grounding:

from google import genai
from google.genai import types

PRO_MODEL = "gemini-3-pro-preview"     # aktuelle ID auf der Modellseite prüfen
FLASH_MODEL = "gemini-3-flash-preview"

client = genai.Client()  # liest GEMINI_API_KEY aus der Umgebung

grounding = types.Tool(google_search=types.GoogleSearch())

resp = client.models.generate_content(
    model=PRO_MODEL,
    contents=(
        "Summarize this week's announcements, pricing changes, and "
        "product launches for Acme, Globex, and Initech. Flag anything "
        "that affects our positioning. Cite every claim."
    ),
    config=types.GenerateContentConfig(
        tools=[grounding],
    ),
)

print(resp.text)
# resp.candidates[0].grounding_metadata enthält die Quell-URLs

Beachten Sie, dass es keine temperature-Einstellung gibt. Bei älteren Modellen hätten Sie sie für Analysearbeit auf etwa 0.3 gesenkt. Googles Empfehlung für Gemini 3 lautet, die Temperatur auf dem Standardwert 1.0 zu lassen, weil niedrigere Werte zu Schleifen oder schlechterem Output führen können. Steuern Sie die Präzision stattdessen über den Prompt („cite every claim“, „say 'no change' if nothing happened“).

Die grounding_metadata in der Response enthalten die belegenden Links, sodass Ihr Briefing jede Aussage mit einer Fußnote versehen kann. Diese Zitationsspur macht den Output vertrauenswürdig genug, um ihn an eine Führungskraft weiterzuleiten. Die aktuelle Struktur der Metadaten finden Sie in der Grounding-Dokumentation.

Entscheidung 4: Umgang mit multimodalen Inputs

Der Drive-Ordner kann die PDF-Preisliste eines Wettbewerbers enthalten und einen Screenshot einer Preistabelle aus einem Webinar. Sie lassen darauf kein separates OCR laufen. Gemini ist nativ multimodal: Übergeben Sie das PDF und das Bild direkt im selben Request, und das lange Kontextfenster erlaubt Ihnen, mehrere vollständige Dokumente auf einmal mitzugeben, statt sie in Chunks zu zerlegen.

An dieser Stelle des Workflows brauchen Sie *kein* RAGRAGVerfahren, mit dem ein KI-Modell aus Ihren eigenen Dokumenten antwortet, indem es relevante Passagen abruft, bevor es eine Antwort erzeugt.Vollständige Definition ansehen →. RAG lohnt sich, wenn Ihr Korpus deutlich größererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → ist als das Kontextfenster. Für „die drei Dateien, die gestern jemand abgelegt hat“ ist es einfacher, günstiger zu bauen und ohne Qualitätsverlust, sie direkt in einen Long-Context-Prompt zu packen. Zu wissen, wann man die Retrieval-Schicht weglässt, ist eine Architekturkompetenz.

pdf = client.files.upload(file="reports/globex_pricing.pdf")
chart = client.files.upload(file="reports/webinar_chart.png")

extract = client.models.generate_content(
    model=FLASH_MODEL,
    contents=[
        pdf, chart,
        "Extract every price, tier name, and feature change. "
        "Return JSON: {items: [{vendor, tier, price, note}]}.",
    ],
    config=types.GenerateContentConfig(
        response_mime_type="application/json",
    ),
)

Achten Sie auf response_mime_type="application/json". Strukturierten Output statt Fließtext anzufordern ist das, was dem nächsten Schritt (dem Writer in Apps Script) erlaubt, das Ergebnis zuverlässig zu verarbeiten. Zwei weitere Gründe, warum hier Flash statt Pro läuft: Der Aufruf erfolgt einmal pro Datei, und Extraktion ist mechanisch.

🎬 [VIDEO: "MultimodalMultimodalKI, die mehrere Eingabe- und Ausgabeformate zugleich verarbeitet: Text, Bild, Audio, Video und Daten, statt nur eines Formats.Vollständige Definition ansehen → promptingpromptingPrompt Engineering ist die Praxis, Texteingaben so zu gestalten und zu verfeinern, dass große Sprachmodelle präzise, relevante und verlässliche Ergebnisse liefern.Vollständige Definition ansehen → with the Gemini API" - https://www.youtube.com/@GoogleDevelopers - Videos von Google for Developers zum Senden von PDFs und Bildern in einem einzigen Request und zum Auslesen der Response]

Entscheidung 5: Orchestrierung und Zeitplan

Jetzt wird alles verbunden. Der Scheduler ist ein zeitgesteuerter Trigger in Apps Script, der günstigste zuverlässige Cron, den Sie in Workspace ohnehin schon haben. Das Script ruft Ihren API-Endpoint auf (oder Gemini direkt über UrlFetchApp) und schreibt die Ergebnisse dann mit den nativen Services in Docs und Gmail.

Hier sitzt der Orchestrator in Apps Script. Er läuft um 7 Uhr, ruft Ihren Synthese-Service auf und hängt das Briefing an:

function dailyBriefing() {
  const payload = { date: new Date().toISOString().slice(0, 10) };
  const res = UrlFetchApp.fetch("https://your-service/brief", {
    method: "post",
    contentType: "application/json",
    payload: JSON.stringify(payload),
  });
  const brief = JSON.parse(res.getContentText());

  const doc = DocumentApp.openById("YOUR_DOC_ID").getBody();
  doc.appendParagraph(brief.title).setHeading(DocumentApp.ParagraphHeading.HEADING2);
  doc.appendParagraph(brief.summary);
  brief.sources.forEach(s => doc.appendListItem(s.url));

  GmailApp.sendEmail("you@company.com", "Daily Intel: " + brief.title, brief.summary);
}

Den Trigger für 7 Uhr richten Sie einmal in der Apps-Script-Oberfläche unter Trigger ein oder programmatisch mit ScriptApp.newTrigger. Kein Server, um den Sie sich kümmern müssen, keine separate Rechnung für einen Scheduler. Wenn Sie das rein serverseitig betreiben wollen, lassen Sie den Python-Code auf Cloud Run mit Cloud Scheduler laufen; der Trade-off ist mehr Kontrolle über die Infrastruktur gegen mehr Einrichtungsaufwand.

Die vollständige Architektur im Überblick

Lesen Sie den Datenfluss einmal von oben nach unten:

1. Trigger um 7:00 Uhr (zeitgesteuerter Trigger in Apps Script) startet dailyBriefing.
2. Ingest (Flash, multimodal): Jede neue Drive-Datei wird hochgeladen und in JSON extrahiert.
3. Research (Pro, mit Grounding): Ein Aufruf mit Search Grounding sammelt aktuelle Wettbewerbernachrichten mit Quellenangaben.
4. Synthese (Pro): Ein Aufruf kombiniert die extrahierten Fakten aus den Dateien und die belegten Nachrichten zu einem einseitigen Briefing, Output als JSON ({title, summary, sources}).
5. Auslieferung (Workspace): Apps Script hängt das Briefing an das fortlaufende Doc an und verschickt die Zusammenfassung per E-Mail.

Die Modellstufen passen sauber zu den Schritten: Flash verteilt sich auf viele kleine Inputs, Pro übernimmt die zwei Aufrufe, die Urteilsvermögen erfordern. Grounding ist auf genau einen Schritt beschränkt. Den Extraktionsschritt grounden Sie nicht, weil diese Fakten aus den vorliegenden Dokumenten stammen, nicht aus dem Web. Grounding im falschen Schritt erhöht die Latenz und kann irrelevante Suchergebnisse einschleusen.

Wo jedes Tool seinen Platz verdient

• API + AI Studio: Prompts und Grounding wurden in AI Studio prototypisch entwickelt und dann als SDK-Code exportiert. Der Button „Get code“ in AI Studio ist der schnellste Weg von einem funktionierenden Prompt zu einem Script.
• Apps Script: der Scheduler, das Bindeglied zu Workspace und die eine Datei, die ein Teammitglied ohne Engineering-Hintergrund gefahrlos bearbeiten kann (den Briefing-Prompt und die Empfängerliste).
• Vertex AI / ADK: hier bewusst nicht eingesetzt. An dem Tag, an dem Sie Tools hinzufügen, zwischen denen das Modell wählt (Suche *und* ein interner CRMCRMCustomer Relationship Management: Software und Strategie, um Kundeninteraktionen über den gesamten Lifecycle zu steuern und zu analysieren.Vollständige Definition ansehen →-Lookup *und* eine Kalenderaktion), stellen Sie den Orchestrator auf ADK um und deployen auf Vertex AI. Das ist die Schwelle: Entscheidungen über mehrere Tools und Schritte gehören in ein Agent-Framework, nicht in selbstgebaute if-Anweisungen.

Die Reihenfolge beim Bauen, die tatsächlich funktioniert

Bauen Sie nicht von oben nach unten. Bauen Sie zuerst die riskante Mitte.

1. Bringen Sie in AI Studio den Synthese-Prompt mit Grounding von Hand in Form. Hier entscheidet sich die Qualität.
2. Machen Sie die JSON-Extraktion auf Ihren echten PDFs zuverlässig. Echte Dateien bringen naive Prompts zum Scheitern.
3. Erst dann packen Sie beides in Apps Script und fügen den Trigger hinzu.

Scheduling und das Schreiben ins Doc sind langweilig und zuverlässig. An den Modell-Prompts werden Sie zehnmal iterieren, also validieren Sie sie zuerst.

Worauf Sie in der Produktion achten sollten

• Quellenangaben, die nicht auflösen. Stellen Sie Grounding-URLs immer dar und klicken Sie jede Woche ein paar davon an. Ein Briefing mit toten Quellen ist schlechter als gar kein Briefing.
• Stille Fehler bei Dateitypen. Stellen Sie sicher, dass der Ingest-Schritt einen leeren Drive-Ordner und eine unlesbare Datei verkraftet, ohne den gesamten Lauf abzubrechen. Packen Sie jede Datei in ein eigenes try/catch.
• Prompt-Drift. Wenn ein Teammitglied den Prompt in Apps Script bearbeitet, kann das Output-Format den Doc-Writer kaputt machen. Behalten Sie die Anforderung des JSON-Schemas im Prompt und validieren Sie vor dem Schreiben.
• Abkündigung von Modellen. Google kündigt ältere Modell-IDs nach einem veröffentlichten Plan ab. Legen Sie sich eine Kalendererinnerung an, die Modellseite jedes Quartal zu prüfen, und tauschen Sie die Konstante aus, bevor Ihr Lauf um 7 Uhr Fehler liefert.

Key Takeaways

• Nach Aufgabe aufteilen, nicht nach Projekt. Nutzen Sie Flash für volumenstarke Extraktion und Pro für den einen oder die zwei Aufrufe, die echtes Urteilsvermögen brauchen. Das ist Ihr größter Hebel für Kosten und Latenz.
• Grounding auf den Schritt beschränken, der aktuelle Fakten braucht. Grounden Sie den Web-Research-Aufruf; grounden Sie nie Schritte, deren Fakten aus Dokumenten stammen, die Sie selbst geliefert haben.
• RAG weglassen, wenn langer Kontext reicht. Bei einer Handvoll Dokumenten pro Lauf packen Sie diese in einen multimodalen Long-Context-Prompt, statt eine Retrieval-Schicht zu bauen.
• Apps Script orchestriert Workspace, die API übernimmt das Reasoning. Sie bekommen einen kostenlosen Scheduler, nativen Zugriff auf Docs/Gmail und einen editierbaren Prompt für Nicht-Engineers, mit voller Kontrolle über das Modell dort, wo es zählt.
• Modell-IDs an einer Stelle halten und die Temperatur bei Gemini 3 auf dem Standardwert lassen. Steuern Sie die Präzision über den Prompt und aktualisieren Sie die ID, wenn Google ein Modell abkündigt.
• Erst auf ADK auf Vertex AI umsteigen, wenn Sie echte Multi-Tool-Agency brauchen. Selbstgebaute Schritte reichen, bis das Modell zwischen mehreren Tools wählen und sich über Läufe hinweg erinnern muss.