Intelligent Agent for Automated Data Analysis, Dashboard Generation, and Training/Evaluation in Hospitality KPIs

1. Introduction

The hospitality industry faces increasing pressure to leverage operational data for revenue optimization, demand forecasting, and strategic decision-making. Hotels generate vast amounts of data from property management systems, booking platforms, and operational metrics, yet many establishments struggle to transform these data into actionable insights. The challenges are multifaceted: data arrive in inconsistent formats, Key Performance Indicator (KPI) calculation requires specialized expertise, and staff training in data interpretation demands significant time and resources.

Revenue managers must routinely process CSV files with heterogeneous structures—different separators, date formats, missing values, and poorly typed columns. Manual data cleaning takes hours before any analysis can begin. KPI calculations such as Revenue per Available Room (RevPAR), Average Daily Rate (ADR), Gross Operating Profit per Available Room (GOPPAR), and occupancy optimization require both domain knowledge and technical proficiency. Creating visualizations and management dashboards typically involves spreadsheet software prone to human error and lacking standardization between properties. Furthermore, training staff to interpret KPIs and apply them to operational decisions remains resource-intensive, particularly for independent hotels and small chains without dedicated analytics teams.

Recent advances in generative artificial intelligence, particularly Large Language Models (LLMs), present new opportunities to address these challenges. Models such as GPT-3 [2] and subsequent iterations have demonstrated remarkable capabilities in natural language understanding, code generation, and complex reasoning tasks. These models can interpret natural language queries, generate executable code for data processing, provide contextual explanations, and adapt responses based on user expertise. The Transformer architecture [1] underlying these models enables the processing of long contexts and the generation of coherent structured outputs in diverse tasks.

However, applying generative AI to specialized business domains introduces significant challenges. The generated code must be validated for correctness and security before execution on operational data. LLM outputs can be inconsistent or hallucinate non-existent information. Integration with existing data processing workflows requires careful architectural design. Security concerns arise when running AI-generated code with access to sensitive business metrics. Despite these challenges, the potential benefits—automated data processing, intelligent KPI suggestion, dynamic visualization generation, and personalized training—justify systematic investigation of integrated AI-powered analytics systems.

1.1. Motivation and Research Opportunity

The convergence of accessible generative AI APIs, mature data science libraries, and cloud infrastructure creates a compelling opportunity to develop domain-specific intelligent agents. Python’s ecosystem provides robust tools for data manipulation (Pandas [3]), numerical computing (NumPy [4]), machine learning (scikit-learn [5]), and visualization (Plotly). Cloud platforms enable rapid deployment and scaling. Conversational AI frameworks simplify integration of LLMs with custom business logic.

From a business perspective, the hospitality sector’s emphasis on operational efficiency and cost optimization creates strong demand for automation tools. Independent hotels and small chains, lacking dedicated data science teams, would particularly benefit from systems that democratize access to advanced analytics. The gap between data availability and data utilization represents both a challenge and an opportunity—many hotels possess rich operational data but lack the technical capacity to extract value from it.

1.2. Proposed Approach

This paper presents an intelligent agent specifically designed for hospitality data management, KPI analysis, dashboard generation, and staff training. Our system integrates Google Gemini 2.0/2.5 Flash within a modular Python-based architecture that encompasses:

1.

Automated CSV Processing: Multi-stage preprocessing pipeline with format detection, type inference, date normalization, duplicate removal, and K-Nearest Neighbors imputation for missing values

2.

AI-Driven KPI Generation: LLM-based KPI suggestion with user validation, dynamic code generation for calculations, three-tier security validation (syntax, pattern matching, semantic checks), and sandboxed execution with timeout enforcement

3.

Interactive Dashboard Creation: Automated generation of HTML dashboards with Plotly visualizations, temporal organization, year-over-year comparisons, and responsive layouts

4.

Contextual Training Delivery: Structured KPI documentation, natural language question answering, and concept explanation grounded in hotel management contexts

5.

Adaptive Assessment: Multi-format question generation (true/false, multiple-choice, open-ended, situational), automated evaluation with LLM-based rubric scoring, and personalized feedback with improvement suggestions

The system employs a conversational interface (Chainlit) that guides users through complex workflows using natural language, reducing cognitive load and eliminating the need for technical expertise. A distinctive feature is the integration of secure AI-driven code generation: rather than relying on predefined calculation templates, the system dynamically generates Python code based on dataset characteristics and user-specified KPIs, validates against security patterns, executes in isolated subprocesses, and verifies output integrity.

1.3. Contributions

The primary contributions of this research are:

1.

Integrated Architecture: A complete system design combines conversational AI, data processing, generative models, visualization, and training within a unified framework, demonstrating how these components can work together securely and effectively

2.

Secure Code Generation Methodology: A novel approach to LLM-driven code generation with multi-tier validation and sandboxed execution that maintains security while enabling flexibility in KPI definition and calculation

3.

Automated CSV Processing Pipeline: A robust preprocessing system achieving 100% success across heterogeneous formats with automatic handling of common data quality issues

4.

Domain-Specific AI Application: Demonstration that generative AI can be effectively applied to specialized business analytics domains (hospitality management) with appropriate architectural patterns and validation mechanisms

5.

TRL 4 Validation Results: Comprehensive experimental validation establishing technical feasibility through 91.5% functional success rate, acceptable performance characteristics, and effective training/assessment capabilities

The remainder of this paper is organized as follows. Section 1.4 reviews foundational work in generative AI, data processing automation, and intelligent systems. Section 2.1 details the system architecture including component interactions, data flows, and security mechanisms. Section 2.2 describes implementation specifics including algorithms, validation strategies, and optimization techniques. Section 2.3 presents experimental methodology, test cases, and comprehensive validation results at TRL 4. Section 4 discusses implications, limitations, and lessons learned. Section  concludes with a summary and directions for future work.

1.4. Related Work

Our work intersects research in generative AI and large language models, automated code generation, data processing pipelines, and intelligent systems for education and training. This section reviews foundational work in these areas and identifies gaps that motivate our integrated approach.

1.4.1. Large Language Models and Generative AI

The development of large-scale language models has progressed rapidly since the introduction of the Transformer architecture [1]. BERT [6] demonstrated that pre-training on large text corpora enables strong performance across diverse natural language tasks through fine-tuning. GPT-3 [2] showed that sufficiently large models can perform tasks through few-shot prompting without task-specific training, introducing in-context learning as a powerful paradigm.

Recent models have further advanced capabilities. InstructGPT [7] introduced reinforcement learning from human feedback (RLHF) to align model behavior with user intentions, improving instruction-following and reducing harmful outputs. GPT-4 [8] extended multimodal understanding and demonstrated strong performance on professional benchmarks. Google’s Gemini models [9] introduced native multimodality and extended context windows supporting millions of tokens, enabling processing of entire documents and codebases.

Chain-of-thought prompting [10] showed that instructing models to reason step-by-step significantly improves performance on complex reasoning tasks. This technique is particularly relevant for our application, where the system must analyze datasets, suggest appropriate KPIs, and generate correct calculation code. Retrieval-Augmented Generation (RAG) [11] demonstrated how language models can be enhanced with external knowledge retrieval, relevant for grounding responses in domain-specific documentation.

Bommasani et al. [12] provided comprehensive analysis of foundation models’ opportunities and risks, highlighting challenges including reliability, bias, security, and environmental impact. Liu et al. [13] surveyed prompting methods systematically, categorizing approaches and identifying best practices for eliciting desired model behaviors. These works inform our prompt engineering strategies and validation requirements.

1.4.2. Code Generation with Language Models

Language models’ ability to generate executable code has received substantial attention. Codex [14], the model underlying GitHub Copilot, demonstrated that LLMs trained on code repositories can generate functional implementations from natural language descriptions. The paper introduced pass@k metrics for evaluating code generation and showed 70-80% success rates on programming challenges when allowing multiple attempts.

However, several studies have identified significant challenges. Code generation systems frequently produce syntactically correct but semantically incorrect programs, requiring validation mechanisms to ensure reliability. Security vulnerabilities in generated code represent serious concerns for production deployments. Our work addresses these challenges through multi-tier validation (syntax checking, security pattern matching, semantic verification) and sandboxed execution environments that isolate generated code from system resources.

1.4.3. Data Processing and Analytics Automation

Python’s data science ecosystem provides mature tools for data manipulation and analysis. Pandas [3] offers high-level data structures and operations for efficient tabular data processing. NumPy [4] provides the foundation for numerical computing with array operations and mathematical functions. scikit-learn [5] implements standard machine learning algorithms including K-Nearest Neighbors imputation used in our missing value handling.

While these tools are powerful, they require programming expertise. Our system automates their application through AI-driven workflow orchestration, making advanced data processing accessible to non-technical users. The challenge lies in reliably generating correct code that leverages these libraries appropriately for diverse datasets and analytical tasks.

1.4.4. Visualization and Dashboard Generation

Interactive visualization libraries like D3 [15] and Plotly enable creation of rich, web-based graphics. Declarative visualization grammars such as Vega-Lite [16] provide structured approaches to specifying visualizations from data and design parameters. These tools form the foundation for our dashboard generation capabilities.

Commercial business intelligence platforms (Tableau, Power BI, Looker) offer sophisticated visualization and dashboarding features but typically require manual configuration and design expertise. Our approach automates dashboard creation through rule-based chart selection and template-driven layout generation, complementing AI-generated analytics with interactive visual representations.

1.4.5. Intelligent Tutoring and Assessment Systems

Intelligent Tutoring Systems (ITS) have evolved from early expert systems to modern adaptive learning platforms. VanLehn [17] compared effectiveness of human tutoring, ITS, and other instructional methods, finding that well-designed ITS can approach human tutor effectiveness for certain domains. However, most ITS research focuses on STEM education rather than professional business training.

Our system extends ITS concepts to hospitality management by generating contextual questions about KPIs, providing automated assessment with rubric-based scoring, and delivering personalized feedback. The integration of training modules with operational data analysis represents a novel combination—users can learn about KPIs while working with their own hotel’s actual metrics.

1.4.6. Research Gaps and Positioning

Despite advances in individual areas, several important gaps remain:

Integration Gap: Existing systems address data analysis, code generation, visualization, and training as separate functions. No prior work demonstrates unified integration of these capabilities within a conversational agent specifically designed for business analytics in specialized domains like hospitality management.

Secure Code Execution Gap: While LLMs can generate code, existing research provides limited guidance on validating and safely executing AI-generated code on operational business data. Security mechanisms, validation strategies, and isolation techniques require systematic investigation.

Domain Specialization Gap: Most AI-powered analytics tools are generic. The application to specific industries with specialized KPIs, terminology, and decision-making contexts remains underexplored. Hospitality analytics presents unique requirements around revenue management, occupancy optimization, and operational metrics.

Practical Validation Gap: Much research on AI systems lacks rigorous validation using Technology Readiness Level frameworks. The systematic evaluation of functional capabilities, performance characteristics, and reliability under realistic conditions is rarely reported.

Our work addresses these gaps by developing and validating an integrated intelligent agent specifically designed for hospitality data management. Through comprehensive TRL 4 evaluation, we demonstrate technical feasibility and establish a foundation for advancing toward production-ready deployments in operational hotel environments.

2. Methods

This section describes the methodological foundations and technical realization of the proposed intelligent agent system. It introduces the system architecture, the key implementation decisions, and the validation methodology used for TRL 4 experimental assessment. Together, these elements explain how the artifact was designed, implemented, and evaluated in a controlled laboratory setting.

2.1. System Architecture and Design

This subsection presents the architectural design of the proposed intelligent agent system. It describes the overall structure, the core components and their interactions, the data flow patterns, and the architectural decisions adopted to ensure modularity, robustness, and safe integration of large language models (LLMs) within data-driven analytical workflows.

2.1.1. Architectural Overview

The system adopts a layered architecture that separates concerns across four conceptual layers: (i) an application layer providing a conversational interface and workflow orchestration, (ii) a data processing layer responsible for dataset transformation and KPI computation, (iii) an AI inference layer managing interactions with large language models, and (iv) an infrastructure layer supporting hosting, execution, and deployment. This separation facilitates independent evolution of components, improves maintainability, enables isolated testing, and supports extensibility toward more advanced deployments.

Figure 1 illustrates the high-level organization of the system. Users interact with the platform exclusively through a conversational interface that mediates all inputs and outputs. User actions are handled within the Chainlit application layer, which manages chat sessions, session state, and workflow progression. This layer coordinates downstream operations by invoking data processing pipelines and LLM-based reasoning tasks. The results produced by these components, such as computed KPIs, validation feedback, and interactive dashboards; are returned to the user through the same conversational channel, maintaining a unified interaction paradigm.

2.1.2. Design Principles

The architecture is guided by several key principles:

Modularity: Each functional module (data processing, KPI generation, dashboard creation, training, evaluation) operates as an independent component with well-defined interfaces. This enables isolated testing, selective deployment, and component replacement without system-wide modifications.

Security by Design: Given that the system executes AI-generated code on operational data, security considerations permeate all architectural decisions. We implement defense-in-depth through input validation, code constraint checking, sandboxed execution, and the principle of least privilege for resource access.

Conversational Interaction: The system employs a conversational paradigm in which users express intentions in natural language and receive guided workflows via dialog. This reduces cognitive load and enables progressive disclosure of functionality.

Context Preservation: The architecture maintains conversational context across interactions by persisting recent exchanges and session state, enabling reference to previous steps and analytical results without requiring explicit repetition.

Fail-Safe Operation: Recognizing that AI-generated outputs are probabilistic and may contain errors, the architecture incorporates validation checkpoints, graceful degradation mechanisms, and clear error communication.

2.1.3. Presentation Layer: Conversational Interface

The presentation layer implements a web-based conversational interface using Chainlit, a framework specifically designed to build LLM-powered applications. Chainlit provides native abstractions for managing chat sessions, maintaining message history, and orchestrating interactions with language models.

Key capabilities include:

Session Management: Each user session maintains an isolated state, including conversation history, uploaded files, intermediate analysis results, and training progress. State persists across message exchanges, enabling multi-turn workflows such as iterative KPI refinement.

Rich Media Support: The interface supports various content types, including text, interactive buttons, file uploads, and embedded visualizations. This multimodal capability is essential for presenting data analysis results, dashboard previews, and training materials.

Asynchronous Event Handling: Chainlit implements an event-driven interaction model where user actions trigger callback functions that can perform long-running operations (CSV processing, LLM inference) without blocking the interface, ensuring responsive user experience during computationally intensive tasks.

Guided Interaction: The interface presents contextualized action buttons alongside natural language responses. Rather than relying on free-form navigation, available actions are dynamically determined by the current interaction context (e.g., data analysis, KPI verification, training, or evaluation). After completing a step such as CSV upload or preprocessing, the system exposes the relevant next actions through interactive buttons, guiding users through the workflow while preserving flexibility. This mixed-initiative approach balances user autonomy with clarity and reduces the likelihood of invalid or unsupported actions.

2.1.4. Business Logic Layer: Orchestration

The business logic layer is implemented within a FastAPI-based ASGI application [18], which hosts the Chainlit runtime and provides the execution environment for orchestration logic, data processing pipelines, and AI model inference, enabling asynchronous execution through Python’s async/await patterns.

The core orchestration logic is distributed across specialized modules:

1.

main.py: Entry point with authentication, session initialization, and message routing

2.

analisis.py: CSV preprocessing, KPI generation, and dashboard creation

3.

formar.py: Training content delivery and LLM-based tutoring

4.

evaluar.py: Question generation and assessment for individual KPIs

5.

examen.py: Global examination system with multi-format questions

6.

callbacks.py: Event handlers for user actions (button clicks, responses)

7.

utils.py: Shared utilities for button generation and workflow orchestration

8.

opciones.py: Configuration of all available user options and workflows

Key implementation details:

Stateful Conversational Workflows: The session state is managed through Chainlit’s user session mechanism with a dictionary structure containing: modo (current workflow state), historico (conversation history), respuestas (evaluation responses), tiempo (time tracking), and timer (current timestamp). State transitions are controlled through explicit mode strings defined in config.py (INICIO, ANALISIS, FORMAR, EVALUAR, EXAMEN, etc.). Execution stages are controlled through these state variables and callback-driven transitions, ensuring consistent progression and simplifying error recovery.

Function Registration System: The system employs a dynamic function registration mechanism where button callbacks are mapped to executable functions using the registrar_funcion() utility. This allows for clean separation between UI actions and business logic, enabling modular development and testing.

Context Management: The backend maintains structured context for each session containing conversation history, active dataset references, generated KPI definitions, and training progress. This context is passed to the LLM during inference to ensure responses are grounded in the current analytical state.

Validation Pipelines: Before executing critical operations, the backend applies multi-stage validation including syntax checking, security pattern matching, and execution monitoring. Each stage can reject operations with specific error messages.

2.1.5. Data Processing Layer

The data processing layer handles the ingestion, validation, transformation, and enrichment of operational datasets through specialized pipelines.

CSV Preprocessing Pipeline

The preprocessing pipeline addresses heterogeneous CSV file structures through multi-stage normalization:

Stage 1 – Format Detection: The system implements a priority-based delimiter detection algorithm. First, if a tab character (\t) is present in the first line, tab is selected as delimiter. Otherwise, if semicolon count exceeds comma count in the first line, semicolon is selected. If neither condition holds, comma is used as default. For encoding, the system uses UTF-8 with errors=’ignore’ for robustness. As a fallback mechanism, if initial detection fails, Python’s csv.Sniffer().sniff() method is applied to the first 2048 bytes of the file to automatically determine the delimiter.

Stage 2 – Schema Inference: The system performs multi-step type detection. Year and month columns are identified using regex patterns (r"año|year", r"mes|month") with case-insensitive matching. For date columns, the system first searches for columns matching patterns r"fecha|date|time". If no such columns exist, object-type columns are heuristically parsed using dateutil.parser with fuzzy=True, requiring at least 8 successfully parsed dates from a 10-sample test for column classification as temporal. Month name mapping supports both Spanish (enero-diciembre) and English (january-december) through a predefined dictionary. Numeric columns are identified using pandas select_dtypes(include=[np.number]). The es_numerica_real() function distinguishes true numeric columns from categorical codes: columns with more than $50\%$ NA after numeric coercion are classified as text, and columns where unique_values/total_values is less than $0.2$ are classified as categorical despite numeric representation.

Stage 3 – Data Cleaning: The pipeline implements threshold-based missing value handling. Columns with more than $40\%$ missing values (p_umbral=0.4) are dropped entirely. For numeric columns with less than $40\%$ missing values, K-Nearest Neighbors imputation is applied using sklearn.impute.KNNImputer with $k=3$ neighbors. The distance metric is Euclidean distance computed over all numeric features. For temporal columns (Year and Month), linear interpolation is applied with limit_direction="both", followed by clipping (months to range [1,12]) and rounding to integers. Categorical columns, including both object-type columns and numeric columns failing the es_numerica_real() test, are removed from the dataset.

Stage 4 – Temporal Feature Engineering: Date columns are decomposed into separate Year and Month columns through pandas datetime operations. Numeric months (1-12) are converted to Spanish month names (MESES_INV dictionary mapping). The DataFrame is then reordered to place temporal columns first: [Año, Mes, ...other columns]. The preprocessed DataFrame is saved to disk with "_preprocesado.csv" suffix for potential reuse within the session.

KPI Suggestion and Validation

The KPI suggestion process integrates dataset analysis with LLM-based reasoning:

Dataset Description: The system extracts the first two rows of the preprocessed DataFrame using df.head(n_head).to_csv(index=False) where n_head=2. This sample is formatted into a structured prompt (PROMPT_PROCESAR_CSV) that instructs the model to: (1) explain column information in a table format (column name, data type, description), and (2) extract possible KPIs in a second Markdown table with columns: KPI, Formula, and Interpretation. Critical constraints enforce that formulas must use plain mathematical symbols (+, -, *, /) without LaTeX notation, as the prompt explicitly states: "NO utilices LaTeX en ninguna parte de la respuesta."

Structured Generation: The LLM (Gemini 2.5 Flash via config["model_cuadro2"]) generates KPI suggestions in standardized Markdown table format. The system uses regex-based parsing to extract tables from the response, tolerating variations in whitespace and formatting.

Table Extraction and Validation: The extraer_tabla_kpis() function parses Markdown tables by: (1) identifying lines containing pipe characters, (2) filtering separator lines (dashes), (3) extracting cell contents by splitting on pipes. Column headers are normalized by removing accents, converting to lowercase, and matching against expected column names (kpi, formula, interpretacion) using flexible synonym mapping. If the "interpretacion" column is missing, it is created with empty values, allowing the system to proceed with incomplete but essential information.

User Review: Suggested KPIs are presented to the user through the conversational interface with options to confirm, edit, or add new definitions. When users choose to edit KPIs, they can provide corrections in either Markdown table or CSV format. The system parses user input using the same table extraction logic, validates that essential columns (KPI, Formula) are present, and preserves the user’s exact formatting and column structure. Edited KPIs are stored in session state and proceed to the calculation stage upon user confirmation.

Automated KPI Calculation

KPI calculation employs LLM-driven code generation with two-tier security validation:

Code Generation: The system constructs PROMPT_GENERAR_CODIGO containing: (1) the first two lines of the preprocessed CSV to provide schema context, (2) the KPI table in Markdown format (from kpis_df.to_markdown()), and (3) explicit constraints requiring the code to define a calculate_kpis(df) function that returns a DataFrame with only [Año, Mes, KPI columns]. The prompt restricts imports to pandas and numpy only, and explicitly prohibits file operations, subprocess execution, network calls, and use of eval/exec. The model used is Gemini 2.5 Flash (config["model_cuadro2"]).

Security Validation (Two-Tier): Generated code undergoes two-tier validation implemented in validar_codigo_generado():

Tier 1 – Function Signature Check: The system verifies presence of the substring "def calculate_kpis" in the generated code. If not found, the code is rejected with message "El código no define la función calculate_kpis(df)."

Tier 2 – Regex-Based Pattern Matching: The system defines a blacklist of prohibited patterns and applies regex matching via re.search():

blacklist = [

    r"\bsubprocess\b", r"\bimport\s+os\b", r"\bimport\s+sys\b",

    r"\bos\.system\b", r"\bsys\.exit\b",

    r"\bopen\s*\(", r"\beval\s*\(", r"\bexec\s*\(",

    r"\brequests\b", r"\bsocket\b", r"\bshutil\b",

    r"__import__", r"pickle", r"multiprocessing"

]

If any pattern matches, the code is rejected with message "Código contiene patrón no permitido: {pattern}". Note that this approach uses simple string pattern matching rather than abstract syntax tree (AST) analysis, which limits its ability to detect obfuscated patterns (e.g., string concatenation like "o" + "s.system") or runtime code construction. The system compensates for these limitations through subprocess isolation and timeout enforcement, providing defense-in-depth despite less sophisticated static analysis.

Sandboxed Execution: Validated code executes in a separate Python process via subprocess.run(). The system creates a temporary Python script using tempfile.mkstemp(prefix="calc_kpis_",suffix=".py") that embeds the generated code within a template. This template includes safe CSV reading using raw string paths, error handling with traceback printing, and validation that calculate_kpis() returns a valid DataFrame. The execution environment provides:

• Process Isolation: Separate process prevents direct memory access to main application
• Timeout Enforcement: 30-second timeout via the timeout parameter of subprocess.run(). TimeoutExpired exception terminates execution if exceeded.
• Output Capture: Both stdout and stderr are captured (stdout=PIPE, stderr=PIPE) for error reporting
• Temporary File Cleanup: The temporary script is deleted via os.remove(tmp_path) after execution regardless of success or failure

Importantly, the current implementation does not enforce memory limits, does not use additional sandboxing mechanisms (containers, seccomp, AppArmor), and does not restrict filesystem or network access beyond Python’s default permissions. The subprocess inherits the system environment and permissions. This level of isolation is suitable for TRL 4 validation in controlled laboratory conditions but would require hardening for production deployment.

Output Verification: After successful execution (return code 0), the system verifies that the output CSV file exists at the expected path. The structural integrity of the output (column names, data types) is checked during execution within the subprocess itself through the template’s validation logic, not in the main process.

2.1.6. Visualization Layer: Dashboard Generation

The dashboard generation module transforms calculated KPIs into interactive HTML visualizations using a template-based approach.

Template Architecture: Rather than dynamically generating Plotly code, the system uses a comprehensive HTML template (TEMPLATE in template_html.py, approximately 400 lines) with embedded JavaScript. The template includes the Plotly library loaded from a CDN (plotly-2.27.0.min.js), CSV parsing logic implemented in JavaScript, and a responsive layout implemented using CSS Flexbox.

Data Injection: The generar_html_cuadro(csvData, col_año, col_mes) function takes the calculated KPIs CSV as a string and injects it as a JavaScript literal within the template. The JavaScript code then performs client-side parsing, including delimiter detection, decimal separator inference, and year extraction directly from the data.

Chart Generation: The template automatically generates line charts for all KPIs using Plotly’s JavaScript API. All years present in the data are automatically detected and plotted as separate traces with year-over-year comparison. Each KPI receives a dedicated section with both a summary card (displaying current year value, previous year value, and absolute/relative differences) and an interactive line chart with hover tooltips and zoom/pan controls.

Responsive Layout: The template employs a responsive layout implemented using CSS Flexbox, allowing dashboard components to adapt dynamically to different viewport sizes and KPI counts while maintaining readability and usability across desktop, tablet, and mobile devices.

2.1.7. AI Inference Layer: LLM Integration

The AI inference layer manages all interactions with the Google Gemini API:

Model Configuration: The system employs two Gemini models for different purposes:

• Gemini 2.5 Flash (config["model_cuadro2"]): Used for KPI suggestion from CSV data and code generation for KPI calculation
• Gemini 2.0 Flash (config["model_name"]): Used for data analysis queries, training content explanations, and evaluation feedback

Prompt Engineering: Prompts are designed to enforce structured outputs, domain-appropriate language, and explicit constraints. Each functional module defines its own prompt templates in prompts.py, carefully crafted to produce consistent, parseable responses.

Context Window Management: The system maintains recent conversation history in session state with a configurable limit (LIMITE_HISTORICO). For dataset processing, full CSV content is not passed to the model; instead, only the first few rows (typically 2) are included along with column metadata to respect token limits.

Error Handling: API failures are caught via try-except blocks with user-facing error messages. The system does not implement automatic retry mechanisms or fallback models in the current TRL 4 version. If API calls fail, the user is informed and workflow progression halts until user intervention.

2.1.8. Training and Evaluation Subsystem

The training module delivers contextualized learning experiences through structured content and adaptive assessment:

Content Structuring: KPI documentation is organized hierarchically in Markdown format, with each KPI corresponding to a chapter in the documentation file. The formar.py module loads this documentation at startup and maintains it in memory for quick retrieval.

Question Bank System: To improve examination efficiency and consistency, the system maintains a persistent question bank stored in preguntas.json. The structure is: {question_type: {kpi_index: [list of question dicts]}}. The bank is loaded at application startup and serialized again at session end. During global examination generation, the system attempts to reuse previously stored questions with probability 0.75 (USAR_BANCO). If no suitable question is found in the bank, a new question is generated through the LLM as a fallback mechanism.

Question Generation: The system employs four distinct prompt templates for different question formats:

1.

PROMPT_FORMAR_PREGUNTA_VF: True/False assertions about KPI concepts

2.

PROMPT_FORMAR_PREGUNTA_OPCIONES: Multiple-choice with 3-4 options and plausible distractors

3.

PROMPT_FORMAR_PREGUNTA_ABIERTA: Open-ended questions requiring explanatory responses

4.

PROMPT_FORMAR_PREGUNTA_SITUACION: Situational scenarios requiring decision-making

Each prompt is contextualized with the specific KPI documentation content to ensure questions are grounded in the training material.

Assessment Implementation:

• Objective Questions: True/false and multiple-choice questions use exact string matching against stored answer keys for instant, deterministic scoring
• Open-ended Questions: Evaluated using PROMPT_EVAL_PREGUNTA_ABIERTA, which instructs the LLM to compare the user’s response against the expected answer, provide explanatory feedback, and assign a score in format "Puntos: X/10"
• Situational Questions: Evaluated using PROMPT_EVAL_SITUACION with similar structure, assessing the appropriateness of the user’s decision-making approach

Score Extraction: For LLM-based scoring, the system searches backward through response lines to locate "Puntos:" patterns, extracts the numeric score, and defaults to 0 if the pattern is not found. This approach is simpler than structured JSON parsing but requires careful prompt engineering to ensure consistent output format.

Progress Tracking: Session state maintains arrays of user responses (respuestas, respuestas_examen) with question data, user answers, correctness flags, and scores. At examination conclusion, the system generates a comprehensive report showing all questions, user responses, correct answers, and performance summary.

2.1.9. Infrastructure and Deployment

The system is deployed within a containerized execution environment to support reproducibility and controlled validation.

Containerization: Application components are packaged as Docker containers, ensuring consistent execution environments across development and deployment. All runtime dependencies are encapsulated within the container images, simplifying setup and reducing configuration variability.

Execution Environment: The containerized application is executed in a single-instance configuration suitable for controlled experimental validation at TRL 4. This setup prioritizes functional correctness, robustness, and transparency over scalability or high availability.

Storage: Uploaded datasets, intermediate artifacts (e.g., preprocessed CSV files), and generated outputs (e.g., HTML dashboards) are stored locally within the execution environment. This storage model provides temporary persistence during interactive user sessions and supports iterative analytical workflows without introducing external storage dependencies.

This deployment configuration provides a practical foundation for experimental validation while remaining compatible with more advanced infrastructure solutions at higher technology readiness levels.

2.2. Implementation Details

This subsection provides detailed technical specifications of the system implementation, including algorithms, data structures, and key implementation decisions. The description focuses on concrete realizations of the architectural components introduced in Section 2.1.

2.2.1. Technology Stack

The system is implemented in Python 3.11 [23], leveraging its extensive ecosystem of data science and web application libraries. Table 1 summarizes the primary dependencies used throughout the implementation.

These dependencies support efficient tabular data manipulation (Pandas [3]), high-performance numerical operations (NumPy [4]), and robust implementations of common preprocessing and machine learning algorithms (scikit-learn [5]).

2.2.2. CSV Preprocessing Implementation

The CSV preprocessing pipeline transforms heterogeneous real-world datasets into normalized tabular representations suitable for downstream analysis. The pipeline combines heuristic-based format detection, schema inference, missing value handling, and temporal normalization.

Preprocessing Pipeline

Given a CSV file F, the pipeline proceeds as follows:

1.

Format Detection: The first line of the file is inspected to determine the field delimiter using a priority-based heuristic. Tab characters are preferred when present; otherwise, semicolon or comma delimiters are selected based on frequency analysis. Files are read using UTF-8 encoding with tolerant error handling. When heuristic detection fails, Python’s csv.Sniffer is applied to a fixed-size byte sample.

2.

Data Loading: The dataset is loaded into a pandas DataFrame using the detected delimiter.

3.

Missing Value Filtering: For each column, the fraction of missing values is computed. Columns exceeding a missing value threshold of ${\theta }_{mv}=0.4$ are removed.

4.

Numeric Imputation: Remaining numeric columns are imputed using K-Nearest Neighbors imputation with $k=3$ neighbors, applied jointly across numeric features.

5.

Temporal Detection: Temporal information is identified using a combination of regular expression matching (for explicit year, month, or date columns) and heuristic parsing of object-type columns using date parsing with fuzzy matching. When a date column is detected, year and month components are extracted.

6.

Temporal Normalization: Year and month values are converted to numeric representations, interpolated when partially missing, clipped to valid ranges, and normalized. Month values are mapped to standardized Spanish month names.

7.

Categorical Filtering: Columns identified as categorical —either through object type or low numeric cardinality— are removed, preserving only continuous numeric measures.

8.

Finalization: The resulting DataFrame is reordered to place temporal columns first and stored as a preprocessed CSV file for reuse within the session.

K-Nearest Neighbors Imputation

Missing numeric values are imputed using K-Nearest Neighbors (K-NN) imputation implemented via scikit-learn [5]. For each row with missing values, the $k=3$ nearest neighbors are identified using Euclidean distance over standardized numeric features:

$$d(x_i,x_j)=\sqrt{\sum _{c\in {\mathcal{C}}_{num}}{\left({\displaystyle \frac{x_{ic}-{\overline{x}}_c}{{\sigma }_c}}-{\displaystyle \frac{x_{jc}-{\overline{x}}_c}{{\sigma }_c}}\right)}^2}$$

(1)

The imputed value ${\widehat{x}}_{ic}$ is computed as the average of the corresponding feature across the nearest neighbors.

Categorical Detection via Uniqueness Ratio

To distinguish true numeric measurements from categorical encodings, the function es_numerica_real() applies two criteria: (i) the fraction of missing values after numeric coercion, and (ii) the ratio of unique values to total observations. Columns with low cardinality relative to dataset size are treated as categorical and excluded from further analysis.

2.2.3. LLM-Driven KPI Generation

KPI generation is implemented as a multi-stage interaction with the Gemini API, combining dataset context with constrained prompt design to ensure structured, interpretable outputs.

Prompt Construction

The system constructs a structured prompt containing a small representative sample of the dataset (the first two rows), instructing the model to (i) describe column semantics and (ii) propose candidate KPIs in tabular format. Explicit constraints enforce non-LaTeX mathematical expressions and restrict output to machine-parseable tables.

Code Validation

KPI computation code generated by the LLM is validated using a two-stage procedure. First, the presence of a required function signature is verified. Second, the code is scanned against a blacklist of prohibited patterns using regular expression matching, preventing access to file system operations, subprocess management, dynamic execution, and networking libraries.

Sandboxed Execution

Validated code is executed in an isolated Python subprocess. The generated code is embedded into a temporary execution template that loads the preprocessed dataset, computes KPI values, and writes the resulting DataFrame to disk. Execution is subject to a fixed timeout and process-level isolation, ensuring that failures or infinite loops do not affect the main application.

2.2.4. Interactive Dashboard Generation

The system generates interactive dashboards using a template-based HTML approach. A predefined HTML template embeds CSS for layout, JavaScript for data parsing, and the Plotly JavaScript library for visualization.

Chart Generation

For each KPI, the template produces an interactive line chart with automatic year-over-year comparison. Different years are rendered as separate traces, with unified hover interaction along the temporal axis. Summary cards show current and previous year values along with absolute and relative differences.

Responsive Layout

Dashboards employ a responsive layout implemented using CSS Flexbox that adapts dynamically to screen size and KPI count, ensuring readability and usability across desktop, tablet, and mobile devices.

2.2.5. Training and Evaluation Implementation

The system includes an integrated training and assessment module to reinforce user understanding of KPIs.

Question Generation

Assessment questions are generated using LLM prompts conditioned on KPI documentation. A persistent question bank is maintained to balance reuse of existing questions with generation of new ones, improving consistency and efficiency across sessions.

Automated Scoring

Open-ended and situational responses are evaluated using LLM-based qualitative assessment, producing explanatory feedback and a single scalar score extracted from a standardized response format. Objective questions are scored deterministically using stored answer keys.

2.2.6. Implementation Considerations

The implementation prioritizes transparency, robustness, and correctness over aggressive performance optimization. Preprocessed datasets are reused within a session to avoid redundant computation, while data loading and preprocessing are performed synchronously using pandas.

2.2.7. Error Handling

Error handling is implemented across all stages of the pipeline. Parsing errors, LLM failures, validation rejections, and execution timeouts are detected and reported to the user with informative messages. Diagnostic information is logged to the console to support debugging during experimental validation.

Overall, this implementation demonstrates the feasibility of combining LLM-driven reasoning with robust data preprocessing, controlled code execution, and interactive visualization within a unified conversational system.

2.3. Validation Methodology

This section presents the experimental validation design of the intelligent agent system at Technology Readiness Level 4 (TRL 4). TRL 4 corresponds to validation of integrated components in a controlled laboratory environment, demonstrating that the system functions as intended under experimental conditions [24]. The validation protocol combines functional testing, performance measurement, and qualitative output assessment across all major system capabilities.

Validation followed a structured protocol designed to evaluate system behavior under realistic usage scenarios while maintaining experimental control.

2.3.1. Test Environment Configuration

Experiments were conducted on controlled cloud-based infrastructure:

• Compute: AWS Elastic Container Service (ECS) using Fargate tasks (0.25 vCPU, 0.5 GB RAM)
• LLM Service: Gemini 2.0 Flash and Gemini 2.5 Flash through Google Gemini API under standard rate limits
• Storage: Local and temporary file storage for datasets and generated outputs
• Monitoring: Execution logs and manual inspection of outputs

This configuration reflects the actual deployment setup used for TRL 4 laboratory validation and avoids assumptions about production-grade infrastructure.

2.3.2. Dataset Preparation

Validation was conducted exclusively using synthetic datasets.

Synthetic Datasets (n=27): A collection of programmatically generated CSV files designed to simulate representative hotel operational data under controlled conditions. Dataset sizes ranged from 50 to 500 rows, with file sizes of a few kilobytes, enabling rapid iteration and reproducible testing across multiple system components.

The synthetic datasets were constructed to introduce controlled structural and data quality variability, including:

• Multiple delimiter types (comma, semicolon, tab)
• Diverse date formats (ISO 8601, MM/DD/YYYY, DD-MM-YYYY)
• Missing values at varying rates, including datasets with no missing values and others with sparse missing entries
• Numeric columns with mixed precision
• Categorical columns with inconsistent capitalization
• Duplicate rows at varying frequencies

Although the datasets do not originate from real operational systems, their structure and variable composition were designed to reflect typical hotel management data. This fully synthetic dataset strategy enabled controlled, repeatable functional validation while avoiding dependencies on sensitive or proprietary real-world data, consistent with TRL 4 laboratory-level validation objectives.

2.3.3. Test Case Design

Test cases were organized into six functional categories:

1.

CSV Preprocessing (TC-P): Evaluation of format detection, schema inference, temporal normalization, and missing value handling

2.

KPI Suggestion (TC-K): Assessment of relevance, structural correctness, and output formatting

3.

KPI Calculation (TC-C): Validation of code generation, security checks, and execution robustness

4.

Dashboard Generation (TC-D): Verification of visualization correctness, layout integrity, and interactivity

5.

Training Delivery (TC-T): Evaluation of documentation retrieval and explanatory adequacy

6.

Evaluation Assessment (TC-E): Validation of question generation, scoring logic, and feedback delivery

Each test case specified initial conditions, user actions, expected outputs, acceptance criteria, and evaluation procedures.

3. Results

This section presents the results of the TRL 4 experimental validation of the intelligent agent system. The results are organized around functional performance, indicative responsiveness, and observed failure modes.

3.1. Functional Validation Results

Table 2 summarizes aggregate functional validation results across all test categories.

The system achieved an overall functional success rate of 98.5%, exceeding the predefined TRL 4 acceptance threshold of 90%. Observed failures were isolated and did not propagate to downstream system components.

3.1.1. CSV Preprocessing Performance

The preprocessing pipeline achieved a 100% success rate across all evaluated cases.

Format Detection: Delimiter and encoding detection succeeded in all test cases, including files containing tab delimiters and quoted fields with embedded separators.

Schema and Type Handling: Column structures were consistently interpreted, enabling successful downstream processing in all cases. Ambiguous fields were handled conservatively without compromising pipeline stability.

Temporal Normalization: Temporal information was correctly identified and normalized whenever present in supported formats, producing consistent year–month representations suitable for time-series analysis.

Missing Value Handling: Datasets containing missing values were processed without execution failures, and resulting datasets preserved structural validity for subsequent KPI computation.

3.1.2. KPI Generation and Calculation Results

Suggestion Quality: KPI suggestion achieved a success rate of 93.0%. Failures were attributable to output formatting inconsistencies or partially incomplete suggestions requiring regeneration. No failures resulted in invalid system states.

Formula Validity: Generated KPI formulas were structurally valid in the majority of cases and executable without manual correction in all successful test cases.

Code Generation and Execution: All KPI calculation test cases completed successfully. Generated code passed static validation and executed without runtime errors under controlled conditions.

Security Validation: Pattern-based static checks correctly rejected all intentionally malicious code samples introduced during testing. No false positives were observed for valid KPI computation code.

3.1.3. Dashboard Generation Quality

Dashboard generation succeeded in all evaluated cases.

Visual Correctness: Generated dashboards accurately reflected computed KPI values and temporal structure, with appropriate chart representations and consistent ordering.

Interactivity and Responsiveness: Interactive features such as hover tooltips and year-over-year comparisons functioned correctly across desktop and tablet viewports. No functional regressions were observed.

3.1.4. Training and Evaluation Results

Training Content Delivery: Training material was consistently retrieved and presented correctly across all evaluated cases.

Question Generation: Evaluation modules generated structurally valid questions across multiple formats (true/false, multiple-choice, open-ended, situational).

Evaluation Consistency: Objective questions were scored deterministically, while open-ended responses were evaluated without execution errors or workflow interruptions.

3.2. Performance Benchmarking

Performance measurements were collected during functional testing to characterize indicative system responsiveness under laboratory conditions.

3.2.1. Response Time Analysis

Observed response times remained within acceptable ranges for interactive use across all major operations, including CSV preprocessing, KPI suggestion, KPI calculation, and dashboard generation. Measured latencies were consistent with expectations for cloud-based LLM-assisted workflows.

3.2.2. Throughput and Resource Utilization

Under simulated concurrent usage with a small number of simultaneous users, the system maintained stable behavior with moderate increases in response latency. CPU and memory utilization remained within the allocated task resource limits, indicating feasibility for moderate workloads in controlled environments.

3.3. Error Analysis and Failure Modes

Observed failures clustered primarily in the KPI suggestion stage and were related to LLM output variability rather than logical or architectural defects. No failures affected system stability or data integrity. Identified issues are addressable through prompt refinement and additional output validation.

3.4. Summary of Validation Results

The experimental validation confirms that the proposed system meets TRL 4 maturity requirements, demonstrating reliable integrated operation in a controlled laboratory setting. High functional success rates were observed across preprocessing, KPI calculation, dashboard generation, training, and evaluation modules. The results establish a robust foundation for subsequent validation in more operationally representative environments as part of future TRL 5 advancement.

4. Discussion

This section interprets our experimental findings, acknowledges limitations, and explores practical implications for hospitality management and AI system development. We examine what the results reveal about the feasibility of integrating generative AI into specialized business analytics workflows.

Methodologically, this study aligns with the Design Science Research (DSR) paradigm. While the research is utilitarian in nature, aiming to solve a specific practical problem (operational inefficiency through knowledge fragmentation), the design and evaluation of the artifact generate prescriptive knowledge regarding how Generative AI can be integrated with heterogeneous data sources to restructure internal knowledge flows. In this sense, the contribution of the work is not limited to the implementation of a prototype, but also includes transferable design knowledge about architectural modularity, validation layering, conversational orchestration, and controlled execution of LLM-generated code in business analytics environments.

4.1. Interpretation of Results

The experimental validation demonstrates that an integrated intelligent agent combining data processing, generative AI, visualization, and adaptive training is technically feasible at TRL 4. The 98.5% overall success rate indicates robust functional integration across the evaluated system capabilities while revealing specific areas requiring refinement.

4.1.1. Strengths and Capabilities

Several findings merit particular attention. The perfect success rate (100%) in CSV preprocessing validates our multi-stage normalization approach and demonstrates that robust data handling is achievable despite format heterogeneity. This is significant given that data quality issues represent a primary barrier to analytics adoption in many business contexts. The preprocessing pipeline consistently produced structurally valid datasets suitable for downstream analysis, even in the presence of missing values and heterogeneous temporal formats.

The KPI generation and calculation pipeline achieved high functional reliability. While KPI suggestion exhibited a small number of failures (93.0% success rate), all successfully generated KPIs were structurally valid and executable, and the KPI calculation stage itself achieved a 100% success rate. This confirms that LLM-driven code generation can be safely and effectively integrated into domain-specific analytics workflows when combined with constraint-based validation and sandboxed execution. Prior studies on general-purpose code generation [14] report comparable success ranges, suggesting that the applied validation strategy effectively mitigates common reliability and security concerns.

Dashboard generation achieved a 100% success rate in the evaluated test cases, indicating that template-driven visualization provides a practical and robust approach for business analytics applications. The system consistently produced interactive HTML dashboards without requiring visualization expertise from users, thereby lowering the barrier to effective data presentation.

The training and evaluation modules further demonstrated the feasibility of LLM-based instructional workflows. Across all evaluated cases, training content delivery and assessment workflows executed without functional errors, supporting the use of generative AI for adaptive learning and self-assessment in applied business contexts.

Beyond technical feasibility, these findings highlight the project’s broader contribution: the system operationalizes a complete knowledge workflow in which heterogeneous data ingestion, KPI formalization, secure computation, visualization, and learning support are integrated into a single conversational environment. This integration is itself an important project outcome, as it shows how Generative AI can move from isolated assistance tasks to orchestrated support for end-to-end analytical work.

4.1.2. Challenges and Failure Modes

The failure analysis reveals a limited number of challenge areas. First, LLM output formatting inconsistencies in the KPI suggestion stage highlight the inherent variability of probabilistic text generation. Despite explicit prompting and structured instructions, language models occasionally deviate from requested formats. This suggests the need for either more tolerant parsing mechanisms or iterative refinement loops that automatically correct formatting deviations.

Second, partial KPI suggestion failures reflect limitations in generating fully complete or well-structured outputs under all prompt conditions. Importantly, these failures did not propagate to downstream components, and system stability was preserved. This isolation of failures supports the robustness of the overall system architecture.

More generally, the observed issues reflect the prototype nature of TRL 4 systems rather than fundamental architectural flaws. As commonly observed in early-stage AI system deployments, edge cases and output variability dominate remaining engineering challenges.

4.2. Limitations and Threats to Validity

Several limitations constrain the generalizability of our findings:

Internal Validity: Test cases were designed by the development team and may not comprehensively represent real-world usage patterns. While datasets were constructed to reflect realistic structures, they were synthesized with awareness of system assumptions, potentially introducing bias. Independent test case design would strengthen internal validity.

External Validity: Testing occurred in a controlled laboratory environment with simulated user interactions. Actual revenue managers may interact with the system differently, formulate queries in unexpected ways, or have implicit expectations not captured in test specifications. Planned TRL 5 validation with real users will address this limitation.

Construct Validity: Success criteria focused primarily on functional correctness rather than user satisfaction, decision quality, or business impact. A system that functions correctly may still fail to deliver value if it does not align with real operational workflows. Usability studies and field evaluations are therefore necessary to assess practical utility.

Ecological Validity: Validation relied exclusively on synthetic datasets of limited size, enabling controlled and reproducible testing but not capturing the full complexity of real-world hospitality data environments. Larger datasets, noisier inputs, and organizational constraints may introduce additional challenges not observed at TRL 4.

Additionally, reliance on a single LLM provider (Google Gemini) introduces vendor-specific dependencies. Although two models (Gemini 2.0 Flash and Gemini 2.5 Flash) were used for different tasks, both originate from the same provider. Evaluation across multiple LLM platforms would strengthen external validity but was beyond the scope of this validation stage.

4.3. Practical Implications

For hospitality management practice, the results suggest that AI-assisted analytics can lower the technical expertise barrier that currently limits data-driven decision-making in many hotels. The ability to process heterogeneous CSV files and generate meaningful KPIs without extensive manual data preparation could democratize analytics access for small or independent properties lacking dedicated data teams.

However, practical deployment considerations remain. The less-than-perfect success rate in KPI suggestion implies that occasional regeneration or user intervention may be required, potentially affecting user experience for non-technical users. Clear error messaging and guided recovery mechanisms are therefore essential to maintain user trust.

The system’s reliance on cloud compute resources and continuous LLM API access also implies non-trivial operational costs. Organizations must weigh the benefits of automation against infrastructure and usage costs, particularly for small-scale deployments. A systematic cost–benefit analysis remains future work.

From an AI system development perspective, the architecture illustrates the effectiveness of defense-in-depth strategies when executing LLM-generated code. The combination of validation and sandboxed execution successfully prevented all attempted security violations observed during evaluation, while maintaining high acceptance of legitimate code.

More broadly, the project contributes a concrete example of how generative AI can be embedded into heterogeneous organizational data ecosystems to improve knowledge accessibility and workflow continuity. In that sense, its impact lies not only in automating isolated analytical tasks, but in restructuring internal knowledge flows around a conversational, guided, and technically safeguarded artifact.

4.4. Lessons Learned

Several insights emerged from the development and validation process:

Prompt Engineering Iteration: Achieving reliable structured output from LLMs required extensive prompt refinement. Initial attempts produced highly variable formats; systematic testing and explicit constraint specification were necessary to stabilize outputs, consistent with prior analyses of prompt engineering practices [13].

Validation Layering: Multi-stage code validation proved essential. Early prototypes without validation successfully generated KPIs but posed unacceptable risks. Incrementally adding validation layers illustrates the importance of defense-in-depth in systems that integrate generative AI.

User Guidance Importance: Natural language interfaces require carefully designed guidance mechanisms. Fully open-ended interaction often led to confusion during informal testing, whereas structured interaction patterns improved usability and outcome consistency.

Error Communication Complexity: Explaining system or LLM failures to non-technical users remains challenging. Designing error messages that are both understandable and actionable requires user-centered design beyond purely technical considerations.

Domain Knowledge Integration: KPI suggestion quality depended on the LLM’s embedded hospitality knowledge. For more specialized or proprietary domains, fine-tuning or retrieval-augmented generation [11] may be required to incorporate organization-specific expertise.

4.5. Comparison with Alternative Approaches

Although direct empirical comparison with other hospitality AI systems is not possible due to limited publicly available implementations, the system can be contextualized relative to existing tools. Commercial business intelligence platforms (e.g., Tableau, Power BI, Looker) provide powerful visualization capabilities but typically require manual dashboard design and technical expertise. In contrast, the proposed system emphasizes end-to-end automation through AI-driven KPI suggestion, code generation, and visualization, while lacking enterprise-grade features such as governance and collaboration.

General-purpose LLM coding assistants operate at the level of isolated code snippets. By contrast, this system orchestrates complete workflows from raw data ingestion to interactive dashboards, integrating validation, execution, and domain context.

The training and evaluation components further differentiate the system by embedding learning and assessment within the analytics workflow itself. While this integration may enhance learning transfer, controlled studies assessing user competency gains remain future work.

4.6. Limitations

Despite encouraging results, several limitations remain:

• Single-Vendor LLM Dependency: Although two Gemini models are employed, reliance on a single LLM provider introduces vendor-specific dependencies. Supporting multiple providers would improve system robustness and deployment flexibility.
• Laboratory-Only Validation: Experimental evaluation was conducted under controlled conditions with simulated interactions and synthetic datasets. Real-world deployment may surface additional technical, organizational, and usability challenges.
• Functional Evaluation Focus: Validation emphasized functional correctness rather than user satisfaction, workflow efficiency, or business impact. These dimensions require dedicated user-centered studies.
• Domain Specificity: The system is tailored to hospitality management. Generalization to other application domains will require further investigation and adaptation.

4.7. Future Work

4.7.1. Near-Term: TRL 5 Advancement

Progression to TRL 5 will require validation in relevant operational settings:

Field Studies with Real Users: Deploy the system with revenue managers and hotel staff to assess usability, workflow integration, and perceived value through observational and longitudinal studies.

Enhanced Error Recovery: Introduce automated refinement mechanisms for output formatting deviations, improved handling of partial KPI suggestion failures, and more informative recovery strategies for common failure modes.

Performance Optimization: Improve responsiveness through prompt reuse, selective caching, and optimized execution strategies. Extend support for concurrent users under controlled operational workloads.

Multi-LLM Support: Implement abstraction layers to enable integration of alternative LLM providers, supporting cost optimization and increased resilience.

4.7.2. Medium-Term Research

Personalization and Adaptation: Incorporate user modeling to adapt interaction style, explanation depth, and training content based on expertise and learning progression.

Multi-Modal Integration: Extend the system to incorporate additional data modalities, such as textual reviews or external contextual data, leveraging emerging multi-modal AI models.

Collaborative Capabilities: Introduce collaborative features including shared dashboards, annotations, and versioning to support organizational decision-making.

Causal and Prescriptive Analytics: Integrate causal inference and scenario analysis techniques to move beyond descriptive analytics toward prescriptive decision support.

4.7.3. Long-Term Vision

Autonomous Analytics: Future systems may proactively monitor operational data, detect anomalies, investigate root causes, and recommend actions with minimal user intervention.

Cross-Domain Transferability: Investigate methods for adapting the proposed architecture and validation methodology to other domains such as healthcare, retail, or manufacturing.

Responsible AI Practices: Address transparency, explainability, robustness, and data governance considerations to support responsible deployment of AI-assisted analytics systems.

5. Conclusion

This paper presents the design, implementation, and validation of an intelligent agent system that integrates generative AI capabilities with operational data processing, interactive visualization, and adaptive training delivery for hospitality management. Through experimental evaluation at Technology Readiness Level 4, the study demonstrates the technical feasibility of this integrated approach and establishes a foundation for advancement toward deployment in relevant operational environments.

5.1. Summary of Contributions

This work makes several contributions at the intersection of artificial intelligence and business analytics:

Integrated System Architecture: We designed and implemented a modular architecture combining conversational interaction (Chainlit), an ASGI-based application backbone (FastAPI), robust data processing (Pandas, NumPy, scikit-learn), generative AI inference (Gemini 2.0 Flash and Gemini 2.5 Flash), and interactive visualization (Plotly). The architecture incorporates security through multi-stage validation, supports asynchronous execution patterns, and promotes extensibility via clearly defined component interfaces.

Automated Data Processing: We developed a comprehensive CSV preprocessing pipeline achieving a 100% functional success rate across all evaluated preprocessing cases with heterogeneous input formats. The pipeline robustly handles delimiter detection, schema interpretation, temporal normalization, and missing value handling, producing structurally valid datasets suitable for downstream analytics.

Secure Code Generation: We introduced a practical, implementation-driven methodology for leveraging large language models to generate executable KPI computation code while maintaining security through layered validation mechanisms and sandboxed execution. The approach achieved high functional reliability, with all successfully generated KPI computation code executing correctly and all intentionally malicious code samples being rejected during validation.

Domain-Specific Application: We demonstrated that generative AI can be effectively applied to specialized business analytics domains, such as hospitality management, when combined with appropriate architectural patterns, domain-aware prompting, and validation strategies.

Empirical TRL 4 Validation: We conducted systematic functional validation achieving an overall success rate of 98.5% across 206 test cases, confirming reliable integrated operation of the system components under controlled laboratory conditions.

5.2. Key Findings

Several broader insights emerge from the results:

Integration Feasibility: Large language models can be successfully integrated into structured business workflows when complemented by robust validation, domain context provisioning, and constrained output formats. Nonetheless, inherent variability in generative outputs necessitates explicit error handling and recovery mechanisms.

Security–Automation Tradeoff: Executing AI-generated code over operational data requires balancing automation benefits against security risks. The results indicate that layered validation and isolation mechanisms can achieve this balance while preserving high functional acceptance of legitimate code.

Conversational Interface Value: Natural language interaction reduces technical barriers for end users but introduces challenges related to intent disambiguation, context management, and error communication. Mixed-initiative designs combining conversational flexibility with structured guidance proved most effective during validation.

TRL 4 Achievement: The system satisfies the criteria for TRL 4 maturity, demonstrating integrated component functionality in a controlled laboratory environment and supporting progression to higher readiness levels.

5.3. Closing Remarks

The convergence of generative AI with specialized business applications presents significant opportunities to democratize data analytics and augment human decision-making. This work demonstrates that intelligent agents integrating robust data processing, secure code generation, interactive visualization, and adaptive training can be developed for complex operational domains while maintaining reliable and secure operation under laboratory conditions.

While substantial work remains to transition from a TRL 4 prototype to a production-ready system, the foundational capabilities validated here provide a solid basis for continued development. As generative AI technologies mature, domain-specific intelligent assistants that balance flexibility with operational robustness are likely to become increasingly relevant. The architecture, methodology, and validated results presented in this paper contribute to the growing body of empirical and methodological knowledge on designing and validating such systems.