The demo is the easy half.

Problem

The same market, researched twice, produced two different peer sets. That is the part that hurts: a partner cannot defend a shortlist to a client if the next analyst would have built a different one. Peer and target benchmarking is repetitive and manual, but the manual part was never the real cost.

My role

Scoped it with the deal team, built the n8n workflows, wired Claude reasoning to live web search and semantic matching over the reference set, and ran the handover session that put it in the team's hands.

under 40 min The company-research pipeline and the peer finder together compressed several consultant-days of work to under 40 minutes. The speed was the side effect. The point was that peer selection became repeatable and explainable instead of analyst-dependent, which is what let partners defend the output to a client.

What I learned My first design was multi-agent: agents negotiating the shortlist in parallel. It was hard to control and harder to explain. A serial funnel, one scored stage feeding the next, was slower to write and far easier to trust, audit and defend. Controllability beat cleverness.

Problem

M&A datasets arrive full of messy company names and unclear ownership. "Acme Corp", "ACME Corporation Ltd" and "acme inc" are one company or three depending on who cleans the sheet. Fuzzy string matching alone either merges distinct firms or splits one across spellings, and analysts lose hours reconciling it by hand.

My role

Built the pipeline in Python: the normalisation rules, the ML matcher, the web-search fallback and the review queue, then integrated it with the M&A analytics that consumed the cleaned entities.

Still open When two records share a name and nothing else, like Apex Ltd in London and Apex Ltd in Delaware, the pipeline flags instead of deciding. That queue is a person's job and I did not try to automate it away.

consistency Reduced manual cleansing effort and improved the consistency of entity data across M&A analytics. Stated conservatively: I left before I could instrument the exact hours saved, so I will not quote a number I do not have.

What I learned Deterministic rules are boring, and they are also right most of the time. Spending the ML and web-search budget only on the tail the rules could not resolve kept the pipeline fast, cheap and auditable, and kept a human on the genuinely ambiguous cases instead of rubber-stamping a model's guess.

Problem

The team would not adopt a new tool. That was the first thing I was told and it was not up for discussion. Meanwhile they were answering long, recurring question lists against hundreds of pages of documents, slowly, and the same question got a different answer depending on who read which PDF. So the interface had to be the spreadsheet they already had open.

My role

Built the Copilot Studio agent, the SharePoint upload and monitoring, the batch processing, and the write-back into the team's own spreadsheet.

seconds to check Cut manual document review to a fraction and made it reusable across projects. Because the answer sat next to the question with its source page, a reviewer could verify it in seconds instead of re-reading the document.

What I learned The client would not adopt a new interface, so the interface became the spreadsheet they already used. OCR on scanned pages stayed unreliable, and I shipped it as a known open edge rather than pretending it was solved.