Zwei Agenten, eine Produktidee. Und plötzlich hatte ich eine JSON-Wand.

Der Use Case: Soll WunderKammer dieses Produkt weiterverfolgen?

WunderKammer ist meine fiktive Ideenmanufaktur für kreative Produkte und Spielwaren. Ich nutze sie, um mit realistischen Geschäftsprozessen, Daten und Agenten zu experimentieren.

In unserem Idea Lab landen neue Produktideen. Eine davon ist Build-a-Bot Junior, ein modularer Robotik-Baukasten, mit dem Kinder mechanische Konstruktionen ohne Elektronik zusammenbauen können.

Die Idee klingt zunächst vielversprechend. Sie passt zum strategischen Fokus auf kreative Lernprodukte, Familien und spielerisches Experimentieren.

In der SharePoint-Liste steht bereits die Empfehlung «Proceed with conditions».

Aber ist diese Empfehlung tatsächlich gerechtfertigt?

Es fehlen beispielsweise belastbare Informationen zu Herstellungskosten, Produktsicherheit und Marktnachfrage.

Nina, unsere fiktive Leiterin der Produktinnovation, möchte deshalb eine nachvollziehbare Bewertung. Der Agent soll die vorhandenen Informationen prüfen, fehlende Nachweise identifizieren und eine Empfehlung für die menschliche Entscheidung vorbereiten.

Wichtig ist dabei: Der Agent soll keine Produktfreigabe erteilen. Er soll eine bessere Entscheidung ermöglichen.

Experiment 1: Ein Copilot Studio Agent als Assistent für Nina

Für die erste Variante habe ich einen Agenten in Copilot Studio aufgebaut.

Er verwendet die SharePoint-Liste als Datenquelle, greift auf Strategie-, Portfolio- und Prozessdokumente zu und kann über einen Workflow den gewünschten Produkteintrag abrufen.

Nina kann ihm einen Auftrag in natürlicher Sprache geben. Beispielsweise, dass er Build-a-Bot Junior untersuchen und eine Empfehlung für den Human Review vorbereiten soll.

Der Agent analysiert daraufhin die Produktidee anhand der vorhandenen Wissensquellen.

Das Ergebnis fand ich fachlich überzeugend.

Er übernimmt die bestehende Empfehlung aus der SharePoint-Liste nicht einfach, sondern kommt zu einer anderen Einschätzung:

Needs more information.

Warum?

Weil die strategische Ausrichtung zwar gut passt, aber wichtige Nachweise fehlen. Unter anderem zur Produktsicherheit, zu Werkzeug- und Herstellungskosten, zur Nachfrage und zur Abgrenzung gegenüber bestehenden Produkten.

Der Agent erklärt diese Lücken, stellt konkrete Fragen und erstellt ein Briefing für die menschliche Prüfung.

Das Ganze ist verständlich formuliert. Nina kann damit direkt weiterarbeiten.

Ganz ohne Schwierigkeiten verlief die Umsetzung allerdings nicht. Frühere Workflow-Aufrufe schlugen mehrfach fehl. Erst nachdem ich den Abruf sauber über die numerische SharePoint-ID neu aufgebaut hatte, funktionierte der Workflow zuverlässig im Test.

Schon dieses Problem war lehrreich: Die fachliche Qualität einer Agentenantwort und die technische Zuverlässigkeit ihrer Werkzeuge sind zwei unterschiedliche Dinge.

Ein guter Agent braucht beides.

Experiment 2: Mein erster Hosted Agent in Microsoft Foundry

Für die zweite Variante wollte ich bewusst weitergehen.

Was passiert, wenn wir die Untersuchung nicht primär über Anweisungen und Tools steuern, sondern ihren Ablauf selbst programmieren?

Ich habe deshalb mit Claude Code einen eigenen Python-basierten Hosted Agent entwickelt und in Microsoft Foundry bereitgestellt.

Er heisst wk-product-investigation.

Anders als der Copilot Studio Agent ist er zunächst kein Gesprächspartner. Er ist eine spezialisierte Investigation Engine, die strukturierte Aufträge entgegennimmt.

Die Untersuchung umfasst vier Bereiche:

• Marktpotenzial: Gibt es glaubwürdige Hinweise auf Nachfrage und strategische Passung?
• Produktsicherheit: Welche Risiken bestehen und welche Sicherheitsnachweise fehlen?
• Herstellbarkeit: Sind Produktionsablauf, Materialien und Fertigung ausreichend geklärt?
• Wirtschaftlichkeit: Lassen sich Kosten, Margen und kommerzielle Tragfähigkeit belastbar bestimmen?

Interessant ist, dass nicht jeder dieser Bereiche einen Modellaufruf benötigt.

Die Markt- und Sicherheitsanalyse nutzen ein Sprachmodell. Die Prüfung bestimmter Produktions- und Wirtschaftlichkeitsdaten erfolgt regelbasiert. Anschliessend führt das Modell die Ergebnisse zusammen.

Für eine vollständige Untersuchung von Build-a-Bot Junior benötigte der Agent in unseren erfolgreichen Live-Tests drei GPT-4.1-Modellaufrufe.

Hinzu kommen feste Entscheidungskriterien, sogenannte Decision Gates. Wenn entscheidende Nachweise fehlen, darf die Empfehlung nicht einfach positiv ausfallen, nur weil das Sprachmodell die Idee überzeugend findet.

Dazu habe ich eine persistente Verarbeitung mit Azure Cosmos DB aufgebaut. Der Agent speichert Untersuchungsschritte, Ergebnisse und Ereignisse. Checkpoints und Schutzmechanismen sorgen dafür, dass die Ausführung kontrolliert bleibt und konkurrierende oder veraltete Schreibzugriffe abgefangen werden können.

Das war technisch eine ganz andere Aufgabe als der Aufbau des Copilot Studio Agenten.

Mein Coding-Partner: Claude Code

Eine Sache habe ich bisher noch gar nicht erwähnt: Meinen ersten Hosted Agent habe ich nicht allein programmiert. Ich habe ihn gemeinsam mit Claude Code entwickelt.

Ich habe den Use Case definiert, die Anforderungen an den Untersuchungsprozess festgelegt und entschieden, welche Kontrollmechanismen wir benötigen. Claude Code hat mich bei der technischen Umsetzung unterstützt: vom Python-Code über die Azure-Integration bis hin zu den Tests.

Dabei ging es keineswegs darum, einmal einen Prompt einzugeben und anschliessend einen fertigen Agenten zu bekommen.

Wir haben uns schrittweise durch Architekturentscheidungen, Berechtigungen, API-Aufrufe, Fehler und Tests gearbeitet. Immer wieder mussten wir nachschärfen, überprüfen und korrigieren.

Und manchmal haben wir uns auch ziemlich intensiv mit technischen Details beschäftigt, während eine wesentlich einfachere Frage noch unbeantwortet war: Wie soll Nina diesen Agenten am Ende eigentlich benutzen?

Die Antwort kam spätestens, als mein erster erfolgreicher Live-Aufruf eine riesige JSON-Antwort zurücklieferte.

Technisch korrekt. Für den Fachbereich trotzdem kaum brauchbar.

Also haben wir mit Claude Code auch noch eine kleine Weboberfläche entwickelt, die den tatsächlich in Azure laufenden Agenten aufruft und seine Ergebnisse verständlich darstellt.

Was ich daraus mitnehme: KI-gestützte Entwicklung kann enorm viel ermöglichen. Aber sie nimmt uns nicht die Verantwortung für Anforderungen, Architekturentscheidungen, Qualität und Benutzererlebnis ab.

Und genau deshalb ist für mich nicht nur spannend, was Claude Code bauen kann, sondern auch, wie wir solche Entwicklungen sinnvoll steuern.

Die Untersuchung funktioniert. Aber wo ist eigentlich mein Agent?

Ich öffnete den Foundry Playground und wollte zunächst einfach «Hi» schreiben.

Das funktionierte nicht.

Mein Hosted Agent verwendet das Invocations-Protokoll und erwartet strukturierte JSON-Befehle. Also musste ich ihm beispielsweise einen solchen Auftrag geben:

{
  "operation": "start",
  "idea_ids": ["WK-003"],
  "request_id": "wk003-live-demo",
  "wait_seconds": 60
}

Damit funktionierte es.

Der Agent startete die Untersuchung, rief die Modelle auf, prüfte die Entscheidungsregeln und speicherte das Ergebnis.

Die Empfehlung lautete:

needs_more_evidence

Die Untersuchung war abgeschlossen, die menschliche Freigabe stand noch aus.

Technisch war das ein Erfolg.

Nur sah ich anschliessend eine riesige JSON-Antwort mit Untersuchungsphasen, fehlenden Nachweisen, Risiken, Modellinformationen, Kennungen, Prüfregeln und Statuswerten.

Für einen Entwickler ist das sinnvoll. Für Nina aus dem Produktmanagement eher nicht.

Und an dieser Stelle wurde mir klar, dass ich zwar eine funktionierende Agentenarchitektur gebaut hatte, aber noch keine Lösung, mit der jemand gerne arbeitet.

Die letzte Meile: Aus der Investigation Engine wird eine nutzbare Anwendung

Ich wollte die funktionierende Architektur nicht nochmals umbauen.

Stattdessen haben wir eine kleine Weboberfläche entwickelt, die über einen lokalen Python-Server mit dem tatsächlich auf Azure gehosteten Agenten kommuniziert.

Die Oberfläche läuft auf meinem Mac. Der Agent, seine Orchestrierung, die Modellaufrufe und die Speicherung bleiben in Azure.

Damit konnte ich erstmals den kompletten Ablauf so nutzen, wie ich ihn mir für die Demo vorgestellt hatte.

Ich klicke auf «Investigate WK-003», bestätige den neuen Lauf und sehe, wie die einzelnen Untersuchungsbereiche abgearbeitet werden.

Anschliessend bekomme ich eine lesbare Zusammenfassung mit Empfehlung, offenen Nachweisen, Entscheidungsregeln und ausstehendem Human Review.

Wer sich für die technischen Details interessiert, kann weiterhin die rohe JSON-Antwort und den Audit-Verlauf öffnen.

Beim Test auf meinem eigenen Mac lief eine neue Untersuchung in rund 24 Sekunden durch.

Das war für mich der entscheidende Moment des Experiments.

Der Agent war vorher schon technisch funktionsfähig. Erst mit der Oberfläche wurde er auch praktisch bedienbar.

Das klingt selbstverständlich. Wenn man mitten in der Entwicklung steckt, kann genau diese Unterscheidung aber erstaunlich leicht untergehen.

Was die beiden Agenten wirklich unterscheidet

Nach diesem Experiment würde ich nicht sagen, dass Foundry grundsätzlich leistungsfähiger oder Copilot Studio grundsätzlich einfacher ist.

So pauschal wäre das schlicht falsch.

Unser Copilot Studio Agent ist vor allem auf die Zusammenarbeit mit Nina ausgelegt. Sie stellt Fragen, erhält eine verständliche Bewertung und kann die nächsten Schritte besprechen.

Unser Foundry Hosted Agent ist dagegen auf einen stärker kontrollierten Untersuchungsprozess ausgelegt. Wir haben die einzelnen Prüfschritte, Regeln, Datenhaltung und Wiederaufnahme selbst implementiert.

Damit erhalten wir zusätzliche Kontrolle. Gleichzeitig übernehmen wir deutlich mehr Entwicklungs- und Betriebsverantwortung.

Auch der Vergleich der Untersuchungsergebnisse braucht eine Einschränkung: Beide Agenten arbeiten in unserem Lab derzeit nicht mit exakt demselben Evidenzbestand. Sie untersuchen denselben grundsätzlichen Business Case, aber ihre Ergebnisse sind deshalb kein sauberer Qualitätsvergleich der beiden Plattformen.

Für mich liegt der Unterschied woanders.

Copilot Studio bringt mich bei diesem Use Case schneller zu einem Agenten, mit dem der Fachbereich arbeiten kann. In Foundry kann ich die Ausführung individueller gestalten, muss aber auch mehr von der Lösung selbst entwickeln.

Beides kann sinnvoll sein.

Entscheidend ist, welche Anforderungen tatsächlich bestehen.

Was ich aus diesem Lab mitnehme

Die wichtigste Erkenntnis betrifft für mich nicht das Sprachmodell und auch nicht die Anzahl der Agenten.

Sie betrifft die Architekturentscheidung.

Wir sprechen häufig darüber, was technisch möglich ist. Ob wir mehr Tools, komplexere Orchestrierung, eigene Modelle oder zusätzliche Azure-Dienste einsetzen können.

Dabei lohnt es sich, zuerst eine einfachere Frage zu stellen:

Was muss für den Menschen, der mit der Lösung arbeiten soll, tatsächlich besser werden?

Bei Nina ist das eine fundierte, nachvollziehbare Produktbewertung.

Wenn sie dafür hauptsächlich einen Gesprächspartner mit Zugriff auf SharePoint und definierte Werkzeuge benötigt, kann Copilot Studio eine sehr gute Wahl sein.

Wenn wir einen stärker kontrollierten Prozess mit eigener Ausführungslogik, persistenten Checkpoints, expliziten Entscheidungsregeln und einer unabhängig nutzbaren Schnittstelle benötigen, wird eine individuell entwickelte Architektur interessanter.

Und wenn Nina beides benötigt, kann eine Kombination der richtige Weg sein: eine nutzerfreundliche Agentenoberfläche und eine separat bereitgestellte Bewertungsfunktion.

Das ist allerdings eine Architekturentscheidung, keine automatische nächste Entwicklungsstufe.

Mein erster Hosted Agent hat mir ausserdem etwas sehr Praktisches gezeigt: Technische Korrektheit und Benutzerfreundlichkeit entstehen nicht automatisch zusammen.

Ein Agent kann sauber orchestrieren, korrekt speichern, seine Regeln einhalten und einen vollständigen Audit-Verlauf erzeugen.

Wenn am Ende niemand versteht, wie er ihn bedienen soll, fehlt trotzdem ein wesentlicher Teil der Lösung.

Wie es weitergeht

Die beiden Agenten funktionieren inzwischen. Der Foundry Hosted Agent läuft in Azure, und die Weboberfläche kann echte neue Untersuchungen starten und ihre Ergebnisse anzeigen.

Für das nächste Experiment fände ich es spannend, die Bewertungslogik über eine gemeinsame, gesicherte Schnittstelle sowohl aus Copilot Studio als auch aus einer eigenen Anwendung nutzbar zu machen.

Damit könnten wir untersuchen, wann eine hybride Architektur tatsächlich Mehrwert bringt und wann sie nur zusätzliche Komplexität erzeugt.

Bis dahin bleibt für mich die wichtigste Frage:

Nicht: Wie viel Agentenarchitektur können wir bauen? Sondern: Wie viel Agentenarchitektur braucht dieser Use Case wirklich?

Dieses Field Lab verwendet eine fiktive Organisation und Demo-Daten. Die Untersuchungen zur Produktsicherheit dienen ausschliesslich der Demonstration und ersetzen keine fachliche Sicherheitsprüfung oder Zertifizierung.