For Lato Bicycles, innovation and efficiency are always in motion. Like many Mendix customers, Lato uses Mendix Portfolio Management to track their initiatives. This strategic overview allowed them to identify areas ripe for innovation and efficiency gains and track them through to deployment and into ongoing operation. During a recent portfolio review, the leadership team spotted a bottleneck in their customer service process: the initial triage of Return Requests.

Each request arrived as unstructured text via a web form, requiring customer service reps to manually read, categorize, and determine next steps. The process was repetitive, time-consuming, and sometimes delayed resolution.

Using Mendix, Lato set out to design their first AI agent: A Returns Request Assistant that could analyze incoming requests, summarize key details, and prepare repair plans automatically.

(For more context on the what and why of AI agent building, see our companion piece below.)

Defining measurable outcomes

Before development began, Lato defined what success meant for the project. Their goals were clear:

• Reduce manual triage time by 40%.
• Achieve 95% accuracy in categorizing return requests.
• Cut claim resolution time from 14 days to 3 days.

These KPIs were tracked directly in Mendix Portfolio Management, ensuring the project stayed aligned with tangible business outcomes.

Choosing the right trigger

Because Return Requests arrive sporadically, the team opted for an event-driven agent that activates whenever a new request is submitted in the Return Request Portal.

The portal was already integrated with key systems like Customer Order Management and Product Inventory, making it an ideal entry point for the agent. Since the agent wouldn’t be running fully autonomously, user interactions with the agent were set to go through user tasks that the agent generates, with out-of-the-box observability for system administrators.

By embedding automation where employees already worked, Lato minimized disruption and accelerated adoption.

Selecting the model

Lato chose Claude 3.5 to power the agent. This provided:

• Strong tool-use capabilities
• Balanced performance and cost
• Simplified procurement and monitoring

While more advanced models were available, Lato’s core needs—tool use, summarization, and decision support—were fully met by Claude 3.5. Furthermore, by leveraging Mendix’s Cloud Gen AI Resource Packs, Lato was able to streamline the entire process. The resource packs:

• Simplified the purchasing and procurement of the model.
• Provided a straightforward, low-code integration path for their development team.
• Included built-in usage monitoring, giving them a clear view of their data consumption and costs from the start.
• Were covered by Lato’s existing Data Processing Agreement with Mendix.

Note on fine-tuning and customization: While base LLMs are powerful, fine-tuning a model on an organization’s specific domain data (e.g., Lato’s product descriptions, common warranty issues) can significantly improve its accuracy and relevance for specialized tasks. This is an advanced technique that should be considered once the initial agent is stable and there is a clear understanding of its performance gaps. It requires dedicated data preparation and computational resources.

Crafting the prompts

Once the underlying model was decided on, the next crucial step was prompt engineering: structuring the data and instructions within the agent’s prompt to elicit the desired behavior.

Agents typically operate using two primary types of prompts: the system prompt and the user prompt. The system prompt is a set of instructions the developer provides to define the agent’s persona, overall goal, constraints, and how it should behave. System prompts contain the core instructions that set the stage for the entire interaction.

For Lato’s Return Request Agent, the system prompt might be something like:

Role: You are an AI assistant for a customer service representative (CSR) at an e-bike manufacturer. Your job is to organize customer repair issues into a clear, actionable plan for the CSR.

Core Task: Your task is to receive a customer’s problem description, identify the key details needed for a repair, research useful information from various Lato systems, and provide that to the CSR. You should consider the customer’s order history, value of the part, and cost of repair when proposing your plan.

Final Output: Your response must be a structured summary using the following format.

Repair Request Summary
Customer: [Customer’s full name and company]
Part: [Name and serial number (if provided)]
Problem: [A detailed description of the issue]
Next Steps: [A clear, simple action plan for the CSR]

The user prompt is the direct input from the user or the system that triggers the agent’s action. This initial user prompt kicks off the agent’s task.

For Lato’s Return Request Agent, the initial user prompt might be something like:

From: {{Email Address of requester}}
InputContent: {{Request content}}

Building the agent’s toolkit

A powerful agent needs tools. These tools are specialized functions, like microflows in a Mendix application, that the agent can call upon to perform specific actions. The agent has a list of available tools, each with a clear name and description. Given a task, the agent’s job is to orchestrate using these tools to achieve the desired outcome.

Lato began with one essential capability: retrieving customer data using a REST call based on the customer’s email. Using Mendix Agent Builder, they:

1. Built a microflow to retrieve data.

2. Added it as a Tool with a clear name and description.

3. Tested the call using a built-in test case.

Initially, the Lato Return Request agent just collected the data necessary and left any actions up to the Customer Service Representative.

This phased approach solved a specific part of the problem without the complexity of a full agentic system.

As users began to rely on the agent, new challenges emerged.

Iterating toward improvement

Agent development is an iterative process, not a one-shot deal. It’s crucial to start with a baseline model, assess it against the KPIs laid out, and then rigorously test the agent across a wide range of scenarios.

When users began to use the agent, they found it frequently failed to locate parts. The agent’s searches were hindered by spelling errors in the incoming requests and data quality issues in both the Product Inventory and Customer Order Management systems.

To rectify this, a new tool was introduced that allowed the agent to look up parts by their serial number. This provided a reliable alternative for finding parts when the name-based search failed.

The team then used the testing capabilities in Agent Commons to review the changes against specific test cases, which allowed them to evaluate the improvement. The more robust agent was deployed as a new version and monitored to ensure its continued success and to identify further potential improvements.

But agents operate on the principle of “anything not stated will be assumed.” This means that ambiguity in a prompt or tool definitions will be filled in by the agent’s inherent knowledge, which can lead to unpredictable and undesirable outcomes. It’s crucial to be specific about the agent’s goals, constraints, and the order of operations.

The Lato Return Request agent was pulling together information in a helpful way, but to take the automation to the next level, Lato wanted it to draft an email that the CSR could review and send with a single click. For this, a new tool was introduced to draft an email and initiate a workflow.

They updated the system prompt to include:

If a response is needed to the customer, draft an email.

This was error-prone; sometimes the agent would not call the tool and just draft an email in the agent response, and it inconsistently decided when an email needed to be drafted.

So Lato refined their prompt:

For unknown customers: Use the EmailDraft_Create function. The subject line should be “Regarding your recent inquiry,” and the body should include a clear call to action: “Please contact us at 0800 444 5555 so we can assist you further.”

For known customers with an unrecognized part: Use the EmailDraft_Create function. The subject line should be “Information needed for your inquiry,” and the body should prompt the user for more details, such as a part number or a photo. A good phrase to use is:

“We’ve received your request. To help us identify the correct part, could you please provide a part number or a photo?”

For known customers with a recognized part: Do not draft an email. Only provide the plan as otherwise instructed.

The specificity of the prompt made the agent much more reliable. The new prompt clarified the tools to be called and the scenarios under which they should be triggered, ensuring that the agent acted as intended.

Keeping a human in the loop

A human should always be in the loop for any decision with significant consequences. While agents are excellent at automating routine tasks, they lack the intuition and ethical judgment required for high-stakes decisions.

Lato designed their system so that all customer communications and repair actions require manual approval.

• The EmailDraft tool prepares responses but doesn’t send them.
• The RepairBookIn_Initiate tool triggers a workflow that routes to a CSR for validation.

This manual review is a crucial safeguard against costly or irreversible actions…

…and ensures automation never bypasses human judgment for high-stakes decisions.

Managing context and scaling smartly

An agent’s context window is its short-term memory and has a limited capacity. Too much information can lead to overwhelmed behavior, where the agent struggles to focus on the most important details. Effective context management is critical.

To prevent the agent from becoming overloaded with irrelevant data, Lato implemented context management strategies:

• Minimal Tool Retrieval: Tools are built to retrieve only specific data (not entire datasets). In this case, Lato ensured that the tools accepted either the part name or serial number, to ensure any response is focused.
• Persisting Data Needed Outside of the Context: Lato found that they wanted accurate reporting on the incoming messages. They only had the agent’s reasoning, which was in an unstructured format. They added StoreInMemory to permanently store the agent’s assessment.

• Retrieval-Augmented Generation (RAG) fetches only the most relevant repair manual content.

Lato found that the repair assessments offered by the agent didn’t fit with Lato repair guidelines, so they decided to add access to a knowledge base of repair manuals using Mendix Cloud Resource packs. This allowed the agent to do a similarity search on the content and retrieve Lato-specific relevant data into context.

As their system matured, Lato began splitting tasks into smaller agents to maintain efficiency. The single Lato Return Request Agent was broken down into:

• ProductEvaluatorAgent: Its sole task is to analyze product information, check warranty dates, and determine eligibility.
• CustomerResearcherAgent: This agent specializes in accessing customer history, purchase records, and communication logs.
• SchedulerAgent: A dedicated agent for using calendar and communication tools to schedule follow-ups with the customer or internal teams.

Smaller agents can then be connected via an orchestration agent, programmatically using a microflow or custom workflow.

Results and next steps

Lato’s Returns Request Agent transformed a slow, manual process into a fast, AI-assisted workflow reducing triage time, improving accuracy, and freeing up human agents for complex cases.

Their journey demonstrates that with clear goals, careful prompt design, and Mendix’s low-code AI tools, organizations can move from experimentation to meaningful business impact, one agent at a time.