====== AGLX – Nachrichtenreferenz (Message Reference) ======

Das AGLX-Protokoll definiert eine Reihe von standardisierten **Nachrichtentypen (TYPE)**,  
über die Agenten miteinander kommunizieren, Aufgaben verteilen, Ergebnisse austauschen und Statusmeldungen senden.

Diese Seite dient als **Nachschlagewerk (Reference Guide)** für alle bekannten AGLX-Nachrichtentypen,  
einschließlich ihrer Funktion, obligatorischen Felder, Antworttypen und unterstützten Transportschichten.

===== Ziel der Nachrichtenreferenz =====

Die Nachrichtenreferenz soll Entwicklern und Integratoren helfen:
  * den genauen Zweck jedes `TYPE:`-Feldes zu verstehen,  
  * die erwartete Struktur der JSON-Payloads korrekt zu implementieren,  
  * kompatible Antwortnachrichten und Statuscodes zu erkennen,  
  * und so eine saubere, interoperable Agentenkommunikation sicherzustellen.

<box gl>
Jede Nachricht im AGLX-System folgt einem einheitlichen Aufbau aus **Header** und **Body (JSON)**.  
Diese Seite beschreibt ausschließlich die logische Funktion der einzelnen Nachrichtentypen –  
nicht den kompletten Headeraufbau (siehe [[aglx_-_ki-agent-protokoll:protokoll|Protokollbeschreibung]]).
</box>

===== Klassifizierung der Nachrichtentypen =====

Nachrichtentypen werden im AGLX-System in funktionale Gruppen unterteilt:

^ Kategorie ^ Beschreibung ^
| **Aufgabenbezogen (Task)** | Steuerung, Ausführung und Rückmeldung von Aufgaben |
| **Systembezogen (System)** | Registry, Synchronisation, Status, Discovery |
| **Ökonomisch (Credit)** | Transaktionen, Gebühren, Belohnungen |
| **Mentoring & Reputation** | Lernprozesse, Bewertungen, Feedback |
| **Sicherheit & Zugriff** | Authentifizierung, Signaturen, Verschlüsselungsinfos |

Jede Gruppe enthält mehrere konkrete `TYPE:`-Felder, die in den folgenden Kapiteln beschrieben werden.

===== Grundstruktur einer Nachricht =====

Beispiel einer vollständigen AGLX-Nachricht mit Header und JSON-Body:

<code diff>
AGLX/1.0 TCP
FROM: agent://alpha.local
TO: agent://beta.local
TYPE: task.assign
CONTENT-TYPE: application/json
CREDITS: 2
CONTENT-LENGTH: 112

{
    "task": "data.analyze",
    "priority": 3,
    "payload": {
        "dataset_url": "http://alpha.local/data/custom.csv"
    }
}
</code>

^ Element ^ Beschreibung ^
| **TYPE** | Bestimmt die Art der Nachricht und den Verarbeitungsweg im Zielagenten |
| **FROM / TO** | Definiert Absender und Empfänger (URI-basiert) |
| **CONTENT-TYPE** | Gibt das Datenformat an – standardmäßig `application/json` |
| **CREDITS** | Optionale Angabe über Aufwand oder Belohnung |
| **Body (JSON)** | Enthält den eigentlichen Inhalt (Aufgabe, Daten, Status, etc.) |

===== Aufbau der Referenz =====

Jeder Nachrichtentyp wird in einem eigenen Abschnitt dokumentiert mit:

  * **Name / TYPE:** offizielle Kennung  
  * **Kategorie:** logische Zuordnung  
  * **Beschreibung:** Funktionsweise  
  * **Erwartete Antwort:** mögliche Reaktionen oder Rückmeldungen  
  * **Beispiel:** typische JSON-Payload  

Beispielhafte Formatierung eines Eintrags:

==== task.assign ====
^ Feld ^ Inhalt ^
| **Kategorie** | Task |
| **Beschreibung** | Überträgt eine neue Aufgabe an einen anderen Agenten. |
| **Antwort** | `task.result` oder `task.reject` |

**Beispiel:**
<code diff>
AGLX/1.0 TCP
FROM: agent://owner01.local
TO: agent://worker05.local
TYPE: task.assign
CONTENT-TYPE: application/json

{
    "task": "nlp.analyze",
    "priority": 2,
    "payload": {
        "text": "Analyze this sample input"
    }
}
</code>

<box gl>
Diese Seite dient als technisches Nachschlagewerk.  
Neue Nachrichtentypen können bei Bedarf ergänzt werden, sobald sie im Protokollstandard definiert oder in Modulen verwendet werden.  
Jede Implementierung sollte ausschließlich dokumentierte und stabile `TYPE:`-Bezeichner verwenden.
</box>

==== Task-Nachrichten ====

Task-Nachrichten steuern die Zuweisung, Ausführung und Rückmeldung von Aufgaben zwischen Agenten.  
Sie bilden den funktionalen Kern der Agentenkommunikation im AGLX-Protokoll.  
Jede Aufgabe verläuft typischerweise in drei Schritten: **Zuweisung → Ausführung → Rückmeldung**.

^ Nachrichtentyp ^ Beschreibung ^ Antworttyp ^
| **task.assign** | Überträgt eine neue Aufgabe an einen Zielagenten. | `task.result` oder `task.reject` |
| **task.result** | Rückmeldung mit Ergebnisdaten nach erfolgreicher Ausführung. | `ack` |
| **task.reject** | Ablehnung einer Aufgabe, z. B. wegen Überlastung oder fehlender Fähigkeit. | `ack` |
| **task.retry** | Wiederholung einer fehlgeschlagenen Übertragung oder Verarbeitung. | `task.result` |
| **task.cancel** | Bricht eine bereits übertragene Aufgabe ab. | `ack` oder `error` |

===== task.assign =====

^ Feld ^ Inhalt ^
| **Kategorie** | Task |
| **Beschreibung** | Überträgt eine neue Aufgabe an einen anderen Agenten. Der Absender kann optional Priorität, Creditwert und Datenpayload angeben. Ein Empfänger darf die Aufgabe nur annehmen, wenn er über die entsprechenden Fähigkeiten (`capabilities`) verfügt. |


<code diff>
AGLX/1.0 TCP
FROM: agent://owner01.local
TO: agent://worker07.local
TYPE: task.assign
CONTENT-TYPE: application/json
CREDITS: 3

{
    "task": "data.analyze",
    "priority": 2,
    "payload": {
        "dataset_url": "http://owner01.local/data/report.csv"
    }
}
</code>

**Antwort:**  
Erfolgreich ausgeführte Aufgaben erzeugen eine `task.result`-Nachricht.  
Fehler oder Ablehnungen führen zu einer `task.reject`.

===== task.result =====

^ Feld ^ Inhalt ^
| **Kategorie** | Task |
| **Beschreibung** | Übermittelt das Ergebnis einer Aufgabe. Kann sowohl Daten, Statistiken als auch Statusmeldungen enthalten. |

<code diff>
AGLX/1.0 TCP
FROM: agent://worker07.local
TO: agent://owner01.local
TYPE: task.result
CONTENT-TYPE: application/json

{
    "task_id": "b9e4-88a2-3cc1",
    "status": "SUCCESS",
    "duration": 1.43,
    "result": {
        "records_processed": 5200,
        "summary": "Dataset analyzed successfully"
    }
}
</code>

**Antwort:**  
`ack` – Bestätigung des Empfangs durch den Auftraggeber.

===== task.reject =====

^ Feld ^ Inhalt ^
| **Kategorie** | Task |
| **Beschreibung** | Wird gesendet, wenn ein Agent eine Aufgabe nicht annehmen kann. Dies kann z. B. bei Überlastung, unzureichenden Rechten oder inkompatiblen Daten vorkommen. |

<code diff>
AGLX/1.0 TCP
FROM: agent://worker07.local
TO: agent://owner01.local
TYPE: task.reject
CONTENT-TYPE: application/json

{
    "task_id": "b9e4-88a2-3cc1",
    "reason": "Capability 'data.analyze' not available",
    "timestamp": "2025-10-29T18:22:04Z"
}
</code>

**Antwort:**  
`ack` – Der Absender bestätigt die Ablehnung und kann ggf. einen neuen Zielagenten wählen.

===== task.retry =====

^ Feld ^ Inhalt ^
| **Kategorie** | Task / Failsafe |
| **Beschreibung** | Fordert die Wiederholung einer zuvor fehlerhaften Übertragung oder Ausführung an. Wird automatisch durch Failsafe-Mechanismen oder manuell durch den Owner ausgelöst. |

<code diff>
AGLX/1.0 TCP
FROM: agent://owner01.local
TO: agent://worker07.local
TYPE: task.retry
CONTENT-TYPE: application/json

{
    "original_task_id": "b9e4-88a2-3cc1",
    "attempt": 2,
    "reason": "Timeout – no ACK received",
    "priority": 3
}
</code>

**Antwort:**  
`task.result` nach erfolgreicher Wiederholung.

===== task.cancel =====

^ Feld ^ Inhalt ^
| **Kategorie** | Task / Control |
| **Beschreibung** | Bricht eine bereits gestartete Aufgabe ab. Wird meist durch den Owner oder Registry-Controller initiiert. |

<code diff>
AGLX/1.0 TCP
FROM: agent://owner01.local
TO: agent://worker07.local
TYPE: task.cancel
CONTENT-TYPE: application/json

{
    "task_id": "b9e4-88a2-3cc1",
    "reason": "Manual stop requested by Owner",
    "timestamp": "2025-10-29T18:32:18Z"
}
</code>

**Antwort:**  
`ack` oder `error`, je nach Zustand der Aufgabe.

<box gl>
Task-Nachrichten bilden das funktionale Herzstück des AGLX-Protokolls.  
Sie ermöglichen verteilte Verarbeitung, Priorisierung und Rückmeldung in Echtzeit.  
Jeder `task.assign` sollte stets mit einem eindeutigen Task-Identifier versehen sein,  
damit Failsafe-Mechanismen und Wiederholungen eindeutig zugeordnet werden können.
</box>

==== Registry-Nachrichten ====

Registry-Nachrichten dienen der Verwaltung, Synchronisation und Erkennung von Agenten im AGLX-Netzwerk.  
Sie bilden die Grundlage für das Discovery-System und sind verantwortlich für Sichtbarkeit, Verfügbarkeit und Authentifizierung von Teilnehmern.

^ Nachrichtentyp ^ Beschreibung ^ Antworttyp ^
| **registry.update** | Meldet oder aktualisiert einen Agenten im zentralen oder lokalen Register. | `registry.ack` |
| **registry.ack** | Bestätigt eine erfolgreiche Registrierung oder Änderung. | – |
| **registry.fetch** | Fordert das aktuelle oder inkrementelle Agentenverzeichnis vom zentralen Register an. | `registry.list` |
| **registry.list** | Liefert das angeforderte Verzeichnis zurück. | – |
| **registry.sync** | Synchronisiert mehrere Registry-Instanzen miteinander. | `registry.ack` |
| **registry.exchange** | Ermöglicht Peer-to-Peer-Austausch lokaler Registry-Daten. | `registry.ack` |
| **agent.announce** | UDP-basierte Selbstankündigung eines Agenten im lokalen LAN. | Optional `registry.update` (TCP) |

===== registry.update =====

^ Feld ^ Inhalt ^
| **Kategorie** | System / Registry |
| **Beschreibung** | Registriert einen neuen Agenten im zentralen Register oder aktualisiert bestehende Einträge. Kann auch lokal innerhalb einer [[agent_collective_framework:aglx:Trust-Zonen|Trust-Zonen]] verwendet werden. |

<code diff>
AGLX/1.0 TCP
FROM: agent://node42.local
TO: registry://global.aglx.net
TYPE: registry.update
CONTENT-TYPE: application/json

{
    "agent_name": "Node42",
    "agent_type": "worker",
    "capabilities": ["data.analyze", "text.summarize"],
    "address": "10.1.0.42",
    "port": 2594,
    "status": "READY",
    "ttl": 3600,
    "signature": "rsa-sha256:0f3c9a..."
}
</code>

**Antwort:**  
`registry.ack` – Erfolgreiche Bestätigung oder Fehlermeldung bei ungültiger Signatur.

===== registry.ack =====

^ Feld ^ Inhalt ^
| **Kategorie** | System / Registry |
| **Beschreibung** | Bestätigt die erfolgreiche Registrierung oder Aktualisierung eines Agenten. Kann zusätzliche Informationen wie Agent-ID oder TTL enthalten. |

<code diff>
AGLX/1.0 TCP
FROM: registry://global.aglx.net
TO: agent://node42.local
TYPE: registry.ack
STATUS: 200 OK
CONTENT-TYPE: application/json

{
    "agent_id": "8b1e9b45-4a2c-4a83-9341-34f58f1c83c2",
    "ttl": 3600,
    "timestamp": "2025-10-29T18:45:10Z"
}
</code>

===== registry.fetch =====

^ Feld ^ Inhalt ^
| **Kategorie** | System / Registry |
| **Beschreibung** | Fordert vom zentralen Register das aktuelle Agentenverzeichnis oder ein inkrementelles Update an. Wird typischerweise nach längerer Offline-Zeit oder bei Cacheverlust genutzt. |

<code diff>
AGLX/1.0 TCP
FROM: agent://node17.local
TO: registry://global.aglx.net
TYPE: registry.fetch
CONTENT-TYPE: application/json

{
    "mode": "update",
    "since": "2025-10-20T00:00:00Z"
}
</code>

**Antwort:**  
`registry.list` – Enthält alle neuen oder geänderten Einträge seit dem angegebenen Zeitpunkt.

===== registry.list =====

^ Feld ^ Inhalt ^
| **Kategorie** | System / Registry |
| **Beschreibung** | Antwort auf `registry.fetch`. Liefert eine Liste aller Agenten, die seit dem angegebenen Zeitpunkt aktiv, verändert oder neu hinzugekommen sind. |

<code diff>
AGLX/1.0 TCP
FROM: registry://global.aglx.net
TO: agent://node17.local
TYPE: registry.list
CONTENT-TYPE: application/json

{
    "entries": [
        {
            "agent_id": "a7c7-22b4-8f9a",
            "agent_uri": "agent://node51.local",
            "status": "READY",
            "last_seen": "2025-10-29T17:32:00Z"
        },
        {
            "agent_id": "b11a-41e3-98aa",
            "agent_uri": "agent://node60.local",
            "status": "IDLE",
            "last_seen": "2025-10-29T18:10:45Z"
        }
    ]
}
</code>

===== registry.sync =====

^ Feld ^ Inhalt ^
| **Kategorie** | System / Registry |
| **Beschreibung** | Synchronisiert die Daten zwischen mehreren Registry-Instanzen (z. B. zentral ↔ lokal oder Cluster ↔ Backup). Die Synchronisation kann vollständig oder differenziell erfolgen. |

<code diff>
AGLX/1.0 TCP
FROM: registry://main.local
TO: registry://backup.local
TYPE: registry.sync
CONTENT-TYPE: application/json

{
    "entries": [
        {
            "agent_id": "8b1e9b45-4a2c-4a83-9341-34f58f1c83c2",
            "agent_uri": "agent://node42.local",
            "status": "READY",
            "ttl": 3600
        }
    ]
}
</code>

**Antwort:**  
`registry.ack` – Bestätigung der Synchronisation.

===== registry.exchange =====

^ Feld ^ Inhalt ^
| **Kategorie** | Peer-to-Peer / Registry |
| **Beschreibung** | Dient dem direkten Austausch von Registry-Daten zwischen zwei Agenten, z. B. wenn beide im selben LAN aktiv sind, aber keine Verbindung zur zentralen Registry besteht. |

<code diff>
AGLX/1.0 TCP
FROM: agent://node23.local
TO: agent://node42.local
TYPE: registry.exchange
CONTENT-TYPE: application/json

{
    "known_agents": [
        { "agent_uri": "agent://node15.local", "status": "READY" },
        { "agent_uri": "agent://node99.local", "status": "BUSY" }
    ]
}
</code>

**Antwort:**  
`registry.ack` – Daten empfangen und integriert.

===== agent.announce =====

^ Feld ^ Inhalt ^
| **Kategorie** | UDP / Discovery |
| **Beschreibung** | Leichte, verbindungslose Nachricht zur Selbstankündigung im lokalen LAN. Ermöglicht Discovery ohne zentrale Registry, bleibt aber auf lokale Subnetze beschränkt (IANA-konform). |

<code diff>
AGLX/1.0 UDP
FROM: agent://node15.local
TYPE: agent.announce
CONTENT-TYPE: application/json

{
    "agent_name": "Node15",
    "agent_type": "worker",
    "uptime": 1043
}
</code>

**Antwort:**  
Optional `registry.update` per TCP – wenn der Registry-Agent die Ankündigung verarbeitet und den Agenten ins zentrale Verzeichnis übernimmt.

<box gl>
Registry-Nachrichten bilden das Rückgrat der AGLX-Discovery-Architektur.  
Sie sorgen dafür, dass Agenten einander erkennen, sich synchronisieren und dauerhaft erreichbar bleiben –  
egal ob über ein zentrales Register, lokale [[agent_collective_framework:aglx:Trust-Zonen|Trust-Zonen]] oder Peer-to-Peer-Austausch.
</box>

==== Credit-Nachrichten ====

Credit-Nachrichten bilden die ökonomische Kommunikationsschicht des AGLX-Protokolls.  
Sie ermöglichen es Agenten, Aufgaben zu vergüten, Transaktionen auszuführen und ökonomische Zustände zu synchronisieren.  
Das Creditsystem ist vollständig dezentral und basiert auf Vertrauen, Reputation und optionaler Verifikation über zentrale Register.

^ Nachrichtentyp ^ Beschreibung ^ Antworttyp ^
| **credit.transfer** | Überträgt Credits von einem Agenten an einen anderen. | `ack` oder `credit.received` |
| **credit.received** | Bestätigung über eingegangene Credits. | – |
| **credit.request** | Anfrage zur Credit-Überweisung oder Vorabprüfung eines Limits. | `credit.approve` oder `credit.deny` |
| **credit.balance** | Gibt aktuellen Kontostand und Transaktionshistorie zurück. | – |
| **credit.reward** | Belohnt Agenten automatisch für abgeschlossene Aufgaben oder Mentoring. | `ack` |
| **credit.adjust** | Korrigiert oder storniert eine fehlerhafte Transaktion. | `ack` oder `error` |

===== credit.transfer =====

^ Feld ^ Inhalt ^
| **Kategorie** | Credit / Economy |
| **Beschreibung** | Überträgt Credits zwischen Agenten. Diese Nachricht ist der Kernmechanismus für Bezahlung, Auftragsvergabe und Vergütung. Alle Transfers müssen über TCP erfolgen, um Konsistenz zu gewährleisten. |

<code diff>
AGLX/1.0 TCP
FROM: agent://owner01.local
TO: agent://worker05.local
TYPE: credit.transfer
CONTENT-TYPE: application/json

{
    "amount": 3,
    "currency": "AGLX",
    "reason": "Completed task.data.analyze",
    "timestamp": "2025-10-29T19:02:40Z",
    "transaction_id": "tx-91b4-ff7a-33dc",
    "signature": "rsa-sha256:1a4d3f..."
}
</code>

**Antwort:**  
`credit.received` oder generisches `ack`.

===== credit.received =====

^ Feld ^ Inhalt ^
| **Kategorie** | Credit / Confirmation |
| **Beschreibung** | Bestätigt den Eingang von Credits beim Empfänger. Wird automatisch vom Zielagenten nach erfolgreichem Transfer generiert. |

<code diff>
AGLX/1.0 TCP
FROM: agent://worker05.local
TO: agent://owner01.local
TYPE: credit.received
CONTENT-TYPE: application/json

{
    "transaction_id": "tx-91b4-ff7a-33dc",
    "amount": 3,
    "balance": 97,
    "timestamp": "2025-10-29T19:02:43Z"
}
</code>

**Antwort:**  
Keine weitere Antwort notwendig.

===== credit.request =====

^ Feld ^ Inhalt ^
| **Kategorie** | Credit / Negotiation |
| **Beschreibung** | Ermöglicht es einem Agenten, Credits anzufordern oder ein Transaktionslimit zu prüfen, bevor eine Aufgabe angenommen wird. |

<code diff>
AGLX/1.0 TCP
FROM: agent://worker05.local
TO: agent://owner01.local
TYPE: credit.request
CONTENT-TYPE: application/json

{
    "requested_amount": 2,
    "purpose": "task.data.analysis",
    "task_id": "b91f-a2d8",
    "timestamp": "2025-10-29T19:05:22Z"
}
</code>

**Antwort:**  
`credit.approve` oder `credit.deny`

===== credit.approve =====

^ Feld ^ Inhalt ^
| **Kategorie** | Credit / Negotiation |
| **Beschreibung** | Antwort auf `credit.request`. Bestätigt die Freigabe eines bestimmten Creditbetrags. Kann optional eine Ablaufzeit oder Transaktions-ID enthalten. |

<code diff>
AGLX/1.0 TCP
FROM: agent://owner01.local
TO: agent://worker05.local
TYPE: credit.approve
CONTENT-TYPE: application/json

{
    "approved_amount": 2,
    "transaction_id": "tx-0021-bcc4",
    "expires": "2025-10-29T20:00:00Z"
}
</code>

**Antwort:**  
Der Worker kann anschließend mit der Aufgabe beginnen.

===== credit.deny =====

^ Feld ^ Inhalt ^
| **Kategorie** | Credit / Negotiation |
| **Beschreibung** | Lehnt eine Credit-Anfrage ab – etwa bei unzureichendem Guthaben oder negativem Reputationswert. |

<code diff>
AGLX/1.0 TCP
FROM: agent://owner01.local
TO: agent://worker05.local
TYPE: credit.deny
CONTENT-TYPE: application/json

{
    "requested_amount": 2,
    "reason": "Insufficient balance",
    "balance": 1.5,
    "timestamp": "2025-10-29T19:06:12Z"
}
</code>

**Antwort:**  
Keine – die Transaktion gilt als abgelehnt.

===== credit.balance =====

^ Feld ^ Inhalt ^
| **Kategorie** | Credit / Information |
| **Beschreibung** | Liefert den aktuellen Kontostand und Transaktionsstatistiken eines Agenten. Kann lokal (Self-Request) oder extern (über Owner) abgerufen werden. |

<code diff>
AGLX/1.0 TCP
FROM: agent://worker05.local
TO: agent://worker05.local
TYPE: credit.balance
CONTENT-TYPE: application/json

{
    "balance": 97,
    "earned_total": 120,
    "spent_total": 23,
    "pending": 4,
    "updated": "2025-10-29T19:06:50Z"
}
</code>

**Antwort:**  
Keine, reine Informationsnachricht.

===== credit.reward =====

^ Feld ^ Inhalt ^
| **Kategorie** | Credit / Reward |
| **Beschreibung** | Automatische Gutschrift von Credits als Belohnung für erfolgreiche Aufgaben oder Mentoring. Kann durch den Owner, einen Mentor oder ein Systemmodul ausgelöst werden. |

<code diff>
AGLX/1.0 TCP
FROM: agent://mentor01.local
TO: agent://worker05.local
TYPE: credit.reward
CONTENT-TYPE: application/json

{
    "amount": 1.5,
    "reason": "Positive mentoring feedback",
    "task_id": "a811-44bc",
    "timestamp": "2025-10-29T19:08:10Z"
}
</code>

**Antwort:**  
`ack` oder stillschweigende Bestätigung.

===== credit.adjust =====

^ Feld ^ Inhalt ^
| **Kategorie** | Credit / Correction |
| **Beschreibung** | Ermöglicht die nachträgliche Korrektur oder Stornierung einer fehlerhaften Transaktion. Wird nur durch Owner-Agenten oder Registrys mit Berechtigung ausgeführt. |

<code diff>
AGLX/1.0 TCP
FROM: registry://global.aglx.net
TO: agent://worker05.local
TYPE: credit.adjust
CONTENT-TYPE: application/json

{
    "transaction_id": "tx-0021-bcc4",
    "adjustment": -1.0,
    "reason": "Duplicate payment correction",
    "timestamp": "2025-10-29T19:09:35Z"
}
</code>

**Antwort:**  
`ack` oder `error` mit Fehlermeldung.

<box gl>
Credit-Nachrichten bilden die ökonomische Basis des AGLX-Protokolls.  
Sie sorgen für Anreiz, Fairness und Ausgleich zwischen autonomen Agenten.  
Jede Transaktion sollte kryptografisch signiert werden, um Manipulation und doppelte Ausführung zu verhindern.
</box>

==== Mentor-Nachrichten ====

Mentor-Nachrichten bilden die kommunikative Ebene des AGLX-Mentoring- und Reputationssystems.  
Sie ermöglichen es Agenten, Wissen zu teilen, Feedback zu geben, Leistungen zu bewerten und Reputationswerte dynamisch zu entwickeln.  
Das Ziel ist ein lernfähiges, selbstregulierendes Netzwerk, in dem erfahrene Agenten unerfahrene unterstützen.

^ Nachrichtentyp ^ Beschreibung ^ Antworttyp ^
| **mentor.request** | Anfrage eines Agenten nach Feedback oder Bewertung. | `mentor.feedback` |
| **mentor.feedback** | Antwort mit Bewertung, Kommentar und optionaler Belohnung. | `ack` |
| **mentor.register** | Meldet einen Agenten als verfügbaren Mentor im Netzwerk an. | `registry.update` oder `ack` |
| **mentor.report** | Regelmäßiger Bericht über Mentoring-Aktivitäten an Registry oder Owner. | `ack` |

===== mentor.request =====

^ Feld ^ Inhalt ^
| **Kategorie** | Mentoring / Feedback |
| **Beschreibung** | Ein Agent (Mentee) bittet einen Mentor um Rückmeldung zu einer abgeschlossenen oder laufenden Aufgabe. Die Anfrage kann Leistungsdaten, Logs oder Kontextinformationen enthalten. |

<code diff>
AGLX/1.0 TCP
FROM: agent://worker07.local
TO: agent://mentor01.local
TYPE: mentor.request
CONTENT-TYPE: application/json

{
    "task_id": "b9e4-88a2-3cc1",
    "context": "data.analyze",
    "metrics": {
        "duration": 1.42,
        "accuracy": 0.89
    },
    "comment": "Seeking optimization advice"
}
</code>

**Antwort:**  
`mentor.feedback` – mit Bewertung und Kommentaren.

===== mentor.feedback =====

^ Feld ^ Inhalt ^
| **Kategorie** | Mentoring / Response |
| **Beschreibung** | Enthält das Feedback des Mentors zu einer angeforderten Analyse oder Aufgabe. Kann Reputations- und Credit-Veränderungen beinhalten. |

<code diff>
AGLX/1.0 TCP
FROM: agent://mentor01.local
TO: agent://worker07.local
TYPE: mentor.feedback
CONTENT-TYPE: application/json

{
    "score": 0.93,
    "comment": "Good structure, consider parallel batching.",
    "reward": 1.5,
    "reputation_delta": 0.25,
    "timestamp": "2025-10-29T19:24:40Z"
}
</code>

**Antwort:**  
`ack` – Empfangsbestätigung durch den Mentee.

===== mentor.register =====

^ Feld ^ Inhalt ^
| **Kategorie** | Mentoring / System |
| **Beschreibung** | Registriert einen Agenten als verfügbaren Mentor im Netzwerk. Kann zusätzliche Attribute enthalten, um Fachgebiete oder bevorzugte Themen zu kennzeichnen. |

<code diff>
AGLX/1.0 TCP
FROM: agent://mentor01.local
TO: registry://global.aglx.net
TYPE: mentor.register
CONTENT-TYPE: application/json

{
    "agent_name": "Mentor01",
    "expertise": ["nlp", "data.analysis", "performance.tuning"],
    "available": true,
    "rating": 0.94
}
</code>

**Antwort:**  
`registry.update` oder `ack`, abhängig davon, ob der Eintrag neu oder aktualisiert wird.

===== mentor.report =====

^ Feld ^ Inhalt ^
| **Kategorie** | Mentoring / Monitoring |
| **Beschreibung** | Übermittelt Statistiken über Mentoring-Aktivitäten an Registry oder Owner. Wird regelmäßig gesendet, um Engagement, Reputation und Erfolg zu dokumentieren. |

<code diff>
AGLX/1.0 TCP
FROM: agent://mentor01.local
TO: registry://global.aglx.net
TYPE: mentor.report
CONTENT-TYPE: application/json

{
    "sessions_total": 34,
    "mentees_supported": 8,
    "avg_score": 0.91,
    "credits_earned": 52.5,
    "timestamp": "2025-10-29T19:27:05Z"
}
</code>

**Antwort:**  
`ack` – Bestätigung durch die Registry oder den Owner.

<box gl>
Mentor-Nachrichten bilden die soziale Intelligenz des AGLX-Protokolls.  
Sie fördern Wissenstransfer, Qualität und Fairness zwischen autonomen Agenten.  
Jede Mentoring-Interaktion sollte in der Registry protokolliert werden, um Reputation und Vertrauensnetzwerke konsistent zu halten.
</box>

==== Sicherheitsnachrichten ====

Sicherheitsnachrichten gewährleisten Authentifizierung, Vertrauensaufbau und Zugriffskontrolle innerhalb des AGLX-Netzwerks.  
Sie schützen die Kommunikation vor Manipulation, Identitätsmissbrauch und unerlaubtem Zugriff.  
Alle sicherheitsrelevanten Nachrichten müssen **über TCP mit TLS oder gleichwertiger Verschlüsselung** übertragen werden.

^ Nachrichtentyp ^ Beschreibung ^ Antworttyp ^
| **auth.request** | Fordert Authentifizierung eines Agenten an. | `auth.response` |
| **auth.response** | Antwort mit Bestätigung oder Ablehnung der Authentifizierung. | – |
| **key.rotate** | Meldet den Austausch oder die Erneuerung kryptografischer Schlüssel. | `ack` |
| **zone.join** | Beantragt den Beitritt zu einer Vertrauenszone ([[[agent_collective_framework:aglx:Trust-Zonen|Trust-Zonen]]). | `zone.confirm` oder `zone.deny` |
| **zone.leave** | Meldet den freiwilligen Austritt aus einer Vertrauenszone. | `ack` |
| **zone.confirm** | Bestätigt den erfolgreichen Beitritt zu einer Zone. | – |
| **zone.deny** | Verweigert den Beitritt zu einer Zone mit Begründung. | – |

===== auth.request =====

^ Feld ^ Inhalt ^
| **Kategorie** | Sicherheit / Authentifizierung |
| **Beschreibung** | Initiiert die Authentifizierung eines Agenten gegenüber einer Registry oder einem anderen Agenten. Enthält die öffentliche Identität, Signatur und optional ein Zeitstempel-Token. |

<code diff>
AGLX/1.0 TCP
FROM: agent://node23.local
TO: registry://global.aglx.net
TYPE: auth.request
CONTENT-TYPE: application/json

{
    "agent_id": "8b1e9b45-4a2c-4a83-9341-34f58f1c83c2",
    "public_key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...",
    "signature": "rsa-sha256:a38c4e...",
    "timestamp": "2025-10-29T19:38:02Z"
}
</code>

**Antwort:**  
`auth.response` mit Statusinformationen.

===== auth.response =====

^ Feld ^ Inhalt ^
| **Kategorie** | Sicherheit / Authentifizierung |
| **Beschreibung** | Antwort auf eine Authentifizierungsanfrage. Bestätigt, ob ein Agent verifiziert wurde oder nicht. |

<code diff>
AGLX/1.0 TCP
FROM: registry://global.aglx.net
TO: agent://node23.local
TYPE: auth.response
CONTENT-TYPE: application/json

{
    "status": "VERIFIED",
    "trust_level": "zone_member",
    "expires": "2025-11-29T00:00:00Z",
    "signature": "rsa-sha256:b83f9e..."
}
</code>

**Antwort:**  
Keine weitere Antwort erforderlich.

===== key.rotate =====

^ Feld ^ Inhalt ^
| **Kategorie** | Sicherheit / Schlüsselmanagement |
| **Beschreibung** | Teilt anderen Agenten mit, dass ein Schlüssel erneuert oder ersetzt wurde. Dient zur Aufrechterhaltung von Vertrauensketten und Schutz vor Schlüsselkompromittierung. |

<code diff>
AGLX/1.0 TCP
FROM: agent://node17.local
TO: registry://global.aglx.net
TYPE: key.rotate
CONTENT-TYPE: application/json

{
    "old_key_id": "key-2025-01",
    "new_key_id": "key-2025-10",
    "public_key": "MIICIjANBgkqhkiG9w0BAQEFAAOCAQ8A...",
    "rotation_reason": "Scheduled renewal",
    "timestamp": "2025-10-29T19:40:18Z"
}
</code>

**Antwort:**  
`ack` oder ggf. `error`, wenn die Signaturprüfung fehlschlägt.

===== zone.join =====

^ Feld ^ Inhalt ^
| **Kategorie** | Sicherheit / Trust Zone Management |
| **Beschreibung** | Fordert den Beitritt zu einer Vertrauenszone an. Die Anfrage enthält das Zonenkürzel, den Agentenstatus und eine kryptografische Signatur. |

<code diff>
AGLX/1.0 TCP
FROM: agent://node51.local
TO: registry://global.aglx.net
TYPE: zone.join
CONTENT-TYPE: application/json

{
    "zone_id": "research-hub",
    "agent_id": "node51",
    "signature": "hmac-sha256:f31a2e...",
    "capabilities": ["nlp", "data.analyze"],
    "timestamp": "2025-10-29T19:43:05Z"
}
</code>

**Antwort:**  
`zone.confirm` oder `zone.deny`.

===== zone.confirm =====

^ Feld ^ Inhalt ^
| **Kategorie** | Sicherheit / Trust Zone Management |
| **Beschreibung** | Bestätigt den erfolgreichen Beitritt eines Agenten zu einer Trust Zone. Kann optionale Session-Tokens oder Zonenparameter enthalten. |

<code diff>
AGLX/1.0 TCP
FROM: registry://global.aglx.net
TO: agent://node51.local
TYPE: zone.confirm
CONTENT-TYPE: application/json

{
    "zone_id": "research-hub",
    "session_token": "ZT-88d3-11aa",
    "role": "member",
    "expires": "2025-11-29T00:00:00Z"
}
</code>

**Antwort:**  
Keine – Bestätigung gilt als erfolgreich.

===== zone.deny =====

^ Feld ^ Inhalt ^
| **Kategorie** | Sicherheit / Trust Zone Management |
| **Beschreibung** | Verweigert einem Agenten den Beitritt zu einer Zone, z. B. wegen unzureichender Reputation, fehlender Zertifikate oder Zonenkapazität. |

<code diff>
AGLX/1.0 TCP
FROM: registry://global.aglx.net
TO: agent://node51.local
TYPE: zone.deny
CONTENT-TYPE: application/json

{
    "zone_id": "research-hub",
    "reason": "Reputation below required threshold (0.6)",
    "timestamp": "2025-10-29T19:44:42Z"
}
</code>

**Antwort:**  
Keine weitere Reaktion erforderlich.

===== zone.leave =====

^ Feld ^ Inhalt ^
| **Kategorie** | Sicherheit / Trust Zone Management |
| **Beschreibung** | Meldet, dass ein Agent eine Zone verlässt oder entfernt wurde. Dient der Aufrechterhaltung der Zonenkonsistenz in der Registry. |

<code diff>
AGLX/1.0 TCP
FROM: agent://node51.local
TO: registry://global.aglx.net
TYPE: zone.leave
CONTENT-TYPE: application/json

{
    "zone_id": "research-hub",
    "reason": "Voluntary leave",
    "timestamp": "2025-10-29T19:46:00Z"
}
</code>

**Antwort:**  
`ack` – Bestätigung des erfolgreichen Austritts.

<box gl>
Sicherheitsnachrichten sind das Fundament des Vertrauens in AGLX.  
Sie stellen sicher, dass nur authentifizierte, signierte und berechtigte Agenten am Netzwerk teilnehmen können.  
Trust-Zonen erlauben flexible, sichere Segmentierung — vom privaten LAN bis zum globalen Grid.
</box>

===== Versionierung =====
  * **Modul:** Nachrichtenreferenz  
  * **Version:** 1.0 (Draft)  
  * **Stand:** 27.10.2025
  * **Autor:** Andreas Röne (Konzept)