Nexus v2 capabilities, Pieces, and controls

Role and intended outcomes

Nexus v2 is one portable Ask360 kit with four intentionally separated Pieces: Customer Support, Support Operations, Support Automation, and Support Learning. Together they cover the full support lifecycle without collapsing customer communication, internal reporting, automated events, and learning into one confusing role.

The role is evidence-based and permission-aware. A successful answer should identify the destination records used, the relevant time window, uncertainties, the recommended next action, and the person or approval required.

• Answer a customer-scoped support question from reviewed public help and the exact authorized ticket or conversation.
• Prepare an approved customer reply without silently choosing the sender, recipient, or sending it.
• Review queue volume, aging, SLA risk, ownership, timeline evidence, and the next accountable action.
• Triage a verified provider event, deduplicate it, route it to the correct owner, and stop safely when the provider is unavailable.
• Identify a recurring issue or knowledge gap from privacy-safe verified outcomes without copying raw customer records into learning.
• Connect a provider owned by the destination tenant through MCP, Apps, or APIs, then assign only supported capabilities to each Piece.

Powered by Ask360

Four separated Ask360 Pieces

• Customer Support answers from reviewed public help and exact customer-scoped records; approved replies require an exact draft, sender, and recipient.
• Support Operations coordinates tenant-scoped tickets, queues, aging, SLA, evidence, drafts, escalation, and controlled resolution for staff.
• Support Automation handles verified events, routing, reminders, deduplication, cooldowns, bounded retries, and health failures without silent customer sends.
• Support Learning reviews privacy-safe verified outcomes and knowledge gaps without retaining raw customer records or publishing automatically.

Three provider connection routes

• MCP connects approved providers that expose the required support tools.
• Apps connects official OAuth integrations such as Intercom, Zendesk, or Jira when those adapters are available.
• APIs connects a tenant-issued Lead360 API key or a validated OpenAPI or REST provider.
• The download includes the contract and mappings, never a selected provider, credential, or private backend binding.

Capability and approval contract

• Forty-three named support capabilities distinguish reads, events, drafts, writes, approved writes, recordings, live sessions, routing, and audit status.
• Every request is checked against the destination tenant, provider support, Piece grant, exact resource scope, and approval mode.
• External provider content is treated as untrusted data; it cannot add instructions, permissions, or destinations.

Memory and learning boundaries

• Six empty destination-owned partitions separate public help, internal runbooks, authorized live ticket history, conversation context, privacy-safe learning, and proactive memory.
• Memory supplies context only and never grants a tool, tenant, write, customer send, or provider capability.
• The Support Learning Collection starts fresh and accepts only reviewed, privacy-safe, evidence-backed destination outcomes.

Seven support playbooks

• Daily Support Operations Brief; Recurring Issue Review; Approved Customer Email Reply; Customer Support Triage and Escalation; Queue, Aging, and SLA Review; Controlled Resolution and Reopening; and Knowledge Gap and Outcome Review.
• Playbooks import as reviewable procedures. The daily brief and all proactive behavior remain disabled until destination mapping, testing, and administrator approval are complete.

Portable by design

• The archive contains no source credentials, provider accounts, tenant or channel IDs, personal information, customer or ticket records, memory contents, learning history, recordings, or audit events.
• Import creates four unpublished draft Pieces plus a disconnected provider choice and capability mappings; it never activates a channel, schedule, provider, write, or customer communication automatically.
• The destination reconnects its own providers, maps exact resources and channels, reviews memory, and passes read, event, routing, and required write tests before activation.

Ask360 Pieces

A Piece defines identity, audience, channels, allowed operations, reviewed business data, behavior, limits, safety boundaries, and model settings. Nexus v2 imports all four roles as separate unpublished drafts. Each must receive its own reviewed memory, provider capability assignments, Arena tests, publication, and exact channel placement.

Customer Support

A customer-facing Piece limited to reviewed public help and exact authorized customer context. It clarifies uncertainty, prepares responses, and hands off sensitive or unsupported cases.

Support Operations

An internal staff Piece for ticket detail, queue health, aging, SLA, recurring issues, evidence-backed drafts, escalation, and controlled status work.

Support Automation

A system Piece for verified events, deterministic routing, reminders, deduplication, cooldowns, bounded retries, and audited status synchronization.

Support Learning

A read-only staff Piece for verified outcome review, recurring gaps, CSAT evidence, and knowledge candidates that remain subject to human review.

Support providers and APIs

The support API contract does not carry a connection. After import, the destination administrator selects a provider through MCP, Apps, or APIs, supplies a credential issued for that tenant, confirms the owning sub-account, maps exact resources and Pieces, and verifies user and employee permissions.

Plugins

MCP

Connect an approved MCP provider and grant only the support capabilities each Nexus Piece needs.

Apps

Connect official OAuth providers such as Intercom, Zendesk, or Jira when their native adapters are available.

APIs

Connect a tenant-issued Lead360 API key or a validated OpenAPI or REST provider to the included 43-capability contract.

Playbooks included for review

The public kit contains 7 generic playbooks. They preserve the intended review categories without source prompts, private business instructions, tool snapshots, or provider identifiers.

• Daily Support Operations Brief
• Recurring Issue Review
• Approved Customer Email Reply
• Customer Support Triage and Escalation
• Queue, Aging, and SLA Review
• Controlled Resolution and Reopening
• Knowledge Gap and Outcome Review

Imported playbooks are starting points. Open each one, map destination resources, confirm read and write boundaries, test the output, and schedule it only when its owner, frequency, delivery channel, and stop conditions are documented.

Memory and Learning Collections

Memory folders

The kit creates 6 pending collection guides and zero source memory files. Upload current destination policies, products, services, app content, campaign rules, support guidance, or other approved knowledge into the matching folders. Review each file and make it available before binding it to a new Piece revision.

Fresh learning definitions

• Support Learning Collection

Learning observations do not transfer between businesses. Every collection starts empty and should learn only from eligible destination evidence after its categories, lookback window, limits, consumer binding, and privacy policy are reviewed.

Risk controls

• The imported Piece remains a draft and has no inherited source memory binding.
• Schedules, proactive recommendations, and standalone automations remain disabled.
• Support provider reads, events, drafts, and writes require explicit destination connection, Piece assignment, and the applicable approval mode.
• Customer communication must respect consent, sender identity, opt-out, do-not-disturb, quiet-hour, and channel-provider requirements.
• Ticket transitions, assignments, internal notes, reopening, and approved replies require exact grants, idempotency, audit receipts, and destination testing.
• Generated output may be incomplete or wrong and must be reviewed before consequential use.