2501.11613

# Conversation Routines: A Prompt Engineering Framework for Task-Oriented Dialog Systems **Authors**: Giorgio Robino Abstract This study introduces Conversation Routines (CR), a structured prompt engineering framework for developing task-oriented dialog systems using Large Language Models (LLMs). While LLMs demonstrate remarkable natural language understanding capabilities, engineering them to reliably execute complex business workflows remains challenging. The proposed CR framework enables the development of Conversation Agentic Systems (CAS) through natural language specifications, embedding task-oriented logic within LLM prompts. This approach provides a systematic methodology for designing and implementing complex conversational workflows while maintaining behavioral consistency. We demonstrate the framework’s effectiveness through two proof-of-concept implementations: a Train Ticket Booking System and an Interactive Troubleshooting Copilot. These case studies validate CR’s capability to encode sophisticated behavioral patterns and decision logic while preserving natural conversational flexibility. Results show that CR enables domain experts to design conversational workflows in natural language while leveraging custom functions (tools) developed by software engineers, creating an efficient division of responsibilities where developers focus on core API implementation and domain experts handle conversation design. While the framework shows promise in accessibility and adaptability, we identify key challenges including computational overhead, non-deterministic behavior, and domain-specific logic optimization. Future research directions include CR evaluation methods based on prompt engineering framework driven by goal-oriented grading criteria, improving scalability for complex multi-agent interactions, enhancing system robustness addressing the identified limitations across diverse business applications. 1 Conversational Agentic Systems (CAS) In the LangChain blog article What is an AI agent? [1], Harrison Chase states: An AI agent is a system that uses an LLM to decide the control flow of an application. This definition resonates with the proposed approach, where business logic is embedded directly within LLM prompts to guide agent behavior. In this paradigm, the prompt itself acts as the primary mechanism for defining control flow. Therefore, in line with Chase’s definition, the conversational agent examples presented here are AI agents: they utilize an LLM to determine the application’s control flow—the train ticket booking or troubleshooting process—based on the embedded CR. This approach contrasts sharply with traditional hard-coded dialog managers, offering greater flexibility and adaptability by defining control flow declaratively through human-readable instructions rather than complex programming code [16, 17, 18, 19]. 1.1 Combining Chat Completion and Function Calling A Conversational Agentic System (CAS) can be defined as an AI agent specialized in chat-based interactions, combining the conversational capabilities of LLMs with structured function calls to execute specific tasks and workflows. Unlike basic prompt text-completion, which characterizes foundational large language models, a CAS requires an LLM that has undergone specialized fine-tuning on dialogue data. This chat-specific training, exemplified by OpenAI GPT-3.5 models behind applications like ChatGPT, transforms the base LLM’s capabilities into sophisticated dialogue management [2, 3]. A chat-completion model can effectively process the complete sequence of messages exchanged between the user and assistant, along with the system prompt, which is the focus of this study. This dialogue-oriented fine-tuning enables the LLM to maintain conversation coherence, track context across multiple turns, and generate contextually appropriate responses. Using chat-completion models, dialogue applications operate through a dynamic feedback loop where user inputs and system responses are appended to a shared conversation history. This history, encompassing the system prompt and prior message exchanges, serves as the model’s short-term memory, enabling in-context learning for coherent and contextually aware responses. Effective management of this conversation history is vital due to the token limitations of LLMs. While strategies like truncating older messages or summarizing interactions are commonly used to maintain dialogue relevance, these techniques fall outside the scope of this study. The second foundational prerequisite for enabling LLM-based agents is the use of an LLM pretrained for function-calling. The LLM is supplied with a list of available functions (also referred to as tools) that can be implemented in any programming language. This capability to invoke external tools is essential for developing task-oriented applications within specific, closed domains. <details> <summary>extracted/6229571/image_1.png Details</summary>  ### Visual Description # Technical Document: Sequence Diagram for Train Booking System ## 1. Overview This image is a **UML Sequence Diagram** illustrating the interaction between a user, a chat history management system, a Large Language Model (LLM) with embedded control logic, and external functional modules (Search and Booking). The diagram tracks the flow of information from an initial user request to a final booking confirmation. ## 2. System Components (Lifelines) The diagram features five distinct entities, represented by vertical lifelines with headers at the top and footers at the bottom: 1. **User**: The human actor initiating requests and receiving displays. 2. **Chat Message History**: The database or service responsible for storing and retrieving the conversation context. 3. **LLM with Control Logic in Prompt**: The central processing unit that interprets natural language, manages state, and decides which functions to call. 4. **Search Function**: An external service used to find available train options. 5. **Booking Function**: An external service used to finalize a reservation. --- ## 3. Process Flow and Message Exchange The sequence is divided into two primary phases: the **Search Phase** and the **Booking Phase**. ### Phase 1: Search and Selection 1. **User → Chat Message History**: The user sends the message: `"I want to book a train ticket"`. 2. **Chat Message History → LLM with Control Logic in Prompt**: The history service forwards the user message along with the existing chat history. 3. **LLM Internal Action**: The LLM performs a self-looping action: `Process prompt logic (control flow, rules, chat history)`. 4. **LLM → Search Function**: The LLM triggers a call: `Call "Search" function (find available trains)`. 5. **Search Function → LLM**: The function returns data via a dashed line: `Return search results (list of train options)`. 6. **LLM → Chat Message History**: The LLM sends the response: `"Here are the available trains"`. 7. **Chat Message History → User**: The system displays the options to the user: `Display train options`. ### Phase 2: Selection and Confirmation 8. **User → Chat Message History**: The user provides a specific choice: `"I choose the 10:30 train"`. 9. **Chat Message History → LLM with Control Logic in Prompt**: The history service forwards the user choice and the updated chat history. 10. **LLM Internal Action**: The LLM performs a self-looping action: `Process user choice and determine next action`. 11. **LLM → Booking Function**: The LLM triggers a call: `Call "Booking" function (reserve ticket)`. 12. **Booking Function → LLM**: The function returns confirmation via a dashed line: `Return booking confirmation (reservation details)`. 13. **LLM → Chat Message History**: The LLM sends the final message: `"Your train is booked for 10:30 AM"`. 14. **Chat Message History → User**: The system provides the final output: `Display booking confirmation`. --- ## 4. Technical Notations and Visual Cues * **Activation Bars**: Vertical rectangles on the lifelines indicate when a specific component is active or processing a request. The **LLM** lifeline has the longest continuous activation bar, indicating it maintains state throughout the transaction. * **Synchronous Messages**: Solid lines with filled arrowheads represent synchronous calls. * **Return Messages**: Dashed lines with open arrowheads represent the return of data from a function call. * **Self-Message**: U-shaped arrows on the LLM lifeline represent internal logic processing. ## 5. Text Extraction Summary | Category | Extracted Text | | :--- | :--- | | **Lifelines** | User, Chat Message History, LLM with Control Logic in Prompt, Search Function, Booking Function | | **User Inputs** | "I want to book a train ticket", "I choose the 10:30 train" | | **System Outputs** | "Here are the available trains", "Your train is booked for 10:30 AM" | | **Internal Logic** | Process prompt logic (control flow, rules, chat history), Process user choice and determine next action | | **Function Calls** | Call "Search" function (find available trains), Call "Booking" function (reserve ticket) | | **Function Returns** | Return search results (list of train options), Return booking confirmation (reservation details) | | **UI Actions** | Display train options, Display booking confirmation | **Language Declaration:** All text in this image is in **English**. No other languages were detected. </details> Figure 1: A Conversational Agentic System for train ticket booking, showing how the LLM with control logic interacts with external functions. The function-calling feature is a critical component that necessitates instruction-tuned LLMs (instruct-models) as a foundational prerequisite for Conversational Agentic Systems. Instruction tuning, as introduced by models such as InstructGPT [5], is pivotal because it equips these models with the ability to bridge natural language and programmatic logic — a capability essential for autonomous agent operations. This training enables the models to translate natural language descriptions into structured programming operations, making instruction tuning an indispensable step prior to implementing function calling in agent-based systems. Without this instruction-tuned foundation, models would lack the reasoning capabilities required to accurately interpret user intentions and reliably execute programmatic actions within a conversational framework. <details> <summary>extracted/6229571/image_0.png Details</summary>  ### Visual Description # Technical Document: LLM Function Calling and Conversation Architecture This document provides a detailed extraction and analysis of the provided architectural diagram, which outlines the flow of information between a Large Language Model (LLM), developers, designers, and end-users within a function-calling framework. ## 1. Component Isolation The diagram is structured into three primary functional regions: * **Region A: LLM Context Window (Top Left):** Defines the static and dynamic data provided to the model. * **Region B: Execution & Processing (Center/Bottom):** The core LLM logic and output generation. * **Region C: Backend Implementation (Right):** The technical infrastructure supporting function execution. --- ## 2. Detailed Component Transcription ### Region A: LLM Context Window This is the primary container for the model's immediate memory and instructions. * **Header Label:** `LLM Context Window` * **Sub-components:** * **Conversation Routine:** The top-level instructional framework. * **Nested Box:** `Functions Signatures` (The definitions of available tools). * **Context Data:** Static or retrieved information relevant to the session. * **Conversation History:** The log of previous turns in the dialogue. ### Region B: Execution & Processing * **LLM:** The central processing unit of the diagram. * **Function Call:** A specific output generated by the LLM when it determines a tool is needed. * **LLM Chat Completion:** The final natural language response generated for the user. ### Region C: Backend Implementation * **Function Implementations:** The actual code (e.g., Python/JavaScript) that executes the logic. * **External System API Wrappers:** The interface used to communicate with outside services. * **Function call Result:** The data returned after the function has been executed. ### External Actors (Input/Output) * **Domain Expert:** Provides input to the Conversation Routine. * **Conversation Designer:** Provides input to the Conversation Routine. * **Functions Developer:** Provides input to both the `Functions Signatures` and the `Function Implementations`. * **User:** The end-point receiving the `LLM Chat Completion` and providing input back into the `Conversation History`. --- ## 3. Flow and Logic Analysis The diagram illustrates a cyclical and interconnected workflow: ### Design & Development Phase 1. **Domain Experts** and **Conversation Designers** define the **Conversation Routine**. 2. The **Functions Developer** defines the **Functions Signatures** (what the LLM sees) and writes the **Function Implementations** (what the server executes). ### Execution Phase (The Loop) 1. **Input:** The **LLM** receives data from the **LLM Context Window** (Routine, Signatures, Context Data, and History). 2. **Decision:** The **LLM** can produce two types of outputs: * **Direct Path:** It generates an **LLM Chat Completion** directly. * **Action Path:** It generates a **Function Call**. 3. **Function Execution:** * The **Function Call** triggers the **Function Implementations**. * This interacts with **External System API Wrappers**. * The result is captured in **Function call Result**. 4. **Feedback Loop:** * The **Function call Result** is fed back into the **Conversation History**. * The **LLM Chat Completion** is sent to the **User**. * The **User's** subsequent response is fed back into the **Conversation History**, restarting the cycle. --- ## 4. Summary of Textual Elements | Category | Extracted Text | | :--- | :--- | | **Main Containers** | LLM Context Window, LLM | | **Context Elements** | Conversation Routine, Functions Signatures, Context Data, Conversation History | | **Output Elements** | Function Call, LLM Chat Completion, Function call Result | | **Backend Elements** | Function Implementations, External System API Wrappers | | **Actors** | Domain Expert, Conversation Designer, Functions Developer, User | </details> Figure 2: A Single-Agent Conversational Agentic System Architecture. The figure illustrates the interaction between key components: the Conversation Routine, contextual data, and conversation history, all encapsulated within the LLM’s context window. Inputs from domain experts and conversation designers define the agent’s instructions and functions, while developers implement API wrappers and external system calls. The system dynamically processes user inputs through the LLM’s chat completion capabilities, leveraging modular function calls and seamlessly returning results. 1.2 Multi-Agent CAS Frameworks: Insights from OpenAI SWARM A Conversational Agent System (CAS) can be implemented using either a single-agent architecture or a multi-agent architecture, where multiple agents collaborate to accomplish a task. In omy experiments, I employed a single-agent configuration because our specific use cases did not initially require decomposing the workflow into multiple specialized agents. However, for complex workflows, a multi-agent approach often offers significant advantages in terms of modularity, scalability, and maintainability. The OpenAI SWARM framework provides a compelling illustration of multi-agent orchestration in action [6, 7]. At its core, SWARM introduces the concept of dynamic switching between specialized agents. Instead of relying on one monolithic agent to handle every aspect of a conversation or task, SWARM empowers distinct agents—each with a narrowly defined role and a tailored system prompt—to take control when their expertise is needed. This modular design minimizes unintended interactions that can arise when too many diverse logics are embedded within a single system. SWARM also emphasizes context-aware handoffs. Each agent operates on a shared conversation history and context variables, allowing it to recognize when a query exceeds its domain of expertise. In such cases, the agent seamlessly transfers control to another agent better equipped to address the request. This handoff mechanism ensures that overall coherence is preserved and that the system’s responses remain contextually appropriate throughout the interaction. Another key benefit of the multi-agent approach—as demonstrated by SWARM —is the use of specialized agent routines. Rather than embedding all business logic into one unwieldy prompt, the framework modular routines allow designers to encode conditional logic, iterative processes, and error management directly into each agent’s instructions. This routines strategy not only simplifies individual agent design but also makes the entire system more robust and adaptable. By isolating different parts of the business logic, updates or refinements can be made with minimal impact on the overall system—a critical advantage for scalability and long-term maintenance. In summary, while our experimental work initially employed a single-agent setup for simplicity, the insights derived from the OpenAI SWARM framework highlight the significant advantages of adopting multi-agent architectures for managing complex, multi-step workflows. By leveraging dynamic agent switching, shared context, and a modular design, multi-agent systems can greatly enhance both the flexibility and efficiency of Conversational Agentic Systems (CAS). This approach not only aligns with contemporary advancements in prompt engineering and LLM-based orchestration but also establishes a scalable foundation for future applications requiring seamless integration of diverse, specialized capabilities. Although the experimental prototypes in this study were implemented using SWARM ’s single-agent configuration, the concepts and findings presented remain broadly applicable and independent of any specific agent framework. In the final chapter of this paper, I’ll explore alternative frameworks and their potential applications in this domain. 1.3 Embedding Business Logic via Natural Language Instructions Traditional deterministic dialogue systems rely on rigid, rule-based state-machine approaches, which often result in inflexible and cumbersome interactions. In contrast, LLM-driven workflows offer greater adaptability by embedding business logic directly within the model’s context through structured natural language prompts. Conversational Agentic Systems are designed to handle conditional logic, iterative processes, and complex procedural sequences, thereby facilitating the execution of moderately complex business tasks. This study explores how embedding business logic within LLM prompts can enhance both functionality and efficiency in closed-domain applications, leading us to ask the following research question: How can natural language instruction prompts be designed to manage procedural logic, conditional flows, and data dependencies so that LLMs can execute multi-step workflows while adhering to specific business constraints? 2 System Prompts as Conversation Routines While CAS excel at natural language interactions and task execution through backend systems, controlling their behavior to enforce business rules remains challenging. This study leverages prompt engineering by embedding procedural logic within Conversation Routines (CR), focusing on system prompts that encode business logic through natural language (low-code/pseudo-code) specifications. This enables LLMs to function as workflow interpreters. The meaning of routine was introduced by OpenAI in the context of SWARM, an experimental open-source framework for conversational agents, as described in the cookbook article Orchestrating Agents: Routines and Handoffs [6] [8]. In this article, Ilan Bigio defines a routine as: The notion of a “routine” is not strictly defined, and instead meant to capture the idea of a set of steps. Concretely, let’s define a routine to be a list of instructions in natural language (which we’ll represent with a system prompt), along with the tools necessary to complete them.[…] The main power of routines is their simplicity and robustness. Notice that these instructions contain conditionals much like a state machine or branching in code. LLMs can actually handle these cases quite robustly for small and medium sized routine, with the added benefit of having “soft” adherence — the LLM can naturally steer the conversation without getting stuck in dead-ends. The Conversation Routines approach outlined in this paper aligns with the OpenAI SWARM definition of routines, leveraging structured natural language directives to specify precise agent behaviors. This approach enables conversation designers to develop complex logic without the need for traditional programming languages. By embedding decision-making logic directly into prompts, CR shifts control flow from conventional code to natural language specifications, leveraging the advanced understanding capabilities of LLMs. In this framework, the system prompt serves as a comprehensive software requirements document, providing both procedural instructions and declarative specifications to guide agent behavior effectively. A notable advantage of CR is its accessibility to non-programmers. Conversation designers and domain experts can independently author and refine prompts, reducing reliance on software developers while ensuring flexibility and clarity in agent behavior design. Application development using CR is structured into two primary components with distinct ownership and responsibilities. The first component, managed by conversation designers, consists of writing the system prompt. This prompt incorporates the CR technique and includes function declarations that clearly define the required tools with names, descriptions, parameters, and return values. The second component, maintained by software developers, is the Tools Library — a collection of custom-implemented functions. Each function is thoroughly documented with appropriate docstrings, providing the actual functionality referenced in the function declarations. <details> <summary>extracted/6229571/image_4.png Details</summary>  ### Visual Description # Technical Document Extraction: Conversation Agentic System Architecture ## 1. Document Overview This image is a technical sequence-style diagram illustrating the workflow and responsibilities between human roles and system components within a **Conversation Agentic System**. It defines the interaction between design, logic declaration, and technical implementation. --- ## 2. Component Isolation ### A. External Actors (Left Side) * **Role:** **Conversation Designer** * **Position:** Represented by two light-grey blocks (top and bottom) on the far left, connected by a vertical lifeline. ### B. Internal System (Center Box) * **Container Label:** **Conversation Agentic System** * **Sub-Components (Lifelines):** 1. **Conversation Routines:** The first internal component. 2. **Functions (Declarations & Docstrings):** The central logic definition component. 3. **Enterprise APIs or External Functions:** The interface for external system integration. ### C. External Actors (Right Side) * **Role:** **Software Developer** * **Position:** Represented by a light-grey block on the far right. </details> Figure 3: Collaboration Between Designers and Developers in a Conversation Agentic System. This clear separation of responsibilities allows conversation designers to concentrate on crafting effective conversational flows and specifying the required capabilities, while developers focus on implementing and maintaining the underlying functional tools. The function declarations act as the interface, ensuring seamless collaboration between the two domains. 2.1 Common Conversation Routines Components The following sections outline the common components of a CR prompt. 2.1.1 Identities and Purpose The foundation of any prompt lies in clearly defining the agent’s identity and purpose (bot-persona), as well as the user’s identity (user-persona). This step transcends basic goal-setting by establishing the contextual framework for all subsequent interactions. For instance: ⬇ 1 You are a specialized assistant focused on helping customers book train tickets. 2 Primary objectives: 3 - Guide customers through the booking process 4 - Ensure accurate information collection 5 - Maintain natural, helpful interactions 6 - Handle problems with patience and clarity 7 8 User persona examples: 9 - A first - time traveler unfamiliar with the booking process 10 - A frequent commuter seeking quick reservations 11 - A customer managing group bookings with specific preferences 12 - An international traveler requiring assistance with language or currency 2.1.2 Functions Integration Protocol A key section focuses on defining how the agent should interact with available tools (external functions). By embedding function specifications also into the system prompt, the agent gains an understanding of both technical capabilities and contextual appropriateness. Example: ⬇ 1 CORE FUNCTIONS: 2 - Station Search: Use ‘ search_railway_station ()‘ to search for departure and arrival stations. 3 Support pagination (next, previous, specific page selection) 4 and allow users to refine search queries if needed. 5 Users must explicitly select a station from the available options. 6 7 - Booking: Use ‘ book_train_ticket ()‘ to finalize the booking. 8 This function requires essential parameters like stations, dates, 9 times, passengers, and class. 10 11 - Date / Time Handling: Use ‘ get_date_time ()‘ to ensure valid and future dates. 12 If issues arise, provide context - aware suggestions for alternative dates. In the above example, when using search_railway_station() to find stations, the agent manages paginated results and allows query refinement, integrating responses seamlessly into the conversation. The protocol also emphasizes error management, equipping the agent to recover from common failures and provide user-friendly feedback. This integrated approach ensures the agent remains both technically proficient and contextually aware, enabling efficient and natural interactions. 2.1.3 Workflow Control Patterns The foundation of agent behavior lies in structured workflow patterns that guide decision-making and action sequencing. These patterns serve as essential frameworks for organizing complex interactions, ensuring consistent and reliable agent responses across various scenarios. The following sections explore key workflow patterns - sequential steps with conditionals, iteration logic, and user confirmation protocols - that form the building blocks of robust agent behavior. 2.1.4 Sequential Steps including conditionals I use systematic indentation patterns to create hierarchical structures for agent behavior specifications. This formatting syntax, similar to Markdown or YAML, enables clear visualization of workflow relationships, with each level of indentation representing a deeper section of behavioral logic. Parent-child relationships between workflow components are expressed through consistent spacing, typically using 2–3 spaces per level, allowing both humans and LLMs to easily parse the control flow and scope of different behavioral instructions. ⬇ 1 TRAIN_TICKET: 2 3 1. Station Search 4 - Get departure station 5 * Validate via search 6 * Confirm selection 7 - Get arrival station 8 * Validate via search 9 * Confirm selection 10 11 2. Journey Details 12 - Collect date / time 13 - Get passenger count 14 - Set travel class 15 16 3. Confirmation 17 IF all valid: 18 - Show summary 19 - Process booking 20 ELSE: 21 - Flag issues 22 - Return to input 2.1.5 Iteration Logic A crucial aspect is its ability to specify iteration patterns within workflows. These patterns enable agents to handle repetitive tasks and multi-step processes while maintaining context and progress. When defining iteration logic, designers can embed both explicit loop structures and conditional repetition patterns using natural language constructs. For instance, in moderate complex workflows like train booking, iteration specifications might include both user-driven and system-driven loops: ⬇ 1 ITERATION CONTROL PATTERNS: 2 3 1. User - Driven Iteration 4 - Present search results in paginated format 5 - While user has not made final selection: 6 * Allow navigation between pages 7 * Accept selection or refinement request 8 * Track current page position 9 - Exit loop only on explicit user confirmation 10 11 2. System - Driven Validation 12 - For each required booking detail: 13 * Collect and validate input 14 * Maximum 3 validation attempts 15 * On failure, offer guided correction 16 - Continue until all fields validated or user requests process restart The power of natural language allows for nuanced iteration control, seamlessly integrating loop management with user interaction patterns. This approach to iteration specification proves particularly valuable in scenarios requiring persistent state management and progressive refinement of user inputs, while maintaining the flexibility to break loops based on user satisfaction or system constraints. 2.1.6 User Confirmation Protocols This section establishes critical checkpoints where user confirmation must be obtained before proceeding with the workflow. Rather than relying on assumed understanding, we structure explicit verification points to ensure alignment between user intent and system actions. These verification points can be implemented through natural conversational flows or through deterministic checkpoint functions requiring explicit binary responses. Here’s how we might explain it: ⬇ 1 Remember to confirm important details naturally, like checking in with 2 " I ’ ve got [this information] so far - is that correct?" before moving forward. For critical workflow stages requiring deterministic confirmation: ⬇ 1 " To proceed with the booking, please review these details: [booking details] 2 3 You must confirm with Yes or No. 4 There are no alternative responses at this stage. 5 After user response always call user_confirmed_booking (confirmation_flag)" 2.1.7 Output Format and Tone This section is all about consistency — making sure our agent communicates in a way that’s both professional and engaging. This isn’t about rigid templates, but rather about maintaining a consistent voice and structure throughout the conversation. For example: ⬇ 1 Keep your responses friendly but focused. 2 When presenting options, structure them clearly: 3 4 " Here ’ s what I found for your journey: 5 Morning option: 9:15 AM departure 6 Afternoon option: 2:30 PM departure 7 Which time works better for you?" 2.1.8 Conversation Examples To further refine agent behavior, interaction examples can be incorporated using one-shot or few-shot prompting techniques. These examples serve as practical demonstrations of desired conversational flows, tones, and responses, helping to anchor the LLM’s behavior within specific interaction patterns. By including one or more illustrative dialogues, designers can guide the system toward consistent responses in similar contexts. For optimal effectiveness, examples can be tailored to each specific flow or decision point within the workflow. For instance, an example might demonstrate how the agent should confirm customer details during the data collection phase or how it should handle edge cases during the validation phase. These examples act as reference points, ensuring the LLM adheres to predefined interaction standards while maintaining natural and contextually appropriate communication. ⬇ 1 CONVERSATION EXAMPLE 2 3 User: I need a train ticket to London 4 Agent: I ’ ll help you book a ticket to London. First, I need some details: 5 1. What ’ s your departure city? 6 2. What date would you like to travel? 7 3. Do you prefer morning or evening travel? 8 9 Let ’ s start with your departure city. This structured approach creates a natural flow from understanding the basic purpose through to handling specific interactions, all while maintaining a conversational tone that makes the agent feel more approachable and helpful. Each section builds upon the previous ones, creating a comprehensive but flexible framework for our conversational agent. The sections listed above represent the basic common components of the framework. In the next chapter, I will present detailed real-world use cases as examples. 3 Conversation Routines in Practical Use Cases In my previous white paper, “A Conversational Agent with a Single Prompt?” [9], I presented three experimental use cases that demonstrate how Large Language Models can be programmed through structured prompts to achieve sophisticated task-oriented dialogs. Virtual Caregiver for Telemedicine: This case study involved a virtual caregiver designed for remote patient monitoring. This agent conducted daily check-ins, collecting vital health metrics such as temperature and blood oxygenation while maintaining empathetic, natural conversations. The system demonstrated a key strength of prompt-engineered LLMs: the ability to accommodate natural conversational digressions while reliably returning to structured data collection tasks. Customer Care Assistant: This case study featured a customer service agent that bridged the gap between free-form user descriptions and structured ticketing systems. This implementation highlighted dual advantages of natural language programming: simplifying development complexity while enabling natural human-like interactions. Users could express their issues conversationally, while the agent systematically gathered the stru ctured data required for backend processing. Virtual Job Interviewer: This prototype showcased a virtual recruiter that dynamically interviewed candidates by analyzing their CVs against job descriptions embedded in the prompt. This system demonstrated sophisticated cognitive abilities, probing candidates’ strengths, weaknesses, and potential mismatches while maintaining a structured yet adaptive conversational flow. The implementation illustrated how LLMs can perform complex workflows within defined conversational settings. During the development of these prototypes, I utilized the OpenAI GPT-3 (text-davinci-003) text-completion model, preceding the release of the GPT-3.5 (gpt-3.5-turbo) chat-completion model. These prototypes demonstrated the LLM’s remarkable capacity for fluid dialogue while staying aligned with assigned objectives. The agents exhibited an extraordinary ability to identify the conclusion of conversations when the programmed goal was achieved, along with maintaining an internal state of completed steps and tracking state variables effectively. Building on these previous experiments, I now present two new use cases where CR was applied in a more systematic manner. Each use case includes a description of the application problem, the specific prompts used, and illustrative conversation excerpts. 1. Train Ticket Booking System: This use case demonstrates how embedded business logic, expressed through CR, enables a Conversational AI System (CAS) to guide users through the complexities of purchasing train tickets. 1. Interactive Troubleshooting Copilot: In this example, a CAS assists technicians in diagnosing and troubleshooting machinery issues. The agent guides users through structured diagnostic procedures and provides access to relevant information, thereby streamlining factory-floor operations. For these two applications, I employed the OpenAI GPT-4o-mini model as the reference LLM, selected for its extensive 128k-token context window, function-calling capabilities, and low latency [10]. Each use case was implemented as an agent using the OpenAI SWARM framework [7, 8]. While the multi-agent architecture was used in this study, it is not a mandatory choice, and a detailed exploration of multi-agent systems is beyond the scope of this work. Since my native language is Italian, I conducted interactions in both English and Italian, with all conversation excerpts presented below in Italian. However, I retained English as the preferred language for prompt writing, as previously observed in my experiments [11]. Notably, the LLM used demonstrates strong multilingual capabilities, effectively handling multiple natural languages, including Italian, even with minimal language-specific instructions. ⬇ 1 LANGUAGE: 2 - Communicate in Italian 3 - Use second person form for instructions 4 Use Case 1: Train Ticket Booking System The first use case presents a demonstrative scenario in which a CAS facilitates the purchase of a train ticket. The agent is integrated with backend functions, enabling it to retrieve the current time, query a railway station names database, identify available train connections between specified origin and destination stations, and generate a ticket in a predefined format. A key challenge lies in constructing a prompt that encapsulates the complete business logic necessary for an efficient booking workflow. This process generally involves acquiring and validating user-provided information, followed by invoking a backend function to finalize the booking and payment. Traditional implementations of such workflows rely on hard-coded scripts developed using dialogue management frameworks [16, 17, 18, 19]. This approach necessitates anticipating all potential user actions, including digressions, out-of-scope requests, and error handling. As a result, script complexity increases rapidly, leading to substantial development overhead, increased costs, and a rigid, unnatural user experience. In contrast, the approach explored in this article utilizes a CAS guided by a comprehensive prompt encoding business logic via CR. Rather than hard-coding every possible interaction scenario, the LLM autonomously manages user interactions while adhering to the guidelines and rules specified within the instructions. The CR approach redefines the role of the conversation designer, expanding their responsibilities to include not only traditional interaction design specifications but also the encoding of business logic. As prompt designers, they now craft system behavior, tone of voice, user and assistant personas, and best practices for conversational interaction design - all articulated through natural language specifications within the prompt. A condensed and illustrative summary of the prompt employed in this use case is provided below; however, the complete prompt is more detailed and structured, with certain specifics omitted for brevity. For full details on the train ticket booking functionalities—including the complete workflow description, function signatures, and docstrings that specify behavior, required variables, and the precise data format for function arguments provided by the LLM—please refer to Appendix 7.1. Although the prompt instruction set is expressed in natural language, it adheres to a structured format to facilitate LLM comprehension. This format explicitly defines the logic and principles governing LLM behavior, such as the step-by-step workflow outlined in the INTERACTION WORKFLOW section, the data validation rules specified in the INFORMATION COLLECTION section, and the error handling procedures detailed in the ERROR HANDLING section. ⬇ 1 OBJECTIVE: 2 Assist users in booking train tickets through clear, user - friendly interactions. 3 4 CORE FUNCTIONS: 5 - Station Search: Use ‘ search_railway_station ()‘ 6 to search for departure and arrival stations. 7 Support pagination (next, previous, specific page selection) 8 and allow users to refine search queries if needed. 9 Users must explicitly select a station from the available options. 10 - Booking: Use ‘ book_train_ticket ()‘ to finalize the booking. 11 This function requires essential parameters like stations, dates, 12 times, passengers, and class. 13 - Date / Time Handling: Use ‘ get_date_time ()‘ to ensure valid and future dates. 14 If issues arise, provide context - aware suggestions for alternative dates. 15 16 INFORMATION COLLECTION: 17 - Departure and Destination: Stations are selected through the ‘ search_railway_station ()‘ function. 18 If multiple pages of results exist, navigate using pagination 19 and present results clearly to the user. 20 - Date and Time: Collect the departure and return dates in ’ YYYY - MM - DD ’ format. 21 Times can be flexible inputs like " early morning " or exact times like "08:30". 22 - Passenger Details: Collect the number of passengers (positive integer) 23 and the travel class (strictly ’1 st ’ or ’2 nd ’). 24 25 INTERACTION WORKFLOW: 26 1. Search Phase: 27 - Use ‘ search_railway_station ()‘ for departure and arrival stations. 28 - Handle paginated results (e. g., " Page 1 of 3") 29 and offer options to navigate, refine, or select a station. 30 2. Validation Phase: 31 - Once all required information is collected (stations, dates, times, passengers, class), 32 present a full summary of the booking details. 33 - Explicitly ask the user to confirm with " YES " or " NO ". 34 3. Booking Phase: 35 - If the user confirms, call ‘ book_train_ticket ()‘ with the gathered details. 36 - If the function returns an error, inform the user, suggest retry options, 37 or guide them to contact support. 38 - If successful, display all the booking receipt details clearly to the user. 39 40 ERROR HANDLING: 41 - If the booking fails, provide the user with a clear, polite message. 42 - Allow the user to revise incorrect information at any point during the process. 43 - If multiple failures occur, offer the user a chance to restart the process 44 or save partial data for later use. 45 46 USER GUIDANCE AND BEST PRACTICES: 47 - Prioritize clear, explicit communication. 48 Provide simple navigation options (next, previous, refine) when browsing station results. 49 - Ensure flexibility for date / time input (accepts " morning ", "08:30", etc.) 50 and strict validation for critical fields (dates, class, and passenger count). 51 - Ask for explicit confirmation before making any booking to prevent user errors. 52 - Gracefully handle booking errors and always offer corrective options to users. The prompt also incorporates a catalog of available back-end functions (APIs) that the agent is authorized to invoke. These functions, such as search_railway_station(), book_train_ticket(), and get_date_time(), are referenced within the prompt to execute specific tasks. These external functions are typically developed by a separate technical team, establishing a clear demarcation of responsibilities between prompt designers ( $\sim$ no-coders) and function developers ( $\sim$ coders). <details> <summary>extracted/6229571/image_2.png Details</summary>  ### Visual Description # Technical Document: Process Flow Diagrams for Station Search and Booking This document provides a detailed extraction and analysis of three interconnected process flow diagrams. The diagrams outline the logic for a station selection, booking confirmation, and result handling system. ## Component Isolation The image is divided into three distinct vertical segments, each representing a specific phase of the user journey: 1. **Left Segment:** Station Search and Selection Process. 2. **Middle Segment:** Booking Details and Confirmation Process. 3. **Right Segment:** Transaction Result and Error Handling. --- ## 1. Station Search and Selection Process (Left Segment) This flow describes the repetitive logic used to select both departure and arrival stations. ### Flow Details: * **Start:** The process begins at the **Start** node. * **Action:** **Search Departure**. * **Sub-process/Function:** `search_station`. * **Decision Point:** **Multiple Pages?** * **Yes:** Leads to **Show Pagination**, then proceeds to **Select Station**. * **No:** Proceeds directly to **Select Station**. * **Action:** **Select Station**. * **Action:** **Search Arrival**. * **Sub-process/Function:** `search_station`. * **Decision Point:** **Multiple Pages?** * **Yes:** Leads to **Show Pagination**, then proceeds to **Select Station**. * **No:** Proceeds directly to **Select Station**. * **Action:** **Select Station**. * **Exit Point:** **To Booking Process** (Indicated by a dashed border box). --- ## 2. Booking Details and Confirmation (Middle Segment) This flow handles the collection of user information and the final purchase execution. ### Flow Details: * **Entry Point:** **From Station Search** (Indicated by a dashed border box). * **Action:** **Collect Details**. * **Decision Point:** **Valid Input?** * **No:** Loops back to **Collect Details**. * **Yes:** Proceeds to **Show Summary**. * **Action:** **Show Summary**. * **Decision Point:** **Confirmed?** * **No:** Loops back to **Collect Details**. * **Yes:** Proceeds to the purchase function. * **Sub-process/Function:** `buy_ticket`. * **Exit Point:** **To Result Process** (Indicated by a dashed border box). --- ## 3. Transaction Result and Error Handling (Right Segment) This flow manages the outcome of the `buy_ticket` function. ### Flow Details: * **Entry Point:** **From Booking** (Indicated by a dashed border box). * **Decision Point:** **Success?** * **Yes:** Leads to **Show Confirmation**. * **Action:** **Show Confirmation**. * **End:** The process terminates at the **End** node. * **No:** Leads to **Show Error**. * **Action:** **Show Error**. * **Exit Point:** **To Booking Process** (Indicated by a dashed border box), suggesting a retry mechanism. --- ## Summary of Textual Elements ### Process Nodes (Rectangles) * Start * Search Departure * Show Pagination * Select Station * Search Arrival * Collect Details * Show Summary * Show Confirmation * Show Error * End ### Decision Nodes (Diamonds) * Multiple Pages? * Valid Input? * Confirmed? * Success? ### External References / Connectors (Dashed Rectangles) * To Booking Process * From Station Search * To Result Process * From Booking ### Functions/System Calls (Plain Text on Connectors or Grey Boxes) * `search_station` (Used twice in the search phase) * `buy_ticket` (Used in the confirmation phase) ### Logic Labels * Yes * No </details> Figure 4: Flowchart visualization of the train ticket booking workflow as specified in the LLM prompt. The diagram was generated by prompting an LLM to create a Mermaid flowchart representation of the prompt. 4.1 A Digression on Best Practices for Tools Design Although the primary focus of this paper is on Conversation Routines as a prompt engineering technique for crafting system prompts, a significant portion of the CAS development effort is dedicated to defining effective (e.g., Python) functions to provide backend services (e.g., booking services). It is important to highlight that these backend functions are integral to the problem domain and would be required regardless of whether the workflow was implemented using a deterministic, hard-coded software tool. A critical consideration is the design of functions that can be seamlessly invoked by an LLM. A crucial aspect of this design is the management of function state persistence. Ideally, functions should be stateless, adhering to the principles of functional programming, with the LLM maintaining state by providing the appropriate arguments for each function invocation. Conversely, when implementing functions with stateful logic, additional precautions are necessary. In such cases, the state must be tracked and made accessible to the LLM. This can be achieved through shared memory mechanisms or by embedding the relevant state information within the LLM’s prompt context, ensuring continuity across multiple function invocations. To illustrate this point, challenges were encountered when implementing a function to search for railway stations within a dataset of thousands of entries, enabling users to navigate the results using pagination and standard navigation commands (e.g., next page, previous page, first page, last page). Initially, the implementation employed a Python class to manage the state of the instantiated class, necessitating the maintenance and explicit sharing of a transaction ID, thereby complicating the LLM-function interface. A more straightforward solution, however, involved designing a stateless function where the page number is passed as an argument. With this approach, the LLM maintains the current page number internally and provides the appropriate page number based on user navigation requests expressed in natural language with implicit references (e.g., “I don’t see the station I’m looking for”, when on page 1 of 10). In this scenario, the LLM correctly requested page 2 via the function call: ⬇ 1 search_railway_station (query: "...", page =2) This demonstrates the LLM’s ability to handle state transitions without requiring explict state management, such as storing the page variable in the LLM’s context window. The function’s docstring is provided below: ⬇ 1 def search_railway_station (query: str, page: int = 1) -> str 2 """ 3 Perform a search for railway station names based on a query 4 and display results in a paginated format. 5 6 Args: 7 query (str): The search query, consisting of one or more space - separated words. 8 page (int, optional): The current page number to display (1- based indexing). 9 Defaults to 1. 10 Returns: 11 str: A formatted string displaying the search results for the specified page, 12 including pagination details. 13 Behavior: 14 - Matches are case - insensitive. 15 - If no matches are found, a message will indicate zero results. 16 - Automatically handles pagination and displays the total number of pages and results. 17 Example: 18 >>> results = search_railway_station (" Genova ", page =1) 19 >>> print (results) 20 Found 2 total results (Page 1 of 1): 21 1. Genova Principe 22 2. Genova Brignole 23 """ gg 4.2 Experimental Results: Analysis of a Train Booking Dialog Session Let’s analyze a dialog session example where the user’s primary intent is to book a train ticket from Genova to Roma for the following morning, with preferences for traveling alone, first-class seating, and an early departure around 6:00. The Train Ticket Booking System dialog session excerpt, provided in Appendix 7.2, exemplifies the agent’s adherence to prompt instructions for managing complex conversations, particularly in handling station searches and confirming travel details. The agent effectively manages the interaction by adhering to a predefined logical flow while dynamically adapting to the user’s input. It systematically gathers all necessary details, handles ambiguities—such as unclear station names—through paginated search results, and maintains transparency by confirming decisions and summarizing key details throughout the process. The interaction begins with the agent requesting essential information, such as the departure station, number of passengers, and travel class. When the user is unsure of the station name and provides ambiguous input (“e’ una staziuone di Genova ma non mi ricordo il nome…”), the agent does not halt but instead offers to refine the search by providing additional pages of results. Once the user identifies the correct station (“Nervi”), the agent seamlessly resumes the flow, confirming the details and proceeding to gather the preferred departure time. This demonstrates the agent’s ability to maintain a user-centered dialog approach by patiently guiding the user through structured queries. The agent correctly leverages available external functions, such as search_railway_station(), to retrieve station information, showcasing its ability to interact with external systems as instructed in the prompt. By dynamically responding to user input, the agent clarifies preferences, such as the travel class and departure time, ensuring that no critical details are overlooked. Transparency is maintained throughout the interaction by confirming decisions at key stages and summarizing the collected details before requesting explicit user confirmation. Once all the necessary information is finalized, the agent executes the booking via the book_train_ticket() function, providing a comprehensive summary of the travel itinerary, seat details, and total cost. This iterative process highlights the agent’s application of behavior rules defined in the prompt, particularly its adherence to requiring user confirmation before executing decisive actions. The session demonstrates the agent’s ability to combine structured dialog management, robust error handling, and seamless integration with external systems, resulting in an efficient and user-friendly ticket booking experience. <details> <summary>extracted/6229571/train_booking_tokens.png Details</summary>  ### Visual Description # Technical Document: Token Usage and Function Calls Analysis ## 1. Document Overview This document provides a comprehensive extraction of data from a line graph titled **"Token Usage and Function Calls in a Train Booking System Dialog Session."** The chart tracks the accumulation of tokens and the execution of specific API function calls across 14 sequential dialog turns. --- ## 2. Chart Metadata and Structure * **Title:** Token Usage and Function Calls in a Train Booking System Dialog Session * **X-Axis Label:** Dialog Turn (Values: 1 to 14) * **Y-Axis Label:** Token Count (Scale: 0 to 4000, increments of 500) * **Legend Location:** Top-left [approx. x=0.1, y=0.9 relative to plot area] * **Legend Categories:** * **Prompt Tokens:** Represented by a yellow line with solid circle markers (●). * **Completion Tokens:** Represented by a green line with open circle markers (○). * **Total Tokens:** Represented by a red line with open triangle markers (△). --- ## 3. Component Isolation & Trend Analysis ### A. Total Tokens (Red Line / Triangle Markers) * **Trend:** Shows a sharp initial spike between Turn 1 and Turn 2, followed by a steady, monotonic upward slope. This indicates a cumulative context window where previous turns are retained in the prompt. * **Data Points (Annotated in Red Text):** 1. Turn 1: 418 2. Turn 2: 2013 3. Turn 3: 2051 4. Turn 4: 2262 5. Turn 5: 2351 6. Turn 6: 2511 7. Turn 7: 2542 8. Turn 8: 2730 9. Turn 9: 2763 10. Turn 10: 2988 11. Turn 11: 3043 12. Turn 12: 3284 13. Turn 13: 3608 14. Turn 14: 3644 ### B. Prompt Tokens (Yellow Line / Solid Circle Markers) * **Trend:** Closely mirrors the "Total Tokens" line, sitting just below it. This confirms that the vast majority of the token budget is consumed by the prompt (input/context) rather than the model's response. ### C. Completion Tokens (Green Line / Open Circle Markers) * **Trend:** Remains consistently low, fluctuating between approximately 20 and 150 tokens per turn. This indicates the model's outputs (function calls or short text) are concise. * **Visual Peaks:** Notable small peaks occur at Turn 2, Turn 8, Turn 10, and Turn 13. --- ## 4. Function Call Transcription Specific function calls are annotated at various turns, connected to the data points by vertical dashed grey lines. | Turn | Function Call (Transcribed Precisely) | | :--- | :--- | | 1 | `handoff_buy_train_ticket({})` | | 3 | `search_railway_station({'query': 'Genova'})` | | 5 | `search_railway_station({'query': 'Genova', 'page': 2})` | | 7 | `search_railway_station({'query': 'Roma'})` | | 9 | `search_railway_station({'query': 'Roma', 'page': 2})` | | 11 | `get_date_time({'timezone': 'Europe/Rome'})` | | 13 | `buy_train_ticket({...})` | --- ## 5. Data Table Reconstruction | Dialog Turn | Prompt Tokens (Est.) | Completion Tokens (Est.) | Total Tokens (Actual) | Function Call Triggered | | :--- | :--- | :--- | :--- | :--- | | 1 | 400 | 18 | **418** | handoff_buy_train_ticket | | 2 | 1930 | 83 | **2013** | - | | 3 | 2030 | 21 | **2051** | search_railway_station (Genova) | | 4 | 2220 | 42 | **2262** | - | | 5 | 2290 | 61 | **2351** | search_railway_station (Genova, p2) | | 6 | 2430 | 81 | **2511** | - | | 7 | 2520 | 22 | **2542** | search_railway_station (Roma) | | 8 | 2630 | 100 | **2730** | - | | 9 | 2740 | 23 | **2763** | search_railway_station (Roma, p2) | | 10 | 2890 | 98 | **2988** | - | | 11 | 3020 | 23 | **3043** | get_date_time | | 12 | 3230 | 54 | **3284** | - | | 13 | 3440 | 168 | **3608** | buy_train_ticket | | 14 | 3620 | 24 | **3644** | - | --- ## 6. Language Declaration The primary language of the document is **English**. The function calls contain Italian geographic names: * **Genova** (English: Genoa) * **Roma** (English: Rome) * **Europe/Rome** (Timezone identifier) </details> Figure 5: Token consumption increases linearly with context window accumulation, as shown in a 14-agent-turn dialog session using 36,208 tokens over 3 minutes and 41 seconds. Functions were correctly called, with search_railway_station() invoked 4 times to resolve source and destination ambiguities. The token count grows from an initial 2013 to 3644 as conversation history and function responses are progressively added to the context window. In conclusion, the dialog interaction highlights the agent’s capability to manage complex conversations efficiently. It dynamically handles ambiguous input, maintains state across multiple turns, and adheres to a predefined logical flow. These qualities result in an effective and seamless user experience, demonstrating the value of using Conversation Routines to structure task-oriented dialog systems. The Conversation Routine prompt consistently delivered excellent user experience results. Across more than 50 test runs, the system successfully booked a train that met the specified requirements in nearly all cases. Challenges arose only when I intentionally introduced non-collaborative interactions, such as requesting a nonexistent station name. Even in these cases, the booking process reliably adhered to the confirmation step, ensuring that the final purchase was completed with accurate data, though it sometimes required additional turns to resolve ambiguities. Conversely, when all necessary data was provided collaboratively, the LLM consistently “converged” on a successful booking within just a few turns, demonstrating its efficiency in handling straightforward interactions. A minor issue I experienced was the LLM’s tendency to output text in markdown format, even when the prompt explicitly requested avoiding special text formatting. A possible solution could involve fine-tuning the general-purpose LLM to precisely follow the desired syntax (e.g., avoiding special formatting). This aspect is potentially significant for voice-interface solutions. However, we consider this a minor problem since it is solvable via fine-tuning or post-processing of the generated text, which lies outside the primary scope of this study. 5 Use Case 2: Interactive Troubleshooting Copilot As a proof of concept demonstrating the capability of a LLM to facilitate real-time, task-oriented dialogues, the Interactive Troubleshooting Copilot was developed as a more complex application. This conversational assistant is designed to support technicians in troubleshooting and repairing industrial systems through continuous interactive guidance while adhering to predefined business logic embedded within the system prompt [12]. The proposed system is particularly beneficial for technicians with limited troubleshooting expertise and unfamiliarity with the equipment involved. It provides a conversational interface through which the user can describe equipment status observations and detail the actions performed during the troubleshooting process. Furthermore, the assistant can address ancillary inquiries regarding equipment specifications and details while maintaining focus on the repair task, guiding the operator back to the appropriate step in the procedure as necessary. The assistant interacts with the user via voice and provides step-by-step guidance through the troubleshooting procedure. The process commences with an initial issue description and proceeds by retrieving relevant troubleshooting documentation, employing a Retrieval-Augmented Generation (RAG) approach. This methodology enables the assistant to offer continuous, contextually relevant guidance throughout the repair process, ensuring operator adherence to the documented procedure with precision. 5.1 The Troubleshooting Procedure Manual as Workflow Guideline A fundamental challenge in leveraging a LLM for task-oriented dialogues is conveying the specific business logic or processes required to complete a task, such as a repair procedure. The central concept is to utilize a human-readable document outlining the procedure, ideally one already available to technicians. For this study, a Conveyor Belt Troubleshooting Procedure Manual was developed — a comprehensive document designed to guide technicians through the diagnosis and repair of industrial conveyor belt systems. This document provides detailed, step-by-step instructions, each associated with specific component codes (e.g., QDE-9900-PRO, RLT-8450-V2), ensuring accurate identification of the components involved. The complete document is available in Appendix 7.3. The procedure incorporates conditional logic and decision points, where the subsequent step is contingent upon the technician’s observations (e.g., detecting misalignment, damaged parts, or sensor malfunctions). Additionally, the procedure includes iterative loops, requiring the technician to revisit previous steps if anomalies persist following an initial resolution attempt. Visualization of the aforementioned procedure as a flowchart reveals a process consisting of 18 discrete steps. While the logic ranges from relatively simple to moderately complex, the procedure incorporates a significant number of conditional branching points and iterative loops, ensuring a systematic and repeatable troubleshooting process. The manual provides a systematic approach for diagnosing and resolving issues in an industrial conveyor belt system. It covers mechanical blockages, belt misalignment, roller wear, sensor malfunctions, and electrical faults. Steps include visual inspections, component-specific checks (e.g., tension rollers, sensors), emergency protocols, repairs, and final testing. Decision points guide technicians through conditional paths (e.g., ” if objects are stuck, go to Step 3; if misaligned, go to Step 7 ”). Key components are identified with codes (e.g., CNV-NT2024-A for the belt) for precise maintenance. <details> <summary>extracted/6229571/image_3.png Details</summary>  ### Visual Description # Technical Document Extraction: Conveyor/Belt System Maintenance Flowchart ## 1. Document Overview This image is a technical flowchart detailing a multi-step diagnostic and repair procedure for a mechanical system, likely a conveyor belt. The process is numbered from 1 to 18, utilizing standard flowchart symbols: rectangles for actions/processes and diamonds for decision points. ## 2. Component Isolation & Flow Analysis ### Region A: Initial Inspection and Blockage Handling (Top Center) * **1: Check System** (Action): The entry point of the procedure. * **2: Inspect Belt** (Decision): The primary diagnostic node. * *Path "Blocked":* Leads to **3: Emergency Stop**. * *Path "Misaligned":* Leads to **7: Check Guides**. * *Path "OK":* Leads to **14: Check Sensors** (Transition to Region D). ### Region B: Blockage Resolution (Center) * **3: Emergency Stop** (Action): Triggered if the belt is blocked. * **4: Remove Objects** (Decision/Action): * *Path "Success":* Leads to **6: Check Belt**. * *Path "Difficult":* Leads to **5: Call Tech**. * **5: Call Tech** (Action): Professional assistance for difficult removals, then proceeds to **6: Check Belt**. * **6: Check Belt** (Decision): Post-removal inspection. * *Path "OK":* Leads to **13: Manual Start**. * *Path "Damaged":* Leads to **12: Document**. * **12: Document** (Action): Recording damage before proceeding to **13: Manual Start**. ### Region C: Alignment and Mechanical Maintenance (Left) * **7: Check Guides** (Decision): Triggered by misalignment. * *Path "Loose":* Leads to **8: Fix Guides**. * *Path "OK":* Leads to **9: Check Rollers**. * **8: Fix Guides** (Action): Repairing loose guides, then proceeds to **13: Manual Start**. * **9: Check Rollers** (Decision): * *Path "Worn":* Leads to **10: Replace**. * *Path "OK":* Leads to **11: Check Tension**. * **10: Replace** (Action): Replacing worn rollers, then proceeds to **13: Manual Start**. * **11: Check Tension** (Action): Final mechanical check, then proceeds to **13: Manual Start**. ### Region D: System Restart and Monitoring (Right) * **13: Manual Start** (Action): Central convergence point for all mechanical repairs. * *Path "Issues":* A feedback loop returns from the output of Step 13 back to **2: Inspect Belt**. * *Path "OK":* Proceeds to **14: Check Sensors**. * **14: Check Sensors** (Decision): * *Path "OK":* Leads to **16: Auto Test**. * *Path "Error":* Leads to **15: Clean/Fix**. * **15: Clean/Fix** (Action): Sensor maintenance, then proceeds to **16: Auto Test**. * **16: Auto Test** (Action): Automated system verification. * **17: Monitor 5min** (Decision): Observation period. * *Path "Issues":* A feedback loop returns from the side of the diamond back to **2: Inspect Belt**. * *Path "OK":* Leads to **18: End**. * **18: End** (Action): Completion of the maintenance cycle. ## 3. Textual Transcription (Precise) | ID | Text Label | Type | Connections/Logic | | :--- | :--- | :--- | :--- | | 1 | Check System | Action | Start -> 2 | | 2 | Inspect Belt | Decision | Blocked -> 3; Misaligned -> 7; OK -> 14 | | 3 | Emergency Stop | Action | From 2 -> 4 | | 4 | Remove Objects | Decision | Success -> 6; Difficult -> 5 | | 5 | Call Tech | Action | From 4 -> 6 | | 6 | Check Belt | Decision | OK -> 13; Damaged -> 12 | | 7 | Check Guides | Decision | Loose -> 8; OK -> 9 | | 8 | Fix Guides | Action | From 7 -> 13 | | 9 | Check Rollers | Decision | Worn -> 10; OK -> 11 | | 10 | Replace | Action | From 9 -> 13 | | 11 | Check Tension | Action | From 9 -> 13 | | 12 | Document | Action | From 6 -> 13 | | 13 | Manual Start | Action | From 6, 8, 10, 11, 12 -> 14; Issues -> 2 | | 14 | Check Sensors | Decision | OK -> 16; Error -> 15 | | 15 | Clean/Fix | Action | From 14 -> 16 | | 16 | Auto Test | Action | From 14, 15 -> 17 | | 17 | Monitor 5min | Decision | OK -> 18; Issues -> 2 | | 18 | End | Action | Terminal Point | ## 4. Language Declaration The primary and only language present in this document is **English**. No other languages were detected. </details> Figure 6: Simplified flowchart representation of the troubleshooting procedure described in the Conveyor Belt Troubleshooting Procedure Manual. The diagram was generated using an LLM prompt to create a Mermaid-based flowchart. 5.2 Embedding Troubleshooting Manual Business Logic in the Prompt The CAS developed for the use case is designed to assist technicians in diagnosing and repairing conveyor systems. It defines the assistant’s role as an expert, with core functions including retrieving troubleshooting steps, providing component details, and generating reports. The system maintains an internal state, tracking the current step, historical progress, safety status, and component information to ensure both procedural continuity and adherence to safety protocols. The troubleshooting process is structured into four distinct stages and is orchestrated by a multi-agent architecture consisting of two agents: 1. a Troubleshooting Assistant Agent manages the Initial Assessment stage by retrieving the relevant instructions using a Retrieval-Augmented Generation (RAG) approach and verifying the necessary safety protocols. During the Step-by-Step Execution phase, this agent guides the technician through each sequential repair step, ensuring compliance with all safety measures. If additional information, such as component specifications, is required, the Part Inquiries stage is triggered, retrieving the necessary details before resuming the repair process. Here above the CR developed for the Troubleshooting Assistant Agent: ⬇ 1 INDUSTRIAL MACHINERY TROUBLESHOOTING ASSISTANT 2 3 ROLE AND CONTEXT: 4 You are an expert industrial machinery repair assistant specializing in conveyor troubleshooting procedures. 5 Your primary goal is to ensure safe and effective repairs while guiding users through documented procedures. 6 7 CORE FUNCTIONS: 8 - retrieve_troubleshooting_instructions (query) -> Returns procedure details 9 - retrieve_part_details (device_code) -> Returns part specifications 10 - handoff_report () -> Transfer control to reporting system 11 12 CONVERSATION FLOW: 13 1. INITIAL ASSESSMENT: 14 - Acknowledge user ’ s reported issue 15 - Call retrieve_troubleshooting_instructions (issue) 16 - Analyze the returned step - by - step instructions 17 - Based on the user issue and the available sep instructions, decide the correct step where to start 18 - Present procedure ID and title 19 - Share a one - sentence summary of the possible diagnosis hypotesis 20 - Recap in one - sentence the step - by - step procedure 21 2. STEP - BY - STEP TROUBLESHOOTING PROCEDURE EXECUTION: 22 For each interaction: 23 - Present current step instructions 24 - Request specific confirmations 25 - Only advance when explicit confirmation received 26 - Handle interruptions (part queries, clarifications) without losing state 27 3. PART INQUIRIES HANDLING: 28 When user requests part information: 29 - Pause current procedure state 30 - Call retrieve_part_details () 31 - Present relevant information 32 - Resume previous procedure state 33 4. COMPLETION PROCEDURE: 34 - Verify all steps completed 35 - Transfer to Troubleshooting Report Agent 36 37 BEHAVIOR RULES: 38 - Retrieve repair instructions by calling retrieve_troubleshooting_instructions (query) 39 - Summarize the troubleshooting procedure with its ID and title 40 - Start from the most relevant step based on the user ’ s reported issue 41 - Present instructions one step at a time 42 - Keep step IDs internal unless explicitly requested 43 - Include safety warnings before any potentially hazardous steps 44 - Track conditional logic internally without exposing it to users 45 - Wait for explicit user confirmation before advancing to next step 46 - Stay within the current repair sequence until completion 47 - Handle part inquiries by calling retrieve_part_details (device_code), then resume current step 48 - Call the transfer function to the Troubleshooting Report Agent upon completion 49 50 SAFETY PROTOCOLS: 51 - Mandatory safety warnings before hazardous steps 52 - Required confirmations for critical operations 53 - Explicit voltage / power state verification 54 - Never skip safety prerequisites 55 56 RESPONSE STRUCTURE: 57 1. [Safety Warning if applicable] 58 2. [Current Step Instructions] 59 3. [Required Confirmation Items] 60 61 LANGUAGE AND FORMATTING: 62 - Communicate in Italian 63 - Use second person form for instructions 64 - Maintain plain text format without markdown 65 - Keep responses concise 66 67 ERROR HANDLING: 68 - If user response unclear: Request specific clarification 69 - If procedure interrupted: Save state and handle inquiry 70 - If safety condition unmet: Block procedure until resolved 71 72 EXAMPLE INTERACTION: 73 User: " Il motore non funziona " 74 Assistant: retrieve_troubleshooting_instructions (" Il motore non funziona ") 75 Assistant: " Procedura di risoluzione problemi motore MPR -2278- BX " 76 Assistant: " Spegni l ’ apparecchio. Verifica che la tensione sia zero. Indossa guanti isolanti. 77 L ’ apparecchio è spento e la tensione è zero?" 78 User: " Si, ho spento tutto, ma aspetta, mi dici che motore è questo MPR -2278- BX?" 79 Assistant: retrieve_part_details (" MPR -2278- BX ") 80 [After providing part details, resume current repair sequence] 2. Once the troubleshooting process is completed by the main agent, all gathered data is handed over to the Troubleshooting Report Agent, which formats a structured report summarizing the troubleshooting actions and saves it to a file. Here below the corresponding prompt: ⬇ 1 ROLE: 2 Expert building technical troubleshooting report documents. 3 4 BEHAVIOR: 5 1. Access troubleshooting conversation between the user and the assistant. 6 2. Access all troubleshooting process document already available. 7 3. Generate a detailed intervention / repair final report via build_report (activities_done). 8 9 FINAL REPORT TEXT FORMAT: 10 - Problem: Initial problem as described by the user. 11 - Source: Troubleshooting document title and reference number. 12 - Actions: List of actions performed by the user with the assistant ’ s guidance. 13 Each action must include details of what was done and end with the step ID in the format [step_id]. 14 - Use Italian language 15 - Use plain text, without markdown or special formatting 16 17 Example (assuming the sequence of step IDs is 1, 2, 3, 4, 6, 13): 18 REPORT INTERVENTO SVOLTO: 19 20 Problema: 21 Qualcosa blocca il nastro. 22 23 Procedura: 24 Procedura di Diagnosi Nastro Trasportatore - Assistente AI 25 DOC - REF: MNT - CNV -2024- IT -001 26 27 Azioni svolte: 28 - L ’ apparecchio è stato spento e scollegato dalla sorgente di alimentazione [1]. 29 - Ispezione visiva del nastro per oggetti incastrati e disallineamenti [2]. 30 - Rimozione del bullone arrugginito [3]. 31 - Il nastro è stato controllato e confermato libero da oggetti incastrati [4]. 32 - L ’ integrità del nastro è stata verificata e risulta integro [6]. 33 - Il nastro è stato riavviato in modalità manuale e ha funzionato correttamente [13]. In this kind of application, we encounter a dual layer of complexity: first, integrating the business logic embedded in the step-by-step troubleshooting procedure, and second, ensuring that the CAS adheres to a structured interaction workflow. Successfully addressing these challenges requires the LLM to manage two distinct levels of internal state: a lower-level state that tracks the detailed progression of troubleshooting steps and a higher-level state that orchestrates the broader interaction workflow. The latter governs tasks such as retrieving document data, evaluating the diagnosis, executing troubleshooting steps, and ultimately generating a repair report. Focusing on the Troubleshooting Assistant Agent, the prompt serves as a comprehensive instruction set that governs the LLM’s behavior during user interactions. Its structure is designed with clearly defined sections, including role and context, core functions, conversation flow, behavioral guidelines, and safety protocols. The CONVERSATION FLOW section, for instance, defines the high-level interaction stages and specifies the actions the LLM should take at each step. In the INITIAL ASSESSMENT stage, the prompt directs the LLM to retrieve troubleshooting documentation, analyze repair steps, present a diagnosis hypothesis, and provide a procedural overview—thus embedding the initial troubleshooting steps directly into the LLM’s behavior. A key aspect of achieving autonomy in troubleshooting assistance is ensuring structured, step-by-step interaction management. The BEHAVIOR RULES section of the prompt enforces this by instructing the LLM to present repair steps sequentially, wait for explicit user confirmation before proceeding, and handle interruptions (such as part inquiries) while maintaining state continuity. For example, if a technician requests component details mid-procedure, the prompt ensures that the LLM pauses the current workflow, calls the retrieve_part_details() function, and then seamlessly resumes from the previous step. This structured approach ensures that the assistant autonomously follows the pre-defined troubleshooting workflow while integrating the business logic outlined in the manual and embedded within the prompt itself. 5.3 Experimental Results: Analysis of a Troubleshooting Dialog Session The experimental results demonstrate the copilot’s ability to navigate a troubleshooting workflow using task-specific procedural knowledge encoded in the prompt. To illustrate this, we analyze a specific dialog session in which the copilot applies the Conveyor Belt Troubleshooting Procedure (MNT-CNV-2024-IT-001) to guide a user through diagnosing and resolving an issue. A full excerpt of this conversation session can be found in Appendix 7.4. <details> <summary>extracted/6229571/troubleshooting_tokens.png Details</summary>  ### Visual Description # Technical Document Extraction: Token Usage and Function Calls Analysis ## 1. Document Header * **Title:** Token Usage and Function Calls in a Troubleshooting Copilot Dialog Session * **Primary Language:** English * **Secondary Language:** Italian (contained within function call parameters) ## 2. Chart Metadata and Structure * **Chart Type:** Multi-series Line Graph with data labels and annotations. * **X-Axis (Horizontal):** "Dialog Turn" (Scale: 1 to 8, integer increments). * **Y-Axis (Vertical):** "Tokens Count" (Scale: 0 to 4000, increments of 500). * **Legend Location:** Top-left corner. * **Legend Categories:** * **Prompt Tokens:** Yellow line with solid circle markers (●). * **Completion Tokens:** Green line with open circle markers (○). * **Total Tokens:** Red line with open triangle markers (△). ## 3. Data Series Analysis and Trends ### Series 1: Total Tokens (Red Line, △) * **Trend:** Sharp upward slope from Turn 1 to 2, followed by a plateau at Turn 3. Another sharp increase occurs at Turn 4, followed by a steady, gradual upward slope through Turn 8. * **Data Points:** * Turn 1: 944 * Turn 2: 2471 * Turn 3: 2515 * Turn 4: 3123 * Turn 5: 3202 * Turn 6: 3289 * Turn 7: 3338 * Turn 8: 3434 ### Series 2: Prompt Tokens (Yellow Line, ●) * **Trend:** Closely mirrors the "Total Tokens" line, remaining just below it throughout the session. This indicates that the majority of the token volume is driven by the prompt/context. ### Series 3: Completion Tokens (Green Line, ○) * **Trend:** Low and relatively stable near the bottom of the Y-axis (0-250 range). It shows minor fluctuations, with small peaks at Turn 4 and Turn 8. ## 4. Embedded Function Call Annotations | Dialog Turn | Function Call Text | Language Note | | :--- | :--- | :--- | | **Turn 1** | `retrieve_troubleshooting_instructions({'query': 'C'è qualcosa che si è incastrato sotto il nastro.'})` | **Italian Translation:** "There is something stuck under the belt." | | **Turn 4** | `retrieve_part_details({'device_code': 'CNV-NT2024-A'})` | English | | **Turn 8** | `build_report({...})` | English | | **Turn 8** | `handoff_report({})` | English | ## 5. Component Isolation & Logic Check * **Logic Check:** Total Tokens (Red) = Prompt Tokens (Yellow) + Completion Tokens (Green). * **Verification:** At Turn 1, Total is 944. Prompt is slightly below 1000, and Completion is near 0. At Turn 8, Total is 3434. Prompt is approx. 3200, and Completion is approx. 200. The math visually aligns across all points. ## 6. Summary of Findings The graph illustrates a cumulative or context-heavy dialog session where the token count increases significantly as the conversation progresses. The most substantial jumps in token usage occur at Turn 2 and Turn 4. The "Total Tokens" are dominated by "Prompt Tokens," suggesting that the system is maintaining a growing conversation history or retrieving large amounts of context to process the troubleshooting request. Function calls are strategically placed at the start, middle, and end of the session to retrieve instructions, part details, and finally generate/handoff a report. </details> Figure 7: Progressive increase in token consumption during the 8-agent-turn troubleshooting dialog, illustrating linear context window expansion. Includes an observed superfluous retrieve_part_details() function call by the Troubleshooting Assistant Agent and the eventual handoff to the Troubleshooting Report Agent to finalize system verification and generate a structured report. The session begins when the user reports a problem: “ C’è qualcosa che si è incastrato sotto il nastro ” (“ Something is stuck under the tape ”). The copilot promptly retrieves the relevant procedure and initiates the diagnostic process by suggesting a possible cause and the first steps. It verifies that the conveyor system is ready by instructing the user to check that the emergency button is not pressed and the electrical panel is active. Once these conditions are confirmed, the copilot proceeds to the next step. As the session progresses, the copilot demonstrates its ability to interpret and act on vague or ungrammatical input. For example, when the user states, “ come ti dicevo e’ cosi’ ma no capoisco cosa sia ” (” As I was telling you, it’s like that, but I don’t understand what it is ”), the copilot correctly infers that the user has observed an obstruction without being certain of its nature and advises the necessary safety and removal procedures. Throughout the interaction, the copilot consistently maintains context by pausing after each instruction to confirm user actions, such as when the user reports having removed a ” bullone ” (”bolt”) from under the conveyor. It then transitions smoothly to the inspection phase, ensuring the belt’s integrity is verified before directing the user to restart the system in manual mode. A notable observation in this session is the copilot’s invocation of the function retrieve_part_details("device_code"="CNV-NT2024-A"), despite there being no real need to call it at that moment. This unnecessary function call did not disrupt the troubleshooting flow, as the copilot continued guiding the user seamlessly through the process. However, this behavior suggests potential areas for optimization, particularly in refining trigger conditions for information retrieval functions to enhance overall efficiency. The procedure concludes successfully with the copilot guiding the user through every step. Following resolution, the system generates a comprehensive intervention report that summarizes the problem, the actions taken, and the final outcome in strict adherence to the prompt’s requirements. Overall, the evaluation indicates that the copilot excels in task completion, error recovery, and contextual understanding, while demonstrating strong dialogue efficiency and user satisfaction—with only minor refinements needed in streamlining confirmation prompts. These results underline the viability of LLM-powered systems in task-oriented troubleshooting within industrial environments. By leveraging a carefully designed prompt and a predefined procedure manual, the copilot effectively guides users through complex workflows with accuracy, consistency, and clarity. This experiment illustrates the potential of such systems to enhance efficiency and reliability in real-world industrial applications. 6 Summary, Related Works and Future Directions 6.1 Summary This article introduced a novel approach to developing Conversational Agentic Systems (CAS) by embedding business logic directly within LLM prompts through Conversation Routines (CR). This methodology empowers domain experts and conversational designers to specify complex, task-oriented workflows using natural language rather than traditional coding methods. By structuring prompts into distinct sections—such as roles, core functions, conversational flow, behavior rules, and error handling—LLMs are enabled to operate as autonomous conversational agents in closed-domain environments. This approach offers a flexible, low-code alternative to conventional hard-coded dialogue systems, reducing development overhead and enabling rapid prototyping. Two use cases, a Train Ticket Booking System and an Interactive Troubleshooting Copilot, were presented to demonstrate how CR guides LLMs in managing complex interactions, resolving ambiguous input, maintaining state over multiple turns, and executing business logic while interfacing with backend systems. Despite its advantages, CAS implementations face limitations. The inherent non-determinism of LLMs can lead to confabulations or deviations from the intended prompt, especially during unexpected interactions. Although guardrail techniques help mitigate these risks, they cannot completely eliminate them. In contrast, deterministic hard-coded solutions typically offer lower latencies and fixed response flows. The trade-off, therefore, is between flexibility in handling unforeseen interactions and the potential for increased latency and unpredictability. Ultimately, the CR approach aims to minimize long-term development costs by using natural language to define agent behavior, thereby reducing the need for extensive manual updates. This research strives to empower domain experts and conversation designers by bridging the gap between design effort and computational execution, making conversational AI development more accessible, scalable, and effective. 6.2 Related Works The Conversation Routines approach leverages LLMs to manage the entire flow of control, ultimately invoking tools for deterministic function execution. However, alternative methodologies tackle this challenge from different perspectives. Below, I highlight some notable approaches. 6.2.1 RASA CALM Rasa’s Conversational AI with Language Models (CALM) framework integrates LLMs to interpret user inputs through an LLM-based Dialogue Understanding (DU) process, translating them into structured commands. These commands are executed by a deterministic dialogue manager that follows predefined business logic specified in Domain-Specific Language (DSL) templates. The Rasa CALM architecture ensures that while LLMs provide flexible and context-aware input interpretation, the execution of business processes remains controlled and predictable. The CALM framework offers several strengths: LLM completion calls are minimized, leading to reduced costs and response latencies, while business logic is executed deterministically, ensuring reliability. However, there are notable downsides. Business logic is hard-coded in YAML files, which may require coding skills, making it less accessible to business stakeholders or domain experts. Furthermore, the workflows tend to replicate the “mechanical” interaction patterns of older fully coded solutions, potentially limiting conversational naturalness and adaptability [13]. 6.2.2 LangGraph LangGraph is a framework built upon the LangChain library, designed to facilitate the development of multi-agent systems by decomposing complex problems into manageable tasks, each handled by specialized agents. It employs a graph-based architecture, where nodes represent discrete computational units, and edges define the pathways for data and control flow. In LangGraph, a shared state reflects the application’s current status, accessible and modifiable by all nodes throughout the workflow. Nodes, implemented as Python functions, process this state, execute specific actions, and return an updated state. This structure enables the system to effectively track and modify information as it advances through various stages, ensuring continuity and coherence across tasks. LangGraph offers several core benefits, including support for cycles, which are essential for most agentic architectures, fine-grained control over both the flow and state of applications, and built-in persistence that enables advanced human-in-the-loop and memory features. One of the main strengths of LangGraph lies in its modularity, which ensures that tasks are clearly separated and the system remains maintainable. Its deterministic execution also ensures predictable, consistent outcomes, making it a strong fit for applications that require reliability and stability. However, a key limitation of the framework is that hardcoding logic within the graph nodes can reduce flexibility. This approach necessitates manual updates whenever business logic changes, which can become challenging as business requirements evolve or grow in complexity. Additionally, implementing a solution with the LangGraph framework requires coding skills, which can make it less accessible to business stakeholders or domain experts [14, 14]. 6.2.3 Hugging Face Smolagents Hugging Face smolagents introduces a distinct paradigm in agentic systems by leveraging code generation as an alternative to traditional function-calling mechanisms. Unlike the deterministic workflows of Rasa CALM, the graph-based orchestration of LangGraph, or the SWARM framework (upon which the CR approach is partially based), smolagents adopts a CodeAgent methodology. In this approach, the LLM generates executable Python code to manage workflows and interact with tools, offering a unique blend of efficiency and flexibility. The primary strength of smolagents lies in its ability to reduce latency and computational overhead. By generating code snippets instead of relying on JSON-like tool calls, the framework minimizes LLM interaction steps. This approach allows for native handling of complex logic, such as loops and conditionals, which are often cumbersome in systems based on function-calling. However, this code-centric paradigm presents significant challenges. Unlike the Conversation Routines (CR) approach, which distinctly separates business logic (embedded in prompts) from deterministic execution (encapsulated in pre-developed and tested functions), smolagents intertwines prompt instructions with dynamically generated code. This fusion can lead to runtime errors that are difficult to trace, such as hallucinations in code logic or misaligned tool invocations. Debugging becomes more complex, as it requires parsing both LLM-generated code and execution logs, contrasting with the structured error-handling mechanisms of CR. Furthermore, the framework’s performance is heavily dependent on the LLM’s ability to generate accurate and syntactically correct code, which may vary across models. In comparison to the CR approach, smolagents excels in scenarios where latency and flexibility are critical, provided that robust runtime safety mechanisms are in place. However, the CR methodology’s clear separation of roles and responsibilities offers greater predictability and ease of troubleshooting, making it more suitable for applications where reliability and maintainability are paramount [20]. 6.3 Future Directions Future research aims to explore several key areas to further advance the development and evaluation of Conversational Agentic Systems (CAS). Below are some potential directions for related research. 6.3.1 Evaluating Conversation Routines through Criteria-Based Dialog Analysis One primary avenue of exploration is the development of a comprehensive framework for evaluating Conversation Routines (CR). While this introductory study illustrates CR’s potential through case studies, it currently lacks standardized metrics for rigorous quantitative assessment. A promising approach involves designing an evaluation system capable of assessing and refining an initial Conversation Routine. This system could follow a two-stage methodology for systematic evaluation and iterative improvement. The first stage would leverage an LLM-based evaluation system (LLM-as-a-judge) with domain-expert-defined, goal-oriented metrics to evaluate agent performance across multiple dimensions. This system would analyze both the CR prompt and specific dialog instances to identify areas for refinement. The second stage would implement an iterative process where conversation logs (refer to Appendices 7.2 and 7.4) are systematically reviewed against these metrics. Based on this analysis, the evaluation system would generate recommendations for modifying the prompt to enhance its effectiveness. Final validation of these modifications would be conducted by human experts to ensure domain relevance and behavioral consistency. 6.3.2 Prompt Optimization Pipelines It is worth highlighting that all Conversation Routines used in the academic use cases were initially developed by the author using predefined tools (Python functions) that simulated backend API behavior. These functions were created ad hoc to emulate real APIs, such as a train booking function or a troubleshooting document retrieval function. Their signatures and docstrings were subsequently embedded into the prompt to define agent specifications. The complete prompt was then iteratively refined during brainstorming sessions with general-purpose LLM applications, such as OpenAI ChatGPT and Anthropic Claude. However, in this iterative process, the function signatures were treated as fixed, potentially limiting opportunities for optimization. To demonstrate this limitation, an evaluation system was implemented in which prompts were dynamically constructed to identify the optimal function for a given task. This process revealed opportunities to refine and improve the function signatures themselves. These findings suggest that future CR optimization should prioritize high-level application requirements rather than relying solely on fixed function specifications or best-effort CR design. A critical research priority is to optimize how business logic is embedded within natural language prompts by examining trade-offs between high-level declarative instructions—such as those found in CRs—and more formalized structures, like pseudo-code or Domain-Specific Languages (DSLs). While DSLs provide enhanced precision and better state management, retaining CR’s natural language format as the primary medium for domain experts to draft specifications offers accessibility and flexibility. This format can later be ”compiled” into optimized LLM prompts for execution. A promising direction for innovation is to conceptualize high-level CRs—or their future iterations—as a form of ”source code” for compilers capable of generating executable workflows for low-level multi-agent frameworks, such as LangGraph or deterministic rule-based dialogue managers. A dedicated CR-compiler could transform CR into optimized prompts, thereby reducing operational costs and improving response latencies. This approach not only addresses the current limitations of Conversational Agentic Systems (CAS) but also ensures that non-programmers remain central to the design process. 6.3.3 Resource Optimization and Performance Benchmarking in Small LLMs Conversational agentic systems that rely on function-calling—especially within complex multi-agent architectures—incur computational costs that scale with workflow complexity, context window size, and the frequency of function calls. These factors can significantly affect both LLM usage costs and response latency. My experiments indicate that the cost grows linearly with complexity: every user interaction, agent invocation, function call, and the subsequent response processing require a substantial number of tokens. Recent benchmarking efforts, particularly through the Hugging Face Agent Leaderboard developed by Galileo AI, have provided structured frameworks for evaluating AI agents’ performance in tool-based interactions. The framework employs the Tool Selection Quality (TSQ) metric, which comprehensively assesses scenario recognition, tool selection precision, parameter handling, and sequential decision-making capabilities. An analysis spanning 17 leading Large Language Models across 14 benchmarks has revealed distinct patterns in AI performance, ranging from basic API calls to complex multi-step interactions [21, 22]. In the context of resource optimization, emerging models demonstrate promising results. The private model OpenAI GPT-4o mini, employed in my experimental study, achieved a medium performance level with an Average Category Score (TSQ) of 0.832. The open-source Mistral Small 3 model emerged as a competitive alternative, matching this TSQ score while offering significant cost advantages. With its architecture of 23.6 billion parameters and an extended context window of 32K tokens, it presents a viable solution for resource-constrained on-premise deployments. A critical research direction involves scaling Conversation Routines for resource-constrained environments. This encompasses investigating the feasibility of deploying CAS powered by small-scale LLMs that demand minimal hardware resources, such as reduced memory usage and lower latency. Such an approach aims to enable on-premise deployment, thereby enhancing accessibility, privacy, and overall operational efficiency. The benchmarking results from the Agent Leaderboard provide valuable insights for selecting appropriate models that balance performance with resource utilization. 6.3.4 Balancing Structured Logic with Conversational Design Principles A core contribution of this study lies in formalizing Conversation Routines as a method to enforce structured business logic flows within closed-domain industrial and business applications. These routines, co-authored by domain experts and Conversation Designer (specialists in translating procedural knowledge into prompt-based dialog frameworks), prioritize task-oriented guidance over conventional conversation design principles. While the current work validates the efficacy of such routines for procedural adherence—such as train booking processes or troubleshooting workflows—it intentionally sidelines foundational tenets of conversational UX design, such as user intent modeling, dialog flow naturalness, error recovery, and context-aware brevity. For instance, in the train booking use case, the agent strictly follows a predefined flow to collect departure times, seat preferences, and payment details but lacks the flexibility to handle off-script queries, such as explaining fare differences or suggesting alternative routes. This rigidity stems from the focus on enforcing a strict business logic flow, which leaves little room for natural conversational deviations or user-driven exploration. Additionally, the agent does not adapt its tone or language complexity based on user expertise, potentially alienating novice users who may require simpler explanations or more guidance. Similarly, in the troubleshooting use case, the Troubleshooting Assistant Agent employs rigid, step-by-step prompting to ensure compliance with safety protocols but does not dynamically adjust its language style or persona to match user expertise (e.g., novice vs. technician). For example, when a user provides vague or ungrammatical input, the agent prioritizes procedural correctness over conversational clarity, which could lead to frustration or misunderstandings. Future work should investigate harmonizing industrial and business task logic with conversation design best practices. For example, integrating adaptive dialog policies could personalize tone, simplify jargon for novices, or recover from off-script queries without compromising procedural rigor. This hybrid approach, while beyond the scope of my current validation, could enhance both usability and safety in human-AI collaboration frameworks across diverse domains. 6.3.5 Modular Multi-agent Design Using Conversation Routines The development of multi-agent architectures represents a significant advancement in the design of Conversational Agentic Systems (CAS). By decomposing complex conversational workflows into smaller, specialized components managed by distinct agents, this approach enables greater scalability, flexibility, and maintainability. At the heart of this design are Conversation Routines (CR) prompts, which serve as structured specifications for agent behavior and interactions. These prompts act as a bridge between human expertise and system implementation, facilitating collaboration between domain experts, conversation designers, and software developers. This modular engineering approach enables teams to focus on specific tasks, ensuring that individual agents are optimized for their respective functions. For example, in a troubleshooting workflow, one agent might handle safety protocol verification, while another manages part specification retrieval. CR prompts formalize the intent and behavior of each agent, providing a shared framework for collaboration. By defining clear roles and leveraging CR prompts, different human contributors—such as subject matter experts and technical developers—can align their efforts effectively. Interactions between agents are mediated through well-defined protocols, such as handoffs or shared contextual data, ensuring smooth communication and workflow orchestration. This modularity also simplifies iterative refinement, allowing updates or modifications to specific agents without disrupting the entire system. While my experiments utilized the OpenAI SWARM framework as an example platform for implementing multi-agent workflows, the principles of this engineering approach extend far beyond any single framework. CR prompts remain central to the process, as they encapsulate the logic and intent of individual agents within the system. For instance, in a train booking scenario, CR prompts could define how one agent collects user preferences while another handles payment processing, with a seamless handoff between them. These principles can be applied across a variety of agentic frameworks, enabling organizations to choose the tools best suited to their needs. However, this approach is not without challenges. Ensuring consistency across agents, managing inter-agent dependencies, and maintaining a unified conversational tone are critical areas that require further exploration. Future research should investigate how to refine CR prompts for better integration into multi-agent systems, optimize inter-agent communication, and enable real-time adaptability. For example, developing mechanisms for dynamic context sharing or conflict resolution between agents could significantly enhance the robustness of CAS in handling complex, real-world scenarios. In summary, the true innovation lies in the engineering process itself, where CR prompts serve as a foundation for modular multi-agent design. By decomposing workflows into manageable components and enabling collaboration across diverse human roles, this approach provides a robust and adaptable methodology for advancing CAS. Future work should focus on addressing the challenges of scalability and consistency while further integrating conversation design principles to enhance user experience. 7 Appendix 7.1 Train Ticket Booking Function Signatures and Docstrings ⬇ 1 def get_date_time (timezone: Optional [str] = None) -> Dict [str, str]: 2 """ Convert current moment into human - friendly datetime strings 3 with timezone support. 4 5 Args: 6 timezone (str, optional): 7 IANA timezone string (e. g., ’ Europe / Rome ’, ’ Asia / Tokyo ’) 8 Uses system default if None / invalid 9 10 Returns: 11 dict [str, str]: { 12 ’ time ’: ’2:30 in the afternoon ’, 13 ’ date ’: ’30 th of October, 2024’, 14 ’ day_name ’: ’ Wednesday ’, 15 ’ timezone_abbr ’: ’ CET ’ 16 } 17 18 Note: All outputs are formatted strings. 19 No exceptions raised - silent fallback to system timezone. 20 """ 21 22 23 def search_railway_station (query: str, page: int = 1) -> str: 24 """ 25 Perform a search for railway station names 26 based on a query and display results in a paginated format. 27 28 Args: 29 query (str): The search query, 30 consisting of one or more space - separated words. 31 page (int, optional): The current page number to display 32 (1- based indexing). Defaults to 1. 33 34 Returns: 35 str: A formatted string displaying the search results 36 for the specified page, including pagination details. 37 38 Behavior: 39 - Matches are case - insensitive. 40 - If no matches are found, a message will indicate zero results. 41 - Automatically handles pagination and displays the total number 42 of pages and results. 43 44 Example: 45 >>> results = search_railway_station (" Genova ", page =1) 46 >>> print (results) 47 Found 2 total results (Page 1 of 1): 48 1. Genova Principe 49 2. Genova Brignole 50 """ 51 52 53 def buy_train_ticket ( departure_city_station, destination_city_station, 54 departure_date, departure_time, 55 passenger_count, travel_class, return_date = None, return_time = None, 56) -> str: 57 """ 58 Books a train ticket with the specified details 59 and returns a JSON - formatted booking confirmation or error message. 60 61 Args: 62 departure_city_station (str): The name of the station where the journey begins. 63 destination_city_station (str): The name of station where the journey ends. 64 departure_date (str): The departure date in ’ YYYY - MM - DD ’ format. 65 departure_time (str): The desired departure time in ’ HH: MM ’ format. 66 return_date (str, optional): The return date in ’ YYYY - MM - DD ’ format. 67 Defaults to None for one - way trips. 68 return_time (str, optional): The desired return time in ’ HH: MM ’ format. 69 passenger_count (int): The number of passengers. 70 travel_class (str): The travel class, where ’1’ indicates first class 71 and ’2’ indicates second class. 72 73 Returns: 74 str: A JSON - formatted string containing booking confirmation details 75 or an error message if the booking fails. 76 """ 7.2 Train Ticket Booking System Dialog Excerpt ⬇ 1 USER: 2 vorrei un treno per Roma domani mattina 3 4 AGENT: 5 Per aiutarti a trovare un treno per Roma domani mattina, ho bisogno di alcune informazioni. 6 1. Da quale stazione partirai? 7 2. Quante persone viaggeranno? 8 3. Preferisci la prima o la seconda classe? 9 Iniziamo con la stazione di partenza! 10 USER: 11 parto da solo da Genova. Se possibile in prima! 12 13 AGENT: search_railway_station (" query "= " Genova ") 14 AGENT: 15 Ho trovato diverse stazioni a Genova. Ecco le opzioni: 16 1. Genova Piazza Principe 17 2. Genova Brignole 18 3. Genova Sampierdarena 19 4. Genova Sestri Ponente 20 5. Genova Pegli 21 Quale stazione preferisci? Se hai bisogno di vedere altre pagine, fammelo sapere! 22 23 USER: 24 non trovo la stazione... 25 26 AGENT: 27 Se non hai trovato la stazione che cercavi, possiamo affinare la ricerca. 28 Puoi fornirmi un nome alternativo o un ’ altra parte del nome della stazione? 29 Oppure posso mostrarti altre pagine di risultati. Fammi sapere come procedere! 30 31 USER: 32 e ’ una staziuone di Genova ma no nmi ricordo il nome... 33 34 AGENT: 35 Non preoccuparti! Posso mostrarti altre pagine di risultati per aiutarti a trovare la stazione. 36 Ecco la seconda pagina di risultati: 37 6. Genova Nervi 38 7. Genova Quarto dei Mille 39 8. Genova Rivarolo 40 9. Genova Voltri 41 10. Genova Campi 42 Se non trovi ancora la stazione, posso continuare a cercare. Fammi sapere! 43 44 USER: 45 ah ecco Nervi! 46 47 AGENT: 48 Perfetto! Hai scelto di partire da Genova Nervi. 49 Ora, per procedere, ho bisogno di confermare alcuni dettagli: 50 1. Data di partenza: Domani 51 2. Orario di partenza: Preferisci un orario specifico per la mattina o va bene " qualsiasi momento "? 52 3. Numero di passeggeri: 1 (tu) 53 4. Classe di viaggio: 1 ª classe 54 Fammi sapere l ’ orario di partenza che preferisci! 55 56 USER: 57 partirei la mattina presto anche verso le 6, dimmi te 58 59 AGENT: get_date_time () 60 AGENT: search_railway_station (" query "= " Roma ", " page "= 2) 61 AGENT: 62 Ho trovato diverse stazioni a Roma. Ecco le opzioni principali: 63 8. Roma Termini 64 9. Roma Tiburtina 65 10. Roma Ostiense 66 Quale stazione preferisci per il tuo viaggio? 67 68 USER: 69 la piu ’ centrale 70 71 AGENT: 72 La stazione più centrale è Roma Termini. Quindi, per ricapitolare: 73 - Partenza: Genova Nervi 74 - Arrivo: Roma Termini 75 - Data di partenza: Domani 76 - Orario di partenza: Intorno alle 6:00 del mattino 77 - Numero di passeggeri: 1 78 - Classe di viaggio: 1 ª classe 79 Ti va bene tutto questo? Se sì, confermiamo i dettagli! 80 81 USER: 82 aspetta mi confermi la data e l ’ ora giusto per vedere se ci siamo capitoi 83 84 AGENT: 85 Certo! Ecco i dettagli da confermare: 86 - Partenza: Genova Nervi 87 - Arrivo: Roma Termini 88 - Data di partenza: Domani (19 dicembre 2024) 89 - Orario di partenza: Intorno alle 6:00 del mattino 90 - Numero di passeggeri: 1 91 - Classe di viaggio: 1 ª classe 92 Ti sembra tutto corretto? 93 94 USER: 95 si 96 97 AGENT: 98 Ottimo! Ecco il riepilogo finale della tua prenotazione: 99 - Partenza: Genova Nervi 100 - Arrivo: Roma Termini 101 - Data di partenza: 19 dicembre 2024 102 - Orario di partenza: Intorno alle 6:00 del mattino 103 - Numero di passeggeri: 1 104 - Classe di viaggio: 1 ª classe 105 Per favore, conferma che tutti questi dettagli sono esatti rispondendo con un chiaro " SÌ " o " NO ". 106 107 USER: 108 tutto corretto 109 110 AGENT: book_train_ticket (" departure_city "= " Genova Nervi ", " destination_city "= " Roma Termini ", 111 " departure_date "= "2024-12-19", " departure_time "= "06=00", " passenger_count "= "1", " travel_class "= "1 st ") 112 AGENT: 113 La tua prenotazione è stata completata con successo! 114 Ecco i dettagli del tuo viaggio: 115 - Riferimento PNR: 4 ERMHD 116 - Codice di Controllo: 490991 117 - Partenza: Genova Nervi 118 - Arrivo: Roma Termini 119 - Passeggeri: 1 120 - Classe di Viaggio: 1 ª classe 121 - Data: 19 dicembre 2024 122 - Treno: Intercity 994 123 - Partenza: 08:00 124 - Arrivo: 09:59 125 - Carrozza: 4 126 - Posto: 19 D 127 - Prezzo: ¤ 55.00 128 Importo Totale: ¤ 95.00 129 Se hai bisogno di ulteriori informazioni o assistenza, non esitare a chiedere! Buon viaggio! 7.3 Conveyor Belt Troubleshooting Procedure Manual ⬇ 1 Procedura di Diagnosi Nastro Trasportatore 2 3 DOC - REF: MNT - CNV -2024- IT -001 4 5 INTRODUZIONE 6 Questo manuale fornisce una procedura sistematica per la diagnosi 7 e risoluzione dei problemi del nastro trasportatore industriale. 8 Il documento copre le principali problematiche operative: blocchi meccanici, 9 disallineamenti, problemi ai rulli, malfunzionamenti dei sensori e guasti elettrici. 10 La procedura è strutturata in 18 passi sequenziali con punti decisionali 11 che guidano l ’ operatore attraverso il processo di troubleshooting, 12 dalla diagnosi iniziale alla documentazione finale dell ’ intervento. 13 Include i codici identificativi di tutti i componenti principali 14 per una precisa identificazione durante la manutenzione. 15 16 CODICI COMPONENTI PRINCIPALI 17 - Nastro Trasportatore: CNV - NT2024 - A 18 - Rulli di Tensionamento: RLT -8450- V2 19 - Guide Laterali: GDL -3320- MK 20 - Sensori di Presenza: SNP -4560- OPT 21 - Quadro Elettrico: QDE -9900- PRO 22 - Sistema di Allineamento: SAL -2270- HD 23 - Motore Principale: MPR -7700- IND 24 - Unità di Controllo: UCT -5150- PLC 25 26 PROCEDURA DI DIAGNOSI PASSO PASSO 27 28 Passo 1: 29 Verificare lo stato del nastro trasportatore CNV - NT2024 - A. 30 Assicurarsi che il pulsante di emergenza non sia premuto 31 e che il quadro elettrico QDE -9900- PRO sia acceso. 32 33 Passo 2: 34 Ispezionare visivamente il nastro. Controllare se ci sono oggetti incastrati 35 o se il nastro appare visibilmente disallineato. 36 Se si notano oggetti incastrati, procedere al Passo 3. 37 Se il nastro è disallineato, passare al Passo 7. 38 39 Passo 3: 40 Spegnere il nastro usando il pulsante di emergenza. 41 Attendere il completo arresto prima di procedere alla rimozione degli oggetti incastrati. 42 43 Passo 4: Rimuovere con cautela gli oggetti incastrati. 44 Se la rimozione risulta difficoltosa, passare al Passo 5. 45 Se la rimozione è avvenuta con successo, procedere al Passo 6. 46 47 Passo 5: 48 (Se rimozione difficoltosa) Chiamare il tecnico specializzato. Non forzare la rimozione. 49 Attendere assistenza qualificata e poi procedere al Passo 6. 50 51 Passo 6: 52 Dopo la rimozione degli oggetti, controllare l ’ integrità del nastro. 53 Se si notano danni, passare al Passo 12. 54 Se il nastro è integro, procedere al Passo 13. 55 56 Passo 7: (Per nastro disallineato) Verificare le guide laterali GDL -3320- MK. 57 Se le guide sono allentate, procedere al Passo 8. 58 Se le guide sono integre, passare al Passo 9. 59 60 Passo 8: 61 Stringere le viti delle guide laterali GDL -3320- MK. 62 Verificare l ’ allineamento con la livella. Una volta allineate, passare al Passo 13. 63 64 Passo 9: 65 Controllare i rulli di tensionamento RLT -8450- V2. 66 Se i rulli sono usurati, passare al Passo 10. 67 Se i rulli sono in buono stato, procedere al Passo 11. 68 69 Passo 10: (Per rulli usurati) Contattare la manutenzione per sostituzione rulli RLT -8450- V2. 70 Attendere l ’ intervento tecnico prima di riavviare. 71 Dopo la sostituzione, passare al Passo 13. 72 73 Passo 11: Verificare la tensione del nastro CNV - NT2024 - A 74 utilizzando il sistema di allineamento SAL -2270- HD. 75 Se la tensione non è corretta, regolarla secondo le specifiche tecniche e procedere al Passo 13. 76 77 Passo 12: (Per nastro danneggiato) Documentare fotograficamente i danni. 78 Contattare il supervisore di linea e attendere autorizzazione per sostituzione nastro. 79 Dopo riparazione, procedere al Passo 13. 80 81 Passo 13: 82 Riavviare il nastro in modalità manuale. 83 Osservare il funzionamento per almeno un ciclo completo. 84 Se si notano anomalie, tornare al Passo 2. 85 86 Passo 14: 87 Controllare i sensori di presenza SNP -4560- OPT. 88 Se i LED dei sensori sono spenti o lampeggiano in modo anomalo, passare al Passo 15. 89 Se i LED funzionano correttamente, procedere al Passo 16. 90 91 Passo 15: (Per sensori malfunzionanti) Pulire le lenti dei sensori 92 SNP -4560- OPT con panno apposito. 93 Se dopo la pulizia i LED rimangono spenti, verificare i collegamenti 94 nel quadro elettrico QDE -9900- PRO. 95 Se il problema persiste, chiamare l ’ assistenza tecnica 96 e attendere l ’ intervento prima di procedere. 97 98 Passo 16: 99 Testare il funzionamento in modalità automatica 100 tramite l ’ unità di controllo UCT -5150- PLC. 101 Verificare che il nastro si muova alla velocità corretta 102 e che i sensori rilevino correttamente il passaggio dei prodotti. 103 104 Passo 17: Monitorare il funzionamento per 5 minuti. 105 Se si verificano arresti improvvisi o anomalie, tornare al Passo 2. 106 Se il funzionamento è regolare, procedere al Passo 18. 107 108 Passo 18: 109 Fine procedura. 7.4 Interactive Troubleshooting Copilot Dialog Excerpt ⬇ 1 USER: 2 C ’ è qualcosa che si è incastrato sotto il nastro. 3 4 TROUBLESHOOTING ASSISTANT AGENT: 5 retrieve_troubleshooting_instructions ( 6 " query "= " C ’\ u00e8 qualcosa che si \ u00e8 incastrato sotto il nastro.") 7 8 TROUBLESHOOTING ASSISTANT AGENT: 9 Procedura di Diagnosi Nastro Trasportatore - Codice MNT - CNV -2024- IT -001 10 11 Possibile diagnosi: C ’ è un oggetto incastrato sotto il nastro trasportatore. 12 13 Procedura: Iniziamo verificando lo stato del nastro trasportatore 14 e assicurandoci che il pulsante di emergenza non sia premuto 15 e che il quadro elettrico sia acceso. 16 17 1. Verifica lo stato del nastro trasportatore CNV - NT2024 - A. 18 Assicurati che il pulsante di emergenza non sia premuto 19 e che il quadro elettrico QDE -9900- PRO sia acceso. 20 21 Il nastro è acceso e il pulsante di emergenza non è premuto? 22 23 USER: 24 si 25 26 TROUBLESHOOTING ASSISTANT AGENT: 27 2. Ispeziona visivamente il nastro. Controlla se ci sono oggetti incastrati 28 o se il nastro appare visibilmente disallineato. 29 30 Hai notato oggetti incastrati nel nastro? 31 32 USER: 33 come ti dicevo e ’ cosi ’ ma no capoisco cosa sia 34 35 TROUBLESHOOTING ASSISTANT AGENT: 36 retrieve_part_details (" device_code "= " CNV - NT2024 - A ") 37 38 TROUBLESHOOTING ASSISTANT AGENT: 39 Ho recuperato le informazioni sul nastro trasportatore CNV - NT2024 - A. 40 41 Nome: Nastro Trasportatore Serie A 42 Produttore: ConveyTech Italia 43 Specifiche: Larghezza 800 mm, Lunghezza 6 m, Capacità 200 kg / m, Velocità 0.5-2 m / s 44 45 Per rimuovere l ’ oggetto incastrato, 46 dobbiamo spegnere il nastro utilizzando il pulsante di emergenza 47 e attendere il completo arresto prima di procedere alla rimozione. 48 49 3. Spegni il nastro usando il pulsante di emergenza. 50 Attendi il completo arresto prima di procedere alla rimozione degli oggetti incastrati. 51 52 Hai spento il nastro e atteso il completo arresto? 53 54 USER: 55 Ho spento tutto 56 57 TROUBLESHOOTING ASSISTANT AGENT: 58 4. Rimuovi con cautela gli oggetti incastrati. 59 Se la rimozione risulta difficoltosa, passa al Passo 5. 60 Se la rimozione è avvenuta con successo, procedi al Passo 6. 61 62 Hai riuscito a rimuovere gli oggetti incastrati? 63 64 USER: 65 ho trovato un bel bullone e l ’ ho tolto 66 67 TROUBLESHOOTING ASSISTANT AGENT: 68 6. Dopo la rimozione degli oggetti, controlla l ’ integrità del nastro. 69 Se noti danni, passa al Passo 12. Se il nastro è integro, procedi al Passo 13. 70 71 Il nastro presenta danni visibili (strappi, usura irregolare)? 72 73 USER: 74 non direi 75 76 TROUBLESHOOTING ASSISTANT AGENT: 77 13. Riavvia il nastro in modalità manuale. 78 Osserva il funzionamento per almeno un ciclo completo. 79 Il nastro funziona correttamente senza anomalie? 80 81 USER: 82 si si 83 84 TROUBLESHOOTING ASSISTANT AGENT: 85 Ottimo! La procedura di risoluzione dei problemi è completata con successo. 86 Ora procederò a trasferire il rapporto di troubleshooting. 87 88 TROUBLESHOOTING ASSISTANT AGENT: handoff_report () 89 90 TROUBLESHOOTING REPORT AGENT: build_report () 91 92 TROUBLESHOOTING REPORT AGENT: 93 REPORT INTERVENTO SVOLTO: 94 95 Problema: 96 C ’ è qualcosa che si è incastrato sotto il nastro. 97 98 Procedura: 99 Procedura di Diagnosi Nastro Trasportatore - Assistente AI 100 DOC - REF: MNT - CNV -2024- IT -001 101 102 Azioni svolte: 103 - Verificato lo stato del nastro trasportatore CNV - NT2024 - A. 104 Il pulsante di emergenza non era premuto e il quadro elettrico era acceso [1]. 105 - Ispezionato visivamente il nastro e confermato la presenza di oggetti incastrati [2]. 106 - Spento il nastro usando il pulsante di emergenza e atteso il completo arresto [3]. 107 - Rimosso un bullone incastrato con successo [4]. 108 - Controllata l ’ integrità del nastro, risultando integro [6]. 109 - Riavviato il nastro in modalità manuale e confermato il corretto funzionamento [13]. References - [1] Chase, Harrison, “What is an AI agent?” https://blog.langchain.dev/what-is-an-agent/ - [2] OpenAI, “Introducing ChatGPT”, https://openai.com/chatgpt/ - [3] OpenAI, “GPT-3.5 Turbo”, https://platform.openai.com/docs/models/gpt-3-5-turbo - [4] OpenAI, “Function Calling”, https://platform.openai.com/docs/guides/function-calling - [5] Ouyang, Long, et al., “Training Language Models to Follow Instructions with Human Feedback”, https://arxiv.org/pdf/2203.02155.pdf - [6] OpenAI, “Swarm (experimental, educational)”, https://github.com/openai/swarm - [7] Robino, Giorgio, “SWARMing Conversational AI”, https://www.linkedin.com/pulse/swarming-conversational-ai-giorgio-robino-ukcvf/ - [8] Bigio, Ilan, “Orchestrating Agents: Routines and Handoffs”, https://cookbook.openai.com/examples/orchestrating_agents - [9] Robino, Giorgio, “Concept of Conversational Agents: Conversational Agent with a Single Prompt?”, https://www.linkedin.com/pulse/conversational-agent-single-prompt-giorgio-robino-vrppf/ - [10] OpenAI, “GPT-4o-mini”, https://platform.openai.com/docs/models/gpt-4o-mini - [11] Robino, Giorgio, “Non-English Languages Prompt Engineering Trade-offs”, https://www.linkedin.com/pulse/non-english-languages-prompt-engineering-trade-offs-giorgio-robino/ - [12] Robino, Giorgio, “Voice-cobots in Industry: A Case Study of a Voice Assistant Application in the Shipping Container Industry”, https://convcomp.it/voice-cobots-in-industry-a-case-study-352294bd0d5a - [13] Nichol, Alan, et al., “Task-Oriented Dialogue with In-Context Learning (RASA CALM)”, https://arxiv.org/pdf/2402.12234.pdf - [14] LangChain AI, “LangChain”, https://github.com/langchain-ai/langchain - [15] LangChain AI, “LangGraph”, https://github.com/langchain-ai/langgraph - [16] Robino, Giorgio, “NaifJs: A Simple State-Machine Based Dialog Manager”, https://github.com/solyarisoftware/naifjs - [17] Robino, Giorgio, et al., “A Conversational Agent to Learn Italian as a Second Language”, in CPIAbot: A Conversational Assistant for Learning Italian as a Second Language, Trentin G. (ed.), Nova Science Publishers, 2021. https://www.researchgate.net/publication/344930113_CPIABOT_A_CONVERSATIONAL_ASSISTANT_FOR_LEARNING_ITALIAN_AS_SECOND_LANGUAGE - [18] Robino, Giorgio, et al., “Un Assistente Conversazionale a Supporto dell’Apprendimento dell’Italiano L2 per Migranti: CPIAbot”, Italian Journal of Educational Technology (IJET), 2020. https://ijet.itd.cnr.it/article/view/1142 - [19] Robino, Giorgio, et al., “Conversational Agent in Mobile Assisted Language Learning: CPIAbot”, presented at the eLmL 2020 Conference, Valencia, Nov. 21–25, 2020. https://www.thinkmind.org/index.php?view=article&articleid=elml_2020_3_120_50066 - [20] Hugging Face, “smolagents: A Barebones Library for Agents”, https://github.com/huggingface/smolagents - [21] Bhavsar, P. and Bronsdon, C., “Introducing Our Agent Leaderboard on Hugging Face”, Galileo AI, Feb. 12, 2025. [Online]. Available: https://www.galileo.ai/blog/agent-leaderboard - [22] Hugging Face, “Agent Leaderboard”, [Online]. Available: https://huggingface.co/spaces/galileo-ai/agent-leaderboard