Nöie Rolle im Agentic Enterprise

Stell dir es Finanzteam vor, wo aafangt, Agenten yzsetze, zum de monatlech Abschluss z' beschlünige. De Agent cha Date us em ERP sammle, en Entwurf vom Kommentar mache und Usnahme markiere. S'Resultat: D'Zyt, wo s'Team bruucht, wird weniger. Aber denn chöme Froge, wo me nid erwartet het: Wer isch eigentlech verantwortlech, wenn de Agent es Konto falsch klassifiziert? Wer entscheidet, welli Verbesserige am Agent nägschti Wuche Priorität händ? Wer stellt sicher, dass de Agent nid uf Date zugryft, won er nid sött?

Söttigi Situatione gits hüt scho i vilne Firme. D'Gschäftsberych finde hüfig, Agent seig e Sach vo de IT. D'IT meint, Agent seig e "Feature", wo s'Gschäft bruucht. Risk und Compliance wärde erst ybezoge, wenns Bedenke git. Operations träit die tägliche Us- und Ywirkige, het aber kei Design-Mandat. S'Resultat isch vorhärsehbar: De Agent läbt zwüsche de Funktionne, aber ghört eigentlech niemerem würkli.

Das Problem wird nid eifach mit Technik glöst. Wenn d'Firma devo weg chunt, nume Copilot uszprobiere, und aafangt, Agenten als Teil vom tägliche Betrieb yzsetze, denn entstönd würkli nöii Job. Nid nume technischi, sondern au Job rund ums Design vo Workflow mit Agenten, d'Überwachig vo Output und Usnahme, s'Manage vo Risiko und Genehmigige, d'Kuration vo Wüsse und Gschäftsregle, und s'Manage vom Läbenszyklus vom Agent als operative Asset.

Die Veränderig passt zu dem, wo me hüt i vilne Organisatione gseht: De Mensch isch nümm nume de Nutzer vo AI, sondern wird immer meh zum Architekt, Überwacher, Verwalter und Manager vo digitale Arbeitschräfte. Wenn die Rolle nid explizit definiert werde, het d'Firma zwei Problem glychzytig: De Gschäftswert vom Agent wird nie würkli maximal, und s'operativ Risiko stigt, wills kei klari Verantwortig git.

Worum nöii Rolle nötig sind

Agentic AI wird hüfig falsch verstande als e nöii Wälle vo Automatisierig. Als ob, sobald de Agent da isch, d'Arbeit vom Mensch nume weniger wird. I de Praxis vom Enterprise passiert genau s'Gegenteil. Wenn Agenten aafönd, Intake, Triage, Entwürf, Routing, Monitoring oder begränzti Usfüehrig z'übernäh, denn bruucht d'Firma umso meh Disziplin rund um das, wo de Agent darf, wer d'Prioritäte für Verbesserige setzt, wer d'Qualität überwacht, wer verantwortlech isch, wenn de Agent en Fähler macht, und wer sicherstellt, dass de Gschäftskontext, wo de Agent bruucht, korrekt blibt.

Mit andere Wort: De Agent löscht nid s'Bedürfnis nach ere Organisation. De Agent veränderet d'Form vo däm Bedürfnis.

Solang de Agent nume en Pilot isch, cha d'Firma mit informelle Strukture überläbe. En Product Manager hilft es bitzeli. En Data Scientist verbesseret de Prompt. En Operations Lead git Input. En Architect hilft bi de Integration. Das cha no go. Aber sobald de Agent i Prozess wie Finance Close, Procurement Intake-to-PO, Customer Complaint Handling, IT Incident Triage, Supply Chain Exception Management oder Shared Services Case Handling yne chunt, isch er nümm en Experiment. Er wird Teil vom Arbeits-System. Und jede Teil vomene Enterprise-Arbeitssystem bruucht en Owner, Kontrolle, Metrike und en Rhythmus für Verbesserige. Wenn nid, fallt d'Verantwortig i d'Lücke zwüsche Business, IT, Risk und Operations.

Es git es paar dütlechi Zeiche, dass die nöie Rolle no nid guet definiert sind. De Agent wird im Betrieb bruucht, aber es git kei eine Business-Owner, wo d'Roadmap i de Hand het. S'Operationsteam beklagt sich hüfig über d'Qualität vom Output, aber s'Feedback landet nie i eme klare Backlog. Änderige am Prompt, am Modell oder am Tool werde vom technische Team gmacht, ohni usreichendi Domain-Review. Risk wird erst ybezoge, wenns en Vorfall oder e Audit-Frog git. D'Wissensbasis vom Agent isch voll mit veraltete Dokument, aber niemer fühlt sich verantwortlech, sie z' säubere. De menschlich Supervisor wird beitrait, "AI z'überwache", aber het kei SOP, kei Dashboard und kei Entscheidigsmandat.

I so eme Zuestand gseht d'Firma de Agent immer no als e technischi Schicht. Aber was würkli bruucht wird, isch es Design vom Operating Model. De hüfigste Fähler isch, die Rolle als informelli Zuesatzarbeit z'behandle: "De Manager vo de Operations luegt scho es bitzeli uf de Output vom Agent", oder "S'AI Platform Team macht das scho alles." Das hält im grosse Stil nid. Nöii Rolle im Agentic Enterprise müend wie anderi Rolle im Betrieb designet werde: mit eme Mandat, mit Entscheidige, wo si träffe dörfe, mit Metrike, mit Arbeits-Fore, und mit eme klare Bezug zu andere Funktionne.

Agent Product Owner: Besitzer vom Wert, nid nume vo de Feature

Die wichtigschti Role isch normalerwis de Agent Product Owner. Das isch d'Person, wo verantwortlech isch, dass de Agent würkliche Gschäftswert bringt, vo de Nutzer adoptiert wird, und sich no de Prioritäte vom Enterprise entwicklet. Wenn de Agent wie es Produkt behandlet wird, denn muss öpper d'Vision und d'Gschäftsziel defür ha, d'Roadmap für d'Entwicklig, d'Prioritäte vom Backlog, d'Metrike für Erfolg, und d'Entscheidige über Trade-offs zwüsche Gschwindigkeit, Qualität, Risiko und Adoption.

De Agent Product Owner isch nid nume en Projektkoordinator für AI. Er muss vier Hauptsache i de Hand ha. Erstens: D'Value Thesis. Er muess chönne beantworte, weles Gschäftsproblem de Agent löst, weli Outcome erwartet werde, und worum dä Use Case Priorität het. Es Bispil bi Finance Close: De Agent wird nid nume bout, zum "em Controller z'helfe", sondern zum d'Zyt fürs Beweismaterial-Sammle z'chürze, d'Exception Triage z'beschlünige, und d'Konsistänz vo de Kommentar-Entwürf z'verbessere. Es Bispil bi Procurement: De Agent isch nid nume en Chatbot für Intake, sondern es Tool, zum d'Cycle Time vo Aafroge z'sänke, d'Konformität vo de Sourcing-Wäg z'verbessere, und d'Nacharbeit vom Buyer z' reduziere.

Zweitens: D'Roadmap und de Backlog. De Agent wird sich immer verändere. Policy ändret sich, SOP ändret sich, Tool chöme derzue, Data Product werde besser, und nöii Failure Mode entstönd. Drum bruucht de Agent en Backlog wie jedes andere digitale Produkt: Qualitätsverbesserige, Uswytig vom Scope, Apassig vo Thresholds, Integration vo nöie Tool, Verbesserig vo de UX, und Stärkig vo de Kontrolle. Ohne en klare Backlog wird s'Feedback us de Operation nume zu Widerholte Beschwerde.

Drittens: Adoption und Operating Fit. En Agent, wo technisch guet isch, wird nid automatisch bruucht. De Product Owner muess sicherstelle, dass de Agent zum würkliche Arbeits-Rhythmus passt: Isch de Output bruuchbar? Isch d'Übergab a de Mensch klar? Wird de Supervisor nid mit z'viel Review belaschtet? Vertraue d'Nutzer uf d'Beweis, wo zeigt werde? Das isch mega wichtig, wil vil Agent nid am Modell scheitere, sondern wil s'tägliche Arbeits-Design nid passt.

Viertens: Läbenszyklus und Metrik-Besitz. De Agent Product Owner sött de Agent wie es Produkt mit eme Läbenszyklus behandle: Pilot, limitierti Production, Hochskalierig, Optimierig, oder Ruestand. Er muess au die relevante Metrike i de Hand ha, wie Adoption Rate, Acceptance Rate, Correction Rate, Escalation Rate, Cycle Time Impact, und Business Outcome pro Workflow.

De Agent Product Owner steit a de Chrüzig vo füf Wälte: Domain Business, Engineering/Platform, Data/Knowledge, Risk/Compliance, und d'operative Nutzer. Drum isch die Role selte geeignet für öpper, wo nume i eim Berich starch isch. En Product Owner, wo z'technisch isch, cha d'Sensitivität für Prozäss verlüre. Eine, wo z'operativ isch, cha Müeh ha, en technische Backlog z'füehre. Eine, wo z'sehr uf Compliance fokussiert isch, cha de Agent nie richtig bewegä. I de Praxis isch die Role am effektivste, wenn si vo öpperem bsetzt wird, wo de Gschäftsprozess tüf verstoot, gnueg Technikverständnis het, zum realistischi Prioritäte z'setze, und fähig isch, Veränderige über d'Funktionne z'füehre.

I chline Organisatione cha de Agent Product Owner vomene Process Owner oder Digital Product Manager mitgmacht werde. Das isch plausibel. Aber für Use Cases, wo über d'Funktionne gönd, a Chärnsysteme gränze, en mittlere bis höche Risk Tier händ, oder i grosse Volume bruucht werde, sött die Role kei Nämebijob si. Wenn d'Product Ownership schwach isch, passiert normalerwis das: D'Roadmap wird devo bestimmt, was eifach z'baue isch, nid was am meiste Wert bringt; d'Operation fühlt sich nid ghört; Risk chunt z' spaat; und de Agent entwicklet sich ohni konsistänte Richtig.

Agent Supervisor und Risk Owner: Produktivität söll nid uf Chöschte vom Vertraue go

Sobald de Agent aafangt, im Betrieb z'schaffe, bruucht d'Firma zwei Rolle, wo hüfig fälschlicherwis für glych ghalte werde, aber nid identisch sind: De Agent Supervisor und de Agent Risk Owner. Si müend sehr eng zäme schaffe, aber ihri Mandat sind nid glych.

Agent Supervisor: De täglich Überwacher vom Agent

De Agent Supervisor isch e operativi Role. Si Fokus isch nid s'strategische Design, sondern d'Leistig vom Agent vor Ort. Er isch verantwortlech für d'Überwachig vom Output, s'Handle vo Usnahme, s'Korrigiere vo falsohe Resultat, s'Gäbe vo strukturiertem Feedback, und s'Sicherstelle, dass de Agent no de tägliche SOP schafft. Wenn de Agent Product Owner d'Roadmap het, denn het de Agent Supervisor d'Realitätsprüefig us de Operation.

Bi Customer Operations prüeft de Supervisor, welli Fäll vom Agent guet behandlet worde sind, welli Refund-Empfehlige hüfig abglehnt werde, welli Muster vo Kund oder Produkt Fähler uslöse, und wänn de Agent z'aggressiv oder z'konservativ isch. Bi Finance Close überwacht de Supervisor oder Team Lead vo de Controllership, welli Kommentar-Entwürf am hüfigste gänderet werde, welli Usnahme nid richtig klassifiziert worde sind, welli Kontene oder Entitäte am hüfigste eskalieret werde, und ob de Agent würkli d'Lascht vom Team reduziert. Bi IT Operations überwacht de Supervisor, welli Incident falsch triagiert worde sind, welli Runbook-Empfehlige nid relevant sind, welli Alert Fatigue vom Agent verursacht wird, und wänn de Ingenieur muess übernäh.

De hüfigste Fähler isch, de Supervisor nume als "Mensch, wo d'AI-Resultat prüeft" z'gseh. Das isch z'eng und z'tüür. En effektive Supervisor muess Tool und es Mandat ha, zum Failure Mode z'markiere, Fählermuster z'gruppe, Änderige a de SOP oder Thresholds vorzschla, und Input in de Backlog vom Product Owner z'gäh. Das heisst, de Supervisor isch Teil vomene kontinuierleche Verbesserigs-Chreis, nid nume en Sicherheits-Zaun.

Wenn z'viel Output vom Agent vom Supervisor müend prüeft werde, isch d'Produktivität verlore. Wenn z'wenig Überwachig da isch, chönd Vertraue und Kontrolle sinke. Drum muess s'Design vo de Supervisor-Role a de Risk Tier vom Use Case, am Grad vo de Autonomie vom Agent, a de aktuelle Qualität vom Agent, und a de Kapazität vom Operationsteam aapasst werde. Für Use Cases mit tüfem Risiko cha e Stichprobeprüefig längä. Für Use Cases mit mittlerem Risiko isch e prüefig basierend uf Usnahme besser. Für Use Cases mit höchem Risiko chönd strengeri Genehmigige oder Ufsicht nötig si.

Agent Risk Owner: Besitzer vo de Vertrauensgränze

Andersch als de Supervisor het de Agent Risk Owner es Governance-Mandat. Er isch verantwortlech für d'Feschtlegig vom Risk Tier vom Agent, de minimale Kontrolle, wo nötig sind, de Genehmigigs-Threshold, d'Gränze vo de delegierte Befuegnis, d'Notwendigkeit vo Auditability, und d'Compliance-Aaforderige. Die Role isch mega wichtig, wil Agentic AI nid nume um Effizienz goht. Si berüert Date-Zuegriff, operativi Entscheidige, Handlige gegenüber Kund oder Transaktion, und mängisch au stark regulierti Berych.

De Risk Owner muess Froge beantworte wie: Darf dä Agent nume empfähle, oder darf er mit Genehmigig usfüehre? Welli Transaktion oder Handlig muess immer dur e menschlichi Kontrolle? Uf welli Date darf de Agent i wellem Kontext zuegriffe? Welli Beweis müend für d'Prüefig ufbhalte werde? Wänn isch en Vorfall vom Agent als material z'betrachte?

Es Bispil bi Procurement: De Risk Owner setzt fescht, dass de Agent en Entwurf für e Purchase Request mache darf, aber kei nöie Lieferant alege oder d'Due Diligence umgah darf. Es Bispil bi Finance: De Agent darf en Entwurf für d'Analyse und Empfählige vorbereite, aber materielli Buchhaltigs-Behandlige müend vom Mensch entschide werde. Es Bispil bi HR Services: De Agent darf allgemeini Policy-Froge beantworte, aber darf kei Entscheidige träffe, wo de Arbeitsstatus oder d'Entlöhnig beträffe, ohni vil strengeri Kontrolle.

Wenn d'Rolle vom Supervisor und Risk Owner ohni Disziplin zäme gleit werde, chönd zwei Sache passiere: D'Operation isch z'dominant und tribt d'Produktivität uf Chöschte vo de Kontrolle, oder s'Risiko isch z'dominant und de Agent wird nie autonom gnueg, zum Wert z'bringe. D'Trennig vo de Rolle hilft, s'Glychgwicht z'halte. De Supervisor bringt d'Realität vo de Produktivität. De Risk Owner bringt d'Disziplin vom Vertraue. Bidi müend i regelmässige Fore zäme cho, zum Bispil i wöchentleche Reviews für Fählermuster, i monatleche Reviews für Threshold-Änderige, und mit eme Sign-Off, wenn de Agent en höchere Autonomie-Grad überchunt.

Platform Engineer und Knowledge Curator: Technischi Basis und Gschäftskontext

Vili Organisatione fokussiere z'sehr uf Modell und Prompt, und vergässe, dass en Enterprise-Agent nume so guet isch wie d'Platform, wo druff lauft, und de Gschäftskontext, wo er verstoot. Drum sind die beide Rolle mega wichtig: De Agent Platform Engineer und de Knowledge Curator.

Agent Platform Engineer: En vertrauenswürdigi Usfüehrigsschicht baue

De Agent Platform Engineer isch verantwortlech für di technischi Basis, wo de Agent sicher, skalerbar und betriibbar macht. Sis Mandat umfasst normalerwis Runtime und Orchestrierig, Tool Registry und Tool Execution, IAM und Access Control, Observability und Tracing, Deployment Pipeline, Environment Management, Rollback und Release Control, und d'Integration i ERP, CRM, HRIS, ITSM und anderi Chärnsystem.

En Software Engineer für Applikatione cha Feature baue. Aber Agentic Systems bruuche zuesätzlichi Disziplin: Model Gateway, Policy Enforcement, Audit Trail, Permission-Aware Access, Verhaltens-Evaluierig, und Kontrolle vo Cost/Latency/Capacity. Drum muess de Platform Engineer für s'Agentic Enterprise d'Chrüzig zwüsche Cloud/Platform Engineering, Enterprise Integration, AI Runtime und Governance-Aaforderige verstoh.

Bi Shared Services stellt de Platform Engineer sicher, dass de Agent für AP Exception Handling nume Tool ufruefe darf, wo erlaubt sind, alli Tool-Ufrüef protokolliert werde, de Genehmigigs-Workflow verbunde isch, und Änderige a de Agent-Version chönd zrugggno werde, wenn d'Qualität sinkt. Bi IT Operations stellt er sicher, dass d'Agent-Remediation imene Sandbox oder korrekte Environment lauft, kei überflüssigi Credentials bruucht, und alli sensitive Handlige d'Policy-Prüefig durelaufe. Ohni die Role het d'Firma Agenten, wo gschyd usgseh, aber zerbrechlech sind, sobald si i Production gönd.

Knowledge Curator: Sicherstelle, dass de Agent s'Gschäft richtig verstoot

Wenn de Platform Engineer d'Maschine wartet, denn wartet de Knowledge Curator de "Inhalt vom Chopf" vom Agent. Die Role isch verantwortlech defür, dass d'Dokument, wo de Agent bruucht, relevant sind, dass d'SOP und Policy, wo i de Context-Landschaft ygspiiset werde, no gültig sind, dass d'Gschäftsregle guet dokumentiert sind, dass d'Metadate und d'Source-of-Truth klar sind, und dass veraltets oder widersprüchlichs Wüsse usegno wird.

Vili Fähler vo Enterprise-Agenten chöme nid vomene schwache Modell, sondern vomene schlächte Kontext. Alti Policy wird no mitgnoo, SOP sind nid konsischtent zwüsche Einheite, informelli Dokument vermische sich mit offizielle Regle, oder Gschäftsdefinitione sind nie standardisiert worde. I so eme Zuestand wird de Agent immer no mit Sälbstvertraue antworte, aber operativ falsch.

Bi Procurement stellt de Knowledge Curator sicher, dass di nöischt Policy für d'Kategorie vom Iichauf verfüegbar isch, dass d'Regle für d'Lieferante-Ufnahm nid mit alte Leitfäde vermischt sind, dass d'Template und SOP fürs Sourcing di richtige Metadate händ, und dass Dokument, wo ersetzt worde sind, nümm di wichtigschti Quelle für d'Retrieval sind. Bi Finance stellt er sicher, dass di gültigi Accounting Guidance d'Source-of-Truth isch, dass de Close Calendar und d'SOP für d'Usnahmebehandlig aktualisiert sind, dass di offizielle Kommentar-Template verfüegbar sind, und dass Begriff wie "material variance" oder "final close status" nid missverstande werde. Bi Customer Operations stellt er sicher, dass d'Refund Policy, d'Entitlement Rules und de Escalation Playbook synchron sind, dass Produkt-Bulletins, wo nümm aktiv sind, nümm bruucht werde, und dass Knowledge Articles, wo am hüfigste korrigiert werde, sofort verbesseret werde.

De Knowledge Curator muess nid us em Data-Team cho. Hüfig isch die Role besser mit eme Domain Expert bsetzt, wo d'Prozäss verstoot, wo weiss, weli Dokument offiziell sind und weli nume informelli Referenze, und wo mit em Platform- oder AI-Team chnapp zäme schaffe cha. De Trade-off isch klar: Wenn die Role z'technisch isch, wird d'Qualität vom Gschäftskontext schwach. Wenn si nume Domain-orientiert isch ohni Disziplin i Metadate und Läbenszyklus, wird d'Wissens-Schicht schnäll unordentlich. I reifere Organisatione schafft de Knowledge Curator hüfig mit Process Excellence, Data Product Owner, Compliance/Policy Owner und em Platform Team zäme.

En realistische Human-Agent-Organisation designe

Nachdem mer die Rolle verstoh händ, isch di nächscht Frog, wie me si i d'Organisationsstruktur ybaut. Es git kei ein Design, wo für alli passt. Aber es git es paar Prinzipie, wo recht konsischtent sind.

Erstens: De Besitz vom Wert sött im Business blibe. De Agent Product Owner sött nöch a de Gschäfts- oder Operationsfunktion si, wo de Wert überchunt. Wenn die Role ganz i d'IT zoge wird, wird de Agent eher es Technologie-Projekt, nid es Tool für Prozess-Transformation.

Zweitens: D'Runtime und di technische Kontrolle bruuche e gmeinsami Platform. De Agent Platform Engineer isch normalerwis effektiver, wenn er i eme zentrale Platform-Team oder in eme federierte Platform-Modell isch, nid wild pro Use Case verteilt. Das isch wichtig für d'Konsistänz vo IAM, Observability, Deployment und Governance.

Drittens: Di täglich Überwachig sött nöch a de Operation si. De Agent Supervisor muess i de Operations-Linie si, wil er d'Usnahme, d'Arbeitslascht und d'Realität vo de tägliche SOP verstoot.

Viertens: De Risk-Besitz sött formal si, nid nume berotend. Für Use Cases, wo Transaktion, Kund, sensibli Date oder regulierti Berych betreffe, darf de Risk Owner nid nume en ab und zue Review mache. Er muess es Entscheidigsmandat ha.

Fünftens: Wüsse dörf nid als Nämebijob betrachte werde. Wenn d'Knowledge Curation informell blibt, wird d'Qualität vom Agent still und heimlig sinke. Das isch eine vo de hüfigste Gründ, wiso en Agent am Aafang guet usgseht und denn bim Skalieren schlechter wird.

Firme, wo no am Aafang sind, müend nid sofort füf nöii Stelle schaffe. Wichtig isch, dass d'Funktion da isch. Zum Bispil i de Aafangsphase cha de Process Owner d'Rolle vom Agent Product Owner mitmache, de Team Lead vo de Operatione cha de Agent Supervisor si, en bestehende Control Owner cha de Agent Risk Owner übernäh, en Enterprise Platform Engineer cha sis Mandat erwitere, und en Subject Matter Expert cha de Knowledge Curator i Teilzyt si. Aber sobald de Agent über Einheite wegg bruucht wird, mehreri Chärnsystem berüert, en Backlog het, wo ständig wachst, oder d'operative KPI wesentlich beiiflusst, denn wird d'Formalisierig vo de Rolle wichtig.

Praktischi Implikatione

Nachdämmer das Thema verstoh händ, söttet ihr es paar Entscheidige hüt träffe. Erstens: Leged fescht, wer de Owner für jede Agent isch, wo scho i Production isch oder yne chunt. Lönd keine Agent ohni en klare Agent Product Owner läbe. Zweitens: Trennid di operativi Überwachig vom Risiko-Besitz. Leged fescht, wer de Agent Supervisor und wer de Agent Risk Owner für jede wichtige Use Case isch. Drittens: Entscheided über s'Modell für d'Platform und de Wissens-Besitz. Wird d'Runtime, s'IAM, d'Observability und s'Deployment vo ere gmeinsame Platform gstüürt? Wer kuratiert d'SOP, d'Policy und d'Gschäftsregle? Viertens: Definiered Metrike pro Role. De Product Owner het d'Value und d'Adoption. De Supervisor het d'Usnahme und d'Feedback-Qualität. De Risk Owner het d'Control Adherence. De Platform Engineer het d'Reliability und d'Operability. De Knowledge Curator het d'Frische und d'Vertrauenswürdigkeit vom Kontext. Fünftens: Entscheided, wänn informelli Rolle formalisiert werde sötted, zum Bispil wenn de Agent a Chärnsysteme gränzt, s'Transaktionsvolume stigt, oder de Grad vo de Autonomie zue nimmt.

Es git es paar Alarmzeiche, dass das Thema no nid bereit isch zum Skaliere. De Agent wird wytume bruucht, aber es git kei Name, wo me als Owner cha nenne. S'Operationsteam wird beitrait, de Agent z'überwache, aber het kei Dashboard, kei SOP und kei Zyt, wo defür reserviert isch. Risk chunt nume am Änd vom Projekt oder nach eme Vorfall. D'Wissensbasis vom Agent isch voll mit alte Dokument, und es git kei Kurations-Prozäss. D'Platform wird pro Use Case bout, so dass d'Zuegriffskontrolle, s'Logging und s'Deployment nid konsischtent sind. De Erfolg vom Agent wird nume ahand vo Demo oder Modell-Genauigkeit gmesse, nid ahand vo operative Outcome und Vertraue.

Wenn morn de Agent en feste Teil vo de Arbeitschraft vo öierer Firma wird, wüsseder scho, wer de Wert füehrt, wer d'Arbeit überwacht, wer s'Risiko i de Hand het, und wer de Gschäftskontext richtig haltet? Wenn d'Antwort no nid klar isch, denn isch öier Useforderig nümm d'Technik. D'Useforderig isch s'Design vo de Organisation.