← all projects

Automation Active 2026

ResearchFlow

Daily multi-agent research-to-product automation

Closed source

The problem

Good research ideas worth building into products are scattered across arXiv, bioRxiv, developer pain points, and market shifts, and finding the ones actually worth a day's build effort - versus the ones that just sound impressive - is a full-time triage job most people don't have time for.

The approach

Built a daily pipeline where a ScraperService pulls papers and signals, a ScoutAgent and AnalystAgent score them, a LangGraph-based Product Director (market scout, paper reviewer, product strategist, commercialization reviewer) brainstorms and filters ideas against a productization rubric, and an ArchitectAgent/BuilderAgent/GardenerAgent chain turns the winner into a real GitHub repo - pushed with a positioned README, PRD, launch checklist, and an optional exported product page on aryansingh.org.

PythonLangGraphLangChainOpenAI APIGitHub ActionsFlask

ResearchFlow is a daily automation that watches recent papers, developer pain, tool shifts, and market signals, then uses an agent pipeline to decide what’s actually worth building - and builds the winner into a real, shippable repo.

pipeline

ScraperService -> ScoutAgent -> AnalystAgent -> Brainstormer
                                      |
                                      v
             LangGraph Product Director (market scout, paper reviewer,
             product strategist, commercialization reviewer)
                                      |
                                      v
                              ArchitectAgent
                                      |
                                      v
                 BuilderAgent -> GitHub About + aryansingh.org export
                                      |
                                      v
                               GardenerAgent -> GitHub

Papers are discovered from arXiv, bioRxiv/medRxiv-style APIs, and RSS/Atom feeds, then scored with deterministic heuristics plus optional OpenAI-assisted scoring - so the pipeline degrades gracefully rather than stalling if the API is unavailable.

the productization rubric

Every candidate idea is scored against the questions a real founder would ask before committing a day: does this map to genuine market pain, is the timing right, is there real leverage in the underlying paper, is there a feasible MVP, is there a distribution path, is there a monetization story, and can the demo actually land?

what a winning idea gets

Once an idea clears the rubric, ResearchFlow creates a local repo, pushes it to GitHub under heyaryansingh, and writes the surrounding materials that make a repo legible to an outside visitor: descriptions, topics, homepage links, a positioned README, a PRD, a build journal, and a launch checklist. If website export is enabled, it also generates an animated product page/feed on aryansingh.org.

safety defaults

Credentials are read from environment/.env and never printed or logged; Stripe hooks are disabled by default and require explicit configuration; email delivery, website export, and OpenAI calls all skip safely rather than failing hard when their prerequisites aren’t configured; and repo-creation and daily-improvement counts are bounded so the pipeline can’t run away with unattended GitHub Actions access.

mission control

A dashboard at http://127.0.0.1:5000 surfaces what’s running, current research and source health, cached brainstorms, the highest-potential products, and setup tasks still pending - the point being that a daily automation like this needs to be legible, not just a black box that occasionally opens a PR.

why this shape

The interesting failure mode for an automation like this isn’t “it builds nothing” - it’s “it builds everything, badly.” Gating the expensive build step behind an explicit productization rubric, and keeping monetization manual until there’s real demand, is the guardrail against that.

What I took away

  • A deterministic scoring fallback for every OpenAI-assisted step (paper scoring, brainstorming, planning) keeps the daily pipeline running even when the API call fails, which matters more for something meant to run unattended in GitHub Actions than for a one-off script.
  • Splitting 'brainstorm what's worth building' from 'build it' into separate agent stages (Analyst/Brainstormer vs. Architect/Builder/Gardener) makes each stage independently testable and lets the productization rubric gate the expensive build step instead of building everything that gets discovered.
  • Monetization paths (Stripe hooks, pricing hypotheses) are recorded but deliberately kept manual-gated - the pipeline decides what's worth building, not what's worth charging for, which is a judgment call best left to a human reviewing the evidence.

0 comments

0/1000

Loading…