1 Introduction↩︎

Group travel planning aims to find an itinerary that balances multiple objectives among multiple participants, such as cost, travel time, and individual preferences. Prior work has focused on supporting human groups in determining balanced itineraries [1]–[3]. Meanwhile, in broader domains, recent studies have explored the use of persona-based Large Language Model (LLM) agents to simulate human behavior [4]–[7]. This emerging direction is also expected to be relevant to group travel planning. For example, automatic evaluation in such simulation environments reduces the costs of large-scale behavioral analysis in group travel planning and the evaluation of existing group travel recommender systems. In application, users could interact with LLM agents representing group members who are unable to participate in the actual discussion and collaboratively determine an itinerary with them.

To address this emerging need, we propose AI Tour Meeting, a group travel planning framework powered by multiple LLM agents. Each agent is instantiated with a distinct persona and collaborates with the others to find an itinerary that satisfies their constraints and preferences through natural-language discussion. Our framework provides interfaces to orchestrate this process. Compared with existing persona-based agent simulations [4], [5] and general-purpose multi-agent frameworks [8], [9], our framework provides domain-specific abstractions for group travel planning, including a structured itinerary representation, explicit proposal-voting workflows, and constraint validation and metric monitoring specialized for travel planning. This allows users to focus on their use cases without implementing the required functionality from scratch using a general-purpose framework.

In the following, we describe the technical details of our framework and validate whether it can successfully complete discussions using Qwen 3.5 and GPT models of different sizes. We then demonstrate its effectiveness as a simulation tool through analysis examples conducted using the framework.

2 Proposed Framework: AI Tour Meeting↩︎

Figure 2 shows the overview of our framework: we first set up both LLM participants with distinct personas and a discussion workflow, then start the meeting among them aligned with the specified workflow. The meeting begins with the conversation phase, in which participants take turns searching information, asking questions, and proposing itineraries. Once an itinerary is proposed, it transitions to the voting phase, where the participants decide whether to accept or reject it. This two-phase process continues until all participants are satisfied with the currently accepted itinerary.

In this section, we describe the definitions of itineraries and participants, the workflow options, the monitored metrics, and the user interface.

2.1 Itinerary↩︎

An itinerary proposed during the meeting consists of information about destinations and the transportation between them, and is defined as follows: \[R = (d_1, d_2, \dots, d_{N}),\]

where \(R\) is the itinerary, \(d_i\) is the \(i\)-th destination. Each destination includes a name, description, monetary cost, arrival time, duration of stay, transportation mode from the previous destination, transportation cost, and transportation duration.

2.2 Participant↩︎

Each LLM agent (participant) is instantiated with a distinct persona. The persona consists of the following attributes: Name specifies their name; Background specifies their experience or situation; Personality specifies their stable traits; Preference specifies their preferences related to the tour; Goal specifies their personal goals in the tour; Role selects their role in the meeting from either facilitator or attendee; Tone specifies their speaking tone such as formal or friendly; Explanation style selects a strategy for convincing others to accept their proposal, from either subjective explanation, contrastive explanation [10] or both. The former provides subjective opinions of the proposal based on their preferences. The latter explains the objective pros and cons by comparing the proposed route with the current route in terms of objective metrics such as cost, time, and number of destinations. We can select an LLM that instantiates the participant with model parameters such as temperature and seed. Both commercial LLMs and local LLMs (via Ollama or vLLM) are supported, Context management methods, including auto-compaction and history truncation, can be also configured individually for each participant.

2.2.0.1 Actions

The \(\mathrm{persona}\) is given to the LLM as a system prompt, and the LLM participant takes actions during the meeting while role-playing according to the given \(\mathrm{persona}\). The meeting proceeds in a turn-based manner, and each participant may take multiple actions during their single turn. The action at each step \(s\) within a turn is defined as follows: \[(a^{\mathrm{type}}_s, \mathrm{msg}_s, a_s) = p_m(\mathrm{persona}_m, H_{s-1}), \label{eq:action}\tag{1}\] where \(p_m\) is the \(m\)-th LLM participant, \(a_s^\mathrm{type}\) is the action type, \(\mathrm{mgs}_s\) is the message associated with the action, \(a_s\) is the taken action, and \(H_{s-1}\) is the meeting history, which includes system messages for managing the discussion workflow \(\mathrm{msg}_\mathrm{sys}\) and the past actions taken by all the participants \(((a_1^\mathrm{type}, \mathrm{msg}_1, a_1), \dots, (a_{s-1}^\mathrm{type}, \mathrm{msg}_{s-1}, a_{s-1}))\). The action \(a_s\) varies depending on the selected action type \(a^\mathrm{type}_s\), as follows:

\[a_s = \left\{ \begin{array}{ll} \rowcolor{midcolor} \mathrm{Search}(q_s) & \text{if } a^{\mathrm{type}}_s = \mathrm{search} \\ \rowcolor{midcolor} \mathrm{Ask}(p_{m'}, q_s) & \text{if } a^{\mathrm{type}}_s = \mathrm{ask} \\ \rowcolor{midcolor} \mathrm{Reflect} & \text{if } a^{\mathrm{type}}_s = \mathrm{reflect} \\[4pt] \rowcolor{convcolor} \mathrm{Propose}(R_s) & \text{if } a^{\mathrm{type}}_s = \mathrm{propose} \\ \rowcolor{convcolor} \phi & \text{otherwise} \\[4pt] \rowcolor{votecolor} \mathrm{Score}(v_s) & \text{if } a^{\mathrm{type}}_s = \mathrm{scoring} \\ \rowcolor{votecolor} \phi & \text{otherwise.} \end{array} \right.\]

There are two types of actions: intermediate and terminal actions. Intermediate actions may be taken multiple times within a turn, whereas once a terminal action is taken, the current turn ends. The intermediate action types include \(\mathrm{search}\), \(\mathrm{ask}\), and \(\mathrm{reflect}\). \(\mathrm{search}\) issues a query \(q_s\) to retrieve information such as location or cost of destinations via web search. \(\mathrm{ask}\) asks another participant \(p_{m'}\) a question \(q_s\) and receives a response. \(\mathrm{reflect}\) organizes and reviews the discussion conducted so far. The

action types differ between the conversation phase and the voting phase. In the conversation phase, they include \(\mathrm{propose}\), \(\mathrm{satisfied}\), and \(\mathrm{pass}\). \(\mathrm{propose}\) proposes a new itinerary \(R_s\). \(\mathrm{satisfied}\) indicates that \(p_m\) is satisfied with the current route. \(\mathrm{pass}\) ends their turn without expressing a specific position. In the voting phase, they include \(\mathrm{accept}\), \(\mathrm{reject}\), and \(\mathrm{score}\). \(\mathrm{accept}\) votes for the proposed itinerary, \(\mathrm{reject}\) does not votes for the proposed itinerary, and \(\mathrm{score}\) assigns a score \(v_s\) to the proposed route.

2.3 Discussion workflow↩︎

A tour meeting consists of a global goal, participants, constraints, a turn rule, and a voting rule. The global goal is a high-level objective shared among all participants, e.g., planning a one-day sightseeing tour in Tokyo. Each participant advances the discussion in pursuit of their own personal goal while remaining aligned with the global goal. Constraints restrict the itinerary in terms of travel date, budget, and time window.

The tour meeting proceeds according to the specified turn rule, under which participants sequentially take the actions defined in Eq. (4) multiple times within their turns. This normal state is referred to as the conversation phase. Once a participant proposes a itinerary (i.e., terminates the turn with \(a^\mathrm{type}=\mathrm{propose}\)), the process transitions to the voting phase. In this phase, all participants except the proposer cast votes on the proposed itinerary. After collecting all votes, the acceptance or rejection of the proposed route is determined in accordance with the specified voting rule. If the itinerary is accepted, the current itinerary is replaced with the proposed one; if it is rejected, the current itinerary remains unchanged. The process then returns to the conversation phase, and the turns resume with the next participant after the proposer.

When all participants consecutively indicate satisfaction with the current route (i.e., terminate their turns with \(a^\mathrm{type}=\mathrm{satisfied}\)), consensus is considered reached, and the meeting concludes. In practice, the termination condition of the meeting may also be constrained by a maximum number of turns or a maximum execution time, in addition to the unanimous agreement.

Algorithm 4 organizes the discussion workflow described above. In the following, we describe turn rules and voting rules available in our framework.

2.3.1 Turn rule↩︎

Our framework supports standard four turn rules, along with two additional options to make them more flexible. There are five types of turn rules: Round robin rotates participants in a fixed cyclic order; Inviting lets the current speaker determine the next speaker; Facilitating assigns an additional turn to a facilitator after each turn, who then determines the next speaker; Random rotates participants randomly; Parallel lets all participants vote simultaneously (only for the voting phase). Note that different turn rules may be applied separately to the conversation and voting phases.

In addition, when the Balancing option is enabled, speaking turns are organized into cycles such that all participants take turns once per cycle to ensure fairness. When the Volunteer option is enabled, participants are allowed to select the \(\mathrm{pass}\) as a terminal action and skip their turn (i.e., only those who wish to speak take a turn).

2.3.2 Voting rule↩︎

Our framework also supports standard five voting rules. In Majority and Unanimous, participants cast a binary vote (accept or reject) on the proposed itinerary. The proposed itinerary replaces the current itinerary if it receives a majority of accept votes in majority voting, or if all participants vote accept in unanimous voting. In Single decider, a specified participant alone cast the binary vote, and the current itinerary is updated accordingly. In Most pleasure and Least misery, participants assign a score to the proposed itinerary according to 10-point rubrics. The proposed itinerary replaces the current itinerary if, in the former, the sum of all participants’ scores is greater than or equal to that of the current itinerary, or, in the latter, the minimum score across participants is greater than or equal to that of the current itinerary.

None

2.4 Monitoring and metrics↩︎

Our framework collects various metrics to analyze both system-level performance and the dynamics of discussions. The system-level metrics include agents’ token usage, the number of retries, and the number of time violations at destinations in the proposed itineraries. The discussion-dynamics metrics include the number of meeting steps and turns, the message history, the distribution of executed action types, the distribution of votes and scores, and the details of the proposed itineraries. Users can leverage these metrics to analyze discussions flexibly from multiple perspectives. Basic analyses, such as computing representative statistics and distributions for each metric, can be performed using built-in functions.

2.5 User interface↩︎

Figure 5 shows the snapshots of meeting settings and meeting dialogue, and analytics dashboard in the GUI of AI Tour Meeting. Participants and meetings can be easily configured through pull-down selections and text inputs, and the meeting can be browsed in a chatbot-style dialogue view. The analytics dashboard allows users to visually explore some basic analytical metrics. Our framework also supports Python API. As shown in Figure 6, users can flexibly configure and launch meetings at scale with only a few lines of code.

3 System Validation↩︎

First, we validate whether our framework runs robustly across different models and model sizes.

3.0.0.1 Setup

We use gpt-5.4-mini [11] to generate 50 synthetic meetings with three participants whose preferences partially overlap and contain moderate conflicts that can be resolved through adjustment. We then run these meetings using five different LLMs to instantiate the participants: Qwen3.5-2B/4B/9B [12], gpt-oss-20b [13], gpt-5.4-mini (medium effort). The temperature is set to 0.6 for the local models and 1.0 for gpt-5.4-mini. Local models are served with vLLM [14] on a single RTX A6000 GPU (48GB). All meetings are configured with round-robin turns, majority voting, a 100-turn limit, a time window of 09:00–18:00, and a budget of $100 per participant.

3.0.0.2 Results

Table ¿tbl:tab:validation? shows the validation results. We report the following metrics: completion denotes the proportion of meetings that ended upon reaching consensus or the maximum number of turns, with at least one itinerary accepted; consensus denotes the proportion of meetings that ended upon reaching consensus; constraint error denotes the proportion of newly proposed itineraries that violated the constraints; action failure denotes the proportion of actions that failed after more than three retries; and turns, duration, and tokens denote the corresponding average values. The results show that all models except for Qwen3.5-2B achieve a 100% completion rate and the rates of constraint errors and action failures decrease as model performance improves. Qwen3.5-2B produces several invalid actions, including repeating the same message and rejecting proposals by referring to a nonexistent “current route.” Overall, our framework runs properly with LLMs that perform comparably to or better than Qwen3.5-4B.

4 Analysis Examples↩︎

In this section, we demonstrate the utility of our framework by providing two analysis examples conducted using our framework.

4.1 Preference conflict↩︎

4.1.0.1 Setup

This example analyzes how meeting dynamics change depending on the degree of preference conflict among participants. We generate 50 synthetic meetings for each of three settings: aligned assigns aligned preferences among the three participants; mixed assigns mixed preferences as in the system validation; conflicting assigns conflicting preferences that require at least one participant to compromise on at least one aspect. After each meeting, we also evaluate each participant’s satisfaction with the final itinerary on a 1–10 scale using an LLM-as-a-judge. All meetings use the inviting turn rule and Qwen-3.5-9B as participants, with all other settings and constraints unchanged from the system validation.

4.1.0.2 Results

Table ¿tbl:tab:alignment? shows that as the degree of preference conflict increases, the number of turns and itinerary proposals both increase, resulting in longer discussions. Meanwhile, as preference conflict increases, the consensus rate and average satisfaction score decrease, while the victim rate—the proportion of participants with a satisfaction score of 4 or lower—increases. These results suggest that discussions among LLM participants reproduce a natural phenomenon observed in human deliberation: greater conflict leads to longer discussions and makes it harder to find a proposal that satisfies everyone.

Figure 7 shows two representative patterns of the consensus-building process under preference conflict. Figure 7 (a) shows a case in which Elena’s proposals are repeatedly rejected by the other two participants. Eventually, Jisoo urges Elena to conclude the meeting, and Elena compromises to end the discussion. Elena assigns the final itinerary a score of 3 in the post-hoc evaluation, indicating that she agreed despite remaining dissatisfied. In contrast, Figure 7 (b) shows a case in which, after Noah’s proposal was rejected twice, Leila intervened and proposed an itinerary on his behalf that incorporated his preferences.

4.2 Speaking order↩︎

4.2.0.1 Setup

This example analyzes how speaking order affects the proposal acceptance rate. We run each of the 50 meetings at three different conflict levels under a round-robin turn rule with a Latin-square seat rotation: each meeting is executed three times, rotating the participants through the speaking positions \(p_1\)–\(p_3\). The other settings and constraints are the same as the previous analysis example.

4.2.0.2 Results

Figure 8 shows no statistically significant difference across speaking positions in aligned. In mixed and conflicting, however, proposals from the second and third participants have significantly higher acceptance rates than those from the first participant. This may be because participants have no preference conflict in aligned, so proposals are likely to be accepted regardless of speaking order. On the other hand, in mixed and conflicting, preference conflicts make it difficult for the first participant to propose an itinerary that satisfies the preferences of the others. Later participants can use more feedback from earlier proposals and voting results to propose itineraries that better reflect the preferences of others, resulting in higher acceptance rates. Additionally, we found that most accepted proposals from the first participant were made after asking the others for input. In contrast, participants who spoke later could often make accepted proposals without asking, relying instead on information from the preceding discussion.

5 Conclusion↩︎

In this paper, we proposed a new LLM-based group travel planning framework and demonstrated its validity and utility through system-level evaluation and use cases. We believe that our framework supports research on the behavior of LLM agents and automatic evaluation of recommender systems for group travel planning. Beyond these uses, it may also enable new applications, such as recommender systems where LLM agents act on behalf of group members who are unable to participate and provide ideas from their perspectives (see Appendix 8).

6 License↩︎

Our code is licensed under NTT’s proprietary license, which restricts the use of our code to research purposes only. Since our framework is designed primarily as a simulation tool to support research on group travel planning, this restriction does not pose a significant limitation.

7 Related Work↩︎

7.0.0.1 Group travel planning

[1] proposed a system that supports consensus building by monitoring chat discussions and adapting recommendations to evolving user preferences. [2] proposed a method that integrates member relationships and POI information through attention mechanisms to optimize group itinerary recommendation. More recent work has investigated whether LLMs can help group travel planning while resolving preference conflicts among group members [3]. These works focus on supporting humans, whereas our work explores the use of LLM agents as proxies for humans in group travel planning.

7.0.0.2 Travel planning with LLM agents

Recent work has proposed benchmarks for evaluating the travel-planning capabilities of LLMs [15], [16], as well as methods for improving their performance [17], [18]. However, these studies primarily focus on individual travel planning.

7.0.0.3 LLM-based multi-agent simulation

LLM-based multi-agent simulation has been widely studied [4]–[7]. However, to our knowledge, no prior work has specifically addressed such discussion in group travel planning. From an implementation perspective, although general-purpose multi-agent frameworks [8], [9] provide basic functionality for orchestrating agent interactions, users must implement domain-specific components for group travel planning. Our framework provides these components by default, allowing users to focus on their use cases.

8 Human Participant (Interactive Mode)↩︎

AI Tour Meeting also allows human users to participate in meetings. At their turn, they can interact with the LLM participants through the chat box by executing the same actions defined in Eq. (1 ) as the LLM participants. Figure 9 shows snapshots of the chat box during voting, when asking another participant a question, and when proposing an itinerary. When proposing an itinerary, users can manually modify destinations. By clicking the “Generate with AI” button, they can interact with an LLM and have it refine their proposal. A use case of this feature is to represent friends who are unable to attend the meeting as LLM participants based on their personas. By discussing the itinerary with these agents, users can incorporate the absent participants’ perspectives into the tour planning.

9 Additional Validation: Participant Size↩︎

9.0.0.1 Setup

We additionally validate whether the framework correctly completes meetings as the number of participants increases. We generate 50 synthetic meetings for each participant size (5 and 10 participants) using GPT-5.4-mini, and evaluate them with Qwen3.5-9B under the same settings as the system validation.

9.0.0.2 Result

Table ¿tbl:tab:validation95size? shows that our framework maintains a 100% completion rate as the number of participants increases to 5 and 10. Although the constraint error rate increases slightly as the group size increases, because itineraries tend to include more destinations, it remains sufficiently low. Additionally, we found that the number of turns grows slightly faster than the number of participants.

10 Context Management↩︎

10.0.0.1 Input context

Figure 10 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 (Eq. 1 ) of all participants in each phase in speaking order. 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. Note that each participant action is also prefixed with the speaker’s name. 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.

10.0.0.2 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. In this paper, the maximum number of retries is set to three.

10.0.0.3 Context compaction

Our framework supports three context compaction methods: summarization, turn-window truncation, and token-based truncation. In the summarization method, 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. The turn-window method retains only the most recent fixed number of turns and removes all earlier turns from memory. The token-based truncation method retains only the most recent context up to a specified number of tokens and removes the rest.

11 Prompts↩︎

Figures 11–17 list the main prompts used by our framework: the system prompt that encodes the persona (Section 2.2), the phase instructions in the conversation and voting phases, the prompts for inviting other participants, and the post-meeting satisfaction evaluation prompt used in Section 4.1. The system prompt can be customized by users. Placeholders in curly braces (e.g., {name}, {format_instructions}) are filled at runtime.

None

None

promptboxtop=tablegreen, title=Phase instruction for itinerary proposal in the conversation phase, listing only, listing options=style=promptstyle You have decided to propose a route in your turn. Present the route you determined.

# History of your turn is as follows: action_history

# Output Format Now, output your proposed route as an ordered list of destinations while setting a natural conversational explanation in the ‘message’ field. Ensure that the arrival time at each destination is consistent with the arrival time at the previous destination, the duration of stay, and the travel time between locations. format_instructions

None

None

None

None

References↩︎