Agentische Features in B2B-SaaS: Build, Buy oder Wait — ein Entscheidungsframework für 2026

Der Beschaffungsfragebogen eines FinTech-Käufers, den wir Anfang Q2 2026 prüften, hatte einunddreißig Fragen — elf davon zu Agenten. Nutzt das Produkt agentische Workflows? Werden Tools vor der Ausführung freigegeben? Gibt es ein Token-Budget pro Trajektorie? Wie werden unsichere Tool-Sequenzen erkannt? Was ist der Rollback-Plan, wenn ein Agent das falsche Tool wählt? Der antwortende Anbieter hatte neun Monate zuvor ein "KI-Agent"-Feature ausgeliefert: eine LangChain-Kette um ein Frontier-Modell, fünf Tool-Definitionen, aufgerufen aus einem Symfony-Controller. Es funktionierte wunderbar in der Sales-Demo und ungefähr in der Hälfte der Fälle in Produktion. Der Deal stockte, dann starb er.

Das ist die Gestalt, die agentische KI in B2B-SaaS 2026 angenommen hat. Jeder Käufer fragt nach Agenten. Die meisten Agenten-Features, die 2025 ausgeliefert wurden, fallen in ein schmales Band der Enttäuschung — zu ehrgeizig für einen deterministischen Workflow, nicht ausreichend gerüstet, um ein echtes autonomes System zu sein. Die Teams, die gerade still gewinnen, sind die mit einem nüchternen Framework, um zu entscheiden, wann ein Agent tatsächlich das richtige Werkzeug ist, wann eine langweilige State Machine gewinnt und wann der klügste Schritt ist, zu warten, bis das zugrunde liegende Tooling aufgeholt hat. Dieser Beitrag ist genau dieses Framework, mit konkreten Architekturmustern für einen Symfony-+-Next.js-Stack am Ende.

Was "agentisch" 2026 tatsächlich bedeutet

Die Branche hat sich grob auf eine Arbeitsdefinition geeinigt: Ein agentisches KI-System ist eines, in dem ein LLM dynamisch wählt, welche Tools es in welcher Reihenfolge aufruft, um ein Ziel zu erreichen, statt einer festen Pipeline, in der das LLM lediglich Slots in einem vorgeschriebenen Skript befüllt. Drei Eigenschaften trennen es von einer regulären LLM-Funktion.

Die Tool-Auswahl ist dynamisch — das Modell wählt bei jedem Schritt aus einem Menü von Tools, statt durch einen festen Call geroutet zu werden. Es gibt Iteration — das Modell erhält den Output eines Tools und entscheidet, was als Nächstes zu tun ist, oft über viele Turns hinweg. Und es gibt ein Ziel — keine einzelne Prompt-zu-Antwort-Transaktion, sondern eine mehrstufige Trajektorie, die auf ein Ergebnis zielt, das vorab vielleicht unmöglich zu skripten war.

Diese Definition ist wichtig, denn die Engineering-Arbeit für ein agentisches Feature unterscheidet sich dramatisch von einer Chat- oder Zusammenfassungsfunktion. Du brauchst ein Tool-Register mit Autorisierung, Budgets pro Trajektorie, Observability über mehrstufige Runs, Evaluations-Frameworks, die Trajektorien statt nur Outputs bewerten, und ein Security-Review jedes Tools, das der Agent aufrufen kann. Eines davon zu überspringen ist genau das, was 2025 die Welle öffentlicher Agenten-Fehlschläge hervorbrachte.

Das Build-, Buy- oder Wait-Entscheidungsframework

Für jedes Kandidaten-Feature auf der Roadmap bewertest du es über fünf Dimensionen. Die Zahlen sind bewusst grob — das Ziel ist eine vertretbare Entscheidung, keine Tabellenkalkulation.

Determinismus-Lücke. Könnte eine endliche State Machine, eine Regel-Engine oder ein Prompt mit strukturiertem Output das erledigen? Wenn ja, ist die Lücke klein und ein Agent ist überdimensioniert. Wenn der Eingaberaum und die erforderlichen Aktionen breit und unregelmäßig sind — offener Kundensupport, Recherche über mehrere Systeme, Code-Reparatur über einen Long-Tail von Repositories — ist die Lücke real.

Tool-Vielfalt. Wie viele Tools braucht der Workflow, mit wie viel Verzweigung? Unter fünf Tools und ein oder zwei Verzweigungen gewinnt handgeschriebener Code fast immer. Über zehn Tools mit bedingter Sequenzierung wird handgeschriebener Code zur Wartungslast, und das dynamische Dispatch eines Agenten verdient seinen Platz.

Nutzereinsatz. Was kostet eine falsche Aktion? Ein Agent, der ein Support-Ticket niedriger Priorität falsch routet, kostet nichts. Ein Agent, der eine Rückerstattung initiiert, einen Compliance-Bericht einreicht oder Produktionsdaten verändert, braucht ohnehin menschliche Freigabe-Gates, was meist bedeutet, dass die deterministische Variante die Anforderung schneller erfüllt.

Toleranz für Vendor-Lock-in. Eine Agenten-Plattform zu kaufen — LangChain Hub, LlamaIndex Cloud, die Plattform des Quartals — ist eine Kopplungsentscheidung. Wenn das Feature zentral für dein Produkt ist, ist jede Prompt-Vorlage, jede Eval-Suite und jede Tool-Definition, die du in die Runtime eines anderen legst, technische Schuld am Tag, an dem sie die Preise erhöhen oder den Kurs ändern.

Tooling-Reife. Ist die Eval-Infrastruktur für deine Domäne reif genug, dass du Regressionen erkennst, bevor es die Kunden tun? Für allgemeine Code-Generierung und Kundensupport ja. Für domänenspezifische Agenten in Healthcare, Recht oder allem Sicherheitskritischen sind die öffentlichen Eval-Frameworks 2026 noch dünn.

Die Entscheidungen mappen sauber. Eine hohe Determinismus-Lücke, niedriger oder moderater Einsatz und brauchbares Tooling für deine Domäne deuten auf Build — aber Build mit ordentlichem Gerüst (Tool-Register, Trajektorien-Observability, Evals in der CI) statt eines Controllers, der ein Frontier-Modell-SDK direkt importiert. Eine hohe Determinismus-Lücke mit unreifem Tooling deutet auf Wait — liefere die deterministische Variante aus, instrumentiere sie und lass die Daten dir sagen, wann der Agent die Kennzahl tatsächlich bewegt. Hoher Einsatz, unabhängig von der Lücke, bedeutet jetzt deterministisch bauen und später erneut prüfen, wenn die Ergonomie menschlicher Freigaben auf Agenten-Plattformen besser wird. Eine moderate Determinismus-Lücke mit häufigem Tool-Wechsel — viele Integrationen, die sich wöchentlich ändern — ist der seltene Fall, in dem Buy einer Agenten-Plattform einen Eigenbau wirklich schlägt, weil die Plattform den Integrationswechsel für dich absorbiert.

Wann agentische Workflows echten Mehrwert bringen

Die Fälle, in denen Agenten ihren Platz in Produktion verdienen, teilen ein Muster: Der Eingaberaum ist breit, der Aktionsraum ist breit, und die Kosten jeder einzelnen falschen Aktion sind begrenzt.

Kundensupport-Triage im großen Maßstab passt hierher. Ein First-Line-Agent, der ein Ticket lesen, die Wissensdatenbank abfragen, den Tarif des Kunden nachschlagen und entweder direkt lösen oder mit dem richtigen Kontext übergeben kann, kann einen routerförmigen deterministischen Flow übertreffen, sobald das Aktionsmenü ein paar Dutzend Optionen überschreitet. Recherche- und Synthese-Aufgaben passen ebenfalls — einen Markt untersuchen, Wettbewerbsinformationen sammeln oder eine Dokumentenprüfung zusammenstellen, bei der die nächste Suche davon abhängt, was die vorherige Suche zurückgab. Code-Generierung und -Reparatur, bei der das richtige Tool davon abhängt, wie der Code selbst aussieht, ist der kanonische Fall. Ebenso Long-Tail-Integrationsarbeit — ein neues System an deine Plattform anbinden, bei dem ein handgeschriebenes Mapping ein mehrwöchiges Projekt ist, ein Agent mit den richtigen Tool-Primitiven es aber an einem Nachmittag erledigt.

Der gemeinsame Faden ist, dass die Freiheit eines Agenten zu wählen Kosten umwandelt: Die Alternative ist ein Mensch, der dieselbe Arbeit macht, und die Kosten pro Trajektorie eines Frontier-Runs sind ein Bruchteil einer Stunde der Zeit dieses Menschen.

Wann ein deterministischer Workflow gewinnt

Überall, wo Vorhersehbarkeit das Produkt ist, gewinnt ein deterministischer Workflow. Dokumentklassifikation mit bekannter Taxonomie. Formularbefüllung mit festem Schema. Finanzberechnungen jeder Art. Alles, was ein Nutzer erneut ausführen und vernünftigerweise dieselbe Antwort erwarten könnte. Hochfrequente, margenarme Features, bei denen Kostenvorhersehbarkeit wichtiger ist als Spitzenqualität — Feature-Seiten, Onboarding-Helfer, In-Product-Hinweise — werden dramatisch besser von einem template-basierten RAG-Flow bedient als von einem mehrstufigen Agenten.

Das Muster: Wenn der Eingaberaum eng oder der Output strukturiert ist, ist die "Freiheit", die ein Agent bietet, nur ein Ort, an dem Halluzinationen und unnötige Tool-Calls wohnen. Ein sauberer Retrieval-Schritt plus ein Prompt mit strukturiertem Output kostet eine Größenordnung weniger, ist in einem Round-Trip fertig und wählt nie das falsche Tool, weil es kein Menü zur Auswahl gibt.

Ein nützlicher Bauchgefühl-Check, bevor du dich auf einen Agenten festlegst: Schreibe die deterministische Variante auf ein Whiteboard. Wenn sie passt, liefere sie aus. Die agentische Variante ist ein Kandidat für v2, sobald du echte Nutzungsdaten hast, die zeigen, wo die deterministische Variante versagt.

Wann es klüger ist zu warten

Die "Wait"-Entscheidung ist die am meisten unterschätzte und die mit dem höchsten Erwartungswert über die meisten B2B-SaaS-Roadmaps 2026.

Die Agenten-Landschaft 2025 hatte drei strukturelle Probleme, die 2026 nur teilweise behoben hat. Die Evaluation auf Trajektorienebene war grob — die meisten Teams lieferten Agenten bestenfalls mit Output-Level-Scoring aus und bemerkten nie, dass der Agent das Richtige aus den falschen Gründen tat. Die Sicherheitsmodelle für Tool-Nutzung waren dünn — Prompt-Injection durch Tool-Outputs ist heute eine gut dokumentierte Angriffsfläche, und die Patching-Leitlinien reifen noch. Und die Kosten waren unvorhersehbar — langlaufende Agenten konnten die Kosten pro Call um das 10- bis 50-Fache gegenüber einer deterministischen Baseline hochtreiben, auf Weisen, die erst sichtbar wurden, als der Produktionsverkehr eintraf.

Wenn deine Domäne noch keine reifen öffentlichen Eval-Frameworks hat, warte. Wenn deine Tools noch keine gehärteten Autorisierungsmodelle haben, die einschränken, was ein Agent im Namen eines Nutzers tun darf, warte. Wenn deine Runway eine fünffache Kostenüberschreitung in einem Quartal nicht verkraften kann, warte. "Wait" bedeutet nicht "nichts tun" — es bedeutet, die deterministische Variante auszuliefern, sie stark zu instrumentieren und die Daten dir sagen zu lassen, was wann aufzurüsten ist.

Architekturmuster für Symfony und Next.js

Wenn du dich entscheidest zu bauen, hat die Architektur drei strukturelle Teile. Sie sind bewusst langweilig. Der Agent selbst ist unvorhersehbar; alles um ihn herum muss vorhersehbar sein.

Tool-Register mit Autorisierung und Budgets

Jedes Tool, das der Agent aufrufen kann, geht durch ein Register. Das Register prüft, dass der Nutzer die Berechtigung hat, jedes Tool aufzurufen, dass das Tool pro Nutzer und Mandant ratenbegrenzt ist und dass der Agent sein Budget pro Trajektorie nicht überschritten hat.

// src/Service/Agent/ToolRegistry.php
final class ToolRegistry
{
    /** @param iterable<Tool> $tools */
    public function __construct(
        private readonly iterable $tools,
        private readonly Authorization $authz,
        private readonly TrajectoryBudget $budget,
        private readonly LoggerInterface $log,
    ) {}

    public function invoke(string $name, array $args, AgentContext $ctx): ToolResult
    {
        $tool = $this->resolve($name);
        $this->authz->assertCanInvoke($ctx->userId, $tool, $args);
        $this->budget->reserveStep($ctx->trajectoryId, $tool->costEstimate($args));

        $this->log->info('agent.tool.invoke', [
            'trajectory' => $ctx->trajectoryId,
            'tool' => $name,
            'user' => $ctx->userId,
        ]);

        return $tool->run($args, $ctx);
    }

    private function resolve(string $name): Tool
    {
        foreach ($this->tools as $t) {
            if ($t->name() === $name) return $t;
        }
        throw new UnknownToolException($name);
    }
}

Das Register ist der einzige Engpass für das Security-Review. Wenn ein Tool nicht registriert ist, kann der Agent es nicht aufrufen, Punkt. Wenn ein Nutzer nicht autorisiert ist, scheitert der Call, bevor er das Tool erreicht. Hier wohnt auch die Prompt-Injection-Minderung — jedes Tool, das nutzerbeeinflussten Text zurückgibt, erhält einen Wrapper, der Inhalte entfernt oder zitiert, die der Agent sonst als Anweisungen interpretieren könnte.

Trajektorien-Observability

Du kannst ein agentisches Feature nicht mit rohen LLM-Logs debuggen. Jede Trajektorie braucht eine einzige ID, die jeden Modell-Call, Tool-Call und jede Entscheidung im Run zusammenbindet. Propagiere sie durch den Handler-Kontext von Symfony Messenger, logge sie bei jedem Schritt und mache sie in der Next.js-UI für Support-Eskalation sichtbar.

// app/lib/agent-tracing.ts
export type TrajectoryStep =
  | { kind: 'model_call'; durationMs: number; tokensIn: number; tokensOut: number; costEur: number }
  | { kind: 'tool_call'; tool: string; durationMs: number; ok: boolean; costEur: number }
  | { kind: 'decision'; reasoning: string };

export type Trajectory = {
  id: string;
  startedAt: string;
  steps: TrajectoryStep[];
  totalCostEur: number;
};

Die Eval-Suite liest aus derselben Form. Trajektorien-Evals — einen Korpus repräsentativer Ziele durch den Agenten in der CI laufen lassen, die Trajektorie bewerten (welche Tools in welcher Reihenfolge mit welchem Ergebnis aufgerufen wurden) gegen ein Rubric und Deploys blockieren, die regressieren — sind das, was Teams, die Agenten ausliefern, von Teams trennt, die agentenförmige Bug-Fabriken ausliefern.

Serverseitige Ausführung, clientseitiges Streaming

Agenten gehören nicht in den Browser. Langlaufende, retry-anfällige, sicherheitssensible Workflows gehören auf den Server. Nutze Symfony Messenger (oder eine beliebige Postgres-gestützte Queue), um die Trajektorie auszuführen; streame inkrementelle Updates über Server-Sent Events an den Next.js-Client.

// src/Controller/Api/AgentController.php
#[Route('/api/agent/run', methods: ['POST'])]
public function run(Request $req, MessageBusInterface $bus): JsonResponse
{
    $trajectoryId = Uuid::v7()->toRfc4122();
    $bus->dispatch(new RunAgentTrajectory(
        trajectoryId: $trajectoryId,
        userId:       $this->getUser()->getUserIdentifier(),
        goal:         $req->getPayload()->getString('goal'),
    ));
    return $this->json(['trajectoryId' => $trajectoryId]);
}

#[Route('/api/agent/{id}/events', methods: ['GET'])]
public function events(string $id, TrajectoryStream $stream): StreamedResponse
{
    return new StreamedResponse(function () use ($id, $stream) {
        foreach ($stream->subscribe($id) as $event) {
            echo 'data: ' . json_encode($event) . "\n\n";
            flush();
        }
    }, 200, [
        'Content-Type' => 'text/event-stream',
        'Cache-Control' => 'no-cache',
        'X-Accel-Buffering' => 'no',
    ]);
}

// app/(app)/agent/[id]/page.tsx
'use client';
import { useEffect, useState } from 'react';
import type { TrajectoryStep } from '@/lib/agent-tracing';

export default function AgentTrajectory({ params }: { params: { id: string } }) {
  const [steps, setSteps] = useState<TrajectoryStep[]>([]);
  useEffect(() => {
    const es = new EventSource(`/api/agent/${params.id}/events`);
    es.onmessage = (e) => setSteps((s) => [...s, JSON.parse(e.data)]);
    return () => es.close();
  }, [params.id]);
  return <TrajectoryView steps={steps} />;
}

Die Form — Tool-Register plus Trajektorien-ID plus SSE-Streaming — ist das, was wir standardmäßig für jedes agentische Feature in einem Symfony-+-Next.js-Stack empfehlen. Sie läuft auf einer einzigen Hetzner-Box, skaliert linear mit Workern und gibt dir den Audit-Trail, den die Enterprise-Beschaffung heute erwartet. Ein fokussiertes Code-Quality-Audit einer bestehenden KI-Integration ist meist der schnellste Weg zu sehen, ob die aktuelle Implementierung in diese Form hineinwachsen kann oder neu gebaut werden muss.

Abschluss

Die nützlichste Frage, bevor man 2026 ein Agenten-Feature baut, ist nicht können wir? — fast jedes Team kann an einem Nachmittag ein Frontier-Modell und ein paar Tool-Definitionen verdrahten. Die nützlichen Fragen sind wird die Trajektorienform ein Enterprise-Audit überstehen, bleiben die Kosten unter echtem Verkehr begrenzt, und fängt die Eval-Suite eine Regression ab, bevor es ein Kunde tut? Teams, die diese drei Fragen beantworten können, liefern Agenten aus, die Deals abschließen. Teams, die es nicht können, liefern Demos aus, die ein Quartal später still zu Beschaffungsrisiken werden. Das Build-, Buy- oder Wait-Framework oben existiert, um diese Unterscheidung sichtbar zu machen, bevor der erste Commit landet.

Wolf-Tech hilft europäischen B2B-SaaS-Teams, agentische Features auf PHP/Symfony-Backends und Next.js-Frontends zu entwerfen und zu härten — Tool-Register, Trajektorien-Observability, Evaluations-Pipelines und das langweilige Gerüst, das eine Agenten-Demo in ein Custom-Software-Entwicklung-Ergebnis verwandelt, das in Produktion standhält. Kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io für eine kostenlose Beratung.