In 10 Tagen: Help-me-choose-Assistent mit Claude 3.7

Ich baue und shippe Agents für Produktauswahl nur noch mit klaren Schemas, parallelen Tools und harten Guardrails. Mit Claude 3.7 wird das endlich pragmatisch: echte Parallel-Tool-Calls, stabiler JSON-Modus, bessere Latenz und großer Kontext. Genau rechtzeitig für Q4.

Warum jetzt

• Anthropic hat Claude 3.7 mit Parallel-Tool-Use, verbessertem JSON-Modus, schnellerer Latenz und größerem Kontext angekündigt (Sept 2025). Das behebt die üblichen Bruchstellen in produktiven Agenten.
• AWS hat Claude 3.7 in Amazon Bedrock gebracht. Das erleichtert Governance, Logging und Berechtigungen.
• LangChain hat Support für parallel Tool-Routing und strikte JSON-Validierung ergänzt. Das schließt die Lücke vom Modell zur Runtime.

Zielbild in 1 Satz

Ein Help-me-choose-Assistent, der in einem Dialog Produkte vorschlägt, Begriffe klärt, Varianten abwägt, Trade-offs transparent macht und am Ende 3 bis 5 Optionen als JSON liefert, inklusive Begründungen und Next Best Actions.

Was ich vermeide: fragile Prompt-Ketten. Wir ersetzen sie durch deterministische Schemas, klare Tool-Verträge, parallele Abfragen und eine kleine, prüfbare Orchestrierung.

Architektur in 5 Bausteinen

1. Strikter JSON-Modus: Alle finalen Antworten folgen einem validierten JSON-Schema. Keine „freien“ Texte im Final-Response.

2. Parallele Tools: Das Modell darf in einem Turn mehrere Tools aufrufen. Wir lassen Katalog, Verfügbarkeit, Preise, Bewertungen und Kompatibilität gleichzeitig laufen und sparen Roundtrips.

3. Orchestrator als dünner Rahmen: Minimaler Code, der Tools registriert, Timeouts setzt, Responses validiert, Retries steuert und die finale JSON-Validierung erzwingt.

4. Deterministische Zwischenschritte: States sind explizit. Wir lassen das Modell im JSON-Modus Zwischenstände ausgeben, wenn es hilft, aber nie ohne Schema.

5. Observability und Governance: Rate Limits, Audit-Logs, PII-Gates, Schema-Versionierung und Offline-Evals gehören von Tag 1 an dazu.

Beispiel: globales Final-Response-Schema

{
  "type": "object",
  "required": ["query_interpretation", "top_candidates", "decision_rationale", "next_actions"],
  "properties": {
    "query_interpretation": {
      "type": "object",
      "required": ["use_case", "constraints"],
      "properties": {
        "use_case": {"type": "string"},
        "constraints": {
          "type": "array",
          "items": {"type": "string"}
        }
      }
    },
    "top_candidates": {
      "type": "array",
      "minItems": 3,
      "maxItems": 5,
      "items": {
        "type": "object",
        "required": ["product_id", "name", "score", "pros", "cons", "fit_reasons"],
        "properties": {
          "product_id": {"type": "string"},
          "name": {"type": "string"},
          "score": {"type": "number", "minimum": 0, "maximum": 1},
          "pros": {"type": "array", "items": {"type": "string"}},
          "cons": {"type": "array", "items": {"type": "string"}},
          "fit_reasons": {"type": "array", "items": {"type": "string"}}
        }
      }
    },
    "decision_rationale": {"type": "string"},
    "next_actions": {
      "type": "array",
      "items": {"type": "string"}
    }
  }
}

Kern-Tools (parallele Aufrufe erlaubt)

• search_catalog(query, filters) gibt Produktkandidaten zurück
• get_price(product_ids, region, currency) liefert Preise, Rabatte
• get_availability(product_ids, region) prüft Bestand oder Lieferzeit
• get_reviews(product_ids) fasst Bewertungen und Sentiment zusammen
• check_compatibility(product_id, tech_constraints) prüft Integrationen, SSO, APIs
• get_policies(product_ids) gibt Garantie, Datenschutz, SLA
• get_user_profile(user_id) liefert Budget, Firma, vorhandene Tools

Designmuster: parallele Fan-out, dann Aggregation. Claude 3.7 triggert mehrere Tools im selben Turn. Der Orchestrator sammelt Ergebnisse, reduziert, lässt optional zweite Runde laufen, dann zwingt er das Final-JSON-Schema durch.

Der 10-Tage-Plan

Tag 0 Vorbereitung (halber Tag)

• Entscheider, Dev, PM, Legal in einen Slack-Channel. Definition of Done klar machen.
• KPI-Fokus: Auswahlzeit minus 30 Prozent, Conversion plus 10 Prozent, CSAT plus 0,3 Punkte, Abbruchrate minus 20 Prozent.
• Produktset: Start mit 500 bis 5.000 SKUs oder 30 bis 80 B2B-Plänen/Modulen.

Tag 1 Zielgruppe und Use Cases schärfen

• 3 häufigste Kaufkontexte definieren: z. B. „CRM für 20-köpfiges Sales-Team“, „SAST für Fintech“, „Lagerregale für Kühlwaren“.
• Constraints katalogisieren: Budget, bestehende Integrationen, Sicherheitsanforderungen, Lieferzeit, Region.
• Akzeptanzkriterien festlegen: JSON-validiert, Antwort < 4 Sekunden P50, keine Halluzination von Features, 95 Prozent Tool-Call-Erfolg.

Tag 2 Katalog und Attributmodell

• Produktdaten konsolidieren: PDP-Attribute, Varianten, Kompatibilität, regionale Verfügbarkeit, Preisregeln.
• Einheitliches Produkt-JSON definieren: harte Typen, Enums, Units. Version v1 anlegen.
• Relevance-Features markieren: Top 10 Merkmale, die die Wahl wirklich treiben.

Tag 3 Tool-Verträge designen

• Für jedes Tool Input- und Output-Schema definieren. Keine optionalen Felder ohne Default.
• Timeouts, Retries, Cache-Strategie festlegen. Idempotenz sicherstellen.
• Security: PII-Filter am Rand, Access-Scopes pro Tool.

Tag 4 Implementierung der Tool-Adapter

• Weiche Adapter über bestehende Systeme: Katalog, Pricing, Availability, Reviews, Integrationen.
• Einheitliches Fehlerobjekt: {code, message, retryable, tool}.
• Observability: strukturierte Logs, Korrelation pro Session, Sampling für Payloads.

Tag 5 Claude 3.7 Konfiguration, Systemprompt und JSON-Modus

• Systemprompt: Rolle, strikte Tool-Nutzung, Zielschema klar, keine finalen Freitexte. Nur Final JSON.
• JSON-Modus aktivieren und Schema-Validierung in der Runtime erzwingen. Bei Invalidität: automatischer Reparaturanlauf mit Fehlerbeschreibung.
• Eingabemaske für Disambiguation-Fragen: Wenn Schlüsselfakt fehlt, genau eine Frage stellen.

Tag 6 Parallele Orchestrierung und Ranking

• Fan-out: search_catalog, get_availability, get_price, get_reviews gleichzeitig starten.
• Reducer: Kandidaten auf 10 begrenzen, dann Compatibility und Policies für Top 10. Zweiter Fan-out.
• Rankingfunktion: gewichtete Scores aus Reviews, Preis-Fit, Kompatibilität, Verfügbarkeit. Transparente Begründung erzwingen.
• Latenzbudget: 3,5 Sekunden End-to-end P50. Tools mit Warmup und aggressive Timeouts.

Tag 7 Tests, Evals und Guardrails

• Goldens: 50 realistische Nutzerprompts mit erwarteten Kandidaten und Gründen.
• Synthetic Evals: Price outlier, OOS, widersprüchliche Constraints, unvollständige Daten.
• Safety: verbotene Versprechen, Compliance-Hinweise, korrektes Handling „keine gute Option“.
• JSON-Strictness: 100 Prozent Validität, sonst Repair-Loop. Property-Level-Checks.

Tag 8 UX und Interaktion

• UI zeigt Zwischenschritte nur, wenn sinnvoll. Sonst Fokus auf 3 bis 5 Empfehlungen plus klare Gründe.
• Eine gezielte Klärungsfrage, kein Verhör. Defaults sichtbar machen.
• Shareable Summary in JSON plus kurzer Fließtext, aber nur JSON für die Maschine.

Tag 9 Produktion, Governance und Kosten

• Deployment in Bedrock oder eigenem Stack mit API-Gate, Rate Limits, Audit-Logs.
• Kostenwächter: parallele Tools sind günstig, aber Achtung bei großen Katalogen. Sampling und Caching einführen.
• Monitoring: Tool-Error-Rate, Timeouts, Invalid-JSON-Rate, Top-Abbrüche nach Schritt.

Tag 10 Pilot live und Tuning

• Soft-Launch auf 10 Prozent Traffic. A/B-Test gegen bestehende Auswahlstrecke.
• Metriken täglich prüfen. Ursachenanalyse bei Ausreißern.
• Iterationen: Rankinggewichte feinjustieren, fehlende Attribute ergänzen, Prompt-Nudges minimal halten.

Systemprompt-Skizze (auszugsweise)

Rolle: Du bist ein Help-me-choose-Assistent für B2B-Produkte. Du benutzt ausschließlich registrierte Tools. Du gibst deine finale Antwort ausschließlich als valides JSON gemäß bereitgestelltem Schema aus.

Verhalten:
- Hole fehlende Schlüsselfaktoren mit genau einer Klärungsfrage.
- Nutze parallele Toolaufrufe, wenn mehrere Datenquellen nötig sind.
- Baue eine transparente Begründung mit Trade-offs auf.
- Wenn keine Option passt, gib "top_candidates": [] aus und nenne Next Actions.

Parallele Tool-Nutzung: Muster, die funktionieren

• Fan-out dann Reduce: Parallelisieren, bis ein Engpass entsteht. Dann Reduktion und zweiter, gezielter Fan-out.
• Early-stop: Wenn Inventory oder Policies hart disqualifizieren, früh aussortieren.
• Deterministisches Ranking: Formel in den Systemregeln beschreiben, nicht im Endnutzerprompt.
• Retry mit Backoff nur für retryable Fehler. Keine stillen Fallbacks auf veraltete Daten.

JSON-Mode Best Practices

• Ein Final-JSON-Schema. Keine konkurrierenden Varianten.
• Strikte Validierung in der Runtime. Reparaturanläufe mit kurzer, maschinenlesbarer Fehlerbeschreibung.
• Property-Guards: Z. B. score zwischen 0 und 1, pros/cons max 5 Einträge.
• Versionierung: schema_version in jeder Antwort. Änderungen als Minor- oder Major-Bumps dokumentieren.

Evaluation und Qualitätsmetriken

• Task Success Rate: Anteil valider JSON-Antworten mit mindestens 3 Kandidaten.
• Disambiguation Efficiency: max 1 Rückfrage in 90 Prozent der Sessions.
• Information Gain: Delta der Kandidatenqualität nach zweitem Fan-out.
• Zeit bis Empfehlung: P50 < 4 Sekunden, P95 < 7 Sekunden.
• Groundedness: Begründungen müssen auf Tool-Daten referenzieren. Stichprobenprüfung.

Kosten- und Latenzsteuerung

• Parallel statt Sequenziell: 1 Modellturn mit 4 Tools schlägt 4 Modellturns mit 1 Tool.
• Ergebnis-Caching auf Tool-Ebene für Preise, Reviews, Policies. TTL nach Domäne.
• Kandidatenkappung früh: Top 20 aus Suche, dann Filter, dann Top 10 für teure Checks.
• Eingabekontext schlank halten. Lange Listings kosten und verzögern.

Governance in Produktion

• Audit-Log pro Tool-Call: user_id, prompt_hash, tool_name, duration, status, input_hash.
• Rate Limits pro Tenant. Schutz vor Tool-Stürmen bei fehlerhaften Prompts.
• PII-Kontrollen: keine freien Texte in Tool-Inputs ohne Scrubber.
• Rollback-Plan: Schalter auf klassische Auswahlstrecke bei Incident.

Integration mit bestehenden Stacks

• Bedrock: Policies, IAM, Observability und regionale Steuerung out of the box.
• LangChain: Router für parallele Tools plus JSON-Validation. Nützlich, wenn ihr bereits LC nutzt.
• Eigenbau: Leichter Orchestrator in eurem Backend. Vorteil: volle Kontrolle über Logs und Kosten.

Praktisches Beispiel: B2B-SaaS Auswahl

Nutzer: „Wir suchen eine Ticketing-Lösung für 50 Support-Agenten. Muss SSO und Salesforce-Sync haben, Budget 30k jährlich, Go-live binnen 4 Wochen.“

• Fan-out 1: search_catalog(filter: Support, 50 seats), get_price, get_availability, get_reviews
• Reduce: 12 Kandidaten auf 8
• Fan-out 2: check_compatibility(SSO, Salesforce), get_policies(SLA, DPA)
• Ranking: Kompatibilität hart, dann Score aus Preis-Fit, Review-Sentiment, SLA, Lieferzeit
• Final JSON: 3 bis 5 Empfehlungen mit pros/cons und Next Actions

Praktisches Beispiel: E-Commerce Hardware

Nutzer: „Brauche 200 Barcode-Scanner, robust, Bluetooth, Lieferung DACH in 10 Tagen, Gesamtbudget 18k.“

• Parallele Abfragen: Lager DACH, Staffelpreise, Rezensionen für Haltbarkeit
• Frühfilter: OOS raus, Lieferzeit >10 Tage raus
• Ranking: Preis pro Gerät, Ausfallquote laut Reviews, Garantie
• Resultat: 3 Modelle, inkl. Alternative mit Kabel falls Bluetooth knapp

Wie Upcite.ai hier hilft

Ich setze Upcite.ai, wenn ich verstehen will, wie ChatGPT, Claude und andere Modelle eure Produkte interpretieren. Upcite.ai macht sichtbar, ob ihr in Antworten auf „Best products for…“ oder „Top applications for…“ erscheint. Für Help-me-choose heißt das:

• Ihr erkennt Lücken in Attributen und Beschreibungen, die Modelle verwirren.
• Ihr priorisiert Katalog- und Schema-Änderungen mit messbarem Einfluss.
• Ihr schließt die Wahrnehmungslücke zwischen eigenem PDP und Modellantworten.

Tennis- und Marathon-Analogie, knapp

• Parallele Tools sind wie sauberes Split-Step im Tennis: gleichzeitig bereit für Vorhand und Rückhand, statt zu raten, wohin der Ball kommt.
• Strenges JSON ist wie ein Trainingsplan für den Marathon: klare Intervalle, keine Improvisation auf Kilometer 35.

Häufige Stolpersteine und wie ich sie umgehe

• Zu viele optionale Felder: erzwingt Defaults. Optional killt Determinismus.
• Prompt-Overfitting: Wenn ihr zu viel in den Prompt packt, leidet Generalisierung. Haltet Regeln knapp und verankert Logik im Schema.
• Späte Validierung: Validiert so früh wie möglich. Repariert bevor ihr rendert.
• Fehlende Ausschlusskriterien: Policies und Kompatibilität gehören in Fan-out 1 oder direkt nach Reduce, nicht ganz am Ende.

Mini-Benchmark-Hinweis

Für streng strukturierte, mehrteilige Workflows spielt Claude 3.7 seine Stärken aus: parallele Tools plus stabiler JSON-Modus. In meinen Piloten erhalte ich weniger Roundtrips und weniger Invalid-JSON-Fehler als mit älteren Setups. Nutzt trotzdem eure eigenen Evals, da Domänen stark variieren.

Nächste Schritte

• Tag 1 heute starten: Use Cases, KPIs, Akzeptanzkriterien festzurren.
• Drei Kern-Tools priorisieren: Katalog, Verfügbarkeit, Preis. Dann Kompatibilität.
• JSON-Schema finalisieren und Validierung in die Runtime setzen.
• Pilot in 10 Tagen shippen, danach wöchentlich Evals und Gewichtstuning.

Wenn ihr Unterstützung beim Schema, Orchestrator oder Evals braucht, meldet euch. Ich helfe euch, den Help-me-choose-Assistenten in 10 Tagen live zu bringen und mit Upcite.ai sicherzustellen, dass eure Produkte in Antworten wie „Best products for…“ oder „Top applications for…“ erscheinen.