Multi-Surface Agent Experience¶
Questions or comments?
Post them as a comment on the tracking issue -- requires a GitHub account with access to this repo.
Novaworks AI | CTO Office | Q3 2026 | IN-PROGRESS
History¶
| Version | Date | Author / Notes |
|---|---|---|
| 1 | June 25, 2026 | Generated through AI assistance and conversation (Eswar Vandanapu) — High level features: Document upload/view, Notifications, Hardening for each Host, Structured Data Collection and "Continue with Nova" features. |
| 2 | June 25, 2026 | Eswar Vandanapu — Added the history. Additional disclaimer. |
| 3 | July 28, 2026 | Eswar Vandanapu — Revised the content for Section 2 and 4. |
| 4 | July 28, 2026 | Eswar Vandanapu — Added Section 5 (re-sync chat with host surface). |
Overview¶
This PRD defines the capabilities required for Novaworks to deliver a consistent, policy-enforced, and auditable HR agent experience across third-party host surfaces. All communication routes through Novaworks Agent Constellation via the Nova A2A Proxy and Nova MCP Gateway. Identity is resolved at the gateway layer. Conversations are owned by Novaworks regardless of host.
This document covers new capability areas only. Existing architecture (Nova A2A Proxy, Nova MCP Gateway, conversation store) is assumed operational.
NOTE: Specifically, the ability for an MCP gateway to hold conversation through a session boundary is yet to be determined and remains a risk in our ability to use non-A2A surface areas. This is currently being tested through a project in conjunction with USF students and professors.
Re-syncing chat state when a conversation continues on a different host surface (Section 5) is a requirement regardless of transport. For A2A this is not a problem. For MCP, this remains dependent on the session-boundary risk noted above — the requirement stands, but what we can actually deliver may be limited by how much state a given chat surface's protocol lets us carry across surfaces.
Compatibility Matrix: Portal, A2A, and MCP¶
The table below summarizes the expected support model for the capabilities in this PRD across the three delivery paths.
| Capability | Portal | A2A | MCP | Notes |
|---|---|---|---|---|
| Document delivery as artifact | Full | Full | TBD | Portal can render document cards and URIs; A2A supports artifact exchange; MCP can pass references and metadata but is not a native document-rendering surface. |
| Document upload ingest | Full | Full | TBD | Portal and A2A support the flow; MCP can forward structured file metadata but still depends on Novaworks-side ingest orchestration. |
| Notifications and async signals | Full | TBD | TBD | Notify pending actions in a chat with deeplink as a fallback. |
| Structured input collection | Full | Full | TBD | Structured collection payloads can be exchanged, but MCP needs host-side mapping or fallback handling for rendering. |
| Continue in Novaworks deep link | N/A | Full | TBD | Continue the conversation in long conversations and instances where hints can't be translated |
| Conversation continuity across session boundaries | N/A | Full | TBD | Depends on gateway/session persistence; this remains a known risk and is under validation. |
| Proactive nudges and app prompts | Full | TBD | TBD | Nudge behavior is implemented at the proxy/gateway layer rather than in the HR agent itself. |
| Audit and traceability | Full | Full | TBD | Logging is possible, but full tenant, user, trace, and timestamp enforcement depends on Novaworks-side processing rather than native MCP transport behavior. |
1 · Document Upload and View¶
Status: Done for A2A.
Objective¶
Enable agents to deliver and receive HR documents (offer letters, I-9s, policy PDFs, onboarding packets) as structured artifacts within any host surface.
Requirements¶
- Agents emit documents as FilePart artifacts within the A2A response envelope
- Novaworks Agent Constellation extracts FilePart metadata and routes to ServiceNow Attachment API
- Host surfaces receive a URI reference, not raw binary — rendering is host-agnostic
- Document delivery events are logged to the Novaworks audit store with tenant, user, document type, and timestamp
- Upload path (employee submitting a document) emits a DataPart with file metadata; Novaworks Agent Constellation handles the ingest to ServiceNow
Out of Scope¶
- E-signature workflows in this release
Risks¶
| Risk | Severity | Mitigation |
|---|---|---|
| Host rendering fidelity | Medium | Rich document cards render only in SN portal. Third-party surfaces receive URI only — acceptable degradation for Tier 1 surfaces. |
| Binary payload size in Novaworks Agent Constellation | Medium | Large PDFs transiting Novaworks Agent Constellation add latency. Enforce file size limit at gateway; reject and return error artifact above threshold. |
2 · Notifications and Async Activity Signals¶
Status: TBD
Objective¶
Provide a way for users from Gemini Workspace and other host surfaces to see the async notifications.
Out of scope¶
Notification system should natively support sending them via multiple channels such as Slack/Teams messages, push notifications to mobile etc. For the purposes of this PRD that is out of scope.
No native notifications¶
Almost all of the chat interfaces are "reactive" i.e. require the user to initiate the chat. They do not proactively poke the user. Any such native integration is out of scope due to this reason.
Functionality¶
When a user has expired/unread notifications, or tasks overdue, initiating a chat will nudge the user to indicate that they have unread notifications or overdue tasks with a link to the Nova portal interface where they can see and act on them.
See
[notifications/spec.md](notifications/spec.md)for the elaborated Feature spec derived from this section.
3 · Structured Input Collection¶
Status: Done for A2A using A2UI
Objective¶
Enable agents to request structured input from employees across any host surface — form fields, acknowledgments, selections — without embedding raw HTML in agent responses.
Design Principle¶
Agents emit a NovaworksCollectionSpec (structured DataPart). The Novaworks sidecar maps this spec to the appropriate host surface renderer: SN portal widget, Now Assist card, or a fallback link to the Novaworks UI.
NovaworksCollectionSpec — Minimum Required Fields¶
| Field | Type | Notes |
|---|---|---|
collection_id |
string (UUID) | Unique ID for this collection request. Idempotency key. |
title |
string | Displayed to employee as form heading |
fields[] |
array | Each field: name, type (text / select / boolean / date), label, required, validation |
policy_context |
string | Tenant policy reference governing this collection event |
expiry_ttl |
integer (seconds) | How long this collection request remains valid |
fallback_url |
string (URI) | Deep link to Novaworks UI if host cannot render (see Section 4) |
Risks¶
| Risk | Severity | Mitigation |
|---|---|---|
| Host cannot render collection spec | Medium | Sidecar must detect host rendering capability and fall back to deep link (Section 4). Never silently drop a collection request. |
| Spec version drift | Low | As NovaworksCollectionSpec evolves, older sidecar versions on customer instances may not support new field types. Version field is required from v1; sidecar must reject unknown versions gracefully. |
4 · 'Continue in Novaworks' Deep Link¶
Objective¶
In the instances where using a chat interface surface is untenable, users have an option to continue with a deep link to the session in Novaworks portal.
Trigger Conditions¶
- A form needs to be displayed, but the host doesn't support form redenring. For ex: No A2UI support enabled.
- Conversation turn count or token length exceeds configured threshold per tenant
- Agent detects a sensitive topic classification that requires a controlled UI context
- An unsupported document action (sign, acknowledge) is required
- Gateway detects unsupported front-end hints
See
[continue-in-novaworks/spec.md](continue-in-novaworks/spec.md)for the elaborated Feature spec derived from this section.
5 · Re-sync Chat with Host Surface¶
Objective¶
In an instance where the conversation is continued via a different surface, or in the Novaworks, re-entering the chat history and asking for something should retrieve the delta for context for the user.
Open questions:
- How to track which surface and channel is sent which messages.
Note
If a chat surface can be used in multiple devices, we depend on the
Native system to sync between devices for a given chat surface.
For ex. Claude web vs desktop.
Status: IN-PROGRESS — For internal engineering review only. Not for external distribution.
Novaworks AI | Confidential