c21 Design Brief — Inventory + Users / Devices

Audience: humans (Qpoint team + Mark Peterson) Companion doc: technical-plan.md — the AI-execution plan for building the wireframes Sources: Mark's notes (initial-prompt.md) + the 2026-08-31 Mark Peterson roadmap call (../market-analyst/data/processed/38075ead-4294-428f-bb58-13898dad7160.json, transcript + Avoma notes in ../market-analyst/data/raw/)

Mark Peterson is a fractional advisor scoping the dashboard product. This call is roadmap input, not customer discovery — but he independently validates the sequencing from CISO-board experience: "the journey starts at the inventory and discovery, observability… Regardless."

1. Why this cycle

The team aligned on inventory/visibility as the first unlock — before governance, before enforcement. The current qcontrol prototype has one blended "agent inventory" (directories of machines, harnesses, surface areas, MCP servers, tools & skills, with users mixed in) plus an AI-generated placeholder Teams & Users page. The call settled a restructure:

Inventory splits into two fundamental problems, two pages:

1. Inventory — the technology view. What agents/harnesses, providers, models, and surface are in use across the fleet, and how much of it we actually monitor.
2. Users / Devices — the people view. Who is using AI, on what devices, with what accounts, at what intensity — and where the sensor is (and isn't) deployed.

Fleet Overview becomes the story entry point: summary widgets that click through into each page.

2. Decisions settled on the call

These are agreed; wireframes should treat them as constraints, not open questions.

1. Split the pages. Agent inventory and personnel become two distinct dashboards. (Tyler, ~56:00, all agreed)
2. Machines leave Inventory and move to Users / Devices. Inventory becomes all about the agents, harnesses, surface, activity, trends.
3. Users become a filter in Inventory, not a dimension of it. Drill path: Users / Devices → pick Tyler → click Claude → land in Inventory double-filtered (user=Tyler, agent=Claude), with a link back. The inverse holds on the other page: agent attributes are filters there.
4. Consolidate around companies/providers, not just agent instances. Three levels: vendor/company (Anthropic) → technology (Claude Code, Claude Desktop) → instances (Tyler's Claude Code). One-to-many, rolled up. Provider data already exists in the underlying model.
5. Monitored vs unmonitored (detected-only) is first-class — for agents on Inventory, and for people/devices coverage on Users / Devices.
6. Accounts & licensing surface in Inventory. We see the account referenced on every inference call, so we can show enterprise vs personal account usage per agent/user. This feeds the standout enforcement use case (see §5).
7. Sessions detach from Inventory. A session belongs to a user: Users / Devices → user → their sessions. Inventory stays a high-level rollup.
8. Fleet Overview = summary widgets + click-through. e.g. an agent-visibility widget → Inventory; a team-deployment-status widget → Users / Devices; aggregated token usage per model per time period.
9. Relationships must survive the split. Workstation ↔ identity ↔ agent linkage is the compliance/accountability backbone: "we need to maintain the relationships… that's the important part… for compliance and accountability." The two pages are two lenses on one graph, not two silos.
10. Local vs centralized mode degrades gracefully. In local (single-machine) mode, Users/Devices and machines drop away entirely — you just see your own agents, harnesses, surface, trends.

3. Page: Inventory

User stories (verbatim-adjacent from the call):

• "I wanna know what agents and harnesses are being used fleet-wide" — including surprises ("are people running Hermes somewhere?")
• "How many of those are we actually monitoring versus just detected?"
• "What models are we actually using?" — even within one vendor (Fable vs Opus)
• "What licensing do we have for each — personal or enterprise account?"
• What's the tool-calling surface: repos, MCP servers, tools, plugins, skills, external services
• Usage trends across the fleet — model mix shifting over time (Anthropic → OpenAI → Grok…)

What the page should make obvious:

• Unique agents/harnesses; monitored vs unmonitored
• Providers/companies rollup (Anthropic, OpenAI, xAI…) with technology → instance drill-down
• Models in use, with usage trends over time (tokens/dollars toggle)
• Accounts in use per provider — enterprise vs personal flagged; unknown account IDs stand out ("the ops person knows what the corporate account is; other account IDs alone is pretty good signal")
• Surface directories: MCP servers, tools, plugins, skills, repos, external services
• User available only as a filter (arrives pre-applied via drill-through)

Explicitly removed: machines, per-user listings, sessions, the experimental risk posturing ("we don't have these flushed out, we should probably remove them from a starting point").

4. Page: Users / Devices

User stories:

• "What's the deployment status of Qpoint sensor across my user base?" — Mark P's own phrasing, the #1 story
• "Who has the sensor installed, and who doesn't — and that should be actionable" ("oh crap, Alexis — investigate that")
• Coverage needs a denominator: integrate a definitive source of truth for people and workstations (identity management + MDM) rather than recreating it. IT ops will want to connect their existing systems and pull the full workstation/endpoint list.
• Per user (or team): which agents/harnesses and providers they use, corporate vs personal account, tokens/dollars (toggleable — "both are just ways of gauging the flow"), intensity of usage, and an LLM-derived summary of what they're doing ("Rob uses 3 harnesses primarily for document creation and workflow; Kamal uses 3 harnesses all for code generation in the following repos")
• For engineers specifically: the concrete tool-calling surface (MCP servers hit, repos touched) alongside the AI summary — "we have more specific actual data in our database about the tool calls"
• Sessions live here: user → device → agent → sessions, flowing down
• Management-facing angle: who's using AI heavily vs barely ("someone wants to know who's not using AI very much… it's still interesting to management")

Structure: user/device is the row; drill-down reveals endpoints → agents on them; cross-links jump to Inventory pre-filtered.

5. The standout use case (thread through both pages)

Enterprise vs personal account separation → blocking personal accounts. Mark P's strongest reaction on the call ("That's such a great use case"): "None of our IP is ever going to a personal ChatGPT account, which doesn't have the same data protections… because we have an enterprise agreement with them."

For this cycle it is an observability story, not an enforcement UI: show account/licensing visibility clearly enough that the block-personal-accounts control is the obvious next step. Observation mode before enforcement — "super important for the journey."

6. Open questions (wireframes may explore, must not silently decide)

• Terminology: agent vs harness. Used interchangeably today; call leaned "AI Agents" (or "AI agents / harnesses") for now. Sensor vs monitor for the endpoint software — "sensor" is winning.
• Name for the people page. "Users / Devices", "Teams & Users", "Personnel" all floated. Working title: Users / Devices.
• Is agents the right starting point, or workstations/endpoints? Mark P raised it; the split answers it partially (both are entry points), but Fleet Overview widget hierarchy should take a position.
• "Fleet" terminology — does fleet mean where the sensor is installed, or the whole org? Affects coverage framing.
• Identity attribution edges: will it always be obvious whose behalf an agent acts on? Wireframes should show an unattributed/unknown-identity state, not assume perfect mapping.

7. Secondary ideas captured (not this cycle's pages, worth parking)

• Gamified adoption checklist as an IT-ops dashboard: control plane installed → in MDM → deployed to workstations → observing → (later) enforcing. Doubles as a customer-success stickiness signal ("where do companies get stuck"). Could appear as a Fleet Overview widget in a later iteration.
• Tier gating (freemium up to N endpoints; compliance frameworks/enforcement in paid tiers) — pricing framing, not UI for this cycle.
• Docs generated from walkthrough transcripts — ops idea, out of scope.
• Windows support is a deployment blocker for the advisor persona (macOS-only today; Kamal on the installer/tapping) — context, not a design task.

8. Personas

• IT ops (primary first target): deploys the sensor, owns coverage, connects MDM/identity. Users / Devices is their home page.
• Security / compliance: needs the inventory before any governance conversation; cares about accounts/licensing, unknown agents, relationships for accountability.
• End user / developer: the monitored; appears in the data, not the audience of these pages.

9. Success criteria

• Two wireframed pages that a viewer can walk without narration and correctly answer: what AI is in use, how much of it do we see, who's using what, and where isn't the sensor deployed?
• The company→technology→instance rollup reads at a glance; personal accounts are visually unmissable.
• Cross-filter drill paths (user → filtered Inventory; agent → filtered Users / Devices) are clickable in the prototype.
• Coverage is framed against an external source of truth (identity/MDM integration state visible), not just what the sensor happens to see.
• The pages feed directly into the product spec Mark Peterson is drafting and the Thursday follow-up review.