Rob Dull Tools Feature Intake Pipeline How it works
Technical Explainer • Agentic Workflow

How the Feature Intake Pipeline Works

Plain language — no prior technical knowledge assumed

The Feature Intake Pipeline is a live demonstration of a concept called agentic chaining — a way of using AI where instead of asking one question and getting one answer, you run a sequence of AI calls where each step's output becomes the next step's input. This page explains what the tool is doing, how the pieces fit together technically, and what "agents" actually means in this context.

What the tool does, in plain terms

You type in a rough feature idea — anything from a customer quote to a Slack message to a half-formed thought. The tool runs it through four separate AI calls, in sequence, each one building on what came before.

The four-step chain
1
Intake Triage
Takes in: your raw text, in any format
Produces: a structured problem statement — the core problem, who is affected, what they can't do today
2
JTBD Framing
Takes in: Step 1's structured output
Produces: a Jobs-to-be-Done analysis — the functional, emotional, and social dimensions of what the user is actually trying to accomplish
3
Assumption Mapping
Takes in: Steps 1 and 2's outputs combined
Produces: the key assumptions that must be true for this feature to matter, ranked by how uncertain and how consequential each one is
4
Prioritization Brief
Takes in: all three prior outputs together
Produces: a RICE scoring rationale and a recommended next action — spike, prototype, backlog, or reject

After each step, you review the output before the next one runs. That review checkpoint is intentional — it's what makes the chain reliable. If Step 2 produces a JTBD statement that doesn't match your context, you catch it before it shapes the assumption map and the final recommendation.

The three pieces of infrastructure and what each one does

Three separate services are involved in running this tool. They each have a distinct job, and none of them can substitute for the others.

Infrastructure — what each service does
Your browser
GitHub Pages
Hosts the HTML, CSS, and JavaScript files that make up the tool's interface. Serves them to anyone who visits the URL. Does not run any code on a server — everything it delivers runs inside your browser.
Your browser sends the prompt directly
Optional secure proxy
Cloudflare Worker
A small piece of server-side code that can sit between the browser and the AI. Its job is to hold the API key securely so it never appears in the browser. In this tool's current configuration, the Worker is bypassed — the browser calls the AI directly using the key you paste into the modal.
Prompt sent to the AI with your API key
The AI
Anthropic API
The service that actually runs the Claude language model. It receives a prompt, generates a response, and returns it. It has no memory between calls — every step in the chain sends the full context it needs as part of the prompt.

GitHub Pages is the filing cabinet — it stores and serves the files. It has no intelligence and runs no logic of its own. When you visit the tool, GitHub sends your browser the HTML file, and from that point on everything runs locally in your tab.

The Anthropic API is where the actual AI work happens. Each time you click Run, your browser sends a prompt to Anthropic's servers, which run the Claude model and send back a structured response. The API charges per use — a fraction of a cent per call — which is why you need your own key to run the tool.

Cloudflare is a secure middleman. In a production deployment — one where you didn't want users to supply their own key — the Cloudflare Worker would hold the API key on the server and forward requests on behalf of the browser, so the key is never visible. In this tool, you supply your own key directly, so the Worker is not in the path.

Why your key is safe: When you paste your Anthropic key into the modal, it goes into your browser's session memory — a temporary holding area that is cleared the moment you close the tab. It is sent directly to api.anthropic.com with each request and nowhere else. It is never stored in a file, never sent to this site's server (GitHub Pages has no server to send it to), and never logged.

What "agents" means here — and what it doesn't

The word "agent" is used loosely in AI discussions, so it's worth being precise about what this tool is and isn't doing.

What an agent usually implies
Autonomous action
An AI that can decide what to do next, take actions in the world (browse the web, run code, send messages), observe the results, and keep going without human input at each step. The AI is in the loop and driving.
What this tool uses
Chained calls with human checkpoints
Four sequential AI calls where each one receives the prior output as structured input. A human reviews the result at each step before the next one runs. The AI generates — the human decides whether to proceed.

This tool is better described as a chained workflow than a true agent. The distinction matters: a fully autonomous agent could run all four steps, decide the output was good enough, and hand you a brief — all without you reviewing anything in between. That would be faster. It would also be less reliable, because errors in early steps would compound silently into the final output.

The design choice here is to keep a human in the loop at every transition. This reflects a core principle from Product Operations: AI is most valuable when it is inside the workflow at the moment of decision, not running autonomously beside it. The human checkpoint is the reliability mechanism.

The chain design in practice: Step 4 produces a better prioritization brief because it has access to Step 1's structured problem, Step 2's JTBD layers, and Step 3's assumption risk map — all as structured inputs. A single prompt asking "prioritize this idea" would produce a generic answer. The chain produces a contextualized one.

Why structure each step's output as JSON

Each step in the chain instructs the AI to respond in a specific structured format — a JSON object with named fields rather than free-form prose. This is deliberate and important.

If Step 1 returned a paragraph of text, Step 2 would have to interpret that paragraph before it could use it. Interpretations drift — especially across multiple calls. By enforcing a consistent schema at each step, the chain passes clean, unambiguous data forward. The final RICE brief is built from precise fields extracted at Steps 1, 2, and 3, not from the AI's interpretation of its own prior prose.

This is the same principle that makes software integrations reliable: agree on the data format up front, and every downstream system can trust what it receives.

The relationship between the tool and the infrastructure

Putting it all together: you visit a URL hosted on GitHub Pages. Your browser downloads the tool's code. You type a feature idea and click Run. The tool constructs a prompt, attaches your API key, and sends it directly to Anthropic. Anthropic runs the Claude model and sends back a JSON response. The tool extracts the relevant fields, displays them, and waits for you to click the next step. This repeats four times. Nothing is stored anywhere. When you close the tab, the session ends.

The sophistication is not in the infrastructure — it is in the prompt design at each step, the schema enforced on each output, and the decision to surface a human checkpoint at every transition rather than letting the chain run unattended.

← Back to the tool All tools ↗