Alle Notizen
21. Mai 202614 Min. Lesedauercopilot-studioai-agentsmicrosoft-365integrationengineering

Copilot Studio: die meisten Agent-Probleme sind Integrationsprobleme

Das Modell scheitert nicht zuerst. Die Oberfläche tut es. Auth, Tenant-Grounding, Latenz und Lizenz-Metering reiten alle auf dem Integration-Muster, das du gewählt hast, bevor du den Prompt-Editor überhaupt geöffnet hast.

Kernaussagen

  • Die Wahl der Oberfläche (iframe, selbstgehosteter Web Chat, BYOUI, S2S-Middleware, Direct Line, Teams) legt Auth-Modus, Grounding, Latenzbudget und Lizenzzähler fest, bevor du einen einzigen Prompt schreibst.
  • Der iframe-Embed rendert nur für No-Auth-Agents und verspielt Tenant Graph Grounding. Das ist ein Demo-Ziel, kein Produktions-Ziel.
  • Tenant Graph Grounding ist eine Eigenschaft des Client-Transports, nicht des Agent. Wählst du Direct Line, hast du volle Copilot Studio-Lizenzkosten für ein Feature gezahlt, das du nicht mehr erreichst.
  • Die 100-Sekunden-Turn-Decke ist die einzige Constraint, die nicht verhandelt. Jeder Middleware-Hop, jeder OBO-Exchange und jeder Payload-Scan zahlt Zinsen dagegen.
  • Für interne Mitarbeiter mit M365-Copilot-Lizenzen ist Teams sowohl die günstigste als auch die fähigste Oberfläche; weiche nur mit schriftlichem Grund ab.

In diesem Artikel

Copilot Studio: die meisten Agent-Probleme sind Integrationsprobleme

Das Muster ist vertraut. Ein Team liefert einen Copilot Studio-Agent in einen iframe im Intranet, sieht die Magic-Code-Login-Karte, sieht das SharePoint-Grounding verstummen und folgert: Der Agent ist „nicht schlau genug". Sie tunen den Prompt. Sie wechseln das Modell. Nichts wird besser. Sechs Wochen später liest jemand die Doku noch einmal und merkt, dass das iframe-Snippet nur rendert, wenn die Authentifizierung auf No authentication steht. Das „Agent-Qualität"-Problem war die ganze Zeit ein Integration-Problem. Ich habe diesen Bogen in einem Quartal dreimal gesehen, mit drei verschiedenen Teams, an drei verschiedenen Agents. Das Modell war in Ordnung. Die Oberfläche war falsch.

Dieses Stück handelt von der Oberflächenentscheidung: iframe, selbstgehosteter Web Chat, BYOUI, Server-to-Server-Middleware, Direct Line, native Mobile, Teams, Power Pages. Acht erstklassige Ziele in der offiziellen Channel-Taxonomie, jedes mit eigenem Auth-Modell, Grounding-Haltung, Latenzbudget und Lizenzzähler. Wähle eins und die nächsten vier Entscheidungen sind für dich schon getroffen.

Hier mein Gedanke: Das zugrundeliegende LLM ist der billigste, austauschbarste Teil eines Copilot Studio-Agent. Die Oberfläche ist der Teil, der nicht iteriert. Welches Embed-Muster du wählst, legt vier nachgelagerte Dinge fest: welche Auth-Modi du tatsächlich anbieten kannst, ob Tenant Graph Grounding überhaupt funktioniert, deinen Tail-Latency-Boden gegen eine harte 100-Sekunden-Turn-Decke und welchen Copilot-Credit-Meter du verbrennst. Ziehe später an einem von ihnen, und du tunest nicht, du baust neu. Die meisten „dieser Agent ist schlecht"-Tickets sind Oberflächen-Tickets in Verkleidung.

Ein Gegenargument läuft durch diesen ganzen Raum: Die Oberfläche ist bloß UI, wähl das Einfachste, iteriere. Ich löse es im Körper auf. Kurzfassung: Oberflächenwahl ist zugleich Auth-Wahl, Grounding-Wahl und Governance-Wahl, und diese drei iterieren nicht billig, sobald der Agent live ist und ein Security-Team ein Wire-Diagramm abgesegnet hat.

Warum die Oberflächenentscheidung dominiert

Die Reihenfolge zählt. Erst Oberfläche, dann Auth-Modus, dann Grounding, dann Latenzbudget, dann Lizenzzähler. Drehst du sie um, baust du zweimal.

Die Channel-Guidance oben listet acht Publish-Ziele. Interessant ist, was jedes davon leise vom Tisch nimmt. Das iframe-Embed-Snippet aus dem Copilot Studio-Maker verschwindet in dem Moment, in dem du in Publish to web channel „Authenticate with Microsoft" oder „Authenticate manually" einschaltest. Das ist kein UI-Bug. Das ist die Doku, die dir schwarz auf weiß sagt: Der einfache Embed ist der Demo-Embed.

Dasselbe Muster zeigt sich beim Grounding. Tenant Graph Grounding, das Feature, mit dem der Agent Antworten in den SharePoint-Daten und Microsoft-Graph-Connectors des angemeldeten Nutzers grundiert, ist nur freigeschaltet, wenn der Client den M365 Agents SDK Client nutzt. Direct Line kann das nicht. Der Microsoft-gehostete iframe kann das nicht. In dem Moment also, in dem du eine Direct-Line-basierte Oberfläche wählst, hast du volle Copilot Studio-Lizenz für ein Feature gezahlt, das du aus deinem UI nicht mehr erreichst.

Latenz funktioniert genauso. Jeder Copilot Studio-Agent läuft gegen eine 100-Sekunden-Turn-Decke, dokumentiert in Modify a flow to use with an agent und an die Oberfläche tretend als Fehlercode flowactiontimedout. Der Agent-Flow-Express-Modus ist Microsofts explizite Antwort auf Teams, denen das Budget ausgeht. Pack einen OBO-Hop, einen Payload-Scanner und ein langsameres Modell-Backend dazu, und du kannst dieses Budget verbrennen, ohne dass die Nutzerin Enter zweimal drücken muss.

Und Lizenzierung. Seit dem 01.09.2025 lautet der Zähler Copilot Credits, nicht Messages, laut Copilot Studio Billing Doc. Agents, die in Copilot Studio for Teams autoriert sind, verbrauchen keine Credits. Konsum durch M365-Copilot-lizenzierte Nutzer rechnet auch nicht gegen standalone-autorisierte Agents. Die günstigste Produktionsoberfläche im gesamten Katalog ist zugleich die mächtigste. Dazu kommen wir zurück.

Nicht „such dir eine Oberfläche und iteriere". Oberfläche IST Auth IST Grounding IST Budget IST Preis.

Die Auth-Oberfläche ist der Agent

Du hast keine Auth-Strategie. Du hast eine Oberfläche, und deine Oberfläche hat eine Auth-Strategie. Die beiden lassen sich nicht entkoppeln.

Nimm den iframe. Die Publish-to-web-channel-Doku zeigt das Embed-Snippet nur, wenn Auth auf No authentication steht. Nicht weil Microsoft vergessen hätte, den anderen Fall zu implementieren. Sondern weil die Kombination aus iframe-Origin (copilotstudio.microsoft.com) und Host-Page auf deinem eigenen Origin den Auth-Flow in einen Third-Party-Cookie-Kontext zwingt, den Safari ITP und Brave per Default blockieren und den Chrome schrittweise abschafft. Die Third-Party-Cookie-Guidance der Microsoft Identity Platform beschreibt genau, was bricht. Silent Token Acquisition stoppt. Der Frame versucht ein Popup. Conditional Access versucht die eingebettete App zu bewerten. Die Nutzerin bekommt eine Login-Karte in einem separaten Tab, und du bekommst ein Support-Ticket mit dem Betreff „Agent ist kaputt".

Wechselst du auf selbstgehostetes Web Chat mit dem Open-Source-Paket botframework-webchat, ändert sich die Auth-Story. Dein Origin besitzt die Cookies. Du brokerst das Token serverseitig über den Direct-Line-Authentication-Endpoint. SSO funktioniert, sobald die Nutzerin in Entra angemeldet ist. Die Magic-Code-Erfahrung, die im Feld als das meistgehasste Copilot Studio-UX-Problem rangiert, verschwindet. Die Minimalverkabelung passt in einen Block:

import { createDirectLine, renderWebChat } from 'botframework-webchat';

// Server-mint a short-lived token from the Direct Line secret.
// Never ship the secret to the browser.
const { token } = await fetch('/api/copilot/token', {
  method: 'POST',
  credentials: 'include',
}).then(r => r.json());

renderWebChat({
  directLine: createDirectLine({ token }),
  styleOptions: { /* your brand */ },
  userID: currentUser.entraOid,
  username: currentUser.displayName,
}, document.getElementById('chat'));

Gehst du BYOUI mit dem M365 Agents SDK Client, kollabiert die Entra-Story auf eine App-Registrierung, geteilt zwischen Agent und Client. Der Beitrag des Custom-Engine-Teams „You Probably Don't Need Manual Auth" ist der klarste Text dazu, warum das zählt: Silent SSO, keine Magic-Codes, Streaming für Copilot Studio-Agents an, Tenant Graph Grounding an. Der Preis: „Authenticate with Microsoft" wird Pflicht. Service-Principal-Tokens sind raus. Anonymer B2C-Traffic ist raus. Du kannst denselben BYOUI nicht für einen internen HR-Agent und ein öffentliches B2C-Portal nutzen.

Das ist der tragende Punkt. Dasselbe React-Chat-Panel, an zwei verschiedene Transports verdrahtet, gibt dir zwei verschiedene Governance-Haltungen. Es ist derselbe Code, derselbe Prompt, dieselbe Agent-Definition in Copilot Studio. Die Auth-und-Grounding-Oberfläche ist der Transport, den du unter dem React-Tree verdrahtet hast. Das ist nicht „nur UI".

💡 Tenant Graph Grounding ist keine Eigenschaft deines Agent. Es ist eine Eigenschaft des Clients, mit dem du ihn erreichst. Wählst du Direct Line, hast du volle Copilot Studio-Lizenzkosten für ein Feature gezahlt, an das du nicht mehr herankommst.

Tenant-Grounding ist eine Eigenschaft des Clients, nicht des Agent

Hier bricht das Gegenargument. „Wähl die einfachste Oberfläche und iteriere später" unterstellt, die Oberfläche sei eine austauschbare Hülle um dieselbe Agent-Fähigkeit. Ist sie nicht. Zwei Oberflächen, an denselben Copilot Studio-Agent verdrahtet, liefern zwei verschiedene Antwortqualitäten, weil Grounding auf der Transportschicht lebt.

Wenn wir den Agent über den M365 Agents SDK Client einbetten oder ihn in Teams, M365 Copilot oder Power Pages mit Entra-Auth konsumieren, grundiert der Agent in den SharePoint- und Microsoft-Graph-Daten des angemeldeten Nutzers, skopt durch dessen bestehende M365-Rollenrechte. Die M365-Copilot-Architekturübersicht beschreibt, wie die Nutzeridentität bis zum Retrieval durchgereicht wird. Bettest du denselben Agent über Direct Line ein, inklusive Default-WebChat-iframe und stock botframework-webchat, ist dieses Grounding weg. Der Agent fällt auf seine öffentlichen Wissensquellen und auf jede explizite Datenquelle zurück, die du in den Agent selbst verdrahtet hast, aber er konsultiert das SharePoint der Nutzerin nicht.

Warum das in der Praxis zählt: Der typische Grund, weshalb ein Unternehmen Copilot Studio überhaupt bezahlt, ist die SharePoint-und-Graph-Grounding-Story. Wir haben den Scheck in der Erwartung geschrieben, „frag den Agent nach dem Q3-OKR-Dokument, und er liest es". Verdrahte denselben Agent in einen Direct-Line-iframe auf einer Portalseite, und die Demo scheitert an der ersten Frage. Das Modell ist in Ordnung. Der Prompt ist in Ordnung. Der Agent erreicht die richtigen Tools. Die Nutzerin ist nur nicht so authentifiziert, dass die Retrieval-Schicht sie sieht.

Das Gegenargument unterstellt zudem, wir könnten die Oberfläche billig wechseln, sobald wir das Problem sehen. Können wir nicht. Die Auth-Verkabelung umfasst eine Entra-App-Registrierung, eine OAuth-Verbindung in Copilot Studio, Redirect-URIs, die zwischen Umgebungen passen müssen, und, wenn du OBO nutzt, einen Custom-Connector-OBO-Flow mit delegierten Berechtigungen und Key-Vault-Secrets. Jeder dieser Punkte ist ein Ticket. Jeder davon zieht mindestens eine Person aus deinem Team raus. Ich habe ein „lass uns von iframe auf SDK Client wechseln"-Projekt sechs Wochen dauern sehen, was wie ein Refactor an einem Tag aussah, weil die Entra-App-Registrierung einer anderen Org gehörte und der Redirect-URI-Wechsel Conditional Access berührte.

Das ist auch, warum ich immer wieder auf die Linie aus Die Identität deines Agent ist eine Postgres-Rolle zurückkomme. Die effektiven Berechtigungen des Agent sind nicht im Agent deklariert. Sie sind aus der Identität geerbt, die die Oberfläche präsentiert. Ändere die Oberfläche, ändere die Identität, ändere das Berechtigungsset, ändere die Antwort.

Latenz, Timeouts und die 100-Sekunden-Wand

Jeder zusätzliche Hop zahlt Zinsen gegen eine harte Decke. Die 100-Sekunden-Turn-Grenze verhandelt nicht, und die Optimierungs-Geschichten sind real, aber klein.

Der Guide Optimize agents to minimize latency nennt konkrete Zahlen, die hängenbleiben. Eine riesige Wissensquelle in fokussierte Quellen mit Metadatenfiltern zu splitten ließ Retrieval von 8 Sekunden auf unter 2 fallen. Ein 6.000-Token-System-Prompt auf 1.200 Token zu kürzen sparte 3 Sekunden pro Turn. Ein Fertigungskunde verteilte 30.000 Handbücher auf 12 produktspezifische Wissensquellen und halbierte Retrieval-Latenz ungefähr. Das sind nützliche Gewinne. End-to-End liegen sie aber in der Größenordnung von 5 bis 10 Sekunden. Sie kaufen dir keinen freien OBO-Middleware-Hop.

Vergleiche Hop-Zahlen grob. Der iframe ist Browser zu Microsoft-gehostetem Web Chat zu Agent: zwei Hops. BYOUI über den M365 Agents SDK Client ist Browser zu SDK zu Agent: zwei Hops, mit Streaming. Server-to-Server-Middleware mit PII-Redaction ist Browser zu deiner API zu OBO-Exchange zu Direct Line oder SDK zu Agent: mindestens vier Hops, mehr wenn du Payloads in beide Richtungen scannst. Direct Line für Nicht-UI-Server-Caller hat eine eigene Steuer: Es gibt kein End-of-Response-Signal, sodass ein Server-Caller den get activities-Endpoint pollen und selbst entscheiden muss, wann der Agent fertig ist, wie die Direct Line API 3.0 Reference schmerzhaft klarmacht. Community-Berichte tippen Direct Line zudem auf rund 2 Requests pro Sekunde, jenseits derer 429s mit Retry-After eintreffen.

Eine Praxisskizze. Interner Customer-Support-Agent. Authentifizierte Mitarbeiter im Firmennetz. SharePoint-Grounding nötig. 30 Sekunden durchschnittliches Retrieval, 10 Sekunden durchschnittliches Reasoning, 3 Sekunden UI-Render. Das sind 43 Sekunden Median, mit dickem Schwanz. Jetzt wickelst du das in eine Middleware ein, die einen LLM-basierten PII-Classifier auf jede ein- und ausgehende Nachricht laufen lässt. Der Classifier braucht im Schnitt 4 Sekunden. Pack einen 1-Sekunden-OBO-Exchange auf kalte Turns dazu. Plötzlich liegt p95 bei 70 Sekunden, und dein p99 trifft die Wand. Das Modell hat sich nicht verändert. Du hast zwei Hops dazugepackt.

Eine vernünftige Daumenregel für Copilot Studio: Halte den Middleware-Pfad bei p95 unter 90 Sekunden gegen die 100-Sekunden-Hartdecke, lass dem Agent selbst 10 Sekunden Slack. Nutzt der Agent verbundene Modelle mit langsameren Antwortprofilen, schrumpft die Reserve weiter: Ein Teilnehmer einer aktuellen Microsoft-Session zur Copilot-Studio-Integration merkte an, dass Anthropic-basierte Agents die Decke häufiger treffen, und der Vortragende widersprach nicht. Autonome Agents sehen, anders als oft angenommen, dieselbe Decke wie konversationale.

Das ist auch, warum ich in Temperatur Null wird dich nicht retten argumentierte, dass die Pass-Bedingung für einen Agent eine Verteilung sein muss, keine einzelne Zahl. Tail-Latenz ist der Teil, der Verträge bricht, und Tails sind inhärent verteilungsbasiert.

Eine durchgespielte Entscheidung: ein regulierter interner HR-Agent

Konkreter Fall. Ein Finanzdienstleister will einen internen HR-Agent auf einem SharePoint-Portal. Nur Mitarbeiter, alle auf Entra. Muss in SharePoint-Policy-Dokumenten grounden. Legal verlangt, dass jede eingehende Nachricht auf PII gescannt wird, bevor sie das LLM erreicht, und jede ausgehende Nachricht erneut, bevor sie die Nutzerin erreicht. Logging in ein SIEM. SOC-2 im Scope.

Geh die Oberflächen durch:

| Oberfläche | Auth | Grounding | Middleware | Verdikt | |---|---|---|---|---| | iframe-Embed | Nur No-Auth | Keines | Unmöglich | Raus. Scheitert SOC-2. | | Selbstgehostetes Web Chat + Direct Line | Entra SSO | Kein Tenant Graph | An deinem Origin möglich | Möglich, verliert Grounding. | | BYOUI + M365 Agents SDK Client | Entra SSO | Ja | An deinem Origin möglich | Starker Kandidat. | | BYOUI + Direct Line | Entra SSO + SP | Kein Tenant Graph | Ja | Verliert Grounding. | | Server-to-Server-Middleware (S2S) | Entra App Identity | Nur über SDK-Pfad | Dafür gemacht | Bester Fit für die Redaction. | | Teams + M365 Copilot | Zero-Config SSO | Ja, gratis | Keine Middleware-Naht | Günstigste, aber keine PII-Redaction. | | Power Pages | Alle Modi + Web Roles | Ja für Entra-Nutzer | Begrenzt | Falsches Publikum: Mitarbeiter, keine Portalnutzer. |

Die Wahl, die diese Tabelle überlebt, ist S2S mit der kommenden M365-Agents-SDK-Client-App-Only-Auth, beschrieben in derselben Microsoft-Session oben. Der Agent wird mit einer Entra-App-Registrierung geteilt, die die Applikationsberechtigung CopilotStudio.Copilot.Invoke hält, ein Admin gibt Consent, und deine Middleware authentifiziert per OAuth2 Client Credentials. Nutzer authentifizieren sich bei deinem Portal in Entra. Deine Middleware sieht ihre Identität, fährt PII-Redaction in beide Richtungen und präsentiert Copilot Studio eine App-Identität. Conditional Access greift weiterhin für die App-Identität. Sign-in-Monitoring funktioniert weiter. Du kannst die Middleware per IP-Allowlist freigeben, sodass nur dein Server den Agent aufruft.

Das Eine, was diese Architektur heute nicht kann, ist Tenant Graph Grounding skopt auf den aufrufenden Nutzer, weil der SDK Client mit einer App-Identität statt eines delegierten Nutzer-Tokens läuft. Für einen HR-Agent, der in tenant-weiten Policy-Dokumenten grundiert, die alle lesen dürfen, ist das in Ordnung: Der Agent liest aus einer bekannten SharePoint-Site, nicht aus dem persönlichen Graph der aufrufenden Nutzerin. Für einen Agent, der im Postfach oder OneDrive der Nutzerin grounden muss, ist S2S mit App-Identität das falsche Werkzeug. Dieser Fall erzwingt einen harten Tradeoff: Entweder akzeptieren wir, dass persönliches Graph-Grounding mit strenger Middleware-Redaction nicht vereinbar ist und wählen eines, oder wir verschieben Redaction in den Agent selbst hinter ein dediziertes Guardrail-Modell und dokumentieren eine kompensierende Kontrolle für die SOC-2-Prüferin. Eine saubere dritte Option gibt es heute nicht.

Würde dieselbe Org stattdessen einen öffentlichen kundennahen Agent auf einem Marketingportal verlangen, kippt jeder Teil dieser Analyse. Anonymer Traffic killt den M365 Agents SDK Client. PII-Redaction bleibt. Die Antwort wird Direct Line hinter deiner eigenen Middleware, mit dem Verlust von Tenant Graph Grounding, weil es keine angemeldete Nutzerin gibt, für die zu grounden wäre. Gleicher Agent, andere Oberfläche, andere Architektur.

Wie du das anwendest

Fünf Regeln, die über die Oberflächen halten, die ich genutzt habe.

  1. Entscheide die Oberfläche vor dem Prompt. Auth-Modus, Grounding, Latenzbudget, Lizenzzähler. Sind diese vier festgepinnt, ist Prompt-Iteration der billige Teil. Diese Reihenfolge zu drehen ist der häufigste Fehlermodus.

  2. Behandle den iframe-Embed als Demo-Werkzeug, nicht als Produktionsziel. Die Kombination aus No-Auth-only-Embed-Snippets, Third-Party-Cookie-Blockierung und fehlendem Tenant Graph Grounding macht ihn strukturell ungeeignet für alles, was Tenant-Daten trägt. Nutze ihn für Marketing-Chatbots, nutze ihn, um den Agent einem Sponsor zu zeigen, nutze ihn nicht für den eigentlichen Rollout.

  3. Greif nach selbstgehostetem Web Chat, bevor du nach BYOUI greifst. Das Open-Source-Paket botframework-webchat absorbiert rund 80 % dessen, wofür die meisten Teams ein voll Custom-UI zu brauchen glauben. styleOptions deckt die Marke ab. Event-Listener lassen es in ServiceNow- oder SharePoint-Seiten verdrahten. BYOUI ist die richtige Antwort, wenn du Tool-Call-Internals an die Oberfläche bringen oder den Agent in ein bestehendes Chat-Framework falten musst. Es ist die falsche Antwort, wenn du nur andere Farben willst.

  4. Für regulierte Middleware: entwirf um die 100-Sekunden-Wand, nicht um das Modell. Hop-Budget, OBO-Token-Lebenszeiten, Poll-Latenz auf Direct Line, End-of-Response-Erkennung. Das Modell ist der Teil, der alle sechs Monate billiger wird. Die Wand nicht.

  5. Für interne Mitarbeiter mit M365-Copilot-Lizenz: per Default auf Teams, außer du hast einen schriftlichen Gegengrund. Zero-Config SSO, Tenant Graph Grounding per Default an, freundliche Copilot-Credit-Behandlung, Governance über das Admin Center. Die meisten „wir brauchen ein Custom-UI"-Anforderungen überleben den Kontakt mit einer gut entworfenen Teams-App-Karte nicht, und die, die ihn überleben, sind meist Marketing-Anforderungen, keine Engineering-Anforderungen. Die breitere Version habe ich in Microsoft 365 liefert Agent-Inventar, keine Observability argumentiert: Die Governance-Oberfläche ist real, die Observability-Oberfläche fehlt, aber die Publishing-Oberfläche ist exzellent.

Offene Fragen

Ich erwarte, dass Teile davon schlecht altern. Die Stellen, an denen ich am wenigsten sicher bin:

Der oben beschriebene S2S-App-Identity-Flow rollt noch aus. Ich habe gegen den bestehenden Direct-Line-App-Token-Flow gebaut, aber die volle M365-Agents-SDK-Client-Variante mit CopilotStudio.Copilot.Invoke als Applikationsberechtigung kommt erst, laut der Microsoft-Session oben. Bis du das liest, kann die Doku existieren, der Berechtigungsname geändert sein oder die Sharing-Erfahrung noch keine App-ID auswählen lassen. Gegenprüfen, bevor du eine Architektur festlegst.

Ich habe den Power-Pages-Embed für gemischte anonym-plus-authentifiziert-Publika zu wenig getestet. Der Microsoft-Blogbeitrag zur Integration behauptet, Power Pages unterstütze alle Copilot Studio-Auth-Modi einschließlich No-Auth, was ihn zum stärksten Kandidaten für Portale macht, die beides brauchen. Ich habe nicht stresstet, ob Web-Role-Gating sauber mit Tenant Graph Grounding komponiert, wenn die Nutzerin per Entra angemeldet ist. Wenn du das hast, will ich davon hören.

Ich bin unsicher, wie lange Direct Line erstklassige Option bleibt. Die Bahn von Microsofts M365 Agents SDK legt nahe, dass der SDK Client der Langzeitpfad für alles außer Service-Principal- und B2C-Fällen ist. Wird Direct Line in 18 Monaten deprecated, wird jedes „S2S über Direct Line"-Muster, das heute existiert, zur Migrationsschuld. Ich würde nicht dagegen wetten.

Und ich bin mit der Observability-Story über diese Oberflächen weiter unzufrieden. Der Optimize-Agents-Guide gibt dir die Hebel. Er gibt dir keine Per-Turn-Traces mit hop-genauer Latenzzuordnung. Wenn du das gebaut hast, auch schlecht, will ich das Schema sehen. Die Linie aus Modelle werten ab, Eval-Suites zinsen gilt auch hier: Die Suite, die den Agent beobachtet, ist das langlebige Asset. Die Oberfläche ist es nicht.

Falls du gerade in einer Version davon steckst: Ich arbeite mit Teams, die produktive KI-Systeme gegen solche Probleme ausliefern, und Oberflächen-Achsen-Entscheidungen sind die häufigste Stelle, an der ich sie festhängen sehe. Schreib mir. Hast du bereits einen Copilot Studio-Agent in eine dieser Oberflächen ausgeliefert, will ich davon besonders gern hören; der schnellste Weg, mein Denken zu aktualisieren, ist ein konkretes Gegenbeispiel mit Wire-Diagramm.