Choosing the Right Tool: Selenium vs. Microsoft Graph API
With the initial goals set, the next challenge was figuring out how to get the data we needed—specifically, the chats and messages from Microsoft Teams. This was crucial for InaTina's functionality, as real-time access to conversations was at the core of her performance.
At this point, we had two primary options: the Microsoft Graph API and Selenium. Both had their strengths and weaknesses, and deciding which one to use involved carefully weighing their pros and cons. To make this decision, we created a decision matrix based on key factors like ease of use, automation level, admin access requirements, and how well each method would work with different types of chats (team vs. 1:1).
Microsoft Graph API seemed like an attractive option on paper. It provided granular access control, worked with both team and 1:1 chats, and was a reliable, official API. However, its complexity was a major hurdle—setting up the OAuth process and securing the necessary admin approval would have slowed us down. Additionally, we were concerned about potential rate limits and the time-consuming setup process.
On the other hand, Selenium Automation offered a much simpler and quicker path. It didn’t require admin access, worked directly from the Teams UI, and was easy to implement. The downside was that it was more prone to UI changes, meaning that a small update to Teams could break our implementation. Manual login was also sometimes necessary, and there were potential performance issues when dealing with large amounts of data.
After considering all the factors, we decided that Selenium was the best fit for us. Its ease of use and the fact that we didn’t need admin permissions or deal with complex OAuth setups outweighed its potential limitations. Plus, the cost-free nature of Selenium was a significant factor, as we wanted to keep InaTina’s development as cost-efficient as possible.
With Selenium in hand, we began extracting the chat data we needed to power InaTina’s intelligence.
Choosing the Right AI Solution: OpenAI Assistant for Seamless Context and Memory
Once we had the chat data extracted, the next step was to integrate an AI solution capable of understanding and responding to those conversations. The decision wasn’t just about choosing a powerful model—it was about selecting one that could handle the complexity of real-time conversations while maintaining context across multiple interactions. This is where the OpenAI Assistant truly stood out.
While we could have used a simple LLM model via the OpenAI API, this would have required us to build and maintain all the features that manage context and memory—two essential components for a dynamic assistant like InaTina. We would have needed to create our own system to track conversations, remember past messages, and provide relevant responses. This would have added considerable complexity to the project, requiring both time and expertise.
The OpenAI Assistant, on the other hand, came with all these features built in. It was designed to manage conversational context, track the flow of threads, and provide responses that stayed consistent with previous interactions. This was crucial for InaTina, as she needed to recall previous messages, understand ongoing discussions, and offer relevant suggestions without needing to be reminded of prior context.
Moreover, the OpenAI Assistant also had the added benefit of file search and function calling capabilities, features that would have been incredibly difficult and time-consuming to implement ourselves. These features enabled InaTina to access important documents and data in real time, and even perform specific actions within Teams based on the conversation—further boosting InaTina’s utility as an in-house assistant.
Perhaps most importantly, the threading feature seamlessly integrated with Microsoft Teams. Since Teams organizes messages into threads, having InaTina able to manage these threads—responding to messages in the correct context—was a game-changer. It allowed InaTina to follow up on specific discussions, just like a human assistant would, ensuring that the flow of conversation was always on point.
With these capabilities in mind, the OpenAI Assistant was the clear choice. It allowed us to avoid reinventing the wheel when it came to context and memory management, giving us more time to focus on making InaTina a truly valuable tool for the team.
Closing the Loop: Sending the Response Back to Teams with Claude Computer Use Tool
With the AI-generated response in hand, the final step was to send it back into Microsoft Teams. At this point, there wasn’t much of a decision to be made in terms of the solution; we knew exactly how we wanted to handle it. We chose to use Claude Computer Use Tool for the job.
While Claude Computer Use Tool might not have been the most optimal or industry-standard choice, we saw it as a valuable learning opportunity. Our goal wasn’t just to find a quick solution—it was to gain hands-on experience with a new tool and better understand its capabilities and limitations. By using it, we could explore its potential, understand how it interacted with Teams, and learn about its real-world performance.
Claude Computer Use Tool allowed us to seamlessly integrate with Microsoft Teams, interacting with the browser window and posting messages to the appropriate chat threads. It gave us the flexibility to automate the entire process, from extracting the message data to posting the AI’s response back into the chat. While the tool had its quirks and challenges, we were able to work through them and learn how to maximize its potential within our setup.
By using Claude, we not only closed the loop on the conversation but also gained valuable insights into automation tools and their practical applications. This knowledge would go on to inform future projects and help refine our approach to building intelligent systems.