Wie Agenten denken
Agenten sind keine Persönlichkeiten. Sie sind Rollen mit klaren Aufgaben, klarer Übergabe und klarer Stop-Logik. Die Rollen, die das System tatsächlich kennt, stehen unten — aus der Konfigurationsdatei gelesen, nicht beschrieben.
Nimmt die Anfrage entgegen, versteht das Ziel, plant die nächsten Schritte und entscheidet, welche Werkzeuge, Subagenten oder Aktionen nötig sind.
- Pflichten
- Ziel klassifizieren
- Scope abgrenzen
- Subagenten delegieren
- Ergebnisse zusammenführen
Erhält eine konkrete, eng umrissene Aufgabe mit klarem Ziel und klarer Übergabe. Hat eigenen Kontext, eigene Toolset-Berechtigungen, eigene Stop-Logik.
- Im System gemessen
- Prozess online: —
- Subagenten-Route: —
- Zuständigkeiten in Fähigkeiten: nicht messbar
Eine klar abgegrenzte Fähigkeit, die der Agent nutzen kann. Kein eigenständiger Akteur. Wird vom Agenten aufgerufen und liefert ein definiertes Ergebnis zurück.
- Im Produkt
- Produktfähigkeiten: —
- Systemfähigkeiten gesamt: —
- Im System
- Fähigkeitsfelder: —
Die Konfigurationsdatei benennt — Meisteragenten. Jeder hat eine eigene Mission, eigene Zuständigkeitsfelder, ein eigenes Eingabeformat und einen festgelegten Arbeitsablauf. Die Namen unten sind keine Beispiele, sie sind der Registerinhalt.
Meisteragenten werden geladen …
assets/data/system_data_v3.json · Feld creation_agentsEine Persönlichkeit ist eine Rolle mit eigener Stimme, nicht ein eigener Prozess. Das Register zählt — Einträge in — Stämmen. Die Zahl wird beim Laden gezählt, nicht von Hand eingetragen.
assets/data/persona_registry.jsonDiese Liste kommt vom Server und nennt zu jeder Fähigkeit den niedrigsten Tarif, ab dem sie verfügbar ist. Sie unterscheidet sich von der Zahl der Systemfähigkeiten — beides wird getrennt ausgewiesen.
| Kennung | Bezeichnung | Beschreibung | ab Tarif |
|---|---|---|---|
| Fähigkeiten werden geladen … | |||
/api/skills
Eine Übergabe endet nicht immer im Erfolg. Das System kennt
— Zustände, in denen eine
Arbeit enden kann. Nur READY und
COMPLETED bedeuten abgeschlossene Arbeit.
assets/data/system_data_v3.json · Feld handoff_statusesWelche Dienste gerade erreichbar sind, steht in der Statusdatei, die alle fünf Minuten neu geschrieben wird. Ist ein Dienst nicht erreichbar, ist das ein Zustand des Systems — kein Fehler dieser Seite. Der Wert ist der gemessene Zustand, nicht eine Zusage.
| Bereich | Erreichbar | Kennzahl |
|---|---|---|
| Betrieb wird geladen … | ||
assets/data/agenten_status.json · Zeitstempel —Die Recherche-Rotation kennt — benannte Agenten mit je einem Schalter. Diese Schalter gehören zu den Agentennamen, nicht zu den Dienstbereichen der Tabelle darüber — deshalb stehen sie getrennt.
| Agent | Schalter |
|---|---|
| Schalter werden geladen … | |
assets/data/agenten_status.json · Feld research.agentenJede Agenten-Phase übergibt ihre Ergebnisse in einem standardisierten Format. Das Format enthält: was wurde gemacht, was bleibt offen, was muss der nächste Agent wissen. Nichts wird stillschweigend überschrieben.
Vorher standen hier vier erfundene Beispielagenten (Recherche, Schreiben, Code, Analyse) und vier erfundene Beispielfähigkeiten (Telegram, Bildgenerierung, Suche, Datenbank). Diese Namen stehen in keiner Konfigurationsdatei. Die tatsächlichen Registereinträge stehen jetzt oben, live gelesen.
- Jeder Agent MUSS
- seine Quelle nennen
- seine Absicht klar benennen
- seine Reichweite markieren (Scope)
- offene Fragen explizit auflisten
- Risiken benennen, nicht verstecken
Ein Agent arbeitet nicht aus einer Beschreibung, sondern aus Aufträgen. Jeder Auftrag hat einen Zustand, und jeder Lauf hinterlässt eine Protokollzeile. Das ist der Teil, in dem die oben beschriebene Stop-Logik messbar wird: ein Auftrag endet in einem dieser Zustände.
- Gemessen aus /api/automation
- Auftraege gesamt: —
- Protokollzeilen: —
- Zustaende: —
- Leistungszaehler .aktiv: —
- Erfolgsquote: —
- Aufgefallen
- Zaehler werden geladen …
Quelle: /api/automation — noch nicht geladen.