Checking AI-generated partner research against its sources.

Leadership supplied 106 potential partners. I initiated the research workflow to help Core Strategy examine which partnerships could address a customer problem, through what combination of products and with what business value.

A Senior Director on the Core Strategy team asked for more than a partner match: why would the partnership matter, what would each side gain, and which products could work together? I reorganized the workbook around those questions, using Copilot to help expand it.

I kept the owner’s original priorities beside the analysis but left them out of the scoring, so Core Strategy could compare those priorities with what the research showed.

The goal was an AI agent built on the final workbook, so three groups could draw on the same evidence instead of starting from scratch.

These were the intended uses. The agent reached my immediate team before my role ended; see Results and adoption.

After presenting an early AI-generated report, I checked its quotes and page references the next day and could not verify them. I rejected the report, told stakeholders it had hallucinated and sent a source-checked replacement.

I moved the first checkpoint ahead of extraction: could the AI actually read the source? A candidate pain point then needed an inspectable passage and location before entering the library. Later review checked support, scope, classification, attribution and duplication.

I kept the courtroom method in a separate Markdown file and instructed the AI to use it as part of the research process.

The preserved logs show how one report was reviewed for a specific question: did it contain customer pain relevant to traffic between services or connectivity across clouds? General networking problems could sound relevant without meeting that scope.

The passage check and the scope judgment answered different questions. A passage could be traceable and still be a weak fit for the strategy question. Keeping the objection beside the retained finding gave the next reviewer a specific issue to resolve.

The principal architect and I discussed how the agents could work together. His agent assessed how a company fit a Lumen product; mine supplied customer-pain context. I built the evidence agent in Copilot Studio, grounded it in eight domain-specific Word documents through SharePoint, tested questions against that material and configured the connection.

For companies in one of my eight researched domains, his agent called mine for end-user pain context. He owned the technical-matching logic; I owned the evidence agent and its connection. The separate research workflow ran in Copilot Cowork.

The work produced a source-linked research library, review and rejection logs, a repeatable workflow method and a 106-partner hypothesis workbook. I published the Studio agent to my immediate team.

My manager supported presenting the workflow more broadly; my role ended before that presentation. Before a rollout like that, I would start from the team’s recurring tasks and incentives, so the agent supports work people already need to finish.

For a future pilot, I would begin with one recurring task the intended team needs to complete now. The employee doing the work, the accountable decision-maker and a technical partner would shape the test together.

1. Understand the existing work. Observe the task, its exceptions and the handoffs between roles. Agree where AI can assist, who can accept or challenge an output, and where a person must take over. Check whether review adds work the team has time and authority to do.
2. Follow a task through its unresolved questions. Test whether people can inspect support, correct an interpretation and return to a deferred decision. Gather feedback in an existing team routine, revise what blocks them, and look for repeat use and useful task completion alongside errors and extra review work.
3. Recheck the context for each client. Confirm the client’s task, language, incentives, decision authority, source access and support owner. Reuse only the parts that still fit, with a way to stop or return to a person when they do not.

A proposed approach based on what I learned.

In Lumen’s Connected Ecosystem work, one-to-one sales pitches spent too much time explaining the initiative. After attending a sales call, I convened Business Development leads, service designers and principal architects from two pods. I created a menu of technically validated solutions organized by customer problem and fit, then proposed taking it to existing sales-team meetings.

The architects owned technical validation. The Business Development Lead presented the menu and managed rep follow-up. Partnership sales still did not count toward rep quotas, so the incentive problem remained.