]> Autonomous Agent Systems Initiative

yazid.benazzouz@gmail.com

Applications and Real-Time Network Working Group LLM Cognition Multi-Agent Transport Routing Discovery Large Language Transport (LLT) v1.0 is a specialized application-layer and transport-layer protocol designed to support real-time streaming, routing, and processing of Large Language Model (LLM) cognitive outputs. Unlike traditional serialization formats or line-based text stream layouts, LLT represents structured cognitive steps—such as internal thoughts, incremental execution tokens, self-revising contextual markers, tool coordination, and conversational state controls—as discrete, prioritizable, cryptographic transport frames. LLT v1.0 defines standard transport semantics over TCP, UDP broadcasts, and QUIC multiplexing to support highly efficient, low-latency, multi-agent cognitive synchronization across decentralized network topographies.

Introduction Modern Large Language Model (LLM) interactions rely heavily on Server-Sent Events (SSE) or simple WebSocket text channels streaming unstructured token buffers. While suitable for simple consumer-facing chatbots, these systems suffer from deep architectural limitations when coordinating advanced agentic and cognitive multi-agent workflows:

• Lack of Cognitive Hierarchy: Structural steps like chain-of-thought reasonings are mingled directly with final user answers, requiring fragile regular expression parsers on clients and leading to potential leaking of proprietary internal reasoning traces.
• Inability to Self-Correct in Real-time: When an agentic entity detects a mathematical error or factual contradiction midway through a stream, it cannot correct the output without resetting the entire connection or transmitting complete text rewrites.
• Synchronous Tool-Blocking: Execution of external tools blocks token streaming, making multi-second tooling gaps look like frozen network sockets to downstream clients.
• Inefficient Multiplexing: Concurrent parallel reasoning trees or multi-agent conversations require establishing separate, heavy socket handlers, introducing severe CPU and network overhead.

The Large Language Transport (LLT) Protocol solves these problems by elevating LLM cognitive steps into native, typed, multiplexed protocol frames. By defining a robust binary framing layer, an explicit cognitive state-machine, and modern transport-to-stream bindings (such as QUIC multiplexed streams), LLT makes agent reasoning fully predictable, secure, and low-latency.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Cognitive Layer (LLT-Core)

Semantic Foundations LLT models LLM interactions as active, stateful cognitive streams. An LLT stream does not merely carry text tokens; it models the active internal thought trajectory of an agentic entity as it reasons, coordinates, calls external systems, and formulates terminal responses. State: WAITING_FOR_TOOL| +-----------------------+ Streams +-----------------------+ ]]>

Standard Cognitive Message Type Taxonomy Every LLT frame MUST conform strictly to one of the following message type profiles. The numeric values designated below are binding and MUST NOT be dynamically reassigned:

REGISTER (0x01)

Requests registration with a central capability registry. It MUST contain details about the agent's identifier URI, local listening port, capability name, and semantic description.

DISCOVER (0x02)

Initiates dynamic or broadcast discovery targeting peer nodes with specific capability profiles.

TOKEN (0x03)

Represents incremental text tokens destined for delivery to the requesting end user or recipient agent.

THOUGHT (0x04)

Represents the model's internal reasoning or chain-of-thought analysis. This is prioritized separately from standard user-facing tokens, allowing client user interfaces to render reasoning traces inside collapsible tabs, logging consoles, or processing HUDs.

REVISION (0x05)

Issued when the agent detects a contradiction or factual error in its prior reasoning path. It contains the updated text segment along with contextual range coordinates to dynamically amend historical buffers.

CONTROL (0x06)

Transport-level lifecycle control frames. Supports fundamental signals such as PAUSE (temporarily halts processing during long-running tool executions), RESUME (restores processing), and CANCEL (instantly aborts calculation).

TOOL_CALL (0x07)

LLM-initiated invocation of registered client or peer capabilities, carrying exact structured argument JSON parameters over standard transport channels.

TOOL_RESULT (0x08)

Encapsulates results retrieved by executing tool calls, injected directly back into the LLM context.

RESULT (0x09)

The terminal payload declaring successful execution of goals.

ERROR (0x0A)

Conveys fatal transport, routing, execution, or cognitive failures.

CAPABILITY_RESPONSE (0x0B)

Conveys the routing response mapping a requested semantic capability back to a physically reachable transport endpoint address and port.

Cognitive State Machine An LLT Agent is modeled as a state transition machine. Permitted transitions are illustrated in the diagram below: | WAITING_FOR_TOOL | +------------+ +-------------------+ | | v v +------------+ +-------------------+ | REVISING | --> | INTERRUPTED | (Error/Cancel) +------------+ +-------------------+ | | v v +------------+ | | COMPLETED | <-------------+ +------------+ ]]> The states are defined as follows:

• THINKING: Initial state while performing deep logical reasoning under THOUGHT frames.
• STREAMING: Actively transmitting TOKEN frames to the recipient.
• REVISING: Transmitting self-corrections or logical backtracks under REVISION frames.
• WAITING_FOR_TOOL: Suspended while awaiting execution results of tools under TOOL_CALL.
• INTERRUPTED: Terminated early due to exceptions, timeouts, or lifecycle CONTROL frames.
• COMPLETED: Terminal success state representing converged goals.

Cognitive Error Classifications To maintain high reliability in multi-agent environments, LLT designates four distinct cognitive error classifications:

ReasoningError

Triggers when the model encounters unresolvable logical loops, deep self-contradictions, or invalid path resolutions.

ToolInvocationError

Issued when client tools or remote capability interfaces crash, fail, or return responses that break payload schematics.

RevisionConflictError

Raised when an incoming REVISION attempt references coordinates, buffers, or historical ranges that do not exist or violate integrity locks.

CognitiveTimeoutError

Occurs when logical execution steps exceed negotiated network budgets or deadline limitations.

Framing Layer (LLT-Frame) LLT MUST support both JSON Framing and Binary Framing encoding profiles. Client and server systems MUST negotiate the active framing profile during the initial network handshake.

JSON Framing Specification A standard LLT JSON packet IS structured as a single, valid JSON object. It MUST contain the following outer keys: Where:

• type: Integer representing the cognitive frame type (e.g. 3 for TOKEN).
• stream_id: Big-endian unsigned 16-bit integer designating multiplexed channels.
• flags: Integer bitmask carrying protocol modifiers (SIGNED=0x01, MULTIPLEXED=0x02, COMPRESSED=0x04, FINAL=0x08).
• sender_uri: A UTF-8 semantic string identifier of the originating agent/service.
• recipient_uri: UTF-8 semantic string identifier of the target destination.
• payload: An arbitrary JSON dictionary conforming to the payload requirements of the frame's type.
• signature: Optional 64-byte hex-encoded Ed25519 cryptographic signature (present only if flags & 0x01 is true).

Binary Framing Specification To maintain microsecond latency constraints, the binary encoding profile enforces a strict 16-byte fixed-width header followed by variable-length fields: Header layout fields are defined as:

Magic Header

Bytes 0-3 MUST equal 0x4C 0x4C 0x54 0x01 (ASCII bytes "LLT" paired with version byte 0x01).

Message Type

Byte 4 is an 8-bit unsigned integer stating the frame type profile.

Flags

Byte 5 is an 8-bit bitmask defining frame traits (0x01: SIGNED, 0x02: MULTIPLEXED, 0x04: COMPRESSED, 0x08: FINAL).

Stream ID

Bytes 6-7 is a Big-Endian 16-bit unsigned integer grouping parallel execution threads.

Sender Len

Bytes 8-9 defines the exact length in bytes of the Sender URI UTF-8 string that immediately follows the fixed header.

Recipient Len

Bytes 10-11 defines the exact length in bytes of the Recipient URI UTF-8 string that immediately follows the Sender URI buffer.

Payload Length

Bytes 12-15 is a Big-Endian 32-bit unsigned integer representing the byte length of the trailing payload buffer.

Discovery Protocol (LLT-DP) To support dynamic capability resolution without static network endpoints, LLT formalizes the LLT Discovery Protocol (LLT-DP). This sub-protocol defines how cooperative agent nodes locate, advertise, and bind system capabilities over physical channels.

Capability Advertisement Schema An active agent node MUST register its capability utilizing the REGISTER (0x01) message type. The payload of a REGISTER frame MUST conform to the following JSON schema: The properties are defined as:

• uri: The canonical semantic identifier URI of the registered agent (MUST be unique within the cooperative cluster).
• port: The local active TCP or UDP port number the registering agent is listening on.
• capability_name: A short, human-readable name string describing the provided skill.
• capability_description: A detailed descriptive paragraph containing key semantic contexts to support fuzzy neural classification and routing matches.

Capability Query Schema A searching node (such as an XML Planner) initiates query resolution by dispatching a DISCOVER (0x02) frame. The payload of the DISCOVER frame MUST conform to the following JSON schema: Where description serves as the semantic target string. The matching node or central capability registry MUST evaluate the semantic affinity (either using mechanical substring checks or LLM-based embeddings and classifications) and reply with a CAPABILITY_RESPONSE (0x0B) frame conforming to this schema: If no registered capabilities match the semantic target, the responder MUST return a CAPABILITY_RESPONSE where match_found is set to false, and the address details are omitted.

Security and Trust Integration in Discovery Discovery frames are highly susceptible to malicious activity. Therefore:

• Every REGISTER and DISCOVER frame MUST have the SIGNED (0x01) flag set, containing a valid signature computed by the originating agent's private key.
• Listening directory agents MUST drop any register request carrying an unsigned frame or a signature failing verification, immediately penalizing the offender's local Trust Score.

Transport Sockets and Bindings (LLT-Transport)

LLT/TCP Binding For point-to-point connections where reliability is guaranteed by the OS TCP engine. Implements standard connection backpressure mechanics, delaying token-generation and processing loops when the local socket output descriptors block or overflow.

LLT/UDP Broadcast Discovery Agents SHOULD employ standard UDP broadcast channels (defaulting to Port 5005) to scan nearby subnets for active capabilities. The discovery protocol flow MUST execute as follows:

1. The initiator broadcasts a signed DISCOVER frame containing the semantic goal to port 5005.
2. Listening multi-agents inspect capabilities and, upon finding a valid local semantic match, MUST stream a unicast CAPABILITY_RESPONSE containing physical host information and capability metadata back to the initiator's port and source IP address.

LLT/QUIC Multiplexing LLT over QUIC represents the recommended gold-standard transport binding. It bypasses head-of-line blocking by mapping separate cognitive frames to isolated virtual sub-streams (e.g., Stream Index 10 for Thoughts, Stream Index 20 for Final Tokens) over a single physical QUIC socket. To ensure seamless operational continuity, LLT over QUIC implementations MUST support dynamic connection migration, allowing agents to transition between host gateways, cell providers, or local network routers without interrupting on-going multi-turn reasoning cycles or resetting conversation state blocks.

Security and Trust Architecture (LLT-Security) LLT operates inside a decentralized peer-to-peer or server-client topology. Security is established through Ed25519 Cryptographic Signatures and a feedback-driven Trust Score System.

Ed25519 Signatures and Canonicalization When the SIGNED (0x01) modifier flag is set in the header, the sender MUST append exactly 64 bytes of Ed25519 signature directly at the absolute end of the transmission (following the payload). The signature is computed over the serialized representation of the binary payload or the canonicalized representation of the JSON outer packet sorted alphabetically (no padding, carriage returns, or spacing characters), ensuring robust end-to-end payload integrity and non-repudiation.

Dynamic Trust Score System Every participant node on an LLT network MUST maintain a local trust database pairing peer URIs with numeric scores configured within the range: Implementations MUST initialize a peer node's trust score to exactly 0.5 upon receiving its first frame, unless explicitly overridden by local administration parameters. Correct and verified cryptographic packets, accurate schema formatting, and logical coherence yield progressive score modifications (incremental +0.02 awards), while cryptographically broken payloads or persistent logical contradictions MUST triggers instant score penalty deducts (-0.15 deductions), paving the way for adaptive firewalls and routing isolations.

IANA Considerations This document requests IANA to establish a new registry for "Large Language Transport (LLT) Cognitive Message Types" on the "Large Language Transport (LLT) Parameters" page. The initial values of this registry are:

• 0x01: REGISTER
• 0x02: DISCOVER
• 0x03: TOKEN
• 0x04: THOUGHT
• 0x05: REVISION
• 0x06: CONTROL
• 0x07: TOOL_CALL
• 0x08: TOOL_RESULT
• 0x09: RESULT
• 0x0A: ERROR
• 0x0B: CAPABILITY_RESPONSE

In addition, dynamic registration of specialized capabilities or extensions MAY register value extensions within the range 0xC0 to 0xFF via experimental RFCs or designated expert reviews.

Security Considerations LLT networks are susceptible to standard transport-layer attacks as well as unique cognitive and semantic manipulation vectors. Implementations MUST apply the following security profiles to mitigate risks:

Replay Attacks Attackers may intercept signed cognitive frames (e.g., a TOOL_CALL authorizing a financial transaction) and replay them over active socket joints. To mitigate this threat, every payload MUST incorporate a monotonically increasing sequence ID paired with a precision Unix timestamp. Receiving nodes MUST drop any arrived packet where the sequence ID is less than or equal to the maximum verified historical ID of that stream, or where the timestamp variance exceeds 5.0 seconds.

Downgrade Attacks Malicious intermediate nodes could intercept frames and clear the SIGNED (0x01) or COMPRESSED (0x04) modifier flags in the header to force recipients into parsing unsecure or unoptimized text branches. Since flags are housed inside the header bytes, headers MUST be included in the signed digest computation. Any signature verification MUST fail if the header attributes are tampered with.

Discovery Spoofing In local UDP configurations, rogue nodes can broadcast fake DISCOVER_RESPONSE or REGISTER frames to hijack capability queries and route agent logic to malicious endpoints. Implementations MUST require discovery responders to include their cryptographic host key certificate. Initiators MUST verify the certificate chain against structured anchor trust stores before executing dynamic connections.

Signature Verification Failures If signature verification fails during transit, the receiver MUST immediately discard the packet, terminate the physical connection, and deduct exactly 0.25 from the sender's local Trust Score. The event SHOULD be logged prominently in diagnostic streams.

Trust Score Poisoning Malicious nodes could artificially inflate their trust metrics by executing rapid sequences of insignificant, correct placeholder transfers, only to subsequently inject corrupted cognitive payload blocks once high status is acquired. Algorithms MUST apply decay models favoring long-term interaction history, and enforce irreversible trust score ceilings for nodes with volatile transfer behaviors.

QUIC Migration Security Rogue agents may attempt to hijack active streams during connection migration by spoofing source IP and CID details. Under QUIC bindings, systems MUST use standard QUIC path-validation procedures, verifying ownership of the new address through random 64-bit cryptographic challenge tokens before restoring active cognitive streams.

Privacy Considerations and Metadata Leakage Unencrypted LLT streams expose cognitive thoughts (THOUGHT) and target skill descriptions (DISCOVER), conveying sensitive behavioral contexts and systemic configurations to intercepting entities. Therefore, LLT transmissions MUST be wrapped inside TLS-encrypted tunnels (such as standard TLS v1.3 inside TCP or QUIC).

Normative References Informative References

Appendix A. LLT Handshake Diagram (1-RTT QUIC) | | | | Server Hello [CID: 0x9fb5, Handshake Key, Trust] | |<-----------------------------------------------------| | | | Signed GOAL Frame [Stream: 10, State: thinking] | |------------------------------------------------------->| ]]>

Appendix B. LLM-To-Cognitive Frame Parsing Flow Index scan completed." | +======> LLTCognitiveParser Processes Tags | +===> Emits: 1. TOKEN: "Here is my analysis... " 2. THOUGHT: "Index scan completed." ]]>