Ein vollständiger Agentenlauf

So verwenden ein Mitarbeiter und sein Agent Weldall CLI, um sicher auf eine Unternehmensanwendung zuzugreifen.

Diese Seite zeigt einen vollständigen Ablauf aus Sicht eines Mitarbeiters und seines Agenten. Als Beispiel dient eine Anwendung, in der das Unternehmen seine Verträge verwaltet.

1. Der Mitarbeiter meldet sich an

Der Mitarbeiter meldet sich einmal selbst über die CLI an:

weldall login

Die CLI öffnet die Anmeldung des Unternehmens im Browser. Nach erfolgreichem Login speichert sie die Sitzung und den Geräteschlüssel im geschützten Betriebssystemspeicher.

Für diese CLI-Anmeldung benötigt der Mitarbeiter vorher einen effektiven weldall:login-Scope, der direkt per E-Mail oder über eine passende Provider-Gruppe zugewiesen wurde. Die Browser-Anmeldung an der Weldall-Administrationsoberfläche ist davon getrennt.

2. Der Mitarbeiter beauftragt seinen Agenten

Weldall ist nicht an einen bestimmten Agenten gebunden. Es funktioniert mit Pi, Claude und jedem anderen Agenten, der die CLI aufrufen kann. Der Agent muss zunächst nur eine Regel kennen:

Verwende Weldall für Aufgaben in meinem Unternehmen.

Weitere unternehmensspezifische Hinweise können Administratoren zentral im CLI-Appendix hinterlegen. Wenn der Agent weldall ohne Unterbefehl aufruft, zeigt die Hilfe das lokal zwischengespeicherte Appendix ohne Netzwerkanfrage an. Anmeldung, Status-, Scope- und Skill-Befehle aktualisieren den Cache für spätere Aufrufe.

Danach gibt der Mitarbeiter seinem Agenten den fachlichen Auftrag:

Suche den Vertrag mit der Nordstern GmbH und ändere das nächste Prüfdatum auf den 30. September 2026.

Der Mitarbeiter muss weder wissen, welcher Service die Verträge verwaltet, noch wie dessen API aufgerufen wird.

3. Der Agent sucht nach verfügbaren Skills

Der Agent beginnt mit den Funktionen, die Weldall für diesen Mitarbeiter veröffentlicht:

weldall skills

weldall skills ist die Kurzform von weldall skills list. Eine mögliche Ausgabe ist:

contracts.manage  Verträge verwalten  available

Die Liste enthält nur Skills, die für diesen Mitarbeiter sichtbar sind. Ein sichtbarer Skill kann je nach Konfiguration verfügbar sein oder auf fehlende Berechtigungen hinweisen.

4. Der Agent liest die Anleitung

Der Agent lädt den vollständigen Skill:

weldall skills show contracts.manage

Das Skill-Dokument weist den Agenten an, wie er die CLI für die richtigen HTTP-Requests verwendet. Es enthält die vollständigen weldall request-Befehle mit Ziel-URLs, Scopes und benötigten Daten:

---
title: "Verträge verwalten"
requiredScopes:
  - "contracts:read"
  - "contracts:update"
---

Suche einen Vertrag:

```sh
weldall request \
  --scope contracts:read \
  "https://contracts.example.com/api/contracts?customer=<url-encoded-name>"
```

Frage den Nutzer vor einer Änderung nach einer Bestätigung. Ändere danach das Prüfdatum:

```sh
weldall request \
  --method PATCH \
  --scope contracts:update \
  --json '{"nextReviewAt":"<YYYY-MM-DD>"}' \
  https://contracts.example.com/api/contracts/<contract-id>
```

Die Bestätigung ist in diesem Beispiel eine Regel des Skills. Weldall erzwingt sie nicht selbst. Weldall erzwingt, dass der Agent nur die freigegebenen Ziele und Scopes verwenden kann.

5. Der Agent liest den Vertrag

Der Agent folgt der Anleitung und sucht den Vertrag:

weldall request \
  --scope contracts:read \
  "https://contracts.example.com/api/contracts?customer=Nordstern%20GmbH"

Der Vertragsservice antwortet beispielsweise:

{
  "id": "contract-4711",
  "customer": "Nordstern GmbH",
  "nextReviewAt": "2026-06-30",
  "status": "active"
}

Der Agent kennt nun den aktuellen Wert und bittet den Mitarbeiter um die im Skill verlangte Bestätigung.

6. Der Agent ändert den Vertrag

Nach der Bestätigung sendet der Agent die Änderung:

weldall request \
  --method PATCH \
  --scope contracts:update \
  --json '{"nextReviewAt":"2026-09-30"}' \
  https://contracts.example.com/api/contracts/contract-4711

Die CLI gibt die Antwort des Vertragsservice aus. Der Agent fasst das Ergebnis für den Mitarbeiter zusammen.

Was Weldall dabei übernimmt

Bei jedem weldall request führt die CLI die sicherheitsrelevanten Schritte selbst aus:

Sie prüft, ob die Ziel-URL zu einem registrierten Unternehmensservice gehört.
Sie prüft, ob der angeforderte Scope für diesen Service unterstützt und dem Mitarbeiter zugewiesen ist.
Sie beschafft kurzlebige, DPoP-gebundene Zugangsdaten für genau diesen Service.
Sie sendet den API-Request direkt an den Vertragsservice.
Sie gibt nur die fachliche Antwort an den Agenten zurück.

Der Agent sieht kein Access Token und muss keine Zugangsdaten speichern. Administratoren kontrollieren zentral, welche Skills sichtbar sind und welche Scopes ein Mitarbeiter verwenden darf. Weldall protokolliert, ob die angeforderte Autorisierung erteilt oder abgelehnt wurde.

Eigene Services mit Weldall verbinden

Damit ein Agent auf einen Unternehmensservice zugreifen kann, verbinden Administratoren den Service einmal mit Weldall. Sie legen die Berechtigungen fest und veröffentlichen einen passenden Skill. Danach können Mitarbeitende den Service verwenden, ohne seine API, URLs oder sein Berechtigungsmodell kennen zu müssen.

Die einzelnen Schritte stehen unter How to: Service integrieren.