Case study · Team-facing agent
FDE Platform product requests lived in Slack threads and stalled Jira tickets without consistent clarification or spec discipline. I built a team-facing PM agent on Obvious that subscribes to the team's Slack channels and a Jira webhook, classifies whether each message is a real work request, runs PM-shape discovery in-thread, and writes the Specification Document only after an explicit human approval. The agent's lane is discovery → clarification → documentation. It never writes code, opens PRs, or merges.
Product requests for the FDE Platform arrived as Slack messages, Jira tickets, and side-of-desk pings - often without clear scope, named users, or success criteria. Engineering would either build the wrong thing or stall waiting on clarification. The bottleneck wasn't writing the spec; it was the discipline of running the discovery loop before the spec is worth writing.
A team-facing agent on Obvious - an AI agent platform with built-in Slack and Jira integrations - that operates the PM discovery discipline at scale. It wakes on two triggers and runs a two-phase sub-agent architecture, with the spec written only after a human says yes.
The agent subscribes to the FDE Slack channels and a Jira webhook on tickets transitioning to Design. On every Slack wake, the first step is a binary classification: is this a real work request? If not, the agent stays silent - even when @mentioned. A mention attached to general chatter, an opinion question, or a tooling discussion is still a no-op. No reactions, no "want me to spec this?" follow-ups, no explanation of why it's quiet. Silence is the right behavior, and stating it explicitly in the operating spec is what makes it reliable.
The orchestrator never asks clarifying questions itself. For Slack-originated work, it spawns an intake sub-agent first: confirm whether this is a feature, task, or bug, and ask enough clarifying questions to support the next phase. No Jira ticket, no Obvious project, no spec is created during intake. Only after intake confirms does the orchestrator create or link the Jira ticket, create the dedicated Obvious project, and spawn the specification sub-agent with the full context to write the doc.
Before the spec sub-agent asks a single clarifying question, it must ground itself in how the relevant part of FDE works today. It reads the platform feature docs, consults the FDE product bibliography, and reads the actual code - components, services, routes - relevant to the feature area. This step is read-only. Nothing technical lands in the spec output (no file paths, no type names, no library choices); the goal is understanding, not narration. Skipping Step 0 is the single most common quality failure for spec-writing agents.
Discovery happens in the originating Slack thread, one question at a time. The agent asks who the feature is for in the user's own words ("warehouse manager", not "internal user"), what they do today, what changes for them, where they encounter it, and what success looks like. Plain product language only. Never asks about DB schema, API endpoints, component names, or build estimates. Four to six exchanges is usually enough.
Once discovery is complete, the agent proposes two or three ways to address the request - with PM-language trade-offs ("faster to ship" vs "more flexible later", "simpler for the user" vs "more powerful"), never technical trade-offs - and a recommendation. When the requester picks an approach, the agent reads back a plain-English design summary and asks: "Should I write this up as the Product Spec? (yes / change something / step back)"
The agent does not write the spec until the requester explicitly approves. If they say "change X", it loops back to discovery or approaches. This is the one chance to align before the spec - and every downstream phase - proceeds on the wrong understanding. The gate is the product.
Only after approval, the spec sub-agent creates a structured document inside the dedicated Obvious project, named Product Spec: [Feature Name]. Every spec has the same five sections: Problem Statement (who has it, why it matters), User Stories ("As a X, I want Y so that Z"), Acceptance Criteria (Given/When/Then where useful - the contract for engineering and testing), Out of Scope (what this does not cover), and Open Questions. The spec link gets posted back in the Slack thread and added as a Jira comment, and the Jira ticket transitions to PRD.
The agent ushers each request through Jira status with explicit human checkpoints. When a human says "go ahead," it transitions the ticket to Build. When a build is ready for testing, it posts the staging link and credentials in the originating thread, @mentioning me for review. When the PR is ready for code review, it @mentions the reviewer in-thread, DMs them so it doesn't get missed, and transitions the ticket to Code Review. The agent never transitions status on its own authority - every transition is tied to a human signal in-thread.
The agent must not write code, create pull requests, or merge any branch - unless a human explicitly instructs it to in-thread. Read-only codebase access is allowed (for Step 0 grounding); anything beyond that requires explicit authorization. The agent does not infer permission from enthusiasm, display names, or implied urgency. When in doubt, it stays in the PM lane and asks. The constraint isn't a guardrail bolted on - it's what defines the agent's job.
Built on Obvious's agent runtime and MCP connections. The intake discipline, spec workflow, two-phase architecture, and handoff lifecycle are mine; Obvious provides the platform underneath.