Input context

The figure below shows the structure of the input context of a participant. The context starts with a system prompt defining the participant's persona and the meeting settings, after which phase markers and action logs are appended alternately as the memory. During the participant's turn, the actions taken so far in the current turn and the phase instructions are appended to this memory, and the model generates the next action. Once the turn ends, all the actions are recorded in the action logs.

The phase marker is a system message that indicates the boundary between the conversation and voting phases. Action logs store the actions of all participants in each phase in speaking order. The phase instruction is temporary context inserted immediately before action generation; it describes the actions available in the current phase and specifies the JSON schema for the output.

When constructing the LLM input, the system prompt is assigned the system role, while phase markers and phase instructions are assigned the user role. The participant's own previous actions are assigned the assistant role, whereas actions from the other participants are assigned the user role, making it easier for the model to distinguish between itself and the other participants. Each participant action is also prefixed with the speaker's name.

Retry loop

If an action output contains invalid JSON or violates a time or cost constraint in the proposed itinerary, the corresponding error message is temporarily appended to the end of the context, and the model is prompted to generate the output again. The maximum number of retries defaults to three.

Context compaction

To keep the context within the LLM's context window during long meetings, the framework supports three context compaction methods. They can be configured individually for each participant.

Summarization

A specified portion of the context is summarized and inserted immediately after the system prompt, followed by the remaining previous-turn context in its original form.

Turn-window truncation

Retains only the most recent fixed number of turns and removes all earlier turns from memory.

Token-based truncation

Retains only the most recent context up to a specified number of tokens and removes the rest.