Before asking a question, first find the meeting
When Fang wanted to check a customer’s latest action items or understand why a project had stalled, he first had to guess which meeting contained the answer. He would search, download one to three transcripts, paste them into AI, and only then ask his question. Identifying the relevant meetings was the time-consuming part.
This need arose almost every day. Team 4 began with that recurring inconvenience and built a Meeting Ink Agent in Copilot Studio, so colleagues could ask directly about summaries, action items or project status while the Agent searched meetings and retrieved transcripts.
The first version worked for its creator, but was not ready to share
Fang built an Agent with two automated flows: one found meetings, and the other retrieved transcripts already produced by Meeting Ink for the Agent to review. The prototype solved his own search problem, but used its creator’s personal credentials. Sharing it would still access data as the creator.
The team tried moving the key into a variable and packaging the Agent and flows for colleagues to import separately. Both flows stopped before sending a request because a required parameter could not be found. Even fixing that binding would only address deployment settings, not how a shared Agent should identify each user.
The turning point: treat this as an identity problem
An AI team colleague subsequently helped redesign the connection architecture. The key became a credential belonging to each user, managed through a custom connector and user authentication. On first use, colleagues enter their own key in the connection form opened from the Connect card. They do not paste it into chat or edit a flow.
The updated Agent can verify identity, list personal or workspace meetings, and retrieve their transcripts. Every tool runs through the current user’s personal connection. Colleagues share one Agent, while their own Meeting Ink permissions determine what they can read.
This support addressed the barrier between a personal prototype and a shared tool. Fang supplied the prototype and real query needs; the AI team helped redesign the connection architecture. Detailed contributions of development tools have not been confirmed and are not attributed here.
Finding an answer without first knowing which meeting to open
In one real query, Fang asked which documents a customer project still lacked at a particular stage. The Agent located two relevant meetings, provided meeting IDs, sources and discussion details, and identified the missing documents. Fang checked the answer against an existing group conversation and found no omissions or errors in that instance.
Another request asked for the summary and action items from the latest customer monthly meeting. The Agent returned the correct content without Fang first deciding which transcript to download. These examples demonstrate help with locating sources as well as summarizing them; a successful example does not guarantee every answer will be correct.
Faster queries, with checks for shared use
Based on usage experience, comparable queries now take about 3 minutes instead of 5–20. Fang says the time saved can be used to follow up on more sales opportunities. This describes a change in how time is used, rather than a measured increase in opportunities or revenue.
Two users have used the Agent in practice. Second-account data isolation, relevant query scenarios, and recovery by updating or recreating a connection after revoking an old key have been verified. These tests support shared use, but do not mean a company-wide rollout is complete.
Before and after
| Work area | Before | After |
|---|---|---|
| Query workflow | Guess which meetings are relevant, download 1–3 transcripts, and paste them into AI. | Ask directly; the Agent finds meetings, retrieves transcripts and organizes an answer. |
| Time per query | About 5–20 minutes. | About 3 minutes. Both figures are usage estimates, not formal KPIs. |
| Sources for answers | The user must first find the right meeting. | The Agent can locate information across meetings and provide sources; a real example was checked without finding errors or omissions. |
| Shared access | The prototype used its creator’s credentials, even when shared. | Each user creates a personal connection and uses the shared Agent with their own identity and permissions. |
| Focus of work | Time is spent locating and moving transcripts. | The Agent handles retrieval; people check answers and sources. The user reports using saved time for sales follow-up. |
From finding information to supporting the next task
For other teams building shared Agents, this case highlights the need to distinguish deployment settings from user identity early, and design data access, personal connections and permission checks together. When a flow fails, the underlying issue may go beyond its parameter settings.
The team next hopes to generate reports in the established Visit Report format, bringing meeting information into follow-up work. This remains a plan, not a completed feature. Colleagues can consult the setup SOP for personal connections, operation and troubleshooting; actual access depends on each account’s permissions.