All they wanted was AI to draft partner emails.

By Leon Papkoff, Co-founder, President and CPO, Nth AI. Published 2026-10-21.

A customer wanted Claude to draft partner emails using product knowledge. Leon Papkoff shares four lessons on getting data access approved, monitoring connections, maintaining models, and resolving conflicting information.

One of our customers wanted to use Claude to draft partner emails. Their IT team would not allow it to connect to Outlook or their product information.

The team had a few hundred detailed PDFs, with one for each product SKU. Those documents contained specifications, product roadmaps, and guidance on competing against other vendors. Outlook held the conversations that explained what their partners needed.

They wanted Claude to bring that information together and draft replies with the right product details. It was a practical use of AI that could save time and help their team respond more accurately.

But before they could get started, IT and security needed to approve how the information would be accessed and used.

I see this often. People use AI at home and quickly recognize what it could help them do at work. Then they discover that connecting it to company information requires a much broader conversation.

When we meet with enterprises, much of that conversation focuses on the data. We discuss which systems hold the information, how to connect them, who should have access, and how to keep the results accurate as the business changes.

These decisions often need to happen before a team can begin building useful agents.

For this customer, we installed Nth AI Nexus™ in their own Azure environment. Nexus connected to Outlook and the product documents, and the team connected Claude to Nexus. IT and security reviewed the architecture and approved the connections once they understood how the setup worked.

The team got up and running quickly and began drafting replies that incorporated specific product information.

That experience reflects four things I would encourage any enterprise data and AI leader to address early.

1. Bring IT and security into the project from the beginning.

IT and security need to understand what you are trying to accomplish and how the proposed connections will work. Bringing them in after the team has already built a solution makes that review more difficult.

We involve them in what we call our mapping meeting. This is where we connect the business goal to the systems, information, and permissions required to support it.

Start by explaining where the data lives and where it will be processed. Identify the sources you want to connect and what information will be made available to the AI. Then explain who can access it and how employees or executives will use the results.

In this customer’s case, deploying Nexus inside their Azure environment was an important part of that discussion. IT could review the architecture and understand the path between the source systems, Nexus, and Claude.

Addressing these questions early gives everyone a shared understanding of the project. It also creates an opportunity to resolve concerns before they become obstacles.

2. Evaluate how each connection performs under real demand.

A connection can work during setup and still struggle when people begin using it throughout the day. APIs have different limits, refresh schedules, and levels of reliability. Whether you connect through an API directly or use an MCP server, those underlying constraints still matter.

Decide what information you need from each source and how often it needs to be refreshed. Some information needs frequent updates. Other information can be refreshed less often. Collecting only what the use case requires helps control demand and makes the scope easier for IT to review.

Then monitor the connections over time.

One customer used a shared API from a large provider to access desk and room bookings. We noticed performance problems at roughly the same time every day, when employees in Asia began booking desks before coming into the office.

After several days of monitoring, the pattern became clear. The API was struggling with the volume of simultaneous requests, which led to errors and connection failures.

We reported the issue, and the vendor implemented a fix about a week later. Performance improved.

That problem would have been easy to miss during an initial connection test. Ongoing monitoring helped us find it and give the vendor useful information to investigate.

3. Plan for ongoing maintenance of the data and models.

The first version of an AI solution reflects the information and business rules available when it was built. Those conditions will change.

Product details get updated. Source systems add or rename fields. Teams revise how they calculate a business measure. New connectors introduce information that was not available before.

The notebooks that process the data, the semantic models that define business measures, and the ontology that describes relationships need to stay aligned with those changes.

Without that maintenance, an AI system can produce an answer that sounds reasonable but relies on outdated information or assumptions.

This is why human review matters. People need a way to identify incorrect results, understand what caused them, and approve the changes needed to improve future answers.

That work should have an owner and an ongoing process. It belongs in the project plan from the beginning.

4. Give people a clear way to resolve conflicting information.

Connecting another source can improve an AI system, but it can also introduce disagreements.

Suppose your CRM reports revenue by region, and some of those figures are outdated. You then connect a regional reporting system with a different number for the same period.

The system now has two possible answers. It needs a reliable way to determine which one should be used.

The discrepancy should be surfaced for review. Someone who understands the business can confirm whether the difference comes from timing, duplicate records, different definitions, or an error.

That decision then needs to be reflected in the data rules and models so future answers use the appropriate source.

Users should also be able to see where a number came from. Being able to trace an answer back to its source helps people check the result and understand why it should be trusted.

Today, that customer uses Claude to draft the partner emails they originally wanted. Their team can bring product knowledge into a reply without manually searching through hundreds of documents.

Getting there required an approved connection to the right information and a way to manage that information over time.

For enterprise leaders, this is a major part of making AI useful. The model needs access to reliable data, the connections need to perform consistently, and people need a way to review and correct the results.

Which data source would make the biggest difference to your team if you could get it approved for AI?