Case Study · AI Ops · 2025–2026
VEDA — AI Project Intelligence Bot
An AI bot inside Microsoft Teams that reads project plans, signed SOWs, and timesheets to auto-generate weekly client-health reports — replacing 3–5 hours of PM work per project with under 30 seconds of generation time.
The fast read
- Live in Microsoft Teams across 5 client engagements.
- Replaced 3–5 hours of weekly PM reporting with 30 seconds of auto-generation.
- Modular connector layer above a swappable Claude API — redeployable for any client in under 4 weeks.
- Leadership demo led directly to a new billable BCG engagement.
Context
Why this got built
Across a portfolio of concurrent client engagements, project managers were burning 3–5 hours per week per project compiling status updates. The source data was scattered — Excel project plans, signed PDF SOWs, timesheet trackers, skill-gap docs — and the assembly was manual.
The diagnosis was the interesting part. This wasn't a reporting problem. It was a wiring problem. The data already existed. What was missing was a system that could read it coherently and put a draft on the PM's desk before they asked.
The problem
Two sides, one shape
For the PM
"I'm losing 3+ hours a week to status reports nobody reads in depth. I want early warning about scope drift, not late warning about margin loss."
For leadership
"Portfolio-level project intelligence — surfaced consistently across every engagement — without growing the PMO."
Constraints:
- Has to live in Microsoft Teams — that's where the team already lived.
- All source data already in SharePoint. No new logins, no new tools, no new entry steps.
- Cannot increase PM workload by even five minutes a week.
My role
Sole product owner and designer
I scoped the product, conceived the architecture, defined every API contract, designed the data schema and the prompt engineering, QA-ed across three live engagements, and presented to leadership.
A developer on the team helped with what I couldn't do alone — providing the API keys and connectivity into the intranet (timesheet, billed-hours, leave-management). Beyond that, the build was mine end-to-end.
Approach
Reframe before you build
Most "AI for project management" work in 2025 looked like chatbots. Clever, but useless for the actual job: writing the weekly status report. I went the other direction — the PM doesn't need a chatbot, they need a prepared draft delivered to the surface they already use, that they can edit and ship in two minutes.
The architecture that fell out of that reframe:
- Connectors that read SharePoint via Microsoft Graph.
- An indexer that chunks and stores with checkpoint logic.
- An intelligence layer that prompts Claude with structured context — not raw text — and returns health cards on a strict schema.
- A delivery layer that posts directly into Teams as a structured card.
The most important architectural decision was separating the intelligence layer from the connector and data layers. That makes the model swappable — Claude today, something else tomorrow — without touching the data infrastructure. It also makes the whole product redeployable for any client in under four weeks.
Key decisions
Four decisions that shaped the product
Decision 01
Swappable intelligence layer
Most "AI for X" tools wire the model into the data layer. We separated them on purpose. The connector layer reads SharePoint via Microsoft Graph; the intelligence layer prompts Claude with structured context; the delivery layer posts into Teams. Swap the model, the rest of the system doesn't care. That's the move that lets one internal tool become a redeployable product.
Decision 02
Schema-bound outputs, not free-form prose
Free-form LLM output is impossible to QA at scale. Every prompt returns a strict JSON schema — milestones, burn variance, scope drift, risk flags — and the Teams card is composed from that schema. It also means errors are inspectable: if a field is wrong, you can see it in the data, not parse it from a paragraph.
Decision 03
Deliver to where the team already is
The naive instinct was to build a dashboard. PMs would have to remember to open it. We landed on Microsoft Teams as the delivery surface — same channel the team already lived in, same notifications they already trusted. Zero new logins, zero new tools, zero new behaviours to learn. The health card just appears.
Decision 04
Checkpoint indexing for large projects
One of the first real projects had a 73-file SharePoint folder. Indexing crashed twice. Rather than chunking smaller, we added checkpoint logic — every batch saves a resumable index state, so any failure restarts from the last successful chunk rather than from zero. Boring infrastructure decision; absolutely critical for production.
01 / 04
Outcome
What changed
- Live in Microsoft Teams across 5 client engagements.
- Weekly health-card generation: 3–5 PM hours per project → under 30 seconds.
- A 73-file project indexed successfully with retry + checkpoint logic — proved the architecture at scale.
- Auto-flagged 3 undocumented scope changes on one engagement that would have shown up as margin loss weeks later.
- The leadership demo led directly to a new billable BCG engagement.
Reflection
"The interesting design problem in AI ops isn't the model — it's the contract between the connectors, the intelligence layer, and the delivery surface. Get the contract right and the model becomes a swappable detail."
VEDA was the project that convinced me the real differentiator at this stage of AI isn't the model. The model is rented from someone else. The differentiator is the system around it — the connectors, the schema, the human surface, the resilience to scale. Every six months the model gets better; the architecture you wrote around it had better still hold.