You are on the permits grid with three filters applied. You open the EPC Assistant and ask which rows look overdue. The assistant asks you to describe the grid.
You are in the SharePoint file navigator with a folder open. You ask for a summary of visible files. The assistant answers from chat history because it never saw the folder.
The UI already holds the context. Re-typing it is the hidden tax of generic chat sidebars on operational software.
The opposite failure mode is worse: dump the entire page, every register, and stale SPA state into every prompt. Token budgets explode. Answers drift after navigation because the model is reasoning over the screen you left two clicks ago.
Scraped HTML soup is not project context. EPC routes need structured summaries: which filters are active, which folder is open, which record is in view. That requires intentional collection, not ambient surveillance.
Every agent run includes lightweight pageContext: URL, pathname, title, page type, timezone. Enough for orientation. Not enough to answer "what filters are applied?" or "what files are in this folder?"
Registered route providers are not merged on routine turns. The assistant stays lean until the question actually requires what is on screen.
When the model needs live UI state, it calls requestUiContext with a reason and a detail level. The run pauses. The assistant tray collects a fresh snapshot and posts it on resume. The agent continues with structured JSON it can reason over.
| Tier | What is included |
|---|---|
| medium (default) | URL, title, pathname, pageType, route summary, routeContext from providers, moderate rich note cap |
| maximum | Extended provider detail, longer rich note, trimmed visible-text excerpt from main layout. Use sparingly. |
This is progressive context: minimal by default, heavy snapshot on demand. Not magic vision on every message.
Each route can register a page context provider through ContextUtils.registerPageContextProvider. The provider returns a bounded JSON summary keyed by feature id. Examples include a data tables grid, a record detail view, or the file navigator.
The contract is owned by the route, not scraped generically from the DOM. Providers merge into a routeContext bag only when a snapshot is requested. Not every route ships a provider on day one; the registry is extensible as views mature.
Document control opens the file navigator on a SharePoint folder. They ask:
I'm in the file navigator - what files are in the current folder?The assistant requests a medium snapshot. The fileNavigator provider supplies structured file names, paths, and counts visible in the current view. The answer cites what is on screen without the user listing twelve filenames by hand.
When they navigate away, stale navigator context clears on route completion so the next question does not inherit the previous folder.
What page am I on and what data is visible right now?Based on what's on my screen, which permits look overdue?Each triggers a deliberate snapshot at the appropriate tier instead of guessing from chat history alone.
The assistant should not guess what is on your screen when it can ask for a fresh, bounded snapshot. Context is intentional, not ambient surveillance.
Worth a conversation if your team still copies grid filters and folder paths into chat before the assistant can help.
No. Routine messages send only minimal page context: URL, pathname, title, and page type. A full UI snapshot is collected only when the assistant requests it through requestUiContext.
A route-registered function that returns a bounded JSON summary of what that view knows, such as visible files in the file navigator or filters on a data grid.
Stale route-specific context is cleared on navigation so the assistant does not reason over a previous screen after you move to a new view.