ℹ️ What this is: A personal AI assistant built for VP/executive-level users in Microsoft 365 environments. Manages email, calendar, data reporting, and team communication through a single agent accessible from anywhere — desktop, mobile, Teams, or email. First target: Dave Devries at ASH (VP of ASCs). This document captures the full architecture from the March 5 deep-dive session.

PART 1 — The Core Problem

Why Not Just Use Microsoft Copilot?

Microsoft Copilot exists. So do dozens of enterprise AI tools. The question is: why would a VP pay for something custom? Here's the honest answer:

	Microsoft Copilot / Generic AI	Your Bespoke Agent
Data access	Microsoft 365 only (email, docs, calendar)	M365 + CRM + claims data + custom databases + web intelligence
Knows your business	Generic understanding	Trained on your org's specific data, KPIs, and workflows
Can build things	No — generates text only	Yes — generates dashboards, reports, summaries, data pulls
Memory	Session-based, no persistence	Persistent — remembers context, past decisions, preferences
Deployment	Microsoft's servers — data leaves your tenant	Your Azure tenant — data never leaves
Customization	None	Built specifically for this person's workflow and data

The Real Pitch

Microsoft Copilot answers questions about your emails. Your agent manages your day. It triages your inbox, flags what needs a decision, drafts replies in your voice, pulls the market share numbers your liason asked about, builds the dashboard before you even open your laptop, and remembers that you prefer bar charts. That's a fundamentally different product.

PART 2 — System Architecture

The Central Insight: Agent Lives in Azure, Not on the Device

The agent runs centrally in Azure. The VP's devices — laptop, phone, Teams, email — are just windows into the same brain. Like Gmail: same inbox whether you're on your phone, laptop, or someone else's computer.

VP's Devices Your Azure Infrastructure ───────────────── ────────────────────────────────── ┌──────────────────────────────────┐ Desktop/Web App ──── WebSocket ─────────►│ API Gateway │ │ (routes all channels to agent) │ Mobile App ──── WebSocket ─────────►│ │ │ ┌────────────────────────────┐ │ Teams Bot ──── HTTPS ─────────────►│ │ Agent Container │ │ (mentions) │ │ │ │ │ │ • One brain, one memory │ │ Email to bot ──── Graph API ─────────►│ │ • Persistent context │ │ (agent@co.com) │ │ • Tool execution │ │ │ └────────────────────────────┘ │ │ │ │ Azure Services: │ │ • Azure OpenAI (model) │ │ • Key Vault (credentials) │ │ • PostgreSQL (memory + history) │ │ • Blob Storage (reports/files) │ │ • Bot Service (Teams) │ └──────────────────────────────────┘

Why This Architecture?

🚨 What NOT to build: An OpenClaw-style local agent on the VP's laptop. If something goes wrong — a hallucinated command, a context compaction incident, a prompt injection through a malicious email — there's nothing protecting his files, his credentials, or his system. Healthcare executives cannot have unsandboxed agents on their machines.

✅ What TO build: Agent runs in a sandboxed Azure container. VP's machine is never touched. All data access goes through Microsoft Graph API (cloud-to-cloud, no local dependency). VP's data stays in their own Azure tenant.

PART 3 — The Channels (How the VP Talks to the Agent)

Channel	How it works	Best for	Streaming?
Desktop Web App	Browser → WebSocket → Azure API	Deep work, reviewing dashboards, long sessions	Yes — real-time
Mobile App	App → WebSocket → Azure API	Quick queries, approvals, on the go	Yes + push alerts
Teams Bot	@mention → Bot Framework → HTTPS → your API	Team-facing, shared agent access, reps asking questions	No — full response only
Email	Email to agent → Graph API webhook → your API	Zero-install access, works on any device, async tasks	No — async reply

Teams Bot UX Consideration

Teams uses HTTPS request/response — no streaming. So the VP sends a message, there's a pause, then the full response appears. For long tasks (build me a dashboard), the pattern is: agent sends "On it — I'll notify you when it's ready" immediately, then delivers the result via push/Teams update when done. For short questions, the pause is fine. Tailor response verbosity by channel.

PART 4 — Inbox Management (The Core VP Use Case)

The Problem with Executive Inboxes

A VP of ASCs gets 200+ emails a day. Vendor pitches, internal reports, physician liaisons, compliance notices, calendar invites. The job isn't reading all of them — the job is knowing which 10 actually need a response and what that response should be. That's where the agent earns its keep.

How Graph API Powers This

Microsoft Graph API gives the agent cloud-to-cloud access to the VP's entire Microsoft 365 environment — email, calendar, contacts, OneDrive, Teams messages — all without touching the VP's machine.

Your Azure Container (Agent) │ │ graph.microsoft.com ▼ ┌─────────────────────────────────────────┐ │ Microsoft Graph API │ │ │ │ /me/messages ← read email │ │ /me/sendMail ← send email │ │ /me/calendar/events ← calendar │ │ /me/contacts ← contacts │ │ /teams/{id}/messages ← Teams messages │ │ /me/drive/root ← OneDrive files │ └─────────────────────────────────────────┘ │ ▼ VP's Microsoft 365 Tenant (data never leaves tenant)

The Daily Inbox Workflow

Morning triage (automated, before VP opens email)
Agent reads all unread emails via Graph API → categorizes by urgency + type → builds a morning brief: "You have 47 unread. 3 need decisions today: budget approval from Sarah, escalation from Acme Corp, contract renewal from vendor X."
Draft-and-review (on request or automated for routine)
VP says "reply to Sarah approving the budget" → agent drafts reply in VP's voice → shows draft → VP approves or edits → agent sends via Graph API. For truly routine emails (meeting confirmations, FYI acknowledgments), agent can draft + queue for batch approval.
Context injection
When VP asks "what did Acme Corp say?" → agent searches email history + CRM data + meeting notes → gives a full briefing, not just the last email. Memory makes this work.
Proactive alerts
Agent monitors for: VIP senders, keywords ("urgent", "contract", VP's name), unresponded threads older than 48h. Sends push alert to phone or Teams message: "You haven't responded to the physician liaison from St. Vincent's — sent 3 days ago."
Calendar coordination
"Find time for a 30-minute call with the ASC team this week" → agent checks VP's calendar + attendees' calendars → suggests 3 options → books on confirmation.

Three-Tier Email Access Model

Email Type	Agent Access Level	Rule
VP's corporate inbox	Read + draft + send-on-approval	Never sends without VP confirmation for non-routine mail
Shared team inbox	Read-only + alerts	Monitors, surfaces items, doesn't reply
Agent's own identity (agent@company.com)	Full send	For automated reports, scheduling coordination, notifications

PART 5 — The "Claws" (What the Agent Can Do)

Claws are the agent's capability modules — discrete tools it can invoke to take action. The agent decides which claws to use based on the request.

📧 Email Claw

Read, search, draft, send, categorize emails via Graph API. "Summarize my emails" → morning brief. "Reply to Sarah" → draft for approval.

📅 Calendar Claw

Read/create/modify events via Graph API. "When's my next board meeting?" → event details. "Find time for X" → suggests + books slot.

📊 Data Claw

Query CRM, claims data, market share databases. "Primary care market share in Southeast region" → pulls from data sources, returns structured results.

📈 Dashboard Claw

Generates interactive HTML/React dashboards from data. Creates a blueprint (persisted) + rendered HTML (ephemeral, 7-day TTL). Rebuilds on demand from blueprint.

📄 Report Claw

Generates formatted reports (PDF, DOCX, PPTX). Pulls data → applies template → delivers file to VP's inbox or OneDrive.

🔔 Notification Claw

Sends push alerts (phone), Teams messages, or emails. "Dashboard ready → [link]". "Urgent email from board member unread for 6 hours."

🧠 Memory Claw

Saves/retrieves/searches persistent context. "Remember Sarah approved the Q2 budget." Loads relevant past context into every new conversation.

Example: End-to-End Orchestration

Rep in Teams: "I need primary care market share for the Southeast"

Teams Bot Framework → HTTPS POST → Your API Gateway │ ▼ Agent identifies user, loads memory │ ┌────────────────┼────────────────────┐ ▼ ▼ ▼ Data Claw Dashboard Claw Memory Claw query CRM for generate HTML from save: "built SE market share data + blueprint primary care dash data save to Blob Storage on 2026-03-08" │ │ └───────┬────────┘ ▼ Notification Claw "Your dashboard is ready → [link]" sent to Teams + push to phone │ ▼ Rep opens desktop web app later: Dashboard is in "Recent" panel, ready

PART 6 — Memory & Session Continuity Across Devices

The VP uses desktop at work, phone on the go, Teams in meetings, email from anywhere. The agent needs to feel like the same conversation everywhere.

Recommended: Per-Channel Sessions + Shared State + Handoff Summaries

Mechanism	What it does
Per-channel sessions	Desktop, mobile, Teams, email each have their own thread — no race conditions if VP is on two devices simultaneously
Shared PostgreSQL memory	All channels write to the same memory database — facts, decisions, preferences, outstanding actions
Handoff summaries	When VP switches channels, new session injects a compressed summary: "You were reviewing Southeast dashboard on desktop 12 min ago. Sarah's budget approval is still pending."

Key Difference from OpenClaw

OpenClaw uses Markdown files on disk as shared memory — simple and effective for one person on one machine. Your enterprise platform uses PostgreSQL with importance-ranked rows, pgvector semantic search, and active handoff summaries that bridge channel switches. Same concept, cloud-native and multi-user.

PART 7 — The Dashboard Blueprint Pattern

Key insight from the March 5 session: don't store rendered HTML — store the blueprint and the data separately.

What to persist	What to keep ephemeral
Data snapshot — the raw numbers, timestamped in PostgreSQL Dashboard blueprint — a structured MD/JSON file: which charts, which metrics, which filters, which data query User preferences — "prefers bar charts, always show YoY comparison"	Rendered HTML/React dashboard — cached in Azure Blob Storage with 7-day TTL, then deleted. Regenerated on demand from blueprint + data.

Why this matters: When the VP says "show me the same thing but for Q3 last year" — agent reads the blueprint, swaps the date range, re-queries data, re-renders. When they say "add a trend line" — agent modifies the blueprint, regenerates. Blueprint is the source of truth. HTML is cheap.

PART 8 — Per-Client Environment Design

The Core Insight: "Chief for Everyone"

This isn't a shared platform where clients log in to your system. Each client gets their own isolated container — their own private brain — running inside their own Azure tenant. Their data never leaves their walls. You never touch their data. You just deploy and configure the agent.

What Chief does for Blake = What the agent does for the VP

Chief (Blake's setup)	Enterprise Agent (VP's setup)
Manages inbox, drafts replies	Manages inbox, drafts replies
Tracks projects and todos	Tracks board action items and deadlines
Builds reports on demand	Builds market share dashboards
Remembers context across sessions	Remembers preferences and past decisions
Accessible via Telegram, web, CLI	Accessible via Teams, mobile, desktop, email
Runs on Mac Mini in Blake's house	Runs in container in client's Azure tenant

The product is not new technology. It's Chief, deployed and configured for enterprise.

What Each Client Gets

Client Container (Azure Container Apps — inside their tenant) ├── Agent runtime ← your code (same image for all clients) ├── SOUL file ← client-specific: persona, tone, workflow rules ├── Memory store ← PostgreSQL, private and isolated to them ├── Active Claws ← configured for their role (VP vs. rep vs. CMO) └── Data connections: ├── Microsoft Graph API ← their M365 tenant (email, calendar, Teams) ├── CRM connector ← optional ├── Claims data connector ← optional └── Custom databases ← optional

What Blake Controls

Your Azure Infrastructure (management layer) ├── Container registry ← your agent code/images (you push updates here) ├── Provisioning API ← spin up new client environments in minutes ├── Configuration store ← per-client Claw settings and data connections ├── Monitoring dashboard ← usage, errors, token spend per client └── Template library ← reusable role-based configs (VP, rep, CMO, etc.)

✅ Data privacy unlocked: Blake's infrastructure manages container images and provisioning config only. Client credentials live in the client's Azure Key Vault. Blake has zero access to client data. This eliminates healthcare's biggest objection: "we can't let vendor data leave our walls."

Onboarding a New Client (Target: < 1 day)

Client signs agreement, provides Azure tenant info
You provision their container using an ARM template / Bicep script — runs inside their tenant, not yours
Client's M365 admin grants Graph API permissions (one-time OAuth approval)
You configure their Claws: which capabilities are active, which data sources connected
Load initial context: their role, org structure, key contacts, communication preferences
Test run — agent triages a sample inbox batch, VP reviews the output
Go live — client gets the web app URL + Teams bot invite

Scaling the Business

Client #	What gets easier
Client 1 (Dave/ASH)	Build everything from scratch. Prove the model.
Clients 2–5	Reuse the container image and provisioning script. Configure per role. Each deployment strengthens the template library.
Clients 6+	Provisioning is nearly automated. Most of the work is configuration and onboarding conversation — not code.

ℹ️ This is the moat: Every client you deploy makes your template library richer, your provisioning faster, and your domain knowledge deeper. A new entrant has to build all of this from zero. You're compounding.

PART 9 — Next Steps

Phase	What to build	Timeline
Phase 1 — Dave's email agent	Graph API connection, inbox triage, draft-and-review workflow. Single user, Azure Container Apps.	2–3 weeks
Phase 2 — Teams bot	Bot Framework integration. Rep-facing queries in Teams. Push notifications when dashboards are ready.	2 weeks
Phase 3 — Data Claw	CRM + claims data queries. Market share dashboards. Blueprint + ephemeral pattern.	3–4 weeks
Phase 4 — Multi-user	Azure AD auth, per-user containers, shared team agent via Teams, role-based access.	4–6 weeks

⚠️ First thing to set up: Microsoft Azure account with the right tenant structure. From the March 5 notes — you started this (Microsoft 365 Business Basic → Entra ID → Azure), hit a snag with Gmail tied to Microsoft account. Pick this back up and get the Azure environment live before building anything.

Enterprise AI Assistant Architecture Brief · Chief · March 8, 2026 · Source: Cowork session great-ecstatic-wozniak (2026-03-05) · Project: ventures/enterprise-assistant/

🏢 Enterprise AI Assistant — Architecture Brief