Comant Chatbot

For my fourth-year internship in CoreTechnologie, the goal was to add an AI chatbot to Comant, the company's internal ticket management tool. From a single natural-language request, the chatbot had to support three main capabilities: searching tickets in the database using specific filters (project, product, client, assignee, date), performing a semantic search to surface tickets related to a topic described by the user, and returning the results of a requested statistic as a table or an appropriate chart.

The whole system had to run on infrastructure the company controlled, which meant relying on an open-source AI model deployed locally rather than an external API.

I built a chat interface inside Comant, backed by a dedicated FastAPI service holding all the chatbot logic: user messages are sent to this API, which returns the response.

Key features I put in place:

• Multi-agent architecture : Using PydanticAI, I designed an orchestrator agent that receives the user's message and delegates it to the right specialized agent (filter search, semantic search, statistics, conversational or memory agent).
• Local model deployment : The agents run on an AI model deployed locally on the company's servers with Ollama. I evaluated several european open-source models to find the one that performed best on the available hardware while staying within the RAM budget.
• Agent design : Each agent has its own system prompt describing its task and a dedicated set of tools to interact with the application's database and the vector database.
• Text-to-SQL : The filter search and statistics agents translate natural-language requests into SQL queries, which are then executed against the application's database to retrieve the relevant results.
• Persistent memory : A memory agent identifies corrections or clarifications made by users and stores them in a vector database (ChromaDB). At runtime, each agent retrieves the memories that are semantically closest to the current request and injects them into its system prompt to refine its behavior.
• Semantic search : I embedded the content of every ticket into ChromaDB, which lets the system find tickets that are semantically close to a topic the user is searching for, beyond simple keyword matching.
• Dual-layer results display : Ticket search results and statistics are rendered directly in the application's interface (as tables or charts), while the chat only returns a concise natural-language summary of the results. This allows keeping the conversation readable while the detailed data lives where users expect it.
• Iterative prompt tuning : Once real users started using the chatbot, I refined each agent's system prompt with more precise instructions and more relevant examples based on observed failure cases.
• Modularity : The architecture was built to make it easy to add new capabilities or new specialized agents later on.

Employees can now find tickets far faster, using whichever filters or topics they care about, instead of searching manually. Project leads can request statistics directly through the chatbot and get results visualized as tables or charts, which helps them track project progress, monitor time spent by employees, and estimate team efficiency.

This project was a deep dive into AI agents, tool use, memory systems, local model deployment, and retrieval-augmented architectures built on vector databases, and into how these pieces come together to automate and simplify real business processes.

Working on this project also meant spending time with the people who would actually use it (project leads and support employees who were not developers). Turning their sometimes vague use cases into precise, well-scoped features required asking the right questions and iterating on their feedback, which turned out to be as important as the technical implementation itself.

Finally, deploying the model locally with Ollama, was a decision reflected the company's requirement to keep sensitive internal data on its own infrastructure. This gave me hands-on experience with the tradeoffs of self-hosting an LLM versus relying on a SaaS provider, from model selection to resource management.