In this story, you learn what it takes to build generative AI applications for a global industrial company, where teams across countries need to access large amounts of technical knowledge and customer information from multiple sources.
Making scattered knowledge easier to access
When the project started, our goal was to create a reusable framework that teams could use to build their own generative AI applications. Rather than developing a separate solution for every use case, we wanted to establish common ways of working that would make applications easier to build, adapt, and maintain. From day one, we approached the work with production in mind, rather than treating it as a proof of concept that might never be used in practice.
One of our first use cases focused on a back-office team in South America that handled customer enquiries. Finding answers often meant searching across several systems and document types, including databases, PDFs, PowerPoint presentations, Excel files, and SharePoint. Technical knowledge was scattered across these sources, and some of it existed mainly in the experience of individual employees. We wanted to make that information easier to find and use, including for people working in Spanish.
We developed several AI agents, each with a different responsibility. One retrieves information about the installed product base, another draws on previous sales presentations, and a third searches technical documentation such as product manuals. Employees can ask questions in natural language and get answers based on information from relevant sources, instead of having to locate and read through every document themselves.
From one use case to an international effort
As the first application developed, we continued to evaluate its performance and improve it based on user feedback. We added features such as cost-monitoring dashboards, image support, and the ability to work with Excel files. For example, a user can take a picture of a device at a customer site to help identify the equipment and find relevant information.
The solution has since expanded to teams in Europe and Central America, and we are working with teams in the United States and Canada on further use cases. The team has also grown, allowing us to develop several applications for different needs across the organisation.
One use case focuses on predictive maintenance. The aim is to analyse data and identify when a device may need maintenance, helping teams spot potential needs proactively rather than relying on someone to notice a problem while checking a system.
Another application, the Field Service Report Reader, is being tested with a team in the United States. When a customer reports a problem, information may be stored in a case management system, while a technician’s observations from a site visit are recorded elsewhere. The customer service team may not see the technician’s notes, and the technician may not have access to the full customer correspondence. By connecting information from these sources, we aim to give people a more complete picture of each case.
Building for production, not just a proof of concept
Building an AI application that can answer questions is one thing. Making sure it can be maintained, reproduced, and adapted for different teams requires a more structured approach.
We have built standardised frameworks and processes to make our applications easier to maintain and reuse. We manage infrastructure and configuration files in Git, a system that tracks changes and helps us recreate the setup when needed, rather than relying on manual changes through a cloud interface. This means we can recreate the system from its stored configuration if it needs to be rebuilt, and manage changes in a consistent way.
Evaluation and monitoring are also part of our development process. We use automated evaluations to assess how the applications perform and monitor costs as they evolve. User feedback helps us identify where the experience can be improved. This allows us to keep refining the applications as new requirements emerge, rather than leaving evaluation and maintainability until later.
Bringing technical development and user needs together
Our team has grown and now includes Developers, Machine Learning Engineers, Designers, and a Product Manager. The Designers help us understand how people work before we decide what to build. They interview users, identify pain points, gather requirements, and help prioritise what needs attention first. Once an application is available, they also carry out user testing and bring feedback back to the team.
This is important because the technical possibilities don’t always tell us which problem is most important to solve. By understanding people’s everyday work, we can focus on applications that fit real processes and address actual needs. We then use feedback to improve the solutions as people start working with them.
My role has also evolved beyond the technical implementation.
I need to consider how the different parts of a solution fit together and how we can build reusable technology while adapting it to the needs of teams with different processes and information sources.
Keeping up with fast-moving technology
Generative AI has changed rapidly during the project. When we started, much of the focus was on retrieval-augmented generation, or RAG. Since then, we have seen growing interest in agentic systems, multi-agent architectures, semantic layers, and knowledge graphs. New tools and approaches keep appearing, and the technology can change even while we are developing a solution.
For me, this brings both opportunities and challenges. I need to keep learning, understand which developments are relevant, and decide what is worth bringing into the project. At the same time, we need to deliver solutions that work in practice, rather than adopting every new technology just because it is available.
AI coding assistants have also changed how we approach development. Some problems that previously led to a conversation with a colleague can now be explored independently with an AI tool. This can make individual work faster, but I still value the human side of development. When a problem needs different perspectives or a shared understanding, talking it through with colleagues remains important.
Growing into an architect role
During this project, I moved from working as a Machine Learning Engineer to becoming an Architect. The biggest change has been learning to look beyond the technical implementation and consider how the solution connects to business needs.
A significant part of my role is bridging the gap between technical teams and business stakeholders. I need to translate business requirements into something the technical team can work with, and explain technical decisions in terms that make sense to the business. That broader perspective has been one of my biggest learnings from the project.
I have also gained practical experience with new technologies that I can apply to future assignments. Support from colleagues at Solita and from Databricks, the platform we use, has been valuable as we work through new challenges and explore different approaches.
What I find rewarding is being able to learn while building applications that people can use in their everyday work. As new needs emerge across teams and countries, and the technology continues to evolve, there is plenty to keep exploring.
Curious to work at Solita? See our open positions or subscribe to our talent community newsletter.