Skip to main content

Architecture

GriMoire is an AI assistant built on Reflexive UI Awareness — a host-side orchestration pattern where the LLM is continuously grounded in the UI it creates, user interactions with that UI feed back into the model as structured events, and the model's service choices across Microsoft 365 are expressed through dynamic building blocks rather than static text.

This lets users search for documents, recap what they find, and share it by email — from the same SharePoint page, without switching tools. The search pipeline retrieves across multiple sources in parallel. The Hybrid Interaction Engine keeps the model aware of what the user sees at every step. And MCP-connected Microsoft 365 services — SharePoint, OneDrive, SharePoint Lists, Outlook Mail, Outlook Calendar, Teams, Word, and Copilot Search — let the assistant take action on the user's behalf through the same building blocks it uses to present results.

The runtime has a split architecture:

  • a SharePoint Framework frontend that owns the UI, the HIE loop, and delegated M365 access
  • an Azure Functions backend that proxies model calls, MCP sessions, and persistence
User on SharePoint page
→
SPFx web part
HIE loop, UI blocks, avatar, compound workflows
→
Three outbound paths
Microsoft Graph
Delegated via AadHttpClient (includes Copilot endpoints)
Backend proxy
API key → LLM, MCP
Backend user routes
Easy Auth → notes, preferences
→
Backend reaches
Azure Foundry
Managed identity
Agent 365 + MCP
8 servers: SharePoint, SharePoint Lists, Mail, Calendar, Teams, Word, Profile, Copilot
Table Storage
User data persistence

The frontend​

The SPFx frontend is responsible for:

  • rendering the assistant UI inside SharePoint
  • maintaining the action panel and block stack
  • handling voice and text entry
  • keeping the HIE loop alive (artifact tracking, interaction normalization, embodiment arbitration)
  • executing compound workflows that chain search, recap, and action steps automatically
  • making delegated Microsoft Graph calls using the built-in SPFx auth model

This is where the interaction becomes visible and grounded.

The backend​

The backend is an Azure Functions proxy that sits between the frontend and the model/MCP surfaces that should not be called directly from the browser.

It is responsible for:

  • routing model calls to the configured backend paths
  • issuing realtime tokens
  • MCP connect/execute/disconnect flows
  • user data persistence (notes and preferences), protected by Easy Auth

The data and action boundary​

Direct from the browser​

The browser calls Microsoft Graph directly through SPFx's delegated auth model. Copilot Search and Copilot Retrieval are Graph endpoints (/beta/copilot/*), so they use the same delegated path. This means the assistant can work in the user's context without a separate custom browser-side app registration.

Through the backend​

The backend handles:

  • model access
  • MCP sessions and execution
  • any server-side persistence

This separation is deliberate. It keeps the user-context API calls in SharePoint's delegated model while keeping model credentials and MCP session execution out of the browser.

UI blocks as the interaction contract​

Retrieved or generated information does not stop at text responses. It becomes typed UI blocks — search results, file previews, document libraries, user cards, compose forms, progress trackers, and more.

These blocks are the core of how Reflexive UI Awareness works in practice. They are not a decoration layer. Each block is:

  • Tracked by the HIE, so the model always knows what the user currently sees
  • Interactive — clicks, selections, and dismissals feed back into the model as structured events
  • Actionable — the same block system that presents search results also presents compose forms, confirmations, and progress trackers

This is what makes flow-of-work continuity possible. The user sees search results, clicks one, gets a recap, says "send this by email" — and at every step, the model knows what is visible, what the user did with it, and which Microsoft 365 services to invoke next. The blocks are the shared medium through which the LLM, the UI, and M365 services converge.

Why this architecture matters​

This architecture has five design characteristics:

  1. Single-page interaction: search, recap, and action happen in the same page.
  2. SharePoint-native placement: the assistant lives where users already work.
  3. Delegated M365 access: Microsoft Graph calls (including Copilot endpoints) run as the current user.
  4. Protected model access: model and speech resources stay behind the backend.
  5. Governed action routing: Agent 365 and MCP actions go through a backend boundary that can enforce policy, session management, and logging.