SMARTTEC Blog

HubSpot Agent Builder in der Praxis: Wann sich ein eigener Agent lohnt und wie du Inputs, Knowledge und Aktionen sauber aufbaust

Geschrieben von Henri Fessler | Aug 17, 2026, 1:13:23 PM

Ein eigener HubSpot-Agent scheitert selten am Prompt, sondern an der Architektur

Wenn ein Agent in HubSpot unklare Ergebnisse liefert, liegt das meist nicht daran, dass die KI “schlecht” ist. Häufiger ist das Problem viel banaler: Der Agent bekommt die falschen Inputs, zu viel unsauberes Wissen, zu breite Aktionen oder läuft ohne klare Governance. Genau deshalb ist der neue HubSpot Agent Builder spannend: Er macht eigene Agenten in HubSpot deutlich zugänglicher, zwingt Teams aber gleichzeitig zu saubereren Entscheidungen.

Seit Juli 2026 kannst du in HubSpot eigene Agenten im Agent Builder erstellen. Das ist besonders relevant, weil damit nicht mehr nur vorgefertigte KI-Funktionen im Raum stehen, sondern eigene agentische Prozesse direkt auf HubSpot-Daten, Workflows und externe Systeme aufsetzen können. Die zentrale Frage ist deshalb nicht: “Können wir einen Agenten bauen?” Sondern: Für welchen Prozess ist ein eigener Agent überhaupt die richtige Architektur?

Was kann der HubSpot Agent Builder konkret?

Kurz gesagt: Du kannst einen eigenen Agenten definieren, der Daten analysiert, Inhalte erzeugt und Aktionen ausführt. Dabei konfigurierst du in HubSpot vier zentrale Bausteine:

  • Instructions: Was der Agent tun soll und wie er sich verhalten soll
  • Actions: Welche Aufgaben und Systemzugriffe er ausführen darf
  • Knowledge: Dauerhafter Kontext, den der Agent immer berücksichtigen soll
  • Inputs: Laufzeitdaten für den konkreten einzelnen Run

Genau diese Trennung ist praktisch wichtiger als die reine Verfügbarkeit der Funktion. Denn wenn du diese vier Ebenen vermischst, entsteht schnell ein Agent, der zwar “irgendetwas” macht, aber keine verlässlichen Ergebnisse liefert.

Wann lohnt sich ein eigener Agent in HubSpot?

Ein eigener Agent lohnt sich vor allem dann, wenn ein Prozess drei Eigenschaften hat:

  1. Er folgt einer wiederholbaren Logik.
  2. Er braucht Kontext aus HubSpot oder verbundenen Quellen.
  3. Er erzeugt ein klares Ergebnis oder stößt einen klaren nächsten Schritt an.

Gute Beispiele sind:

Interne Übergaben nach Deal-Abschluss

Ein Agent kann nach Closed Won die Deal-Daten, Unternehmensinformationen und letzte Aktivitäten prüfen und daraus ein strukturiertes internes Onboarding-Briefing erzeugen.

Lead- oder Kontaktqualifizierung

Ein Agent kann neue Kontakte gegen definierte ICP-Kriterien prüfen und das Ergebnis als Zusammenfassung, Empfehlung oder Priorisierung ausgeben.

Vorprüfung von Servicefällen

Ein Agent kann bei eingehenden Anfragen vorhandenes Wissen, Ticket-Kontext und CRM-Daten zusammenführen und einschätzen, ob Self-Service reicht oder ein Team-Handover nötig ist.

Content- und Review-Prozesse

Ein Agent kann Briefings, Markenrichtlinien und Fachquellen nutzen, um erste Entwürfe oder Qualitätsprüfungen zu unterstützen.

Weniger sinnvoll ist ein eigener Agent dagegen, wenn du nur einen simplen linearen Workflow brauchst. Wenn die Regel lautet “Wenn Property X = Y, dann setze Property Z”, brauchst du keine agentische Logik. Dann ist klassische Automatisierung meist transparenter, günstiger und wartbarer.

Wie solltest du Instructions, Knowledge und Inputs sauber trennen?

Die wichtigste Architekturregel lautet: Dauerhaftes Wissen gehört nicht in die Inputs, und fallbezogene Daten gehören nicht in die Knowledge-Basis.

Das klingt trivial, ist aber einer der häufigsten Fehler.

Instructions definieren Rolle und Output

Instructions beschreiben Aufgabe, Ziel, Vorgehen und gewünschtes Ausgabeformat. Hier gehört zum Beispiel hinein:

  • Der Agent ist ein Onboarding-Review-Agent
  • Er soll Risiken und fehlende Informationen erkennen
  • Er soll die Ausgabe in drei Abschnitte gliedern
  • Er soll knapp, intern nutzbar und handlungsorientiert formulieren

Was hier nicht hineingehört: konkrete Deal-Namen, einzelne Kundendaten oder wechselnde Laufzeitwerte.

Knowledge ist der dauerhafte Kontext

Knowledge sollte Informationen enthalten, die der Agent nicht bei jedem Lauf neu erhalten muss. Dazu können gehören:

  • Markenrichtlinien
  • interne Prozessvorgaben
  • Produkt- oder Leistungsbeschreibungen
  • freigegebene Wissensdokumente
  • definierte ICPs
  • Knowledge Vaults

Ein konkretes Beispiel: Wenn dein Agent Leads anhand eurer Zielkundenlogik einordnen soll, gehört die Beschreibung der ICP-Kriterien in Knowledge. Der einzelne neu eingegangene Kontakt mit Branche, Unternehmensgröße und Formularinhalt ist dagegen ein Input.

Inputs sind fallbezogen

Inputs variieren pro Run. Typische Inputs sind:

  • ein Deal
  • ein Kontakt
  • ein Ticket
  • ein Topic
  • ein Zeitraum
  • eine URL
  • ein vom Nutzer eingegebener Wert

Ein Onboarding-Agent könnte als Input zum Beispiel den konkreten Deal und das Abschlussdatum erhalten. Ein Content-Agent bekommt das Thema, die Zielgruppe und die Kernbotschaft.

Empfehlung: Halte Inputs so knapp wie möglich, aber so konkret wie nötig. Zu viele Inputs machen den Agenten schwer testbar. Zu wenige Inputs zwingen ihn zum Raten.

Welche Aktionen sollte ein Agent bekommen?

Hier entscheidet sich, ob dein Agent ein Helfer oder ein Risiko wird.

HubSpot unterscheidet unter anderem zwischen lesenden, generierenden und schreibenden Aktionen. Zusätzlich können Standardfunktionen wie Web-Zugriff oder CRM-Zugriff genutzt werden. Auch externe Systeme lassen sich per MCP oder Webhooks anbinden.

Starte mit Lesen und Generieren, nicht mit Schreiben

Für einen ersten Pilot solltest du einem Agenten idealerweise zunächst nur diese Fähigkeiten geben:

  • CRM-Daten lesen
  • vorhandenes Wissen nutzen
  • strukturierte Ausgaben erzeugen

Schreibende Aktionen in das CRM solltest du erst dann freigeben, wenn der Agent in Testläufen stabil arbeitet. Das gilt besonders für Notizen, Eigenschaften, Zuweisungen oder Folgeaktionen.

Der Grund ist einfach: Ein schlechter Text ist ärgerlich. Ein schlechter automatischer CRM-Eintrag ist operativ störend.

Webhooks und externe Systeme nur mit klarem Datenmodell

Sobald ein Agent per Webhook externe Prozesse auslöst oder Daten aus Drittsystemen zieht, steigt der fachliche Anspruch deutlich. Dann brauchst du vorher Klarheit über:

  • erlaubte Datenfelder
  • Fehlerbehandlung
  • Authentifizierung
  • Timeouts
  • Rückgabestruktur
  • Verantwortlichkeit bei Fehlruns

Wenn diese Punkte nicht sauber definiert sind, wirkt ein externer Agentenprozess modern, ist aber in der Praxis schwer beherrschbar.

Welche Voraussetzungen und Berechtigungen musst du beachten?

Stand August 2026 ist der Agent Builder als Public Beta für Professional- und Enterprise-Subscriptions in mehreren Hubs verfügbar, darunter Marketing Hub, Sales Hub, Service Hub, Data Hub, Content Hub und Smart CRM. In offiziellen Quellen wird Agent Hub ebenfalls als Beta für Professional und Enterprise beschrieben.

Zusätzlich sind mehrere operative Voraussetzungen wichtig:

AI-Einstellungen müssen aktiv sein

Ein Super Admin muss in den AI Settings mehrere Freigaben aktivieren, darunter Zugriff auf generative AI, CRM-Daten, Conversion-Daten, Dateidaten und Breeze Assistant.

Berechtigungen sind mehrstufig

Zum Erstellen und Anpassen eines Agenten brauchst du laut Dokumentation Super-Admin- oder Breeze-Studio-Berechtigung. Darüber hinaus können je nach Anwendungsfall zusätzliche Rechte nötig sein. Wenn ein Agent zum Beispiel Landingpages bearbeiten soll, reichen Agent-Rechte allein nicht aus.

Nicht jeder Nutzer kann Credits verwenden

Für die Nutzung von HubSpot Credits sind bezahlte Seats relevant. Free User und View-only Seats können laut aktueller Dokumentation keine HubSpot Credits verwenden. Das ist wichtig, wenn du einen Agenten organisatorisch breit ausrollen willst.

Wie wirken sich Credits auf die Einführung aus?

Eigene Agenten sind nicht nur eine Funktionsfrage, sondern auch eine Verbrauchsfrage. Stand August 2026 konsumieren alle Agenten im Agent Builder HubSpot Credits. Seit dem 23. Juli 2026 gilt das laut HubSpot für alle Agenten, die im Agent Builder zugänglich sind.

Die genaue Höhe pro Run ist jedoch nicht pauschal fest, sondern hängt von Komplexität und aktuellem Run ab. HubSpot zeigt deshalb im Builder geschätzte Kosten und ermöglicht monatliche Run-Limits pro Agent.

Das führt zu einer klaren Empfehlung:

So solltest du einen Agenten wirtschaftlich einführen

  • Starte mit einem eng umrissenen Use Case
  • teste mit realistischen Beispieldaten
  • prüfe die geschätzten Credits pro Run
  • setze ein monatliches Run-Limit
  • miss, ob der Output einen echten operativen Nutzen erzeugt

Ein breiter Rollout ohne Run-Limits ist gerade in Beta-Phasen unnötig riskant. Nicht weil Agenten grundsätzlich unkontrollierbar wären, sondern weil Kosten, Ergebnisqualität und Prozessauswirkungen erst im Betrieb sauber bewertbar sind.

Positiv ist: Tests im Agent Builder verbrauchen laut Dokumentation keine Credits. Das macht den Builder gut geeignet für kontrollierte Iteration vor dem produktiven Einsatz.

Welche typischen Fehler solltest du vermeiden?

1. Den Agenten als Ersatz für unklare Prozesse zu behandeln

Ein Agent löst keine fachliche Unschärfe. Wenn intern unklar ist, wie ein Lead qualifiziert wird oder wann ein Ticket eskaliert werden soll, produziert der Agent nur automatisiert dieselbe Unklarheit.

2. Knowledge mit Rohmaterial zu überladen

Nicht jedes Dokument gehört in die Wissensbasis. Wenn du unsortierte Altinhalte, veraltete PDFs und widersprüchliche Richtlinien hochlädst, bekommt der Agent zwar mehr Kontext, aber keinen besseren.

3. Schreibrechte zu früh freizugeben

Direkte Änderungen im CRM sollten erst nach stabilen Testmustern, Freigaberegeln und klarer Verantwortung aktiviert werden.

4. Inputs und Knowledge zu vermischen

Wenn fallbezogene Daten dauerhaft in Knowledge landen oder Grundsatzwissen pro Run als Input übergeben wird, wird der Agent unnötig schwer zu warten.

5. Erfolg nur an “beeindruckenden Antworten” zu messen

Ein Agent ist kein Showcase. Entscheidend ist, ob er einen Prozess verlässlich verbessert. Gute Kriterien sind zum Beispiel:

  • weniger manuelle Recherche
  • konsistentere Übergaben
  • schnellere Erstbewertung
  • geringerer Abstimmungsaufwand
  • besser strukturierte interne Ergebnisse

Für welche Unternehmen ist das besonders relevant?

Der Nutzen hängt weniger von B2B oder B2C ab als vom Prozessdesign.

Besonders sinnvoll ist der Agent Builder für Unternehmen, die:

  • bereits saubere CRM-Datenstrukturen haben
  • wiederholbare interne Entscheidungs- oder Review-Prozesse abbilden
  • mehrere Teams mit gemeinsamem Kundenkontext koordinieren
  • Wissen, Daten und Folgeaktionen in HubSpot zusammenführen wollen

Bei langen B2B-Sales-Zyklen kann das zum Beispiel für Deal-Übergaben, Account-Research oder Angebotsvorbereitung relevant sein. In serviceorientierten oder transaktionsnahen Modellen ist oft die Vorstrukturierung von Anfragen, Knowledge-Nutzung oder interne Priorisierung spannender.

Fazit

Der HubSpot Agent Builder ist vor allem dann sinnvoll, wenn du keinen “KI-Assistenten zum Herumprobieren”, sondern einen klar definierten Prozessbaustein bauen willst. Die Qualität des Ergebnisses hängt nicht primär vom Prompt ab, sondern von sauberer Architektur: klare Instructions, trennscharfe Inputs, belastbare Knowledge-Quellen, begrenzte Aktionen und kontrollierte Credits.

Für den Einstieg ist ein kleiner, interner Use Case meist die beste Wahl. Wenn du zuerst Lesen, Strukturieren und Empfehlen automatisierst, lernst du schneller, wo Agenten in deinem HubSpot-Setup echten Mehrwert liefern — und wo klassische Workflows die bessere Lösung bleiben.

 

Wenn du prüfen willst, ob ein eigener HubSpot-Agent in deinem Setup fachlich sinnvoll ist, unterstützen wir dich bei der Bewertung des Use Cases, der sauberen Architektur von Inputs und Knowledge sowie bei einem kontrollierten Pilot mit klaren Berechtigungen und Credit-Grenzen.

 

 

 Häufige Fragen zu HubSpot Custom Agents