Project Argon: Designing an AI-Assisted Product Development Lifecycle, From Cursor Prototype to Board Presentation

Project Argon is about designing how an enterprise builds product with AI, from a Cursor-backed prototype to a cloud architecture the org could actually use.

My role

UX Workbench Lead & Co-Creator. I designed the agent architecture, built the skill pipeline, and led the UX contribution within a small pilot team reimagining how an enterprise software company develops product.

Timeline: Q2 2026 (ongoing)
Company: B2B SaaS, Cybersecurity & IT Management
Team size: 5 people

Context

I work at a large B2B SaaS company that builds software for managed service providers (MSPs). The product suite spans dozens of modules maintained by distributed engineering, product, UX, and research teams across multiple time zones.

A small pilot team, five of us total, set out to challenge the way the entire organization builds product. The team included our senior UX director who coordinated the initiative, a prototyper and widget builder, a data and agent architecture lead, a backend infrastructure engineer, and me leading the UX workbench and agent pipeline.

We had no dedicated budget, no formal program charter, and no organizational mandate. What we had was a shared frustration with the status quo and the conviction that AI agents could fix it, if we designed the system correctly.

The before: a fragmented process

Before Argon, the journey from "someone has a product idea" to "partners are paying to use it" was broken at nearly every seam:

• Opportunity discovery was manual and scattered. Product signals lived across analytics platforms, research repositories, CRM notes, sales call recordings, community forums, and support tickets. There was no unified way to surface, classify, or prioritize them. Teams relied on tribal knowledge and quarterly review cycles.

• Intake was inconsistent. Some teams wrote detailed briefs; others submitted a sentence in a backlog. PRDs varied wildly in structure, depth, and quality, causing misalignment before work even started.

• Redundant work was the norm. Without centralized component catalogs, teams frequently rebuilt the same UI patterns and widgets independently. Internal estimates put the cost of this duplication in the tens of millions annually.

• Handoffs were lossy. Research insights didn't reliably flow into PRDs. PRDs didn't reliably flow into design. Design didn't reliably flow into engineering specs. Each transition was a point of context loss and rework.

• Validation was reactive. Viability, feasibility, and usability assessments happened late, often after significant investment, rather than being built into the process from the start.

The result: slow cycle times, costly rework, and strategic misalignment across the product organization.

The vision: human-led, agent-accelerated

We conceived Argon as an end-to-end, AI-assisted product development process. Not a single tool or UI, but an organizational operating system for how the company develops product in an agentic world.

Our guiding principle: "Human-Led, Agent-Accelerated."

The idea: AI agents handle the repetitive, data-heavy lifting at every stage (scanning for opportunities, assembling intake packages, scoring readiness, generating PRD drafts) while humans retain full decision-making authority at every gate.

We organized the system into domain-specific workbenches (UX, PM, Engineering, Research), each owning their slice of the lifecycle but sharing a common architecture, skill format, and governance model.

The tool: Cursor as AI workbench

Our entire proof of concept was built using Cursor, the AI-powered IDE. Cursor served as both our development environment and our agent execution runtime during the POC phase.

Here's how it worked:

1. A lightweight React SPA served as the front-end, a workbench UI where users could browse agents, fill in skill forms, and trigger runs.
2. The SPA connected to a local bridge server running on the developer's machine.
3. The bridge wrote structured run requests to disk: full skill specs, user inputs, and any chained data from prior agents.
4. Cursor's agent and MCP (Model Context Protocol) integration picked up those requests, executed the skill against configured data sources, and wrote results back.
5. Server-Sent Events (SSE) let the UI poll for completion and display structured outputs in real time.
6. Optionally, a Cursor deeplink allowed a human to inspect or drive the run directly inside the IDE.

This architecture was intentionally scrappy, tied to a local machine and a specific IDE. But it let us iterate on agent behavior, skill definitions, and data source integrations at high speed with near-zero infrastructure cost. We went from concept to a working multi-agent pipeline in roughly two weeks.

What I built: the UX workbench

I designed and developed the UX Workbench, a modular system of six AI agents that transforms raw product signals into validated, design-ready artifacts. Each agent runs as a structured skill inside Cursor, with defined inputs, data sources, scoring logic, and output formats.

The agent pipeline

Beyond the agents

• PRD generation and wiki push. The pipeline can auto-generate structured PRDs from concept packages and push them directly to the team wiki for collaborative editing, covering 12 key sections based on our existing template.
• Discovery launcher. Scans existing PRDs for completeness gaps, generates enriched discovery packs by pulling insights from multiple data sources, and assigns a readiness score before design begins.
• Agent architecture map. I created the visual system map showing all agents, skills, rules, and data flows across workbenches. The shared mental model the entire pilot team worked from.
• Skill file standards. I defined the standardized .mdc / .md format for agent skill definitions, ensuring that any contributor, even from other disciplines, could write a skill file that the platform could orchestrate without custom integration.

From Cursor to cloud

Phase 1: local POC (Cursor)

Everything ran locally through Cursor. The bridge model was fast, flexible, and perfect for rapid iteration. I deployed the front-end to an internal GitLab Pages instance so the team could access the workbench UI without running Cursor themselves, though execution still required a local environment.

Phase 2: cloud architecture (AWS)

Our backend engineer re-architected the system onto AWS, replacing the local bridge with a serverless Backend-for-Frontend (BFF) pattern:

This eliminated the dependency on developer laptops and Cursor for execution, making Argon accessible to the broader organization.

Key design decisions

• Human-in-the-loop at every gate. Agents gather data and synthesize; humans make every decision to advance. No agent output moves to the next stage without human review.

• Skills over agents. We deliberately chose a model where cross-functional teams don't build agents. They contribute skill files, structured definitions of what needs to happen, what data is required, and what outputs are expected. The platform handles orchestration. This dramatically lowered the contribution barrier.

• Modular, non-sequential workbenches. Each discipline owns their workbench. Workbenches aren't a strict waterfall. They're domain-driven modules that can run in parallel or be skipped entirely depending on the project.

• Cursor-first, cloud-second. By building in Cursor first, we could iterate on agent behavior and skill logic daily. The cloud migration happened only after we'd validated the pipeline end-to-end, not before.

• Incremental proof of value. We never asked for permission to build Argon. We built it, demoed it, and let the results speak. Small projects first, then scale.

Impact and reception

• Built a working multi-agent pipeline from concept to demo in approximately two weeks, with a five-person team and no dedicated budget.
• First AI pilot ever presented to the company's board of directors. Executive feedback: it was the most engaging segment of the entire board meeting.
• Demoed to a cross-functional audience of 12+ leaders across Engineering, Product, and UX within the first month. An audience that organically grew from word of mouth.
• Established a cross-discipline governance council for ongoing prioritization, skill standards, and risk management across all workbenches.
• Co-authored a premortem analysis identifying three failure modes we actively designed against:
  1. "AI Junk Drawer". Ungoverned agent sprawl with inconsistent outputs
  2. "PM Productivity Trap". Losing the strategic layer by getting reduced to a task tool
  3. "Org Not Ready". Assuming organizational maturity that doesn't yet exist

What's next

• Broader organizational rollout with real production use cases
• Live API integrations for real-time opportunity scanning from analytics platforms
• Full UX-to-Engineering workbench handoff automation
• Partner-facing prototyping experiences at industry events

Reflection

Five people. No budget. No mandate. A shared frustration and an AI-powered IDE.

This project pushed me from traditional UX management into agentic system design, defining how humans and AI collaborate across an entire product lifecycle. I learned that building with Cursor as a first-class development and execution environment enables a kind of rapid prototyping for processes, not just products. We weren't just prototyping screens. We were prototyping how an organization thinks, prioritizes, and builds.

The technology was the easy part. The real design challenge was operationalizing it: aligning cross-functional mental models, building governance structures from scratch, and creating a shared language for how disciplines contribute to a system none of them fully own.

The most impactful UX work isn't always about interfaces. Sometimes it's about designing the systems and processes that shape how products get built.