Verwaltete Agent-Runs

Mit verwalteten Agent-Runs starten Sie autonome KI-Agenten direkt aus Archyl heraus. Geben Sie ihnen eine Aufgabe, wählen Sie das Profil, das ihr Verhalten festlegt, verbinden Sie sie über MCP-Konnektoren mit externen Diensten, legen Sie einen wiederkehrenden Zeitplan fest und lassen Sie sie mit vollem Architekturkontext an Ihrer Codebasis arbeiten.

Öffnen Sie in der Seitenleiste Agent Hub → Ausführungen, um Ihre Runs zu verwalten, Agent Hub → Profile, um das Verhalten der Agenten festzulegen, oder Agent Hub → Zeitpläne für wiederkehrende Automatisierung.

Überblick

Ein verwalteter Run ist eine einzelne Agenten-Ausführung. Der Agent:

1. Klont das Repository Ihres Projekts in einen frischen Arbeitsbereich auf dem Agent-Worker
2. Erhält Ihren Architekturkontext (C4-Modell, ADRs, Konformitätsregeln, API-Verträge, Technologie-Stack) sowie das Briefing seiner Arbeitssession: die Elemente, die die Aufgabe berührt, was frühere Sessions über sie gelernt haben, und das Preflight-Ergebnis
3. Führt die von Ihnen definierte Aufgabe aus, ruft Tools auf und trifft Entscheidungen innerhalb der Grenzen seines Profils
4. Veröffentlicht seine Codeänderungen als Pull Request und berichtet mit einer vollständigen Aufzeichnung aller Aktionen zurück

Runs können manuell (einmalig) oder automatisch über Zeitpläne ausgelöst werden.

Einen Run starten

1. Gehen Sie zu Agent Hub → Ausführungen
2. Wählen Sie Ihr Projekt aus dem Dropdown-Menü
3. Klicken Sie auf Neue Ausführung
4. Wählen Sie ein Profil
5. Schreiben Sie eine Aufgabenbeschreibung (z. B. "Prüfe veraltete Abhängigkeiten und erstelle eine Zusammenfassung")
6. Fügen Sie optional Konnektoren hinzu (siehe unten)
7. Klicken Sie auf Ausführung starten

Der Agent beginnt sofort mit der Arbeit. Den Fortschritt verfolgen Sie in Echtzeit auf der Run-Detailseite.

Agentenprofile

Ein Profil ist eine wiederverwendbare Definition dafür, wie sich ein Agent verhält. Jeder Run und jeder Zeitplan verwendet eines. Beim ersten Besuch legt Archyl für Ihre Organisation das Profil backend-fixer an; weitere erstellen Sie unter Agent Hub → Profile.

Wenn Sie ein Profil löschen, bleibt der Verlauf seiner Runs erhalten. Zeitpläne, die es verwendet haben, werden pausiert und als Profil gelöscht markiert; wählen Sie im Zeitplan ein anderes Profil, um ihn fortzusetzen.

Skills

Skills sind Playbooks, die Archyl pflegt und laufend an die Tools anpasst, die Agenten tatsächlich zur Verfügung stehen. Aktivieren Sie sie pro Profil, statt Anweisungen in den Prompt zu kopieren.

Ein Profil mit einem unbekannten Skill oder einem ungültigen Muster für erlaubte Tools wird beim Speichern abgelehnt.

Das Standardprofil backend-fixer aktiviert Architecture memory, Conformance first und Decision records.

Run-Detailseite

Jeder Run hat eine Detailseite mit folgenden Informationen:

Der Ereignis-Feed zeigt aufklappbare Karten für jede Aktion:

• Tool-Aufrufe — Zeigt den Tool-Namen, Eingabeparameter und Ausgabe. Jede Karte trägt ein Quell-Label, das angibt, von welchem Konnektor das Tool stammt (z. B. github, archyl, linear).
• Nachrichten — Die Überlegungen und Entscheidungen des Agenten.
• Ergebnis — Das Resultat, der Token-Verbrauch, der Pull Request und die Dateien, die der Agent geändert hat.
• Fehler — Hervorgehoben für schnelle Identifikation.

Einen laufenden Agenten steuern

Solange ein Run läuft, können Sie im Steuerungsfeld eine Nachricht eingeben, um den Agenten umzulenken, ohne ihn abzubrechen ("Migration überspringen, konzentriere dich auf den Handler"). Die Nachricht wird sofort eingereiht und beim nächsten Schritt in die Konversation des Agenten eingespielt; sobald der Agent sie erhalten hat, zeigt der Feed Steuerungsnachricht an den Agenten zugestellt an.

Wenn ein Run vorzeitig stoppt

Scheitert ein Run, erreicht er sein Kosten- oder Zeitlimit oder sind seine Iterationen aufgebraucht, geht die bereits geleistete Arbeit nicht verloren: Archyl veröffentlicht sie in einem Pull Request als Entwurf, der erklärt, warum der Run gestoppt hat. Siehe Pull Request weiter unten. Ein Run, den Sie abbrechen, veröffentlicht nichts.

Zuverlässigkeitsgarantien

• Ausgefallene Worker werden erkannt. Der Agent-Worker meldet sich alle 10 Sekunden. Ein Run, dessen Worker seit 3 Minuten schweigt oder der 10 Minuten nach seinem Zeitlimit noch läuft, wird automatisch als failed markiert und gibt seinen Slot frei.
• Hängende Runs blockieren keine Slots. Ein Run, den innerhalb von 10 Minuten kein Agent-Worker übernommen hat, scheitert, ebenso ein Run, der mehr als 1 Stunde und 10 Minuten auf die Antwort eines Menschen gewartet hat.
• Zugangsdaten überdauern keinen Run. Jeder Run erhält einen eigenen, kurzlebigen Archyl-API-Schlüssel, der widerrufen wird, sobald der Run endet.
• Ein Abbruch erreicht den Agenten. Ein abgebrochener Run stoppt bei seiner nächsten Rückmeldung, auch wenn die direkte Stopp-Anfrage den Worker nie erreicht hat.

Arbeitssitzungen und Koordination

Jeder Run läuft in einer Archyl-Arbeitssitzung, dem Protokoll, das der Archyl Harness lokalen Coding-Agenten bereitstellt. Die Plattform öffnet und schließt die Sitzung; der Agent verwaltet sie nie selbst.

Die Arbeitssitzung eines Runs

Wenn ein Run startet, öffnet Archyl eine Sitzung auf den Architekturelementen, die die Aufgabe berührt. Archyl nimmt Leases auf diese Elemente, ermittelt das Urteil des Preflight-Gates (allow, warn oder deny) und legt die relevanten Entscheidungen, Leitplanken und Gedächtniseinträge in das Briefing des Agenten. Das Urteil erscheint im Ereignis-Feed als Event Prüfung.

Arbeit anderer Agenten berücksichtigen

Arbeit anderer Agenten berücksichtigen ist eine Profileinstellung unter Koordination und standardmäßig deaktiviert. Ist sie aktiv, wird die Sitzung exklusiv geöffnet:

• Jemand anderes hält die Elemente. Hält ein anderer Agent einen Lease auf dieselben Elemente, sei es ein Coding-Agent wie Claude Code oder ein anderer verwalteter Run, wird der Run abgelehnt. Die Begründung nennt, wer dort arbeitet.
• Das Gate warnt nur, etwa weil eine Leitplanke der Stufe Error greift. Der Run wartet dann im Status Wartet auf Freigabe und belegt keinen Slot. Die Run-Seite zeigt die Gründe, zusammen mit Freigeben und starten und Ausführung abbrechen.

Beim Freigeben wird das Gate erneut geprüft: Ein Konflikt, der inzwischen entstanden ist, führt trotzdem zur Ablehnung des Runs. Ein Run, den innerhalb von 24 Stunden niemand freigibt, wird abgebrochen.

Ist die Einstellung aus, startet der Run unabhängig vom Urteil des Gates; der Agent liest die Gründe in seinem Briefing.

Guard bei Schreibvorgängen

Sobald der Agent in einem Repository arbeitet, ob mit dem Projekt verknüpft oder über den GitHub-Konnektor geöffnet, wird jeder Aufruf von write_file und edit_file gegen die Konformitätsregeln des Projekts geprüft, bevor die Änderung übernommen wird:

Schlägt die Prüfung selbst fehl, geht der Schreibvorgang durch: Der Guard blockiert einen Agenten nie wegen eigener Fehler. Er verhält sich wie der Guard-Hook für lokale Coding-Agenten, beschrieben im Harness-Leitfaden.

Ergebnis der Arbeitssitzung

Vor dem Abschluss meldet der Agent sein Ergebnis: eine Zusammenfassung, seine Entscheidungen, Follow-ups und die Gedächtniseinträge, auf die er sich gestützt hat. Wenn der Run endet, passiert Folgendes:

1. Archyl ordnet die geänderten Dateien der Sitzung zu und erkennt so, auf welchen geleasten Elementen tatsächlich gearbeitet wurde
2. Archyl schließt die Sitzung und speichert die Zusammenfassung als Gedächtnis an diesen Elementen
3. Die Entscheidungen werden ins Projektgedächtnis übernommen, und ein Architektur-Änderungsantrag im Entwurf wird zur Prüfung geöffnet. Nur ein erfolgreicher Run hält Entscheidungen fest

Die Run-Seite zeigt eine Karte Ergebnis der Arbeitssitzung mit Zusammenfassung, Entscheidungen, Follow-ups, den berührten Elementen und einem Link zum Änderungsantrag. Elemente, die eine andere Sitzung hält, sind als Von einer anderen Arbeitssitzung belegt markiert.

Einen Run live verfolgen

Eine Run-Seite hat zwei Ansichten: Aktivität, den Ereignis-Feed, und Änderungen, die Dateien, die der Agent geschrieben hat. Braucht der Agent Sie, zeigt ein Banner darüber, worauf er wartet (Wartet auf Ihre Planprüfung oder Der Agent hat eine Frage), und führt Sie direkt dorthin.

Der Plan

Bevor der Agent etwas ändert, teilt er einen Plan: eine Zusammenfassung in einem Satz und eine Handvoll konkreter Schritte, höchstens 12. Das Panel Plan oben auf der Run-Seite macht daraus eine Checkliste. Der Agent markiert jeden Schritt als In Arbeit, Erledigt oder Übersprungen, manchmal mit einer kurzen Notiz, und das Panel zeigt den aktuellen Schritt und den Fortschritt (3/7).

Plan zuerst prüfen ist eine Profileinstellung unter Koordination und standardmäßig deaktiviert. Ist sie aktiv, wartet der Agent auf eine Prüfung, bevor er etwas ändert:

1. Das Panel wechselt zu Plan prüfen. Sie können Schritte umbenennen, Details ergänzen sowie Schritte hinzufügen, entfernen oder neu anordnen.
2. Plan freigeben (Bearbeiteten Plan freigeben, sobald Sie ihn bearbeitet haben) lässt den Agenten loslegen. Ihre bearbeitete Fassung ist der Plan, dem der Agent folgt und den die Checkliste abbildet.
3. Änderungen anfordern schickt Ihr Feedback. Der Agent überarbeitet den Plan und legt Ihnen eine neue Revision zur Prüfung vor. Frühere Revisionen bleiben im Feed.

Solange kein Plan freigegeben ist, kann der Agent lesen, aber nichts ändern: Das Schreiben von Dateien und jedes Tool, das etwas anlegt, aktualisiert, löscht, verknüpft, importiert, pusht oder mergt (in Archyl und in jedem Konnektor, z. B. linear__create_issue), werden abgelehnt, ebenso remember. Der Agent wird angewiesen, auf die Prüfung zu warten.

Fragen

Braucht eine Entscheidung einen Menschen, etwa bei einer unklaren Anforderung, einem Zielkonflikt ohne klaren Favoriten oder einem destruktiven Schritt, fragt der Agent nach. Die Frage erscheint über dem Feed, mit Vorgeschlagene Antworten, wenn der Agent welche anbietet, und einem Feld für eine freie Antwort (Cmd/Ctrl + Enter sendet sie). Alle, die das Projekt bearbeiten dürfen, können antworten, und der Feed hält fest, wer geantwortet hat.

Der Agent stellt höchstens 5 Fragen pro Run und ist angewiesen, nie nach etwas zu fragen, das er selbst nachschlagen kann.

Wenn der Agent auf Sie wartet

Während der Agent auf eine Planprüfung oder eine Antwort wartet, zeigt der Run Wartet auf Sie und erscheint in der Run-Liste unter Braucht Sie, zusammen mit den Runs im Status Wartet auf Freigabe.

• Die Wartezeit zählt nicht zum Zeitlimit des Runs: Seine Deadline verschiebt sich um die Wartezeit nach hinten. Der Run behält seinen Slot.
• Eine Frage, die niemand innerhalb einer Stunde beantwortet: Der Agent arbeitet nach eigenem Ermessen weiter und nennt die getroffene Annahme in seinem Ergebnis.
• Ein Plan, den niemand innerhalb einer Stunde prüft: Der Run scheitert, ohne etwas geändert zu haben.

Wo der Agent arbeitet

Der Agent liest und ändert Code in seinem Arbeitsbereich, einem Klon des Repositorys:

• Repository mit dem Projekt verknüpft: Archyl klont es beim Start des Runs.
• Kein verknüpftes Repository, GitHub-Konnektor angebunden: Der Agent klont das Repository, um das es in der Aufgabe geht, selbst mit den Zugangsdaten des Konnektors, bevor er eine Datei anfasst. Unterstützt wird nur der gehostete MCP-Server von GitHub (api.githubcopilot.com). Der Konnektor muss sich mit einem Authorization: Bearer-Header authentifizieren, und sein Token braucht Zugriff auf das Repository.

Sobald ein Arbeitsbereich offen ist, ändert der Agent Dateien nur noch dort: Dateien über Konnektor-Tools zu pushen oder darüber Pull Requests zu öffnen, wird abgelehnt. So läuft jede Änderung durch den Guard, erscheint in der Ansicht Änderungen und landet in einem einzigen Pull Request.

Änderungen

Änderungen listet jede Datei auf, die der Agent schreibt, sobald er sie schreibt: Hinzugefügt, Geändert oder Blockiert, mit den hinzugefügten und entfernten Zeilen pro Datei und für den gesamten Run. Wählen Sie eine Datei aus, um zu sehen, was jeder Schreibvorgang geändert hat.

• Ein vom Guard abgelehnter Schreibvorgang ist Blockiert: Der Diff zeigt, was der Agent schreiben wollte, zusammen mit der verletzten Regel. Ein Schreibvorgang, den der Guard nur markiert hat, geht durch, mit einer Warnung an der Datei.
• Lange Diffs werden nach 600 Zeilen abgeschnitten, und Dateien über 128 KB erscheinen ohne Diff.

Eine Zeile kommentieren

Prüfen Sie den Diff, während der Agent arbeitet. Klicken Sie in Änderungen auf eine Zeilennummer, um diese Zeile zu kommentieren, und dann auf An den Agenten senden (Cmd/Strg + Enter). Der Agent erhält die Datei, die Zeile und ihren Inhalt, setzt den Kommentar um und fährt dann mit seinem Plan fort.

• Ein Kommentar erscheint unter seiner Zeile: Eingereiht, bis der Agent ihn liest, danach Zugestellt. Er erscheint auch in Aktivität, und jede Datei zeigt die Anzahl ihrer Kommentare.
• Sie können hinzugefügte, unveränderte und entfernte Zeilen kommentieren. Vom Guard blockierte Schreibvorgänge lassen sich nicht kommentieren.
• Kommentare werden angenommen, solange der Agent arbeitet oder auf Sie wartet. Ein Kommentar, der am Ende des Runs noch Eingereiht ist, wird als Nicht zugestellt angezeigt.

Bei einem beendeten Run wird ein Kommentar zur Notiz für den nächsten Run: Für die Fortsetzung merken speichert ihn in Ihrem Browser, und die Leiste über den Dateien (3 Kommentare für eine Fortsetzung) setzt den Run damit fort (Damit fortsetzen).

Pull Request

Wenn der Run endet, committet Archyl die Änderungen aus dem Arbeitsbereich auf einen Branch namens archyl/agent-, gefolgt von den ersten 8 Zeichen der Run-ID, und öffnet einen Pull Request gegen den Branch, von dem der Klon ausging. Sein Link erscheint oben in Änderungen (Pull Request öffnen) und im Ergebnis.

Auf GitLab ist der Entwurf ein Draft:-Merge-Request. Auf Bitbucket wird der Branch ohne Pull Request gepusht. Ein Run, der keine Dateien geändert hat, veröffentlicht nichts.

Pull Requests werden auf github.com, gitlab.com und bitbucket.org geöffnet. Archyl sendet Ihre Git-Zugangsdaten nur an diese Hosts: Ein Repository auf einem selbst gehosteten Git-Server (GitHub Enterprise, ein privates GitLab, Azure DevOps, Gitea) wird ohne Zugangsdaten geklont, sodass ein privates Repository nicht geklont werden kann, und es wird kein Pull Request geöffnet.

Einen Run fortsetzen

Ein beendeter Run bietet unabhängig von seinem Ergebnis zwei Schaltflächen:

• Fortsetzen startet einen neuen Run, der die Arbeit dieses Runs aufgreift. Schreiben Sie, was der Agent als Nächstes tun soll: Ihre Kommentare für die Fortsetzung füllen die Anweisungen vor, einer pro Zeile (Pfad:Zeile — Kommentar). Standardmäßig wird das Profil des Runs verwendet, und Sie können Konnektoren auswählen.
• Erneut ausführen öffnet den Startdialog mit derselben Aufgabe und demselben Profil, für einen neuen Run von Grund auf.

Eine Fortsetzung weiß, was der vorherige Run tun sollte und was er getan hat. Sie beginnt auf dem Branch, den dieser Run veröffentlicht hat, committet darauf und fügt ihre Änderungen demselben Pull Request hinzu, statt einen neuen zu öffnen. Hat der vorherige Run seinen Branch ohne Pull Request gepusht, öffnet die Fortsetzung einen, gegen den Branch, auf den ein neuer Run abzielen würde. Hat der vorherige Run ein Repository über den GitHub-Konnektor geöffnet, öffnet die Fortsetzung es erneut auf diesem Branch.

• Existiert der Branch nicht mehr (etwa weil er gemergt und gelöscht wurde), beginnt die Fortsetzung auf dem Branch, von dem ein neuer Run ausgehen würde, dem verknüpften Branch des Projekts oder dem Standard-Branch des Repositorys, und öffnet einen neuen Pull Request. Der Feed weist darauf hin.
• Ein Draft-Pull-Request bleibt ein Draft: Markieren Sie ihn als bereit zur Prüfung, sobald die Arbeit erledigt ist.
• Archyl setzt nur auf Branches fort, die seine Agenten erstellt haben, nie auf Ihren eigenen.

Die Seite des neuen Runs verweist auf den Run, den er fortsetzt (Fortsetzung von), und der vorherige Run verweist auf seine Fortsetzungen (Fortgesetzt in). Ein laufender Run kann nicht fortgesetzt werden: Kommentieren Sie stattdessen seine Zeilen.

MCP-Konnektoren

Mit Konnektoren binden Sie externe Dienste an Ihre Agent-Runs an. Jeder Dienst, der einen MCP-Server (Model Context Protocol) bereitstellt, kann verbunden werden.

Unterstützte Dienste

Einen Konnektor erstellen

1. Gehen Sie zu Agent Hub → Konnektoren
2. Klicken Sie auf Neuer Konnektor
3. Geben Sie einen Namen ein (z. B. "github")
4. Fügen Sie die MCP-Server-URL ein
5. Fügen Sie bei Bedarf Authentifizierungs-Header hinzu
6. Klicken Sie auf Konnektor erstellen — Archyl prüft den Server und zeigt die verfügbaren Tools an

Tool-Namensräume

Wenn ein Konnektor an einen Run angebunden wird, erhalten seine Tools den Konnektor-Namen als Präfix:

Tools des integrierten Archyl-MCP-Servers haben kein Präfix (z. B. get_agent_context, list_conformance_rules).

Diese Namensräume verhindern Kollisionen zwischen Tool-Namen, machen den Ereignis-Feed leicht überschaubar und erlauben es, mit den erlaubten Tools eines Profils einen ganzen Konnektor über ein einziges Muster wie github__* freizugeben.

Zeitpläne

Mit Zeitplänen definieren Sie wiederkehrende Agent-Runs über standardmäßige Cron-Ausdrücke.

Einen Zeitplan erstellen

1. Gehen Sie zu Agent Hub → Zeitpläne
2. Klicken Sie auf Neuer Zeitplan
3. Wählen Sie ein Profil und schreiben Sie die Aufgabenbeschreibung
4. Wählen Sie einen Cron-Ausdruck (Vorlagen verfügbar oder geben Sie einen eigenen ein)
5. Fügen Sie bei Bedarf Konnektoren hinzu
6. Klicken Sie auf Zeitplan erstellen

Zeitplan-Verwaltung

Jeder Zeitplan zeigt:

• Cron-Ausdruck — Wann der Agent läuft
• Nächster Run — Wann die nächste Ausführung geplant ist
• Letzter Run — Wann der Agent zuletzt gelaufen ist
• Status — Aktiv oder pausiert, oder Profil gelöscht, wenn sein Profil gelöscht wurde

Sie können:

• Einen Zeitplan pausieren, ohne ihn zu löschen
• Einen pausierten Zeitplan fortsetzen
• Jetzt ausführen — Sofort außerhalb des normalen Rhythmus ausführen
• Den Aufgabentext, Cron-Ausdruck oder die angebundenen Konnektoren bearbeiten
• Den Zeitplan löschen

Ein Zeitplan, dessen Profil gelöscht wurde, bleibt pausiert: Fortsetzen oder Jetzt ausführen wird abgelehnt, bis Sie den Zeitplan bearbeiten und ein anderes Profil wählen.

Beispiel-Zeitpläne

Architekturkontext

Jeder verwaltete Run erhält automatisch Zugriff auf den MCP-Server Ihres Archyl-Projekts. Der Agent kann:

• Das C4-Modell abfragen, um Systemgrenzen zu verstehen
• ADRs lesen, um vergangene Architekturentscheidungen nachzuvollziehen
• Konformitätsregeln prüfen, um zu wissen, welche Muster einzuhalten sind
• API-Verträge durchsuchen, um Service-Schnittstellen zu verstehen
• Technologie-Zuweisungen nachschlagen, um die richtigen Tools auszuwählen
• Über das Architekturgedächtnis Fakten zu Elementen abrufen und festhalten

Dieser Kontext wird dem Agenten vor Arbeitsbeginn bereitgestellt — er muss Ihre Architektur nicht von Grund auf neu entdecken. Außerdem läuft jeder Run in einer Harness-Arbeitssession, sodass sein Ergebnis zum Gedächtnis der Elemente wird, die er berührt hat.

KI-Anbieter

Runs verwenden das von Archyl verwaltete Modell, es sei denn, Ihre Organisation hat Eigener KI-Anbieter aktiviert. Mit aktiviertem BYO laufen Runs auf Ihrem Anbieter und mit Ihren Anmeldedaten — Anthropic, AWS Bedrock, OpenAI oder ein OpenAI-kompatibler Endpoint, der die Responses-API implementiert. Google Gemini kann noch keine verwalteten Agenten ausführen: Runs werden mit einer eindeutigen Meldung abgelehnt, statt stillschweigend das Modell von Archyl zu verwenden.

Kontingente und Parallelität

Verwaltete Agent-Runs sind in den Plänen Scale und Custom verfügbar. Die Nutzung wird pro Organisation mit monatlichen Kontingenten erfasst, die oben auf den Seiten Ausführungen und Zeitpläne angezeigt werden. Das Fortsetzen eines Runs und das Freigeben eines zurückgehaltenen Runs zählen ebenfalls als Runs. Organisationen mit aktiviertem BYO-KI-Anbieter werden nicht auf das Kontingent angerechnet — weder bei manuellen noch bei geplanten Runs.

Jeder aktive Run (pending, running oder waiting_for_input) belegt einen der gleichzeitigen Run-Slots Ihrer Organisation. Der Slot wird frei, sobald der Run endet, egal aus welchem Grund.

Best Practices

• Formulieren Sie Aufgabenbeschreibungen präzise — "Prüfe Go-Pakete auf bekannte CVEs und liste sie mit Schweregrad auf" funktioniert besser als "Abhängigkeiten prüfen"
• Geben Sie jeder Aufgabe ihr eigenes Profil — Ein reiner Lese-Reviewer, dessen allowedTools auf list_*, get_* und read_file beschränkt sind, kann nichts versehentlich verändern.
• Binden Sie nur benötigte Konnektoren an — Jeder Konnektor fügt dem Kontext des Agenten Tools hinzu. Weniger Tools bedeuten eine fokussiertere Ausführung.
• Beginnen Sie mit manuellen Runs — Testen Sie Ihre Aufgabenbeschreibung mit einem einmaligen Run, bevor Sie einen Zeitplan erstellen.
• Nutzen Sie Konformitätsregeln gemeinsam — Definieren Sie zuerst Leitplanken und aktivieren Sie dann den Skill Conformance first, damit Runs automatisch dagegen validiert werden.