Skip to content

Explanation

The reference architecture of an AI-native Product Development Lifecycle: a data/context foundation, a knowledge-and-artifact platform above it, a governed AI agent embedded in each lifecycle phase, and execution tools wired end-to-end through explicit gates. The layering is inferred from converging disclosures — principally Freshworks — and then mapped against the public productizations (GitHub Spec Kit, AWS Kiro) that package the same shape for everyone else.

Evidence Strata

  • [F] Freshworks-reported from the flagship disclosure: the episode writeup, the full video, and the author's deck. Unauditable single-vendor narrative.
  • [P] Publicly reproducible: Spec Kit repository/docs (read directly from the repo, 1.0.11), Kiro docs (cross-checked against launch and GA press coverage).
  • [A] Our analytical extension. Internal implementation details the source does not disclose are marked "not disclosed" (checked against the writeup, video listing and deck on 2026-09-27). External career/financial facts are cross-verified in index sources.

Reference Architecture

The four layers and the governed phase agent, with real component names from the Freshworks case where they are known:

flowchart TB
    subgraph DF["Layer 0: Data-First Foundation"]
        direction LR
        DS["Agent-Parseable<br/>Design System"]
        CS["Explicit Written<br/>Standards/Rules"]
        REPO["Single Source-of-Truth<br/>Repository"]
        CONST["Project Constitution<br/>(governing principles)"]
    end

    subgraph PLAT["Layer 1: Knowledge & Artifact Platform"]
        direction LR
        KH["Knowledge Hub<br/>product graph + dependencies"]
        CH["Context Hub<br/>state threaded between phases"]
        AR["Artifact Library<br/>skills / rules / commands / templates"]
    end

    subgraph PDLC["Layer 2: Phase-Gated Lifecycle"]
        direction LR
        P1["Requirements"] --> P2["Clarify"] --> P3["Plan / PRD"] --> P4["Design"] --> P5["Prototype"] --> P6["QA / Evals"] --> REL["Release Train"]
    end

    AG["Governed Phase Agent<br/>one per phase"]

    subgraph TOOLS["Layer 3: Execution Tools (swappable)"]
        direction LR
        ED["Agentic IDE / CLI<br/>(Cursor, Kiro, Claude Code ...)"]
        UI["Prototyping Surface<br/>(for example, Figma Make)"]
        WH["Grounding Warehouse<br/>(for example, Databricks 'Bel')"]
    end

    DF --> PLAT
    PLAT --> PDLC
    TOOLS --> PDLC
    AG -.->|"every phase"| P1
    AG -.-> P3
    AG -.-> P6

    classDef foundation fill:#e8f0fe,stroke:#1a73e8,color:#174ea6
    classDef platform fill:#fef7e0,stroke:#f9ab00,color:#7c5000
    classDef lifecycle fill:#e6f4ea,stroke:#188038,color:#0d652d
    classDef tooling fill:#f3e8fd,stroke:#a142f4,color:#6a1da8
    classDef gov fill:#fce8e6,stroke:#d93025,color:#a50e0e

    class DS,CS,REPO,CONST foundation
    class KH,CH,AR platform
    class P1,P2,P3,P4,P5,P6,REL lifecycle
    class ED,UI,WH tooling
    class AG gov

The dependency direction is the doctrine's core claim [F]: teams fail when they invert it ("open Cursor, start prompting") because Layer 2 without Layers 0-1 has nothing trustworthy to stand on — at Freshworks' stated 300M-end-user scale, hallucination tolerance is zero.

Instance Mapping

Same roles, three vocabularies:

Pattern Role Freshworks instance [F] Spec Kit analogue [P] AWS Kiro analogue [P]
Governing principles Prism knowledge hub + written coding standards /speckit.constitution -> constitution-template.md Reviewed requirement documents
Requirements artifact Idea brief -> PRD (phase 1-N) /speckit.specify -> spec-template.md requirements.md in EARS notation
Interrogation gate Agent asks persona/drill-down/success questions before building /speckit.clarify (recommended before plan) Requirement review before design
Context between phases Prism context hub .specify/ artifacts + agent file hand-off Spec files as contract across phases
Consistency check CPO Check (human persona gate) /speckit.analyze read-only cross-artifact analysis (after tasks) Design review vs requirements
Quality checklist Evals phase (mechanism not disclosed in the source) /speckit.checklist — "unit tests for English" Acceptance criteria embedded per story
Execution Prototype -> QA inside 12-phase run /speckit.implement, then /speckit.converge until Converged Task execution + agent hooks. Property-based tests check code against the spec (since GA, 2025-11)
Grounding data Bel Databricks lake, agent-written SQL shown in-PRD Nothing prescribed — bring your own [gap] Existing codebase as design grounding

Reading The Gaps

Two asymmetries are analytically load-bearing. First, grounding ([Bel]-style warehouse access) has no analogue in the open tooling yet — anyone adopting Spec Kit must build that integration themselves. Second, human authority gates (CPO Check) exist in the enterprise narrative but only as culture in the mandates — the tooling encodes consistency checks, not accountability.

Spec-Driven Instantiation [P]

Spec Kit (1.0.11, 2026-09-24) turns the lifecycle into a chain of artifacts. Its commands install as skills or slash commands into any of its 40 named agent integrations (plus a generic one). The canonical order from the command reference is shown below. Dashed boxes are optional quality gates, and the converge loop was added before 1.0.

flowchart LR
    INIT["specify init<br/>--integration claude"] --> CON["speckit.constitution<br/>principles"]
    CON --> SPEC["speckit.specify<br/>what and why"]
    SPEC --> CLA["speckit.clarify<br/>max 5 questions"]
    CLA --> PLAN["speckit.plan<br/>stack and architecture"]
    PLAN --> CHK["speckit.checklist<br/>requirements tests"]
    CHK --> TASKS["speckit.tasks<br/>tasks.md"]
    TASKS --> ANA["speckit.analyze<br/>read-only consistency"]
    ANA --> IMP["speckit.implement"]
    IMP --> CONV{"speckit.converge"}
    CONV -->|"tasks appended"| IMP
    CONV -->|"Converged"| PR["Review / PR"]
    ANA -.->|"issues found"| SPEC

    classDef cmd fill:#e6f4ea,stroke:#188038,color:#0d652d
    classDef gate fill:#fef7e0,stroke:#f9ab00,color:#7c5000,stroke-dasharray: 4 3
    class CON,SPEC,PLAN,TASKS,IMP,CONV cmd
    class CLA,CHK,ANA gate

Two changes in the last year matter for the pattern. First, Spec Kit grew from one process into three first-party ones: SDD in core, plus opt-in bug (assess -> fix -> test) and assess (intake -> research -> define -> shape -> decide) extensions. The assess process is the closest open-source equivalent to Freshworks' idea-brief phases, because it ends in a documented go / needs-clarification / kill decision before any spec exists. Second, the checklist became an explicit human gate. Custom checklists are "reviewer-owned", and /speckit.implement reads their checkbox state but must not tick items itself. This is the kind of human authorisation the "CPO check" provides.

Kiro reaches the same three documents with more formalism. Acceptance criteria are written in EARS (Easy Approach to Requirements Syntax), for example: WHEN usage drops 20% week-over-week THE SYSTEM SHALL list the affected accounts ranked by MRR. The fixed syntax makes each criterion something an agent can test, not just read. Since GA (2025-11-17) Kiro also derives property-based tests from the spec, so "does the code match the requirements?" becomes an automated check. The spec moves through these states:

stateDiagram-v2
    [*] --> Requirements: Requirements-First feature spec
    [*] --> Design: Design-First feature spec
    Requirements --> Design: requirements.md approved
    Design --> Requirements: derive requirements (Design-First)
    Design --> Tasks: design.md approved
    Tasks --> Executing: run tasks from tasks.md
    Executing --> Verified: property-based tests pass
    Executing --> Tasks: failures or spec change
    Verified --> [*]
    note right of Requirements
        Bugfix specs use the same three phases,
        recording root cause and behaviour to preserve.
        Quick spec skips the approval gates.
    end note

See reference for Kiro versions and pricing, and the Spec Kit command table.

Case Study: Freshworks (flagship disclosure)

The deepest single narrative available. All details vendor-narrated.

Operating Model (Flagship Case: Freshworks)

Actor Discovered Role Source
Builder (any of PM / designer / engineer) Invokes /fw-innit, answers agent questions, owns outcome incl. money [F] Episode
Phase agents Governed AI worker embedded in each PDLC phase [F] Episode
Prism platform team Maintains knowledge hub, context hub, artifact library Not disclosed: the source names the hubs but not who owns them
CPO check gate Draft-quality review persona institutionalized as pipeline step [F] Episode
Evals phase Final automated evaluation gate before release train [F] Episode

Cadence target after transformation: features ride a 2-week release train (was 6 months) [F].

Layer 0 Foundation [F]

Component Role Failure mode it prevents
Agent-parseable design system Tokens/components machine-readable. Feeds Figma Make prompts Generators inventing or silently skipping components (observed live: Figma Make skipped some — declared residual-human territory)
Written coding standards Ingestible rules instead of tribal norms Style drift across concurrent sessions
Single monorepo One canonical codebase Forked realities between docs, prototypes, shipped code

Prism Platform [F]

Three declared parts — knowledge hub (product + dependencies), context hub (per-feature state threaded across phases), and the AI builder artifacts library (skills/rules/commands/agents encoding how Freshworks builds):

flowchart LR
    KB["Knowledge Hub"] -->|"grounding"| RUN["Phase Agents at runtime"]
    CTX["Context Hub"] <-->|"read/write phase state"| RUN
    ART["Artifact Library"] --> RUN
    RUN --> HARN["12-Phase Harness Run"]

    classDef store fill:#fff4ce,stroke:#f9ab00,color:#7c5000
    classDef runtime fill:#e6f4ea,stroke:#188038,color:#0d652d
    class KB,CTX,ART store
    class RUN,HARN runtime

Harness Flow [F]

Entry via Cursor slash command /fw-innit (collects business unit, Epic ID, feature team), deliberately model-agnostic — demoed on Grok ("Nothing takes more than 10-15 seconds" and "No Claude Code or Codex. Just Cursor + any model"):

sequenceDiagram
    autonumber
    actor PM as Builder (Product Builder)
    participant CUR as Cursor + /fw-innit harness
    participant PH as Phase Agent
    participant PZ as Prism (context hub)
    participant BEL as Bel (Databricks)
    participant CP as CPO Check gate
    participant FIG as Figma Make
    participant EV as Evals Phase

    PM->>CUR: "/fw-innit"
    CUR->>PM: ask business unit, Epic ID, feature team
    CUR->>PH: launch up to 12 phases (idea brief ... prototyping, QA)
    PH->>PM: clarifying questions a good PM would ask
    PM-->>PH: answers in plain English
    PH->>PZ: pull product knowledge + prior phase context
    PZ-->>PH: grounded facts
    PH->>BEL: write SQL against usage telemetry
    BEL-->>PH: quantitative results (demo: 4,358 active ITSM accounts)
    PH->>PH: assemble PRD, evidence shown inline
    PH->>CP: draft submission
    CP->>CP: review the way Srini would (gate named after him)
    CP->>FIG: approved PRD
    FIG->>FIG: prototype against parseable design system
    FIG-->>EV: working prototype
    EV->>CUR: pass/fail feeds biweekly release train

Reported outcomes and their caveats live in reference. Context caveats from the same period [x]: in May 2026 Freshworks announced a ~500-person (~11%) restructuring from a base of ~4,500 employees, leaving roughly 4,000. The CEO said at the time that "more than half of our code is now generated through AI tools". The share price fell by roughly a third during 2026. The efficiency story and the cost-cutting share a timeline, so read them together (timeline).

Not disclosed in the source (checked 2026-09-27): the names and purposes of the 12 phases beyond the endpoints, the evals-suite composition, and the per-run cost or token envelope. Freshworks has not said publicly whether the ratio targets survived the move to a merged CPTO role (Ryan Manning, announced 2026-07-28, started 2026-08-10).

Structural Risks (class-level)

Summarized here, threat-modeled properly in the threat model:

  1. Artifact rot — stale skills/rules degrade every downstream phase simultaneously, unlike document rot which degrades only readers.
  2. Silent generator omission — demonstrated by the disclosed Figma Make skips. Mitigations must enumerate from ground truth (design system), not prompts.
  3. Gate keying to individuals — "CPO check" encodes one executive's review style, and that executive left Freshworks after the disclosure was recorded (departure announced 2026-07-28).
  4. Mandate/process decoupling — orgs can order substitution (mandates) without shipping machinery. Velocity claims then rest on unstructured usage.

Identity And Access Flow

Identifiable actors and channels, as reconstructed from the disclosure:

flowchart LR
    B["Builder<br/>PM/Designer/Engineer"] -->|"editor account"| CUR["Cursor"]
    CUR -->|"harness runtime,<br/>model API keys<br/>(custody not disclosed)"| M["Any-model endpoint<br/>(demoed: Grok)"]
    PH["Phase Agents"] -->|"reads"| MONO["Monorepo<br/>(source of truth)"]
    PH -->|"generated SQL"| BEL["Bel<br/>Databricks usage lake<br/>(75k customers' telemetry)"]
    PRISM["Prism hubs"] -->|"context/rules"| PH
    GATE["CPO Check gate<br/>(human)"] -->|"approves"| FIG["Figma Make"]
    FIG -->|"prototype"| EV["Evals"]

    classDef actor fill:#e8f0fe,stroke:#1a73e8,color:#174ea6
    classDef store fill:#fef7e0,stroke:#f9ab00,color:#7c5000
    classDef flow fill:#f3e8fd,stroke:#a142f4,color:#6a1da8
    classDef control fill:#fce8e6,stroke:#d93025,color:#a50e0e
    class B,GATE actor
    class MONO,BEL,PRISM store
    class CUR,M,PH,FIG,EV flow
    class GATE control
Edge Authentication basis Disclosed?
Builder → Cursor Personal/workspace editor account Implied [F]
Cursor → model APIs Managed keys. Key custody and per-team budgets not disclosed No
Agents → monorepo Presumably repo ACLs; not disclosed No
Agents → Bel Undisclosed service credential. Principle-of-least-scope strongly implied by "you can't afford a hallucination" framing Scope/RBAC detail not disclosed
Human gate → Figma Make Enterprise SSO typical; not disclosed No

Governance As Disclosed

Four concrete control surfaces appear in the narrative, despite light detail:

  1. "Governed AI agent" inside each phase — the writeup's exact term. The source does not describe the mechanism. Plausible surfaces include the rules of the artifact library (explicit written coding standards feeding rule files) and Prism's context hub enforcing phase-appropriate visibility.
  2. Requirements interrogation gate — the agent pauses generation to ask PM-grade questions. Functions as an input-validation control: underspecified requests get bounced back upstream instead of surfacing later as defects.
  3. CPO Check — an executive-review persona encoded as a mandatory pipeline step before prototypes ship. Functionally human-in-the-loop authorization over PRD-level decisions.
  4. Evals phase — terminal automated gate gating the release train itself. The one control that scales without reviewer hours.

Known limits admitted in-source: the prototyping step silently skipped design-system components — caught by humans, positioned explicitly as the residual manual layer ("those are the places where humans still have a role").

Access Control Observations

  • Warehouse blast radius is the crown-jewel question. Agent-authored SQL ran against a lake spanning usage telemetry from all 75,000 customers in a demo context. Whether that read path is row-scoped per analyst/business-unit in production is not disclosed in the source. The replication playbook recommends role-scoped, read-only grants regardless (see operations step 7).
  • Single-repo source of truth concentrates write access. Convenient for agents, hazardous without branch protection + signed-commit hygiene [A].
  • Artifact library is an implicit privilege store. Whoever edits rules/commands shapes agent behavior org-wide. Write access there deserves review rigor normally reserved for infrastructure code [A].

Threat Model

[A] Analytical model for this harness class, calibrated to the disclosed failures. (Residual risks acknowledged even under best-case versions of the undisclosed items.)

ID Threat Vector Impact Disclosed Mitigations Recommended Additions
T1 Prompt injection via ingested data Malicious/negligent strings inside Bel telemetry (customer-authored tickets!) enter agent context and steer SQL/PRD outputs Contaminated requirements reasoning. Silent policy violation in generated artifacts Requirements interrogation. Evals. Human gate (partial, indirect) Treat warehouse-derived text as untrusted input: scrub/quarantine fields. Constrain SQL via allow-listed views. Assert-run contracts in eval suites
T2 Over-broad data reachability Agent-written SQL joins across tenants/product lines by accident Cross-customer data bleed into an internal document, then into prototypes None stated Per-business-unit read roles. Column-level masking on identifying fields. Query logging with anomaly alerts
T3 Artifact poisoning / rot Stale or maliciously edited rule/skill files steer every downstream phase simultaneously Org-wide behavior corruption — a single bad rules edit outlives audits of any one generated artifact Explicit written standards (provenance clarity only) Versioned artifact library with mandatory reviewed merges. Periodic attestation that each active artifact maps to an owner and rationale
T4 Silent generator omission Design-system components skipped during prototyping Defective UX gets to evals unchecked if eval coverage mirrors the same blind spot Humans catch residual errors (stated) Independent component-parity diff between prototype and token registry. Eval assertions enumerated from the design system, not from the prompt
T5 Source-code and strategy egress Model-agnostic harness ships monorepo context to whichever external model endpoint is fastest Proprietary roadmap/code transits third-party infrastructure by default Vendor choice autonomy treated as feature, not control Provider agreements aligned with enterprise posture. Consider Zero Data Retention arrangements for training-side retention. Classify which repo subtrees can ever leave the boundary
T6 Gate-keying to individuals "CPO check" encodes one executive's judgment patterns Leadership churn weakens authorization without anything formally changing None stated Role-owned written gate criteria. Quarterly calibration sessions replacing single-reviewer dependence

Encryption And Data Handling

  • Transport encryption rests with vendors (Cursor workspace sync, model endpoints, Figma Make, Databricks) — industry-standard TLS presumed, vendor attestations not examined in this note [A].
  • Field-level protection inside Bel for customer-identifying telemetry is not disclosed in the source. Do not assume it exists in any replication plan.
  • Prompt/context payloads — often overlooked — mirror the sensitivity of whatever they quote: assume prompts replay privileged snippets unless the controls described earlier in this note exist [A].

Residual Risk Statement

Even granting every undisclosed control its best plausible form, three residuals follow from disclosed design choices themselves: (1) the deliberate model-vendor agnosticism widens the egress surface permanently (T5). (2) Single-pass automated evals cannot certify what their own coverage language does not enumerate (T4). (3) Human-gate effectiveness is bounded by reviewer attention at 2-week cadence. These accept the efficiency thesis knowingly — the same trade any org adopting this pattern makes.

Sources