We Wrote 101 Use Cases Before We Wrote the Platform. Here's What That Bought Us.

The AI industry has a problem it will not name out loud: most of what is being sold is a solution in search of a problem. Walk any vendor floor and you will hear the same pitch twenty times — a model, a framework, a capability, a demo. Ask the follow-up question — which of my team's actual jobs does this do — and the room gets quiet. WalkMe's 2025 State of Digital Adoption, covered by Fortune in April 2026, found that 80% of enterprise workers are avoiding the AI tools their employers bought, and 54% actively bypassed them in the last thirty days. Transformation budgets rose 38% year over year to an average of $54.2 million per company — and most of it is underperforming.

The RAND Corporation and S&P Global have both published the same finding from different angles: more than 80% of AI proofs of concept never reach production. Goldman Sachs quantified the human cost: skilled AI users save 40–60 minutes per day, and unskilled users lose roughly the same amount of time fighting tools that were not shaped around their work. That is not a model quality problem. It is a product discovery problem. The vendor built a capability and then went looking for a job to attach it to.

We built our platform backwards. Before writing a single line of it, we wrote down 101 real business use cases — drawn from regulated industries, public-sector operations, engineering organizations, and enterprise IT — and engineered exactly the capabilities required to ship them. No more, no less. The features you will read about in this post exist because a specific use case demanded them. That is the inversion, and it is why workers who touch our platform recognize their job in it within the first five minutes.

fig. 1 · capability-first spins. business-case-first ships.

the 101 use cases that ran us

The catalog lives in the platform as a first-class artifact. Every capability in the platform was defended against it before it entered the roadmap. If a feature could not close a numbered use case, it did not get built. The list spans three groups, and every one of them puts different pressure on the platform.

Enterprise core (UC-001 through UC-051). Deep research agents, agentic flows, BI and AIOps, AI-assisted development, enterprise security, admin and governance. This is the bread-and-butter of internal IT and knowledge work.
Public-sector and regulated health (GOV-001 through GOV-030). Public health surveillance, hospital network operations, public-payer claims analytics, population health. Every one of these has audit, data-residency, and human-in-the-loop requirements that capability-first platforms simply do not have.
Engineering and ML operations (ENG-001 through ENG-020). Infrastructure as code, Kubernetes cluster management, CI/CD optimization, MLOps, data pipelines. These surface the extreme edges — long-running operations, tool composition, sandboxed execution.

We are transparent about the state of each one, because credibility matters more than marketing. 49 cases are built and demonstrable in the current release. 24 are partial — architecture and some pieces exist, but a custom connector is still required for full delivery. 28 are on the roadmap. When a customer reads the catalog and picks a scenario, they see exactly what they will get on day one and what we are shipping next. That is the opposite of a demo-driven sales motion.

fig. 2 · 49 live. 24 partial. 28 roadmap. published and tracked.

six use cases that shaped the platform

Below are six scenarios from the catalog, each one with the real-world friction that prompted it, the specific v0.6.5 capabilities that close it, the execution mode that owns it, and the outcome metric we track. None of these are marketing extrapolations — the problem text is the same text we write against when we prioritize engineering work.

UC-001 · Deep Research Agent

The friction. Analysts lose weeks gathering sources, cross-checking facts, and still ship reports with hallucinations buried inside. Executive decisions run on research that no one has time to verify end-to-end. This is the use case that forced us to build validation into the pipeline instead of bolting it on.

What closes it in v0.6.5. An 8-phase research pipeline with 4-layer validation — source credibility, cross-reference, hallucination detection, expert review — powered by the Web MCP, Milvus vector RAG for semantic grounding, and Flows for multi-step orchestration. Runs primarily in Chat Mode with handoff to Flows and Synth for ad-hoc tool creation. Outcome: 80% research time saved, zero misinformation risk because every claim is cited.

UC-011 · MCP Workshop

The friction. Integrating a new internal system used to mean waiting quarters for a vendor roadmap item. In the real world, the system you need is the one your vendor will never ship an adapter for — a bespoke claims database, a regional ERP, a ten-year-old mainframe gateway.

What closes it in v0.6.5. A full development environment for creating, testing, and deploying custom MCPs with hot-reload into production. Runs in Code Mode. Every new MCP lands alongside the 16 first-party connectors (AWS, Azure, Azure Cost, GCP, Kubernetes, Prometheus, Loki, Alertmanager, GitHub, Admin, Agent Architect, Code, Incident, Knowledge, Runbook, Web). Outcome: same-day integrations. The system requested Monday morning is in production Monday afternoon.

UC-025 · Log Analysis & Troubleshooting

The friction. SRE teams spend the first hour of every incident grep-ing through logs. The cognitive load of correlating traces across Loki, Prometheus, and Alertmanager consumes senior engineers while the business waits. Mean time to root cause is measured in coffee refills.

What closes it in v0.6.5. AI-powered log correlation and root-cause analysis across services, running on the Loki, Prometheus, Alertmanager, and Admin MCPs. Execution splits across Chat Mode (the incident-channel conversation), Flows (the automated correlation pipeline), Code Mode (for deep, scripted forensics), and Synth (for on-demand diagnostic tools the team has never needed before). The HITL approval gate keeps destructive remediation behind human sign-off. Outcome: faster MTTR — the root cause is already in the incident channel when humans arrive.

UC-042 · Data Loss Prevention

The friction. PII and infrastructure secrets can leak through a well-meaning AI prompt. Every enterprise legal team sees this risk the moment an AI product is proposed, and it is the single most common reason a POC gets blocked on the way to production.

What closes it in v0.6.5. The DLP Scanner ships with 50+ detection rules for credentials, personal data, and infrastructure secrets, running as a mandatory content-safety stage on every prompt and every tool output. It scans, redacts, or blocks based on policy. Runs across Chat Mode, Flows, and Code Mode. Pair it with the Immutable Audit Trail — every action hash-chained cryptographically — and regulated industries can finally answer the question that every auditor asks: show me what the AI did, prove it has not been edited. Outcome: real-time DLP on every message with compliance enforced before the model ever returns a response.

UC-028 · Security Incident Response

The friction. Threat response is a manual relay race across teams and tools. A suspicious login in one console, a container escape alert in another, a ticket queue in a third. Breach containment time is measured in days because coordination is measured in meetings.

What closes it in v0.6.5. Automated threat detection and SOAR-pattern response workflows, assembled in Flows with the Security MCP and the Incident MCP. The mandatory HITL approval gate sits on every destructive action — no quarantine, no account lockout, no firewall rule change executes without a named human approval, and every approval is signed into the audit trail. Runs across Chat, Flows, Code, and Synth. Outcome: minutes to contain, not days.

ENG-002 · Kubernetes Cluster Management

The friction. Debugging a broken cluster means twenty kubectl commands and a stack of browser tabs. The platform team hoards institutional knowledge because the tooling does not let anyone else in.

What closes it in v0.6.5. Natural-language management of Kubernetes clusters, deployments, and troubleshooting, powered by the Kubernetes MCP with the Smart Router picking gpt-5-1 for the complex reasoning paths. Runs across every mode — Chat for conversational ops, Flows for scheduled jobs, and Code Mode for scripted remediation and cluster-adjacent code work. Outcome: natural-language kubectl. Conversational incident response turns platform engineers back into force multipliers instead of human routing tables.

fig. 3 · four execution modes feeding one shared memory fabric.

why business-case-first beats capability-first

Every vendor in this market has roughly the same raw ingredients — frontier models, vector stores, a tool-calling protocol. The difference is how you arrive at the shape of the product. Capability-first builds a feature and hopes someone pays for it. Business-case-first builds a specific job-to-be-done and the feature emerges as a byproduct. The platforms look similar in a two-minute demo; they are unrecognizable at six months.

Users trust an AI that solves their actual job. The Goldman Sachs number — 40–60 minutes saved per day for skilled users — collapses to zero when the interface does not match the work. A business-case-first catalog forces the product team to see the job before they see the tool.
Real use cases surface real requirements. The Immutable Audit Trail, the mandatory HITL gate, the DLP Scanner, the OBO authentication architecture — none of these would exist on a capability-first roadmap. They exist because UC-042 demanded DLP, UC-028 demanded HITL sign-off on destructive actions, and GOV-series scenarios demanded cryptographic hash chaining. Capability-led products discover these requirements in a security review six weeks before launch.
101 use cases means the platform already knows your edge cases. When a prospect shows up with a scenario we have not shipped, it is usually a variant of one we have. The feature surface has been shaped to bend toward the long tail, not toward a happy-path demo.
Competitors ship "AI." We ship outcomes. The metric on every use-case card is a business outcome — 80% research time saved, minutes to contain, same-day integrations, 5x faster IaC. A capability ("we have RAG") is not a metric. An outcome is.

fig. 4 · spinning question marks vs. a completed equation.

what's actually shipping in v0.6.5

The current release is v0.6.5 "Lock Step", shipped on 2026-04-17. Every bullet below is from the release notes and is implemented in the current build and exercised in our own test and staging environments, not a roadmap item.

Codemode streams /v1/messages end-to-end with inline tool-use cards, tool_result events, and assistant text — claude.ai/code parity, delivered over our native streaming transport.
Smart Router picks gpt-5-1 without Opus-bias. Routing is a first-class concern: the right model for the task, proven via regression evidence captured on 2026-04-16. Unrecognized models now fail loud instead of silently downgrading to something cheaper.
Azure MCP hardened. Every long-running-operation .result() call is wrapped in asyncio.to_thread. Application Gateway returns on 201 Accepted. Front Door survives LRO flakes via verify-by-get. This is the kind of fix that only surfaces under sustained, long-running test workloads.
16 MCPs covering the full enterprise surface — AWS, Azure, Azure Cost, GCP, Kubernetes, Prometheus, Loki, Alertmanager, GitHub, Admin, Agent Architect, Code, Incident, Knowledge, Runbook, Web. Each one typed, each one audited.
Unified cross-mode memory. Chat, Code Mode, and Flows share one per-user context layer. The AI that knows you in Chat already knows you in Code Mode.
Mandatory HITL approval gate at the server, no bypass. The DISABLE_HITL_GATE escape hatch exists for CI and Playwright only — production traffic always passes the gate.
DLP Scanner with 50+ detection rules for credentials, personal data, and infrastructure secrets, with scan/redact/block actions.
Immutable Audit Trail with cryptographic hash chaining. Tamper-evident logs that hold up in compliance review.

"Lock Step" is a deliberate codename. Every component — platform, API, UI, MCP proxy, code manager, agent proxy — ships on the same version on the same day. No drift, no "which piece is on which release." The whole system moves together because the use cases demand it.

the gap widens every release

Imagine a competitor adopting our platform early. They could pick a use case they recognize — maybe log analysis, maybe DLP, maybe a deep research agent — and start there. As the platform matures release over release, they would be positioned to extend across all four execution modes. v0.6.5 gives them Smart Router routing, hardened Azure tooling, and a 16-MCP surface that extends same-day. The catalog now stands at 101 scenarios with 49 live, and every release closes two or three more.

The capability-first vendors are still pitching models. We are shipping outcomes against a numbered list. If you want to see the list, start with a scenario you recognize →. If you want to see how fast a real business case lands on your infrastructure, talk to us →. The gap widens every release, and this is the cheapest it will ever be to close it.