Stages 2–4 Demo Roadmap

Updated 9 September 2026

Current Update · 9 September 2026: The user authorized tenant-wide AI. Release 6b1875f deploys the removal of per-ticket AI allowlists/decisions. Capture exclusions, history access, knowledge permissions, feature/provider checks, publication, stop state and the existing 100-request/USD3 budget remain in force. Earlier release observations below describe their original narrower test scope.

Objective

Show how company conversations become reviewed knowledge, visible processes and bounded specialist agents. Tenant employees use the Teams support flow. 99 Venture owns discovery, knowledge publication, process validation, baseline personalities, model configuration, evaluation and agent release in Administration.

This is an authorized, portable fictional demonstration. It does not claim real business improvement, production connector readiness or fine-tuning. The source vision explicitly defers automatic knowledge publication and model training on customer data at Stage 2.

Delivered Scope

Slice	Build	Acceptance
Control Boundary	Central knowledge management; tenant support can use approved answers and provide case feedback.	Server rejects management writes from Teams and non-platform administrators.
Stage 2: Discovery	Import a versioned fictional source pack; select allowed sources; extract answers, decisions, exceptions and repeated patterns; review candidates.	Stable IDs prevent duplicate imports. Every finding cites source evidence. Approval, edits, rejection and withdrawal are recorded.
Stage 3: Visualization	Evidence-to-process map, responsibility lanes, process draft/approval and comparison with observed runs. Interactive 2D and Three.js views use one saved graph.	Clicking a node opens its evidence; recorded runs replay in both views. Human/agent/knowledge/tool nodes are distinct. Export and restart preserve history.
Stage 4: AI Workforce	Two friendly specialist personas, a Copilot Studio-inspired builder, preview, evaluation, monitoring, publishing and stop control.	Published versions combine baseline personality, approved workspace knowledge and the current request. Unknown or prohibited actions escalate; humans control customer sends.
Delivery	Repeatable demo setup, live throwaway messaging rehearsal, guides/screenshots and bookkeeping exports.	Tests pass, no unrelated resources change, releases are committed, and the same pack can be installed in a client-owned instance.

Demo Narrative

Use 99 Events Demo, an explicitly fictional event-support company. Three workflows cover registration/check-in, equipment/badge printing and connectivity. Sources include repeated enquiries, resolved exceptions, an outdated contradictory policy and a blocked source. The demonstration shows why some material becomes a candidate and why other material does not.

Two baseline personalities have separate strengths: a welcoming service concierge and a calm technical specialist. Both are presented as configured agents in the support interface and are instructed to admit unknowns and preserve customer commitments. Personality cannot override knowledge permissions, tool boundaries or escalation rules.

The builder follows the supplied reference: Build, Preview, Evaluate and Monitor, with instructions in the main editor and model, knowledge, tools controls alongside. The 2D map is the operational view. The 3D view is an interactive presentation of the same evidence and run history, with selection, focus, replay and reduced-motion/2D fallback.

Pipeline and Records

Import → Source Permission → Extraction → Pattern Candidate → Human Review → Approved Knowledge/Process → Published Agent Version → Support Request → Knowledge and Read-Only Tool Use → Reply Draft or Escalation → Human Send/Takeover.

Persist source IDs/revisions, permissions, run IDs, candidates, decisions, process versions, persona/publication versions, tool inputs/results, model metadata, usage, errors and concise evidence-based explanations. Visual traces show observable processing and decision summaries, not private model chain-of-thought. Drafts and inferred process edges are labeled until an administrator approves them.

Implementation Boundaries

Reuse Node, SQLite, existing authentication and durable request patterns. Add a dedicated Studio database for the fictional corpus and run ledger; do not silently ingest the existing support database or real tenant documents.
One bounded discovery batch, three workflows, two personas and two read-only fictional tools. No autonomous purchases, account changes, refunds or bookings.
Teams may request a grounded support draft and explicitly send it through the existing ownership/delivery checks. No automatic send or ambiguous-send replay.
Graph connections remain a documented, disabled connection boundary. The first demo imports portable Teams-style records directly, avoiding new tenant-wide permissions or dependency on existing SharePoint/OneDrive content.
Use a small maintained Three.js distribution only for the requested 3D renderer; keep the normal 2D interface accessible without WebGL. Avoid a general workflow engine, vector database, autonomous multi-agent framework or cloud migration here.
Fictional tools and deterministic fallback runs must be visibly labeled. Real model executions must be distinguishable in the ledger and screenshots.

Model Test Envelope

The user authorized the supplied OpenRouter account. A dedicated key has a verified US$3 spending limit. Keep it server-side in ignored private configuration. Use at most 100 requests, bounded input/output and a durable run budget. Reserve before calling; uncertain requests are not automatically repeated. Stop at either cap. The current authorization enables AI across the demonstration tenant through its central switch. There is no case-ID allowlist or per-ticket AI grant. Capture and history access remain enforced, and this does not authorize importing unrelated tenant files or adding Graph permissions. Use fictional content for rehearsals.

OpenRouter is a demo transport, not an Azure production choice. Provider/model/data handling and production costs require their own later decision. API key limits are supported by OpenRouter's key API.

Release Order

Commit this roadmap and central ownership convention.
Ship discovery data, pipeline, permission boundary and candidate review.
Ship saved process graphs, 2D inspection and the Three.js presentation.
Ship the builder, published personas, evaluation, bounded support drafting and stop controls.
Run local fault/authorization checks and a throwaway live channel rehearsal.
Refresh staff/admin/demo guides and screenshots; package portable evidence; deploy only the isolated existing service with a consistent rollback.

Verified Release — 8 September 2026

Release 6688067 is deployed on the isolated pilot service. The local application suite has 52 passing tests. Real OpenRouter discovery/reply requests are verified, and a real Ari draft generated through Teams was explicitly sent and confirmed visible in the designated WhatsApp Web test chat. The tester sent “Agent reply received” as a follow-up. No unrelated tenant data was used for this model exercise.

This establishes the deployed technical flow, including its human send step. The portable corpus, catalogue and booking records remain fictional. Simulated scenario results are distinct from real provider execution and neither establishes production quality. See Verification Evidence for the boundary.

Real Acceptance Beyond This Demo

Stage 2 needs named knowledge owners, acceptable review effort, useful reuse and clear privacy boundaries. Stage 3 needs process suggestions accurate enough to help real discovery. Stage 4 needs quality, trust and safe escalation in the selected role. The PDF supplies qualitative gates for these stages, not numerical targets. Fictional records demonstrate mechanics; they cannot prove those business outcomes.