Hi,

Hi dlaborie, Yes, we implemented Dust’s native Jira MCP, which includes 22 tools. I’m a contractor and a Dust admin at Criteo, and we have more than 1,500 members in our workspace, so we wanted to make sure the rollout was secure and scalable. Here’s how we approached it:

Jira has become one of the main tools in our workspace, and users really like it. We have not experienced any issues so far, and more than 359 agents are currently using it. Globally I've found native MCP hosted by dust itsefl way more reliable than the one developed by Atlassian

Hello Fanchon, Thank you very much for your feedback. This is very interesting and particularly impressive given the volume of users involved. I was wondering whether you had used webhooks to allow certain tickets to directly trigger a Dust agent. For example, when a ticket is created in Jira, Jira could automatically call a Dust agent: If so, when the Dust agent takes a relatively long time to answer, what approach do you use to ensure that the agent can then send its response back to Jira for the right Ticket, either by adding it to a dedicated column or by automatically updating the ticket status? My second question concerns the progressive enrichment of the knowledge base. As Jira processes tickets and validated requests contribute to building up the company’s use cases and knowledge, how do you leverage this information to feed a semantic knowledge base or create accessible FAQs, for example in the form of Spaces in Dust? Thank you very much for your feedback.

Hi dlaborie Well, our current approach is a mix of event-driven automation, agent-assisted workflows, and human validation. We have not implemented one single, fully automated Jira → Dust → Jira loop for every ticket, but we do use several Jira-related workflows for ticket intake, troubleshooting, prioritisation, escalation tracking, coverage monitoring, reporting, and ticket creation from other business systems. For longer-running workflows, the Jira issue key is the main correlation ID. The agent first extracts the issue key from the incoming request or event, then retrieves the issue again before taking any action. Once the analysis is complete, it can add a comment, update a dedicated field, apply a label, or transition the issue, provided the relevant write permissions are enabled. We would typically use a dedicated status or label, such as AI_REVIEW or READY_FOR_VALIDATION, to make the workflow visible. We also kept write actions restricted during the initial rollout, test them in a limited project, and retain human validation for changes that could have a material operational impact. It is important to add safeguards against loops, so that an update made by the agent does not unintentionally trigger the same workflow again. Regarding knowledge enrichment, we do not treat every Jira ticket as an automatic knowledge-base entry. Jira remains the system of record, while Dust is used to make validated knowledge easier to find and reuse. A typical process is:

This approach allows us to build reusable FAQs from recurring Jira topics, while avoiding a noisy knowledge base full of unverified or duplicate answers. We would ideally use the Jira issue key as the document identifier, so that an updated resolution enriches the existing entry instead of creating a duplicate. At this stage, I would describe this as a curated enrichment workflow rather than a fully native, one-click Jira-to-Space synchronisation. The main principle for criteo is to keep Jira as the operational source of truth and Dust as the layer for orchestration, semantic search, and reuse of validated knowledge.

nice, thanks for the feedback !