💼 Monday Business

I Built a Copilot Agent to Pull Lessons Learned—Here's Why It Works

August 10, 2026

Every organization has lessons learned buried in SharePoint. Most PMs don’t read them. I built an agent that makes them useful again.

Lessons learned documents have a reputation problem.

They exist in every project management office. They get written at the end of projects—sometimes carefully, sometimes as a checkbox exercise. They sit in SharePoint folders, organized by year or project name, waiting for someone to find them useful. And for the most part, nobody does.

Not because the information isn’t valuable. Because reading through dozens of lessons learned documents to find the three or four that apply to your new project is genuinely time-consuming work. So PMs skip it. They rely on memory, on colleagues, on institutional knowledge that lives in people’s heads rather than in any documented system.

I felt that friction myself. So I built a Copilot agent to solve it.

The Problem It Solves

When you’re starting a new project, you want to know: what have we learned from projects like this one? What went wrong? What worked better than expected? What should we watch out for?

The answers exist. They’re in past project charters, post-mortems, and lessons learned documents from every project the organization has completed. The problem isn’t that the information isn’t there—it’s that retrieving the relevant pieces requires you to already know which projects are comparable and then read through enough material to find what applies.

That problem is hard for experienced PMs. It’s significantly harder for someone who is new to the organization and doesn’t yet know which projects are worth looking at, or what the internal vocabulary even means.

I built this agent specifically because I was spending too much time on that retrieval work. And because I saw newer colleagues struggling even more—not from lack of skill, but from lack of context.

What the Agent Does

The agent is built in Microsoft Copilot and grounded on two SharePoint document libraries:

  • Project Charters — past and current projects, including scope, objectives, team structure, and key constraints
  • Lessons Learned — post-project documentation capturing what went well, what didn’t, and what we’d do differently

“Grounding” means the agent answers questions using the actual content of those documents—not general AI knowledge, not training data, but the real records from our organization’s projects. When it tells you that stakeholder alignment in the early phases of infrastructure projects has historically been a pain point, it’s pulling that from documents your colleagues wrote about projects your organization ran.

That specificity is what makes it useful.

How I Use It

The simplest workflow: share your new project charter with the agent and ask for recommendations.

Because the agent is grounded on past project charters, it can read your new charter, compare it against what it knows from previous projects, and surface the lessons learned that are most relevant to what you’re actually doing. You don’t have to manually describe your project or figure out which past projects are comparable—you just hand it the document and ask. No charter yet? You can describe your project directly and the agent will work from that context instead.

“Here is my project charter. Based on our past projects and lessons learned, what should I be aware of as I kick off this project?”

That single prompt does the work that used to require reading through a pile of documents and relying on institutional memory to know which ones mattered.

When I shared the agent with a colleague, their instinct was exactly right: they wanted to bring their new project charter and get recommendations. That’s the intended use. The charter provides the context; the agent does the matching.

A few other prompts that are worth having in your toolkit:

“Which past projects are most similar to this one, and what did we learn from them?”

“What are the most common failure points in projects like this one based on our historical records?”

“We’re working with [specific team or vendor]. What have our past projects documented about working with them?”

That last one is consistently valuable. When institutional knowledge about a particular team’s patterns or a vendor’s tendencies is buried in a lessons learned document from three years ago, most PMs never see it. The agent surfaces it in seconds.

What It Gets Right

The agent is particularly good at identifying patterns across multiple projects. A single lessons learned document might note that requirements changed late in the project. The agent can tell you that requirements instability has appeared in the closeout documentation for four of the last six projects of this type—which is a signal worth paying attention to.

It’s also useful for new PMs and PMs who are new to the organization. Instead of relying on relationship networks and institutional memory that take years to build, someone starting their first project can ask the agent what the organization has learned and get answers grounded in actual project history. That matters. New employees make the most avoidable mistakes in their first year, and a lot of those mistakes are avoidable precisely because the organization already learned the lesson—just not in a form the new PM could access.

What It Doesn’t Replace

The agent surfaces information. It doesn’t interpret it for you.

A lessons learned entry that says “stakeholder communication broke down in phase two” is a flag, not a diagnosis. You still need to understand why it broke down, whether those conditions exist on your project, and what a different approach would actually look like. That’s PM judgment—not something an agent provides.

The agent also only knows what’s been documented. If your organization’s most experienced PM carries ten years of lessons in her head and none of it made it into a SharePoint document, the agent doesn’t know it. The grounding is only as good as the documentation.

This is, incidentally, a good argument for writing better lessons learned at the end of projects. The more specific and honest the documentation, the more useful the agent becomes. Vague lessons learned produce vague agent responses. “Communication could have been better” is not a lesson. “The executive sponsor needed weekly written summaries rather than meeting attendance, and we didn’t figure that out until month four” is a lesson.

What You Need to Build One

If your organization uses Microsoft 365 and Copilot, you have what you need. The agent is built in Copilot Studio and connected to the relevant SharePoint libraries through a data connection. Your IT or M365 admin team can set up the SharePoint grounding; the agent configuration itself is straightforward once the data connection is in place.

The more important prerequisite is the documentation. The agent is a retrieval tool—it can only surface what exists. Before building the agent, it’s worth doing a quick audit of your lessons learned library: Are documents being created? Are they specific enough to be useful? Are they stored consistently in a way that makes grounding reliable?

If the answer to those questions is “sort of,” the agent is still worth building—and it may motivate better documentation practices once PMs see what good lessons learned can produce.

The Broader Point

Organizations invest significant effort in documenting project experience. Most of that investment produces documents that nobody reads.

An AI agent grounded on that documentation doesn’t solve the underlying problem—organizations still need PMs who think critically about lessons and apply them thoughtfully. But it removes the retrieval barrier that keeps most of those documents inert. It makes institutional knowledge accessible to everyone on the team, not just the people who’ve been around long enough to know where to look.

That’s a meaningful change. The lessons are already there. The agent just makes them findable.

Related Monday Business Posts:

The lessons are already there. The agent just makes them findable.