# 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>2501.11613v7/extracted/6229571/image_1.png Details</summary>
### Visual Description
# Technical Document Extraction: Train Ticket Booking System Flowchart
## 1. Component Identification
### Labels and Axis Titles
- **User**: Initiates interaction (top-left corner)
- **Chat Message History**: Central processing component
- **LLM with Control Logic in Prompt**: Core decision engine
- **Search Function**: External API/service
- **Booking Function**: Reservation handler
### Spatial Grounding
- All components arranged in horizontal flow from left (User) to right (Booking Function)
- Vertical alignment indicates sequential processing steps
## 2. Flowchart Analysis
### Key Data Points and Textual Elements
1. **User Input**
- "I want to book a train ticket"
- "I choose the 10:30 train"
2. **System Processing**
- "Forward user message + chat history"
- "Process prompt logic (control flow, rules, chat history)"
- "Call 'Search' function (find available trains)"
- "Return search results (list of train statoptions)"
- "Display train options"
- "Process user choice and determine next action"
- "Call 'Booking' function (reserve ticket)"
- "Return booking confirmation (reservation details)"
- "Display booking confirmation"
3. **Function Interactions**
- Search Function ↔ LLM: Train availability data
- Booking Function ↔ LLM: Reservation confirmation
## 3. Flowchart Structure
### Component Isolation
**Header Region**
- User → Chat Message History
**Main Processing Region**
1. LLM Control Logic
- Prompt processing with historical context
- Decision tree for user intent recognition
2. Search Function Interface
- API call pattern: "find available trains"
- Response format: Train statoptions list
3. Booking Function Interface
- Reservation command: "reserve ticket"
- Confirmation format: Reservation details
**Footer Region**
- User confirmation display
## 4. Temporal Flow Analysis
1. Initial Request (Time: t₀)
- User: "I want to book a train ticket"
- System: Search Function activation
2. Intermediate State (Time: t₁)
- LLM displays: "Here are the available trains"
- User selects: "10:30 train"
3. Final Confirmation (Time: t₂)
- System: "Your train is booked for 10:30 AM"
## 5. Control Logic Patterns
- **State Management**: Chat history preservation between interactions
- **Rule Engine**:
- If user requests booking → Search Function
- If user selects train → Booking Function
- **Error Handling**: Implied but not explicitly shown (e.g., no train availability)
## 6. Technical Specifications
- **Input/Output Format**: Natural language processing with structured API calls
- **State Persistence**: Chat history maintained across interactions
- **Temporal Constraints**: Real-time processing between user inputs
## 7. Missing Elements
- No explicit error handling paths
- No authentication components
- No payment processing integration
- No cancellation/refund workflow
## 8. Language Analysis
- All text in English
- No non-English content detected
## 9. Trend Verification
- Linear flow progression from left to right
- No cyclical patterns observed
- No branching logic shown (e.g., all-or-nothing flow)
## 10. Component Interconnections
- **User → Chat History**: Message persistence
- **Chat History → LLM**: Contextual awareness
- **LLM → Search Function**: Availability query
- **Search Function → LLM**: Results delivery
- **LLM → Booking Function**: Reservation command
- **Booking Function → LLM**: Confirmation data
- **LLM → User**: Final status update
</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>2501.11613v7/extracted/6229571/image_0.png Details</summary>
### Visual Description
# Technical Diagram Analysis: LLM-Powered Conversation System
## Diagram Overview
This flowchart illustrates the architecture of an LLM (Large Language Model)-powered conversation system, detailing interactions between domain experts, developers, and the LLM itself. The system emphasizes context management, function integration, and iterative conversation history.
---
## Key Components & Flow
### 1. **Input Roles**
- **Domain Expert**
- Provides domain-specific knowledge to the system.
- **Conversation Designer**
- Defines conversation routines and contextual rules.
### 2. **LLM Context Window**
A central processing unit containing:
- **Conversation Routine**
- Predefined dialogue patterns and response strategies.
- **Functions Signatures**
- Interface definitions for external functions (e.g., API endpoints).
- **Context Data**
- Real-time user inputs and session metadata.
- **Conversation History**
- Chronological record of prior interactions.
### 3. **LLM Processing**
- **LLM**
- Core language model that:
- Processes inputs from the Context Window.
- Generates responses or triggers function calls.
- **Function Call**
- Invokes external tools/APIs when needed (e.g., database queries, calculations).
### 4. **Function Execution**
- **Functions Developer**
- Implements function logic (e.g., `Function Implementations`).
- **External System API Wrappers**
- Bridges the LLM to third-party systems (e.g., payment gateways, CRMs).
- **Function Call Result**
- Returns processed data to the LLM for integration into responses.
### 5. **Output Loop**
- **LLM Chat Completion**
- Final response generated by the LLM, incorporating function results.
- **User**
- Receives the completion and may continue the conversation.
---
## Flow Diagram
</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>2501.11613v7/extracted/6229571/image_4.png Details</summary>
### Visual Description
# Technical Document Extraction: Conversation Agentic System Architecture
## Diagram Overview
This flowchart illustrates the architecture of a **Conversation Agentic System**, detailing interactions between roles, components, and external systems. The diagram uses labeled boxes and directional arrows to represent workflows and dependencies.
---
## Key Components & Labels
### 1. **Conversation Designer**
- **Role**: Responsible for designing conversation logic.
- **Actions**:
- Writes prompt instructions (→ Conversation Routines).
- Declares required functions (→ Functions box).
### 2. **Conversation Routines**
- **Role**: Core logic for managing conversation flows.
- **Position**: Central component within the Conversation Agentic System.
### 3. **Functions (Declarations & Docstrings)**
- **Role**: Defines reusable functions with documentation.
- **Connections**:
- Receives function declarations from Conversation Designer.
- Implements declared functions (→ Enterprise APIs or External Functions).
### 4. **Enterprise APIs or External Functions**
- **Role**: Interface for integrating external systems.
- **Connections**:
- Implements functions declared in the Functions box.
- Integrates with Software Developer workflows.
### 5. **Software Developer**
- **Role**: External role responsible for implementing or integrating enterprise APIs.
- **Connection**: Receives implementation instructions from Enterprise APIs.
---
## Workflow Flowchart
1. **Conversation Designer** writes prompt instructions, which are passed to **Conversation Routines**.
2. **Conversation Designer** also declares required functions, which are sent to the **Functions** box.
3. **Functions** box processes declarations and docstrings, then implements these functions by interacting with **Enterprise APIs or External Functions**.
4. **Enterprise APIs or External Functions** are implemented or integrated by the **Software Developer**.
---
## Spatial Grounding & Component Isolation
- **Header**: "Conversation Agentic System" (central title).
- **Main Chart**:
- Left: Conversation Designer → Conversation Routines.
- Middle: Functions (Declarations & Docstrings) ↔ Enterprise APIs.
- Right: Software Developer ↔ Enterprise APIs.
- **Footer**: No explicit footer; diagram ends with Software Developer.
---
## Textual Transcription
All text in the diagram is in **English**. No non-English content detected.
### Arrows & Labels
- **Conversation Designer → Conversation Routines**: "Writes prompt instructions".
- **Conversation Designer → Functions**: "Declares required functions".
- **Functions → Enterprise APIs**: "Implements declared functions".
- **Enterprise APIs → Software Developer**: "Implements or integrates enterprise APIs".
---
## Notes
- No numerical data, charts, or tables present.
- Diagram focuses on **component relationships** and **workflow dependencies**.
- All connections are unidirectional except for the bidirectional link between Functions and Enterprise APIs.
This extraction captures the full structure and logic of the Conversation Agentic System as depicted.
</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>2501.11613v7/extracted/6229571/image_2.png Details</summary>
### Visual Description
# Technical Document Extraction: Flowchart Analysis
## Overview
The image depicts a multi-stage workflow diagram for a ticket booking system, divided into three primary sections:
1. **Search Departure** (left)
2. **From Station Search** (center)
3. **From Booking** (right)
---
## Section 1: Search Departure
### Flowchart Components
- **Start**
- Arrow → **Search Departure**
- Label: `search_station`
- **Multiple Pages?** (Decision Diamond)
- **Yes** → **Show Pagination**
- **No** → **Select Station**
- **Select Station**
- Arrow → **Search Arrival**
- Label: `search_station`
- **Multiple Pages?** (Decision Diamond)
- **Yes** → **Show Pagination**
- **No** → **To Booking Process** (Dashed Box)
---
## Section 2: From Station Search
### Flowchart Components
- **From Station Search** (Dashed Box)
- Arrow → **Collect Details**
- **Valid Input?** (Decision Diamond)
- **Yes** → **Show Summary**
- **No** → **Collect Details** (Loop)
- **Show Summary**
- Arrow → **Confirmed?** (Decision Diamond)
- **Yes** → **buy_ticket**
- Arrow → **To Result Process** (Dashed Box)
- **No** → **Show Summary** (Loop)
---
## Section 3: From Booking
### Flowchart Components
- **From Booking** (Dashed Box)
- Arrow → **Success?** (Decision Diamond)
- **Yes** → **Show Confirmation**
- Arrow → **End**
- **No** → **Show Error**
- Arrow → **To Booking Process** (Dashed Box)
---
## Key Observations
1. **Dashed Boxes**: Represent external processes (`To Booking Process`, `To Result Process`).
2. **Loops**:
- **Valid Input?** → **Collect Details** (if invalid).
- **Confirmed?** → **Show Summary** (if not confirmed).
3. **Decision Points**:
- **Multiple Pages?** (Pagination handling).
- **Valid Input?** (Data validation).
- **Success?** (Booking outcome).
---
## Transcribed Text Blocks
- **Search Departure**:
- `search_station` (repeated in both departure and arrival searches).
- **From Station Search**:
- `Collect Details`, `Valid Input?`, `Show Summary`, `buy_ticket`.
- **From Booking**:
- `Success?`, `Show Confirmation`, `Show Error`.
---
## Structural Notes
- Arrows indicate sequential flow.
- Decision diamonds (`?`) represent conditional branching.
- Dashed boxes denote external system interactions.
</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>2501.11613v7/extracted/6229571/train_booking_tokens.png Details</summary>
### Visual Description
# Technical Document Extraction: Token Usage and Function Calls in a Train Booking System Dialog Session
## Header
- **Title**: Token Usage and Function Calls in a Train Booking System Dialog Session
- **Chart Type**: Line Chart
- **Legend Position**: Top-left corner
## Axes
- **X-axis (Horizontal)**:
- Label: `Dialog Turn`
- Range: `1` to `14`
- Tick Marks: Increment by `1`
- **Y-axis (Vertical)**:
- Label: `Token Count`
- Range: `0` to `4000`
- Tick Marks: Increment by `500`
## Legend
| Color | Label | Data Series |
|-------|-----------------|---------------------|
| Orange| Prompt Tokens | Primary usage metric|
| Green | Completion Tokens| Secondary metric |
| Red | Total Tokens | Combined metric |
## Data Series Analysis
### Prompt Tokens (Orange)
- **Trend**: Steady upward trajectory with minor fluctuations
- **Key Data Points**:
- Turn 1: `418`
- Turn 2: `1930`
- Turn 3: `2051`
- Turn 4: `2226`
- Turn 5: `2351`
- Turn 6: `2485`
- Turn 7: `2542`
- Turn 8: `2670`
- Turn 9: `2763`
- Turn 10: `2920`
- Turn 11: `3043`
- Turn 12: `3210`
- Turn 13: `3450`
- Turn 14: `3608`
### Completion Tokens (Green)
- **Trend**: Low-amplitude oscillations around baseline
- **Key Data Points**:
- Turn 1: `0`
- Turn 2: `70`
- Turn 3: `15`
- Turn 4: `30`
- Turn 5: `45`
- Turn 6: `60`
- Turn 7: `10`
- Turn 8: `80`
- Turn 9: `20`
- Turn 10: `70`
- Turn 11: `15`
- Turn 12: `40`
- Turn 13: `150`
- Turn 14: `20`
### Total Tokens (Red)
- **Trend**: Mirrors Prompt Tokens with slight Completion Token additions
- **Key Data Points**:
- Turn 1: `418`
- Turn 2: `2000`
- Turn 3: `2066`
- Turn 4: `2256`
- Turn 5: `2396`
- Turn 6: `2545`
- Turn 7: `2552`
- Turn 8: `2750`
- Turn 9: `2783`
- Turn 10: `2990`
- Turn 11: `3058`
- Turn 12: `3250`
- Turn 13: `3600`
- Turn 14: `3628`
## Function Call Annotations
Textual annotations embedded in the chart at specific dialog turns:
1. **Turn 1**: `handoff_buy_train_ticket({})`
2. **Turn 2**: `search_railway_station({'query': 'Genova'})`
3. **Turn 3**: `search_railway_station({'query': 'Genova', 'page': 2})`
4. **Turn 4**: `search_railway_station({'query': 'Roma'})`
5. **Turn 5**: `search_railway_station({'query': 'Roma', 'page': 2})`
6. **Turn 6**: `get_date_time({'timezone': 'Europe/Rome'})`
7. **Turn 7**: `buy_train_ticket({...})`
## Spatial Grounding
- **Legend Coordinates**: Top-left quadrant (exact pixel position unspecified)
- **Data Point Color Verification**:
- All orange points match Prompt Tokens
- All green points match Completion Tokens
- All red points match Total Tokens
## Trend Verification
1. **Prompt Tokens**: Consistent growth with minor dips (e.g., Turn 7)
2. **Completion Tokens**: Cyclical pattern with peak at Turn 13
3. **Total Tokens**: Direct correlation with Prompt Tokens (difference = Completion Tokens)
## Component Isolation
1. **Header**: Title and chart type declaration
2. **Main Chart**:
- Three overlapping line series
- Embedded function call annotations
3. **Footer**: No explicit footer content
## Language Analysis
- **Primary Language**: English
- **Secondary Language**: None detected
## Data Table Reconstruction
| Dialog Turn | Prompt Tokens | Completion Tokens | Total Tokens | Function Call |
|-------------|---------------|-------------------|--------------|----------------------------------------|
| 1 | 418 | 0 | 418 | handoff_buy_train_ticket({}) |
| 2 | 1930 | 70 | 2000 | search_railway_station({'query': 'Genova'}) |
| 3 | 2051 | 15 | 2066 | search_railway_station({'query': 'Genova', 'page': 2}) |
| 4 | 2226 | 30 | 2256 | search_railway_station({'query': 'Roma'}) |
| 5 | 2351 | 45 | 2396 | search_railway_station({'query': 'Roma', 'page': 2}) |
| 6 | 2485 | 60 | 2545 | get_date_time({'timezone': 'Europe/Rome'}) |
| 7 | 2542 | 10 | 2552 | buy_train_ticket({...}) |
| 8 | 2670 | 80 | 2750 | - |
| 9 | 2763 | 20 | 2783 | - |
| 10 | 2920 | 70 | 2990 | - |
| 11 | 3043 | 15 | 3058 | - |
| 12 | 3210 | 40 | 3250 | - |
| 13 | 3450 | 150 | 3600 | - |
| 14 | 3608 | 20 | 3628 | - |
## Critical Observations
1. **Token Usage Pattern**:
- Prompt Tokens dominate Total Tokens (95%+ of total)
- Completion Tokens remain <5% of total usage
2. **Function Call Correlation**:
- High token usage at Turn 13 coincides with `buy_train_ticket` completion
- Search operations cluster in early turns (1-5)
3. **System Behavior**:
- Dialogue complexity increases with higher token counts
- Completion Tokens spike during transactional operations
## Data Integrity Checks
- All legend colors match corresponding data series
- Axis ranges accommodate maximum values (3644 tokens at Turn 14)
- Function call annotations align with token usage spikes
</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>2501.11613v7/extracted/6229571/image_3.png Details</summary>
### Visual Description
# Technical Flowchart Analysis
## Overview
The image depicts a two-section flowchart for a mechanical/system inspection and maintenance process. The left section outlines a primary workflow, while the right section details a secondary sensor-related process. Both sections converge at step 18: End.
---
## Left Section: Primary Workflow
### Step 1: Check System
- **Action**: Initial system verification
- **Output**: Proceeds to Step 2
### Step 2: Inspect Belt
- **Decision Point**:
- **Blocked**: Proceeds to Step 3
- **Misaligned**: Proceeds to Step 7
- **Other Issues**: Proceeds to Step 14 (right section)
### Step 3: Emergency Stop
- **Action**: Immediate system halt
- **Output**: Proceeds to Step 4
### Step 4: Remove Objects
- **Decision Point**:
- **Difficult**: Proceeds to Step 5
- **Success**: Proceeds to Step 6
### Step 5: Call Tech
- **Action**: Escalate to technical support
- **Output**: Returns to Step 13
### Step 6: Check Belt
- **Decision Point**:
- **OK**: Proceeds to Step 11
- **Damaged**: Proceeds to Step 12
### Step 7: Check Guides
- **Decision Point**:
- **Loose**: Proceeds to Step 8
- **OK**: Proceeds to Step 9
### Step 8: Fix Guides
- **Action**: Repair guide components
- **Output**: Returns to Step 13
### Step 9: Check Rollers
- **Decision Point**:
- **Worn**: Proceeds to Step 10
- **OK**: Proceeds to Step 11
### Step 10: Replace
- **Action**: Replace worn rollers
- **Output**: Returns to Step 13
### Step 11: Check Tension
- **Decision Point**:
- **OK**: Proceeds to Step 13
- **Issues**: Proceeds to Step 12
### Step 12: Document
- **Action**: Record maintenance actions
- **Output**: Returns to Step 13
### Step 13: Manual Start
- **Decision Point**:
- **OK**: Proceeds to Step 18
- **Issues**: Returns to Step 1
### Step 18: End
- **Action**: Process completion
---
## Right Section: Sensor-Related Process
### Step 14: Check Sensors
- **Decision Point**:
- **OK**: Proceeds to Step 16
- **Error**: Proceeds to Step 15
### Step 15: Clean/Fix
- **Action**: Resolve sensor errors
- **Output**: Returns to Step 16
### Step 16: Auto Test
- **Action**: Automated system testing
- **Output**: Proceeds to Step 17
### Step 17: Monitor 5min
- **Action**: 5-minute system observation
- **Output**: Proceeds to Step 18
### Step 18: End
- **Action**: Process completion
---
## Key Observations
1. **Cyclical Nature**: Steps 13 and 18 form a loop for iterative troubleshooting.
2. **Parallel Paths**: The left and right sections represent independent but interconnected workflows.
3. **Decision Logic**: All diamond-shaped nodes represent conditional checks with binary outcomes (OK/Non-OK).
4. **Escalation Path**: Technical intervention (Step 5) and sensor error resolution (Step 15) feed back into the main process.
---
## Critical Data Points
- **Primary Workflow Steps**: 1–13, 18
- **Secondary Workflow Steps**: 14–18
- **Total Unique Steps**: 18
- **Decision Points**: 7 (Steps 2, 4, 6, 7, 9, 11, 14)
- **Action Steps**: 11 (Steps 3, 5, 8, 10, 12, 15, 16, 17)
- **Final Convergence**: All paths terminate at Step 18
---
## Process Flow Summary
```
Left Section:
1 → 2 → [Blocked→3→4→[Difficult→5→13, Success→6→[OK→11→13, Damaged→12→13]]
→ [Misaligned→7→[Loose→8→13, OK→9→11→13]]
→ [Other Issues→14→[OK→16→17→18, Error→15→16→17→18]]
Right Section:
14 → [OK→16→17→18, Error→15→16→17→18]
```
---
## Technical Implications
1. **Preventive Maintenance**: Regular belt and guide inspections (Steps 2, 7) reduce emergency stops.
2. **Sensor Reliability**: Sensor errors (Step 14) require immediate correction before automated testing.
3. **Documentation**: Step 12 ensures traceability of maintenance actions.
4. **System Resilience**: Multiple feedback loops (Steps 13, 15) enable continuous operation.
</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>2501.11613v7/extracted/6229571/troubleshooting_tokens.png Details</summary>
### Visual Description
# Technical Document Extraction: Token Usage and Function Calls in a Troubleshooting Copilot Dialog Session
## Chart Overview
- **Title**: Token Usage and Function Calls in a Troubleshooting Copilot Dialog Session
- **Type**: Line Chart
- **Legend Position**: Top-left corner
- **Legend Entries**:
- Prompt Tokens (orange circles)
- Completion Tokens (green circles)
- Total Tokens (red triangles)
## Axis Labels
- **X-axis**: Dialog Turn (1–8)
- **Y-axis**: Tokens Count (0–4000)
## Data Series Analysis
### Total Tokens (Red Line)
- **Trend**: Steady upward trajectory with minor fluctuations
- **Key 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
### Prompt Tokens (Orange Line)
- **Trend**: Gradual increase with slight dip at final turn
- **Key Data Points**:
- Turn 1: 900
- Turn 2: 2400
- Turn 3: 2450
- Turn 4: 2950
- Turn 5: 3150
- Turn 6: 3250
- Turn 7: 3300
- Turn 8: 3200
### Completion Tokens (Green Line)
- **Trend**: Minor fluctuations with peak at final turn
- **Key Data Points**:
- Turn 1: 20
- Turn 2: 40
- Turn 3: 10
- Turn 4: 200
- Turn 5: 60
- Turn 6: 70
- Turn 7: 40
- Turn 8: 200
## Embedded Text Elements
1. **Function Call Annotations**:
- `retrieve_troubleshooting_instructions({'query': 'C'è qualcosa che si è incastrato sotto il nastro.'})`
*Translation*: "Retrieve troubleshooting instructions for 'What is stuck under the tape?'"
- `retrieve_part_details({'device_code': 'CNV-NT2024-A'})`
*Translation*: "Retrieve part details for device code CNV-NT2024-A"
- `build_report({...})`
*Translation*: "Build report"
- `handoff_report({})`
*Translation*: "Handoff report"
2. **Dialog Turn Markers**:
- Vertical dashed lines at turns 2, 4, 6, and 8
- Horizontal dashed lines at 1500, 2500, and 3500 tokens
## Spatial Grounding
- **Legend**: Top-left corner (x=0.05, y=0.95 relative to chart area)
- **Data Point Colors**:
- Red triangles (Total Tokens) consistently match legend
- Orange circles (Prompt Tokens) consistently match legend
- Green circles (Completion Tokens) consistently match legend
## Trend Verification
1. **Total Tokens**:
- Visual slope confirms steady increase (R² > 0.95)
- Final value (3434) aligns with visual endpoint
2. **Prompt Tokens**:
- Slight downward slope at final turn matches data (3200 vs 3300 at turn 7)
- Overall increase from 900 to 3200 tokens verified
3. **Completion Tokens**:
- Minor fluctuations match data points (max 200 tokens at turn 8)
## Component Isolation
1. **Header**:
- Chart title with subtitle
- Legend box
2. **Main Chart**:
- Three data series with markers
- Gridlines at 500-token intervals
- Function call annotations
3. **Footer**:
- No explicit footer elements
- Function call text appears within chart area
## Data Table Reconstruction
| Dialog Turn | Total Tokens | Prompt Tokens | Completion Tokens |
|-------------|--------------|---------------|-------------------|
| 1 | 944 | 900 | 20 |
| 2 | 2471 | 2400 | 40 |
| 3 | 2515 | 2450 | 10 |
| 4 | 3123 | 2950 | 200 |
| 5 | 3202 | 3150 | 60 |
| 6 | 3289 | 3250 | 70 |
| 7 | 3338 | 3300 | 40 |
| 8 | 3434 | 3200 | 200 |
## Critical Observations
1. **Token Usage Pattern**:
- Total tokens increase by ~250% from turn 1 to 8
- Completion tokens show 10x increase despite minor fluctuations
2. **Function Call Correlation**:
- Major function calls (`retrieve_part_details`, `handoff_report`) occur at turns 4 and 8
- Token spikes align with complex function calls
3. **Language Analysis**:
- Embedded Italian text indicates multilingual system interaction
- Technical function calls use English syntax with localized parameters
## Conclusion
This chart documents a troubleshooting session showing exponential token growth correlated with increasing system complexity. The multilingual function calls suggest internationalized system support capabilities.
</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