What looks like a training problem but isn't?

Staff weren't struggling because of low digital literacy, as initially assumed. Through user research, we discovered that the real friction came from fragmented information and inconsistent workflows spread across siloed departments.

Role
Product Management Intern
Organization
Whitney Museum of American Art
Focus
Product Discovery, AI Systems, Organizational Adoption
Timeline
Fall 2025
01

The Challenge

As the Whitney transitioned to Microsoft Teams, adoption was inconsistent across departments. The issue was initially framed as a training problem.

After observing workflows and reviewing support requests, I suspected the root cause was something different.

02

My Role

I helped evaluate technical approaches, define product requirements, structure the knowledge architecture, and design role-aware experiences.

03

The Insight

Staff often knew what they wanted to accomplish. They simply couldn't find institution-specific guidance when they needed it.

The challenge wasn't training. It was knowledge accessibility.

04

Key Decisions

  • Reframe the problem

    Instead of creating more training materials, we focused on delivering contextual guidance directly within existing workflows.

  • Design around roles

    Different users needed different information. The system was designed to adapt responses based on responsibilities, permissions, and organizational context.

  • Establish clear AI boundaries

    To maintain trust, we built around structured knowledge sources and clearly defined where AI reasoning should and should not be used.

05

The Architecture

WhitneyBot is built in three layers, each with one job, so the pieces can change independently.

Bot layer
Handles sign-in and routes incoming messages.
Agent layer
Works out what the user is asking, picks the right tool, and composes the answer.
Tool layer
Two tools: a knowledge base of the museum's documented workflows, and a graph tool that reads live Teams and role data.

Keeping these separate means the underlying language model can be swapped out, governance boundaries stay clear, and different roles get different answers without rewriting the logic each time.

Whitney Teams Agent — Component Architecture (v1)

Microsoft Teams
Client interface
  • User message events
  • OAuth SSO
  • Adaptive Cards (future)
↓ Incoming activity
Bot Service Layer
Azure Bot Framework + Azure AD
  • Authentication (SSO via Azure AD)
  • Token validation
  • Message routing
  • Conversation state storage
  • Error handling
↓ Forward to agent
AI application layer
Agent Orchestration Layer
Provider-agnostic LLM interface
  • Intent parsing
  • Tool selection logic
  • Multi-step orchestration
  • Context memory
  • Response synthesis
Swappable LLM provider OpenAI / Anthropic / local model
Differentiation engine
  • Role-aware (Owner vs Member)
  • Context-aware
  • Skill-aware scaffolding
↕ Tool invocation
Knowledge Tool
Whitney Markdown KB
  • Institutional workflows
  • Naming conventions
  • Indexed retrieval (RAG / search)
Graph Tool
Microsoft Graph API (read-only v1)
  • Role lookup
  • Teams & file metadata
  • Permission-scoped access
↓ Response to user
Azure Cloud Infrastructure
  • Secure token storage
  • Logging & telemetry
  • Hosting environment
  • Future CI/CD
v1 scope
  • Read-only operations
  • No write access to Teams or Graph
  • Governance-first rollout
The v1 component architecture, from the Teams client down to the Azure infrastructure it runs on.
06

Outcome

WhitneyBot is being developed as a Teams-native assistant designed to make institutional knowledge more accessible across the museum.

07

What I Learned

One of the most valuable product skills is diagnosing the right problem before building the solution.