## 4 Implementation  
To enable personalization, a communication protocol is implemented, using the APIs of LLMs. The AI models share a common communication model based on a REST architecture. In this architecture, the client sends HTTP requests to the API endpoints exposed by the respective servers. Any application that interacts with the API can function as a client, including chatbots, virtual assistants, or a Unity C# application such as WarehouseGame Training. Each platform provides extensive documentation, including sample code in multiple programming languages, simplifying the integration process. Before our software can communicate with any of these APIs, several preliminary steps must be completed:  
1. Account creation: A user account must be created on each platform. 2. API key generation: An API key must be generated to authenticate and secure communication between our software and the API. 3. Credit balance: Since API usage is not free, it is necessary to add funds to the account. Each platform applies different pricing, based on the model and number of requests. If the user lacks sufficient credit, the service will not process requests. Figure 10: AI assistance. Once these steps are completed, our software can establish communication with the selected API and process the responses accordingly. During interaction, the application sends requests based on user input, processes the JSON response returned by the API, and interprets it to provide real-time feedback through the 3D interface. The communication flow is straightforward (see Figure 11):  
1. Request AI assistance: From the Unity-based application, which serves as a 3D simulator, requests are sent to the AI for assistance in various aspects of training. These requests are handled by the corresponding class within the application, depending on the AI model used, ensuring efficient and adaptive communication with the selected API. 2. Send message: Once the request type has been identified, the system constructs the message to be sent to the AI. There are several types of messages. Each message consists of two parts: a description of the request's objective (see Table A1) and a specification of the expected response format (see Table A2). The first part is a textual instruction directed at the AI, while the second part is a standardized JSON structure, ensuring that the Unity application can correctly interpret and process the response. 3. HTTP Post Request: Once the message is constructed, the next step is to send a POST request to the LLM server. This request must follow a specific structure to ensure that the server can correctly process it. The message must be encapsulated in a format that complies with the API's requirements. Fortunately, as previously mentioned, all LLM models use share architectural similarities, making the POST request structure identical across all of them. The required format is as follows:  
Figure 11: Communication architecture. {  \"model\":\"\". \"messages\":[  {\"role\":\"system\",\"content\":\"\"},  {\"role\":\"user\",\"content\":\"\"}],  \"temperature\",  \"max_tokens\"  }, where  
* \"model\" specifies the language model to be used;
* \"messages\" contains the structured conversation;
* \"role\":\"system\" defines the AI's general behavior;
* \"role\":\"user\" represents the message sent by the user. Once this structure is prepared, the HTTP client sends a POST request to a generic API endpoint, such as https://server_llm/v1/chat/completions, where server_llm represents the server of the LLM model (ChatGPT, Grok, or DeepSeek). This endpoint is consistent across all models, with only the server name changing depending on the LLM provider. 4. Http post response: The server processes the request, executes the language model, and generates a response based on the conversation history and the defined parameters. The response is returned in JSON format with the following structure:  
{  \"id\",  \"model\". \"choices\":[{  \"index\":0,  \"message\":{  \"role\":.