Coalition of the Willing (Novaworks Marketplace — Phase 1)¶
Questions or comments?
Post them as a comment on the tracking issue -- requires a GitHub account with access to this repo.
Novaworks AI | x_novaw_platform + Super Agent orchestration
Major Change History¶
| Version | Date | Author / Notes |
|---|---|---|
| 1 | 2026-08-06 | Eswar Vandanapu — Feature Set created from a verbal brief on external-agent marketplace underpinnings. |
| 2 | 2026-08-06 | Eswar Vandanapu — Reframed business case away from "bespoke integration is broken" toward "deliberately paving repeatable extension points, one at a time." Both partners and customers can now insert external agents; Feature 1/2 redefined as the manual-to-templated progression for the orchestration track specifically. |
| 3 | 2026-08-06 | Eswar Vandanapu — Grounded the business case in skills-product/business-context.md: tied Feature 1/2 to the Sidecar/mid-market GTM split and the "AI-native alone is a shrinking differentiator" timing signal; flagged ServiceNow Ventures' strategic-investor overlap as an open positioning question. |
| 4 | 2026-08-11 | Eswar Vandanapu — Reformatted to the current nova-feature-set template: added the required Data Model (Conceptual) section, moved inline citations and process asides into Sources/Open Questions per the skill's Voice convention. No change to business case, scope, or Open Questions content. |
| 5 | 2026-08-11 | Eswar Vandanapu — Broadened the set of future extension points named in Business case/Goal beyond "Advisor data, portal widgets, custom guardrails, conversation listeners" to the fuller, now-agreed taxonomy: transfer agents, orchestration agents, conversation listeners, a general functional-agent registration mechanism, and partner-bundled UI. Added two Open Questions on Regulations/Rules partner scope boundary and Policy/Info Provider readiness. No change to Feature 1/2 scope. |
| 6 | 2026-08-11 | Eswar Vandanapu — Compressed Business case prose and replaced the inline extension-point enumeration with an explicit Extension Points table; added the point that Novaworks can define additional extension points beyond this list. No change to Feature 1/2 scope or Open Questions. |
| 7 | 2026-08-11 | Eswar Vandanapu — Pivoted Feature 1 to Transfer Agents, proven via the original motivating case (transferring a sensitive/private conversation to a dedicated agent) instead of external-agent insertion. External Agent Insertion (manual) and its Tenant Controller templating move to Feature 2/3, reusing the pattern Feature 1 proves. Retired the Open Question on whether private-conversation-handoff becomes "Feature 3" — it's now Feature 1 directly. |
| 8 | 2026-08-11 | Eswar Vandanapu — Marked ready: the remaining Open Questions can only be resolved by running Feature 1 as an experiment, not by more upfront analysis. Removed the "hold off" warning banner. |
| 9 | 2026-08-11 | Eswar Vandanapu — Created Commitment Meeting issue #757 and Feature sub-issue #758 in Novaworks-ai/Roadmap, milestone Current Quarter. |
| 10 | 2026-08-11 | Eswar Vandanapu — Assigned #757 to Vivek Tiwari (@viveknova); frontmatter owner updated to match. |
Business case¶
Novaworks is an AI-native HCM operating system on ServiceNow, with ServiceNow Ventures as a strategic investor — a live positioning consideration against ServiceNow's own ecosystem plays (see Open Questions). Co-sell/coalition partner agents (Feature 2) extend the Enterprise Sidecar motion; templated customer self-service via Tenant Controller (Feature 3) extends the case for mid-market customers to treat Novaworks as their system of record. "AI-native" alone is a shrinking differentiator as agentic entrants (Intuit, Paychex) emerge in HCM — a partner-built agent ecosystem is harder to copy, which is part of the timing case for starting now.
Novaworks has no point today where partner-, customer-, or Novaworks-own functionality plugs into how a conversation is handled — not in orchestration, Advisor's data layer, or the portal. This is the start of that journey: opening extension points one at a time, each establishing a repeatable pattern the next reuses, rather than a full marketplace in one step.
Three groups have this problem today. Employees and other end users have no way for the Super Agent to recognize a conversation should move to a dedicated agent and hand it off for a stated reason — everything stays in the same general context regardless of what it's about. Co-sell/coalition partners have no sanctioned way to get their agent in front of a customer. Customers want to browse and activate Novaworks-vetted external agents in their own tenant themselves — a distinct need from a partner pushing their agent out to many tenants. Without a repeatable pattern, every extension point needs its own bespoke design, multiplying engineering cost with every partner and integration type.
Value to customers. An employee gets a conversation that's actually private when it should be — the Super Agent recognizes a sensitive or private moment and hands it to a dedicated agent for a stated reason, rather than staying in the general orchestration context (Feature 1). A co-sell/coalition partner gets a sanctioned, repeatable path to reach a Novaworks customer instead of a one-off engineering negotiation per deal (Feature 2). A customer gets to browse and activate a Novaworks-vetted external agent in their own tenant themselves, without waiting on Novaworks to build that specific capability natively (Feature 3).
Value to Novaworks. Proving one extension-point pattern end-to-end — trust model, hand-off/insertion mechanism, tenant-level control — de-risks every extension point that follows (see table below) instead of each being designed from zero. It turns coalition/co-sell partnerships into an actual product surface, and starts positioning Novaworks as a platform other agents plug into rather than a closed system — relevant against Microsoft Copilot Studio's agent store and Salesforce AgentExchange (see Table-Stakes below), and a differentiator harder for emerging agentic HCM entrants to copy than the AI-native claim alone.
Novaworks lens. Novaworks proves the extension-point pattern on the smallest concrete case first: Feature 1 hands one real scenario — a sensitive conversation transferred to a dedicated agent, for a stated reason, with an optional summary the receiving agent decides how to act on — to the Transfer Agent mechanism, rather than opening any general capability. The manual-then-templated sequencing that follows for external-agent insertion (Feature 2, then Feature 3) reuses exactly what Feature 1 proves: prove narrow and manual first, template only once trust is established. That sequencing, not just "we also have a marketplace," is the differentiated stance, and it's what every extension point below will reuse.
Extension points.
| Extension point | What it does | Status |
|---|---|---|
| Transfer Agents | Hand a conversation to another agent for a stated reason (Private Conversation, Not Our Job, Explicit Ask), with an optional summary the receiving agent decides how to act on | Feature 1 — this Feature Set |
| External Agent Insertion (Orchestration) | Partner- or provider-built A2A agents registered into Super Agent orchestration | Feature 2/3 — this Feature Set |
| External Data Integration (Advisor) | External data sources plug into Advisor's data layer | Next — see Open Questions on specs-advisor ownership |
| Orchestration Agents | Functional agents that carry out tasks via A2A/A2UI/FA protocol without shared-state access; can register UI widgets | Agreed conceptually, not yet scoped |
| Conversation Listeners | Org- or user-enabled agents that observe a conversation to offer side hints, or signal it shouldn't be processed further | Agreed conceptually, not yet scoped |
| Portal Widgets | Partner-bundled UI surfaced in the ServiceNow portal | Agreed conceptually, not yet scoped |
| Custom Guardrails | Partner- or customer-defined guardrail logic | Agreed conceptually, not yet scoped |
| Functional Agent Registration/Marketplace | A general registration mechanism other functional agents (e.g. a rewards-disbursement agent) build on | Agreed conceptually, not yet scoped |
| Policy/Info Providers | A decision-rule prefix resolves to a policy/info source (e.g. the ServiceNow built-in KB, or another location) | Concept sketch only, no use case yet |
| Regulations/Best-Practices/Rules Partners | Data sources the Policy Advisor searches — not used by Super Agent directly | Scope boundary open — see Open Questions |
This list isn't closed — Novaworks can define additional extension points as new partner, customer, or internal needs surface; the pattern this Feature Set proves is meant to generalize, not enumerate a fixed set.
Goal¶
Prove a repeatable extension-point pattern for partner-, customer-, and Novaworks-supplied functionality — starting with Transfer Agents, proven end-to-end through one concrete case: transferring a sensitive or private conversation to a dedicated agent for a stated reason (Feature 1) — then reusing that pattern for external A2A agents in Super Agent orchestration, progressing from partner-only, manually-inserted agents (Feature 2) to Novaworks-templated agents customers can browse and activate themselves via Tenant Controller (Feature 3). Beyond that, the fuller set of extension points already agreed conceptually — orchestration agents, conversation listeners, portal widgets, custom guardrails, external data for Advisor, and a general functional-agent registration mechanism — will reuse the same pattern.
Scope¶
x_novaw_platform (orchestration/registration) and the Super Agent (nova-superagent-agent) for the Transfer Agent mechanism (Feature 1), which depends on ai-guardrails-sensitive-routing's sensitivity-detection signal as one trigger into a transfer, alongside a user's own explicit request. The same systems, plus Tenant Controller (nova-tenant-controller) for the templated-insertion step (Feature 3), for external-agent insertion (Feature 2/3). External data integration for Advisor is named in the Business case as another extension point in this same wave, but Advisor is owned by specs-advisor, not this repo — see Open Questions on whether that piece is scoped as its own Feature Set there rather than folded in here.
Sources¶
skills-product/business-context.md— Novaworks strategic context: the Sidecar/mid-market GTM split, ServiceNow Ventures as strategic investor, and the "AI-native alone is a shrinking differentiator" timing signal.- Verbal brief, this conversation, 2026-08-06 — original problem framing.
Related PRDs¶
- ai-guardrails-sensitive-routing — its
human-escalation-context-handoffFeature is the first consumer of Feature 1 (Transfer Agents): it owns sensitivity detection, the mandatory-vs-declinable decision, the mandatory immediate-handoff path for crisis-level content, and the actual employee-facing UX (nudge, channel picker, summary review) — calling Feature 1's infrastructure once it has a reason, destination, and summary decided. Feature 1 has no direct relationship to that Feature Set's classification or crisis-handoff mechanisms;human-escalation-context-handoffsits between them. - ai-chat-surfaces — owns the "Continue in Novaworks" deep-link fallback for host surfaces Novaworks doesn't control the rendering of; that fallback is
human-escalation-context-handoff's concern when rendering its own UX on such a surface, not Feature 1's — Feature 1 has no UI to fall back on. - ticketing-integrations — owns converting an unfulfillable request into a ticket automatically ("Agent capability gap") and treating an agent execution failure as a ticket ("technical execution failure"); Feature 1 has no distinct "Not Our Job" mechanism of its own since the former already covers it, and reuses the latter for an unavailable Receiving Agent once live sessions exist.
Who this is for¶
| Persona / Role | Friction today | Value gained |
|---|---|---|
| Employee / End User (primary) | When a conversation turns sensitive or private, the Super Agent has no way to hand it to a dedicated agent — it stays in the same general context regardless of what it's about. | Feature 1: the Super Agent transfers the conversation to a dedicated agent for a stated reason (starting with a detected sensitive/private case), optionally carrying a summary the receiving agent decides how to act on. |
| Coalition Partner / Co-sell Partner | No sanctioned way to get their own agent in front of a Novaworks customer at all — the only path today would be a bespoke integration built from scratch. | Feature 2: their agent can be inserted into Super Agent orchestration via a manual update set — not templated or self-service yet, but a proven, repeatable path reusing what Feature 1 established. |
| Customer SN Administrator | Has no way to bring an external agent into their own tenant themselves, and no way to know which external agents Novaworks has actually vetted. | Feature 3: can browse Novaworks-vetted external agents and insert/activate one into their tenant via Tenant Controller, using a Novaworks-defined template — self-service within Novaworks' curated set, not yet an open marketplace. |
| External Widget/Advisor Dataset/Guardrail/Listener/Orchestration-Agent Provider — Phase 2, out of MVP scope | N/A — these integration points don't exist yet. | Advisor data integration is named in the Business case as another extension point in this same wave (see Scope); portal widgets, custom guardrails, orchestration agents, and conversation listeners remain further out, unscoped. |
What we are building¶
The Notes column is a breadcrumb, not commentary — it carries a Feature-specific insight surfaced while working this concept.md until that Feature is seeded into its own spec.md, so nova-feature picks it up as part of the seed rather than losing it.
| # | Feature | Folder | Notes |
|---|---|---|---|
| 1 | Transfer Agents (prove the mechanism through one concrete case: transferring a sensitive/private conversation to a dedicated agent for a stated reason) | transfer-agents/spec.md | — |
| 2 | External Agent Insertion into Orchestration (manual, via update sets — partner agents only) | not yet seeded | Scope as an experiment, not a fixed process: what a partner's manifest/spec format, security review, and sign-off actually need to look like is the expected outcome, observed across real partners — that outcome is what Feature 3's template design reuses. |
| 3 | External Agent Insertion via Tenant Controller (Novaworks-defined templates; customer browses/activates a vetted agent) | not yet seeded | — |
Phasing, effort, and sprint/month targets are planning decisions — they live on the GitHub issue, not here.
Data Model (Conceptual)¶
erDiagram
CONVERSATION ||--o{ AGENT_TRANSFER : "is handed off via (Feature 1)"
TRANSFER_REASON ||--o{ AGENT_TRANSFER : "justifies"
RECEIVING_AGENT ||--o{ AGENT_TRANSFER : "accepts"
COALITION_PARTNER ||--o{ EXTERNAL_AGENT : "supplies (Feature 2)"
EXTERNAL_AGENT ||--o{ AGENT_REGISTRATION : "is inserted into orchestration via"
AGENT_TEMPLATE ||--o{ AGENT_REGISTRATION : "governs templated insertion for (Feature 3)"
TENANT ||--o{ AGENT_REGISTRATION : "activates within"- Agent Transfer — the record of a Conversation handed from the Super Agent to a Receiving Agent for a stated Transfer Reason, optionally carrying a summary (Feature 1).
- Transfer Reason — the stated cause for a transfer (e.g. Private Conversation, Not Our Job, Explicit Ask).
- Receiving Agent — the agent a Conversation is transferred to; what it does next is its own judgment, based on the Transfer Reason and any summary carried.
- External Agent — a partner- or provider-built A2A agent that can be registered into Super Agent orchestration (Feature 2/3).
- Agent Registration — the record that makes an External Agent reachable within a given Tenant's conversations, created either manually (Feature 2) or from an Agent Template (Feature 3).
- Agent Template — a Novaworks-defined, Novaworks-vetted definition a customer can browse and activate against, used only for the Tenant Controller path (Feature 3).
- Coalition Partner — the partner or co-sell entity supplying an External Agent for manual insertion (Feature 2).
- Tenant — the customer instance an Agent Registration is activated within.
Table-Stakes & Differentiation¶
| Table-stakes capability | Bar set by | Where we cover it |
|---|---|---|
| Some form of third-party agent/app registration | Microsoft Copilot Studio's agent store, Salesforce AgentExchange, and the ServiceNow Store itself all have an established partner-registration model. | Feature 2 |
| Tenant-level control over which third-party integrations are enabled | Established app-marketplace pattern across the same platforms. | Feature 2 (Customer SN Administrator row above) |
Differentiation.
- Feature 1 proves a capability no generic agent marketplace or orchestration framework offers: the Super Agent recognizing a conversation should move to a dedicated agent — starting with a detected sensitivity/privacy case — and transferring it for a stated reason, with an optional summary the receiving agent decides how to act on.
- Insertion happens at the orchestration layer, not the portal — a registered agent (Feature 2/3) inherits the Super Agent's existing identity-resolution and conversation-ownership model rather than each partner building its own, unlike a typical "install a widget" marketplace entry point.
- The external-agent-insertion path deliberately proves itself manually first (Feature 2, update sets, partners only) before any templated self-service exists (Feature 3) — reusing the prove-manually-first pattern Feature 1 established.
- Feature 3's customer-facing browse/activate flow is still Novaworks-curated (Novaworks-defined templates, Novaworks-vetted agents) rather than an open listing — a deliberately narrower bar than a self-service app marketplace, by design at this stage.
UX & Interaction Design¶
Not yet available.
Open Questions¶
| # | Question | Blocks |
|---|---|---|
| 1 | What does the Novaworks-defined template for Feature 3 actually constrain (what an external agent can declare vs. what's fixed), and what does Novaworks' vetting process for a template-eligible agent look like? | Feature 3 scoping |
| 2 | Is "External data integration for Advisor" — named in the Business case as the other extension point in this same wave — scoped as its own Feature Set in specs-advisor, or intentionally tracked here even though Advisor is owned by that repo? |
Scope / repo boundary |
| 3 | No jbtd-coalition-of-the-willing/ job map exists yet for the underlying job ("a partner or customer wants an external agent reachable inside a customer's Novaworks experience," and separately, "a conversation needs to move to the right dedicated agent"). Per convention this should precede detailed Feature scoping — not blocking, but flagged. |
Feature-level scoping depth |
| 4 | The new "Coalition Partner / Co-sell Partner" persona named above hasn't been added to product/personas.md yet — that's a separate, explicit root edit once this Feature Set has PM sign-off, not something done silently here. |
Root persona file |
| 5 | No domain section exists yet in skills-product/naming-and-references.md for Superagent/Platform (table prefix, reference competitor set) — the Table-Stakes table above is inferred, not sourced. |
Table-Stakes accuracy |
| 6 | Given ServiceNow Ventures is a strategic investor, does an external-agent coalition/marketplace risk overlapping or competing with any agent-marketplace plans ServiceNow itself pursues (e.g. via the ServiceNow Store)? business-context.md flags this framing as load-bearing for Core HR (never compete with HRSD) but doesn't yet say how it applies to an agent-ecosystem play specifically. |
Positioning / GTM framing |
| 7 | Regulations/best-practices/rules partner sources are consumed by the Policy Advisor's policy engine, not by Super Agent orchestration directly — is that extension point in scope for a Feature Set in this repo at all, or does it belong entirely to specs-advisor? |
Scope / repo boundary |
| 8 | Policy/info provider resolution (e.g. a decision-rule prefix routing to a source other than the ServiceNow built-in KB) is agreed as a concept sketch only, with no real use case yet — worth naming as a future extension point, but not yet concrete enough for a Feature candidate. | Feature-set completeness |
For internal engineering review only. Not for external distribution.
Novaworks AI | Confidential