Databricks AI Agents Accessible Through Microsoft Teams and Microsoft 365 Copilot
Challenges
The Databricks AI agent was working, but users without Databricks access needed a simple way to use it.
The organisation wanted to avoid building and maintaining a separate front end while still supporting contextual conversations. The integration also needed traceability and user feedback without adding another application or monitoring layer.
Outcome
The existing Databricks agent became accessible through Microsoft Teams and Microsoft 365 Copilot without direct Databricks access. The integration delivered 2X faster time to market, lower engineering overhead and integration costs.
Solution
Databricks AI agents to Microsoft Teams and Microsoft 365 Copilot
Challenges
Solution
Technology Stack
Outcomes
A multinational retail brand had already built AI use cases inside Databricks. These included RAG applications and conversational agents backed by Databricks endpoints. Things worked as expected, but access was the problem. The people who needed to use these agents did not necessarily have Databricks access. Giving every user a Databricks licence or direct privileges to the environment was neither practical nor necessary. The client needed a simpler way to bring the existing Databricks intelligence to users through tools they already worked with every day. Cloudaeon worked with the organisation to establish that integration pattern. Instead of rebuilding the AI application or creating another custom front end, we connected the Databricks agent to Microsoft Copilot Studio and made it available through Microsoft Teams and Microsoft 365 Copilot. What looked like a front end problem became an integration, context management, traceability and user experience challenge.
Challenges
Making the Databricks Agent Accessible
The AI agent was already running in Databricks, but not every intended user had Databricks access. The client needed a way for employees to use the agent without giving them direct access or additional privileges inside Databricks.
Avoiding a Separate Front End
A custom UI could have been built using technologies such as React or Node.js. But that would mean another application to develop, deploy, maintain and ask users to access. The client wanted to use Microsoft Teams and Microsoft 365, where users were already working.
Connecting Copilot Studio to Databricks
The AI logic, RAG processing and calculations already existed in Databricks. Copilot Studio therefore needed to act as an integration, not duplicate the backend logic. It had to accept user questions, send them to the Databricks endpoint, handle the returned response and present it correctly to the user.
Maintaining Conversation Context
The integration also needed to support follow-up questions. Copilot Studio did not provide the required multi-turn behaviour for this integration by default. The solution had to retain recent conversation history so the Databricks agent could understand the context of subsequent questions.
Building Traceability and Feedback
The client needed visibility into how the agent was being used. This included capturing who asked a question, what was asked, what the agent returned, and how users rated the response during UAT. The challenge was to add this traceability without introducing another monitoring or feedback application.
Root Cause Analysis
Cloudaeon did not start by choosing a new front-end framework and building another application. We first looked at where the intelligence already existed, who needed to access it, and which parts of the architecture actually needed to change. The analysis showed that the Databricks agent itself was not the root problem. The gap was between the working Databricks endpoint and the users who needed to consume it. The solution was to keep Databricks as the intelligence intact and use the Microsoft environment for interaction.
Solution
Cloudaeon built the integration using Microsoft Copilot Studio. The Databricks agent and model-serving endpoint remained responsible for the actual AI processing. Copilot Studio became the bridge between that backend and the user's Microsoft interface.
How We Delivered
A step by step approach was followed to implement the solution: Multi-turn conversation: Cloudaeon also added custom conversation memory. For every interaction, the system keeps the recent sequence of user queries and agent responses. Up to the last 10 conversation turns are maintained within the session, with the number of turns easily configurable based on need. When another question is submitted, this recent conversation history is passed as context so the agent can respond appropriately to related follow-up questions. As the conversation continues, the context window moves forward. The system retains the most recent 10 turns instead of carrying the full session indefinitely.
Agent tracing: Every important interaction is also recorded. The solution captures information such as the user asking the question, the question itself and the agent's response. This conversation history is stored at the session level, using SharePoint Lists or similar data storage options. Copilot Studio agent flows are used to trigger this logging process. The result is a traceable record of how the agent is being used. That data can later support analysis of common questions, usage patterns and agent behaviour.
User feedback: We implemented a custom feedback experience using Adaptive Cards as part of custom topics. After an agent response is presented, users can rate the result. During UAT, feedback can also be categorised based on the type of interaction being tested, such as single-turn or multi-turn behaviour. Where an answer is incorrect, the user can add a written comment explaining the issue.
Deployment through Microsoft Teams: Once the Copilot Studio agent was configured, it could be published directly into Microsoft Teams or Microsoft 365 Copilot. Users see the agent as an application within the Microsoft environment they already use. Access can be controlled through the relevant sharing and access policies. The user interacts with the familiar Teams or Copilot interface. Behind the scenes, those questions continue to be processed by the Databricks agent endpoint. No direct Databricks access is required for the end user.
Technology Stack
Databricks
Microsoft Copilot Studio
Microsoft Teams
Microsoft 365 Copilot
Outcome
The approach delivered faster access to the existing Databricks agent without requiring a separate custom front end.
2X faster time to market: The solution enabled 2X faster time to market compared with building an additional UI layer.
Lower engineering overhead: No separate UX engineering team was required to create an interface for the agent.
Simpler user access: Users could interact with the agent inside Microsoft Teams or Microsoft 365, without switching applications or requiring direct Databricks access.
Lower integration cost: The solution used existing Microsoft capabilities rather than premium connectors, helping keep additional integration costs down.
Better agent experience: Users could hold contextual conversations instead of isolated question-and-answer exchanges.
Greater traceability: Agent activity could be logged and UAT feedback could be captured directly inside the experience.
Reusable integration pattern: The organisation gained a repeatable way to bring backend AI agents into the Microsoft tools its users already know.
Conclusion
The organisation did not need another AI application. It needed the existing one to reach the right users without creating another technology layer to manage. For organisations already building RAG applications or agents in Databricks, the same problem often appears after the AI itself is ready: how do you put it in front of users without opening the underlying platform to everyone. Cloudaeon can help design that last mile, from the Databricks endpoint to a governed, usable enterprise experience.
Ready to bring your Databricks AI agents to the right users? Talk to an expert now.