SDLC Agent Family

The five agents that run on the AI Cortex knowledge graph, one per stage of the software lifecycle. Each supplies only a prompt, an edge policy, and a surface; the graph, retrieval, and project isolation are shared, which is what makes a family of agents cheap to add rather than five separate products to maintain.

**Plan.** An ideation agent takes an idea with no code behind it, interrogates it through adaptive rounds of questions until it is a real proposal, writes the ideation document alongside you, and emits a project skeleton a coding agent can start from. A requirements agent then takes a feature request through an approval-gated chain — clarified requirement, a PRD written for non-technical stakeholders with a rendered flow diagram, optional wireframes, a blast-radius impact map, and finally the work breakdown — filing the resulting epics, features, and stories straight into Azure DevOps Boards, each with a ready-to-paste implementation prompt. The blast-radius stage is where the graph earns itself: it traverses the cross-repository edges built at ingestion to say what a planned change actually reaches, and renders the subgraph.

**Build.** A documentation Q&A agent answers questions over code, documents, and work items together, showing every citation plus the entities involved and the retrieval trace, so a thin answer can be diagnosed rather than guessed at. It pitches the same evidence differently per persona, renders architecture and sequence diagrams inline, and maintains self-updating per-repository wikis generated from the graph, with per-page regeneration when one drifts. A conversational RCA agent handles a failure happening right now: paste a trace id, a log, or a link and it identifies the failing service and call, renders the span waterfall and a sequence diagram, replays the request step by step, hands back a runnable curl reproduction, and files the bug with the evidence attached.

**Test and release.** An autonomous RCA agent inverts that loop. It polls production continuously through the observability backend (Elasticsearch or ClickHouse/OpenTelemetry), normalizes heterogeneous telemetry into structured records, clusters look-alike failures by fingerprint so a recurring incident is diagnosed once rather than on every recurrence, correlates each cluster with deployment events, code changes, and infrastructure signals, and produces a structured root-cause assessment naming affected services, suspected commits, and remediation steps — then files it. Resolved incidents feed a knowledge base so known failure patterns are never re-diagnosed.

Governance is part of the platform, not bolted on: role-based access with per-agent grants, per-user usage quotas, and an append-only audit log that records field names but never values — no credential, prompt, message body, or document text enters it.