HubSpot Agent Builder: Agenten & Workflows

Was ist der HubSpot Agent Builder – und was ist er nicht?

Der Agent Builder ist HubSpots neue Automations-Canvas im Agent Hub, die Workflows, KI-Agenten, Trigger und Monitoring in einer Oberfläche vereint. Aktuell läuft er als Beta in den Professional- und Enterprise-Stufen. Er ersetzt keine Workflows und ist kein autonomer Vertriebsmitarbeiter, sondern die Umgebung, in der du beide Bausteine kombinierst.

Gegenüber den klassischen Workflows ändern sich drei Dinge. Erstens hängen Trigger nicht mehr an der Enrollment-Logik des CRM, sodass ein Prozess auch aus einem Zeitplan, einem Webhook oder einer Drittanbieter-Integration startet. Zweitens läuft ein Custom Agent als Schritt im selben Ablauf: Die Automation übergibt an den Agenten, wartet auf sein Ergebnis und macht dann weiter. Drittens baut dir Breeze Assistant auf Wunsch den ersten Entwurf, wenn du den Ablauf in Alltagssprache beschreibst.

Zum Rahmen: Agent Hub bündelt Agent Builder, Agent Inbox, Context und die Workflow-Canvas. Verfügbar ist das Ganze laut HubSpot Knowledge Base in den Professional- und Enterprise-Stufen. Das gilt für Marketing Hub, Sales Hub und Service Hub ebenso wie für Data Hub, Content Hub und Smart CRM. Custom Agents verbrauchen dabei HubSpot Credits. Die allgemeine Verfügbarkeit hat HubSpot in den Product Updates für den 16. September 2026 angekündigt, und bis dahin kann sich das Verhalten der Beta noch ändern.

Willst du zuerst die klassische Workflow-Mechanik sauber aufsetzen? Dann lies HubSpot Workflows, die Umsatz wirklich skalieren, dort stehen genau diese Grundlagen. Hier geht es um die Schicht darüber: wann ein Agent in den Ablauf gehört und wie die Kontrolle dabei im Workflow bleibt.

Den 1:1-Implementierungsguide findest du auch auf LinkedIn:

Workflow oder Agent: Wo gehört welche Entscheidung hin?

Landen Kontrolle und Interpretation im selben Baustein, kann später niemand erklären, warum etwas passiert ist. Deshalb gilt eine einfache Regel: Der Workflow besitzt die Kontrolle. Er entscheidet über Eligibility und Trigger, über Branches und Timing. Auch SLAs, Fallbacks und jeder Schreibvorgang gehören ihm, während der Agent eine begrenzte Interpretation besitzt. Er liest freigegebenen Kontext, vergleicht Evidenz und benennt Lücken, bevor er eine strukturierte Empfehlung zurückgibt. Menschen besitzen Policy, Ausnahmen und folgenreiche Freigaben.

Die erste Frage bei der Implementierung ist deshalb nicht, wo sich ein Agent einbauen lässt. Sie lautet: Welche Entscheidungen müssen deterministisch bleiben, und welche brauchen Interpretation? Und wer entscheidet im Ausnahmefall, wenn sich das System nicht sicher ist? Autonomie nützt dir nur, wenn das System erklären kann, was passiert ist. Es muss zeigen, welche Daten es benutzt hat und wem die nächste Aktion gehört.

Wie das in einem echten Ablauf aussieht, zeigt der ICP-Check, den HubSpot selbst als Prototyp im Agent Hub führt:

Wie wird Context zur verlässlichen Wissensquelle statt zur Ablage für alles?

Ein Agent ist nur so verlässlich wie das Wissen, das er liest. Dieses Wissen holt er sich aus Context: Informationen zu Firma, Kunden, Team und Prozessen, als Freitext oder als hochgeladene Datei. Verlässlich ist eine Quelle aber erst, wenn vier Fragen beantwortet sind. Wer gibt sie frei? Wer darf sie sehen? Wann läuft sie ab? Und welchen Rang hat sie?

Für jede Quelle legst du deshalb vier Dinge fest:

• Owner: Eine benannte Person oder ein Team gibt die Quelle frei und pflegt sie.
• Scope: Festgelegt ist, welche Agenten und Nutzer darauf zugreifen. Die Wahl beim Upload zwischen account-weit und persönlich ist eine Governance-Entscheidung, keine Formalie.
• Freshness: Ein Datum, an dem jemand die Quelle prüft, ersetzt oder stilllegt.
• Authority: Geklärt ist, ob die Quelle Evidenz, Policy, Beispiel oder Entwurf ist.

Die teuerste Abkürzung an dieser Stelle: Jemand lädt einen persönlichen Entwurf hoch, und der wird still zum Qualifizierungsstandard des ganzen Accounts. Widersprechen sich zwei Quellen, gibt der Agent einen Conflict-Zustand zurück und wählt nicht einfach die bequemste Antwort.

Wie sieht ein sauberer Instruction Contract für deinen Agenten aus?

Ein Agent ohne klare Grenzen tut irgendwann etwas, das niemand bestellt hat. Deshalb bekommt jeder Custom Agent eine eng begrenzte Rolle mit fünf Bestandteilen. Das sind Rolle und Verbot, Ziel, Inputs, Vorgehen und das Ausgabeschema. Der ICP-Check-Agent etwa bewertet Kontakt und Firma gegen das ICP-Framework, setzt aber weder die finale Qualifizierungsstufe, noch startet er Outreach. Genau diese Verbote gehören in die Instructions, nicht in die Hoffnung.

In der Praxis steht oder fällt dieser Auftrag an den Agenten (Instruction Contract) mit einem Teil: dem Ausgabeschema. Der Agent liefert eine Empfehlung aus festen erlaubten Werten. Not Fit, Low Fit, Medium Fit und Perfect Fit beschreiben die Passung. Insufficient Data und Conflict melden, dass er nicht sicher entscheiden kann. Dazu kommen Begründung, benutzte Evidenz, fehlende Daten und der Review-Bedarf, jeweils als getrennte Felder. Der Workflow brancht auf die erlaubten Werte, nie auf Prosa.

Zwei Zustände fehlen in fast jedem ersten Entwurf, und sie tragen die halbe Betriebssicherheit. Insufficient Data meldet fehlende Firmendaten, statt eine Bewertung zu raten. Conflict meldet, dass sich zwei freigegebene Quellen widersprechen, statt still eine davon zu wählen. Beide Zustände erzeugen benannte Review-Arbeit, und genau dafür sind sie da.

Warum darf eine Agent-Empfehlung nie direkt operative Wahrheit werden?

Sonst stehen Reporting und Routing auf Interpretationen statt auf Entscheidungen. Und niemand kann später sagen, was der Agent vorgeschlagen und was ein Mensch daraus gemacht hat.

Deshalb bekommt die Empfehlung eigene Felder, in denen auch ihre Begründung, die benutzte Evidenz, der Zeitstempel und die Agent-Version stehen. Getrennt davon liegen der freigegebene ICP-Tier, die menschliche Entscheidung und der strukturierte Entscheidungsgrund, und dazwischen liegt ein sichtbares Gate.

Diese Trennung macht Overrides messbar, statt sie in Freitext-Notizen zu verstecken. Ausserdem hält sie drei Entscheidungen auseinander, die dir jedes Reporting ruinieren, wenn du sie in ein Feld wirfst:

• Fit: Ist das der richtige Account für das definierte ICP?
• Evidenz: Welches belastbare Verhalten oder Kaufsignal liegt vor?
• Aktivierungsreife: Gibt es einen Owner, einen erlaubten Play, genug Kontext und einen klaren nächsten Schritt?

Ein Perfect Fit ohne Signal ist kein Sales-Fall, ein starkes Signal ohne Owner auch nicht. Beantwortest du die drei Fragen in getrennten Feldern, kannst du später messen, an welcher es scheitert.

Was darf automatisch laufen – und was braucht ein Human Gate?

Nicht jede Aufgabe trägt dasselbe Risiko: Recherche, Zusammenfassungen und Entwürfe sind risikoarm, sie dürfen automatisch laufen. Eine Lifecycle-Änderung dagegen, eine Suppression, eine Sales-Aktivierung oder sensible Kommunikation braucht ein Gate, das ihrer Wirkung entspricht.

Wer freigibt, prüft fünf Dinge. Stützt die Evidenz die Empfehlung? Sind die Pflichtfelder vollständig? Sind Ownership und Deal-Status verstanden? Werden die Consent- und Suppression-Regeln eingehalten? Und ist der finale Zustand samt Entscheidungsgrund erfasst?

Dazu gehört ein Fallback-Pfad, der mehr kann als „Fehler ist aufgetreten“. Er hält Workflow- und Agent-Version fest, den Grund und den Input-Datensatz. Dazu kommen der Zeitstempel, ein benannter Owner oder eine Queue, die Retry-Bedingung und die finale Auflösung. Ohne diesen Pfad schafft Automatisierung die manuelle Arbeit nicht ab, sondern versteckt nur die manuelle Reparatur.

Dass sich der deterministische Unterbau lohnt, ist keine Theorie. Beim Treuhand-Software-Anbieter aumico hat SalesPlaybook den Angebotsprozess in HubSpot neu aufgesetzt. Statt Freitext und Zuruf gibt es seither klare Workflow-Zustände, definierte Owner und feste Übergabepunkte. Das veröffentlichte Ergebnis steht in der Case Study aumico: „Reducing the time for sending quotes by 80%“, erreicht „within 2 weeks“. Achtzig Prozent weniger Zeit pro Angebot, in unter zwei Wochen Umsetzungszeit. Und die Zahl stammt aus einem reinen Workflow-Projekt, ohne einen einzigen Agenten.

Genau das ist der Punkt: Der messbare Hebel liegt zuerst in sauberen Zuständen, Ownern und Übergabepunkten. Erst danach lohnt sich die Schicht, die interpretiert. Ein Agent, der auf diesem Unterbau Empfehlungen in erlaubten Werten liefert, macht den Prozess schneller und bleibt dabei auditierbar. Ein Agent auf einem ungeklärten Prozess automatisiert nur das Chaos. Drehst du die Reihenfolge um, bezahlst du beim Aufräumen: mit Handarbeit, die als Automatisierung verbucht wurde.

Wie testest du das Betriebsmodell – und nicht nur die Antwort?

Ein Agent, der im Demo-Datensatz die richtige Empfehlung gibt, ist noch nicht getestet. Getestet ist das System erst, wenn jeder Randfall einen definierten Zustand erzeugt, den du beobachten kannst.

Zwei Beispiele: Der Perfect-Fit-Datensatz durchläuft Eligibility, Owner-Zuweisung und das Freigabe-Gate, während der Non-Fit-Datensatz seinen Entscheidungsgrund behält und nie automatisch gelöscht wird.

Diese Testfälle machen in der Praxis den Unterschied:

• Fehlende Firmendaten erzeugen Insufficient Data oder Review Required. Eine stille Aktivierung gibt es nicht.
• Widersprüchliche Quellen erzeugen einen Conflict-Zustand mit benanntem Reviewer.
• Bestandskunden und offene Deals sind vor der falschen Sales-Motion geschützt.
• Ein Agent-Output ausserhalb des Schemas erzeugt einen Fallback-Zustand und benachrichtigt Operations.
• Re-Enrollment folgt einer dokumentierten Policy, statt Aktionen doppelt auszulösen.

Danach misst du den Betrieb, nicht die Demo. Wie oft werden Empfehlungen angenommen, und mit welchen Gründen überschrieben? Wie hoch sind die Raten für Insufficient Data und Fallback? Wie lange dauert es vom Trigger bis zur freigegebenen nächsten Aktion? Und wie hoch ist die Conversion je freigegebenem Fit-Tier?

Dieselbe Architektur trägt auch jenseits der Qualifizierung: Ein Ablauf zur Vorbereitung von Demos (Demo Prep) folgt exakt demselben Muster. Ein Meeting-Event triggert, der Agent fasst die CRM-Historie zusammen, und der Workflow erstellt Note, Task und Benachrichtigung. Der Job ändert sich, die Architektur nicht. Rollst du das über mehrere Teams oder Landesgesellschaften aus, findest du die Governance-Seite dazu unter Group-wide CRM.

Für wen lohnt sich der Einstieg jetzt?

Die Beta ist offen genug für belastbare Piloten, und die Muster oben stehen. Einen Grund, alles auf einmal zu wollen, gibt es dagegen nicht.

Gewinnen wird nicht das System mit der meisten Autonomie. Es gewinnt das System, das dein Team erklären, auditieren und verbessern kann. Baust du die Kontrollschicht vor der allgemeinen Verfügbarkeit, bekommst du die Vorteile ohne die Reparaturkosten.