DEV Community: Prakhar Shukla

Just shipped VentureNode for the Notion MCP Challenge! I built an autonomous, multi-agent AI Co-Founder that lives entirely inside your Notion workspace. Check out the open-source code and deep-dive!

Prakhar Shukla — Mon, 30 Mar 2026 06:02:09 +0000

Notion MCP Challenge Submission 🧠

Prakhar Shukla

Mar 30

VentureNode: I Built an Autonomous AI Co-Founder That Runs Inside Notion

#devchallenge #notionchallenge #mcp #ai

Comments

6 min read

VentureNode: I Built an Autonomous AI Co-Founder That Runs Inside Notion

Prakhar Shukla — Mon, 30 Mar 2026 02:45:43 +0000

This is a submission for the Notion MCP Challenge

What I Built

VentureNode is an autonomous, multi-agent AI operating system for startups. You give it a raw startup idea in plain English. It returns a scored analysis, live market intelligence from the web, a 3-phase product roadmap, and a full sprint of execution-ready tasks, all structured directly inside your Notion workspace.

No copy-pasting. No manual data entry. No spreadsheets.

The entire lifecycle of turning an idea into a company (from initial research through planning to execution tracking) is handled by a 5-agent LangGraph pipeline that writes its outputs to Notion databases via the Notion MCP protocol. Your Notion workspace becomes the actual brain of the company, not just a place to take notes.

The Architecture: 5 Specialized Agents

The system is orchestrated as a directed StateGraph using LangGraph. Each node is a specialized, async agent powered by Groq's LLaMA 3.3 70B

Here is what each agent actually does:

1. Idea Analyzer Agent
Takes your startup idea as a raw string. Uses the LLM with structured Pydantic output to score it on 5 dimensions: market size, technical feasibility, competition intensity, defensibility (moat), and execution risk. Creates a structured record in the Notion Ideas Database (title, rich_text, number, select properties).

2. Human-in-the-Loop Checkpoint #1
The pipeline literally pauses here. It writes a status of pending_approval to Notion and begins an async polling loop (asyncio.sleep + exponential backoff). A real human goes to the Notion Ideas database, reviews the AI's analysis, and manually changes the status to approved. Only then does the pipeline resume. This is the core of the "human-in-the-loop" architecture that the Notion MCP Challenge explicitly asks for.

3. Market Research Agent
Runs live OSINT using DuckDuckGoSearchRun and BeautifulSoup4 to scrape competitor websites, product pages, and industry reports. It synthesizes this into a competitor matrix and market opportunity summary, which gets written to the Notion Research Database.

One critical engineering detail here: web scraping with requests is synchronous and blocking. Calling it directly inside an async def LangGraph node would freeze the entire FastAPI event loop, killing all other concurrent users. Instead, VentureNode uses asyncio.get_event_loop().run_in_executor(None, scrape_func) to offload all HTTP calls to a thread pool — the async code stays non-blocking while the scraping runs on a separate thread. Most developers get this wrong; this is the correct production pattern.

4. Human-in-the-Loop Checkpoint #2
Same pattern. The pipeline pauses again for human review of the market research before committing to a roadmap.

5. Roadmap Builder Agent
Takes the approved analysis and market data and generates a structured 3-phase roadmap (MVP, Growth, Scale), complete with milestone descriptions, timelines, and dependencies. Written directly to the Notion Roadmap Database.

6. Task Planner Agent
Breaks each roadmap phase into granular, sprint-ready tasks with priorities, effort estimates, and categories. Populates the Notion Tasks Database — this is a real Kanban board you can start working from immediately.

7. Execution Monitor + FAISS Memory
Tracks completion rate by reading task statuses from Notion. Stores a vector embedding of every idea and its full analysis in a local FAISS index (faiss-cpu), so the system remembers past decisions and can avoid redundant research runs.

The Full Tech Stack

Layer	Technology	Why
LLM	Groq LLaMA 3.3 70B	Fast, free, state-of-the-art reasoning
Orchestration	LangGraph StateGraph	Production-grade, stateful, pauseable agents
Data Store	Notion (via MCP)	Human-readable, structured, no external DB needed
Memory	FAISS (faiss-cpu)	Local vector search, zero cloud cost
Market Research	DuckDuckGo + BeautifulSoup4	Real OSINT, no paid search API
Backend	FastAPI (Python 3.11, `async def` everywhere)	High-performance async API
Frontend	Next.js 14 App Router + Tailwind + Framer Motion	Premium, fast, open-source marketing + application
Auth	Clerk v7 (JWT)	Secure multi-tenant, free tier
Infra	Render (backend) + Vercel (frontend)	Both on free tier

Video Demo

Show Us the Code

GitHub Repository: https://github.com/Prakhar2025/VentureNode

Live Demo: https://venture-node.vercel.app

The project is fully open-source under the MIT License. The repository contains:

backend/ — FastAPI app, all 5 LangGraph agent nodes, Notion MCP client, FAISS memory store.
frontend/ — Next.js 14 public marketing landing page + protected application dashboard.
docs/notion-setup.md — The exact Notion database schema required to run this yourself.
docker-compose.yml — One command to run the entire stack locally.

Key Code Snippet: The LangGraph Pipeline

# backend/orchestrator/graph.py
from langgraph.graph import StateGraph, END
from backend.orchestrator.state import AgentState

def build_graph() -> StateGraph:
    graph = StateGraph(AgentState)

    graph.add_node("idea_analyzer", idea_analyzer_node)
    graph.add_node("idea_approval_checkpoint", idea_approval_node)
    graph.add_node("market_research", market_research_node)
    graph.add_node("research_approval_checkpoint", research_approval_node)
    graph.add_node("roadmap_generator", roadmap_generator_node)
    graph.add_node("task_planner", task_planner_node)
    graph.add_node("execution_monitor", execution_monitor_node)

    graph.set_entry_point("idea_analyzer")
    graph.add_edge("idea_analyzer", "idea_approval_checkpoint")
    graph.add_edge("idea_approval_checkpoint", "market_research")
    graph.add_edge("market_research", "research_approval_checkpoint")
    graph.add_edge("research_approval_checkpoint", "roadmap_generator")
    graph.add_edge("roadmap_generator", "task_planner")
    graph.add_edge("task_planner", "execution_monitor")
    graph.add_edge("execution_monitor", END)

    return graph.compile()

Key Code Snippet: The Human-in-the-Loop Checkpoint

This is the most critical architectural piece. The pipeline literally pauses and waits for a human to change a value in Notion before it continues.

# backend/notion/mcp_client.py (simplified)
async def poll_idea_approval(client: NotionClient, idea_id: str) -> bool:
    """Async polling loop — will not return until the human approves in Notion."""
    backoff = 5  # seconds
    for _ in range(60):  # Max 5-minute wait
        page = await client.pages.retrieve(page_id=idea_id)
        status = page["properties"]["Status"]["select"]["name"]
        if status == "Approved":
            return True
        if status == "Rejected":
            return False
        await asyncio.sleep(backoff)
        backoff = min(backoff * 1.5, 30)
    raise TimeoutError("Human did not respond within 5 minutes.")

How I Used Notion MCP

Notion is not a side feature of VentureNode. Notion IS VentureNode.

Every single data structure in the system lives in Notion. There is no separate PostgreSQL, no Redis, no MongoDB. The Notion API (via the Notion MCP client in backend/notion/mcp_client.py) is the single source of truth for every piece of data the AI agents create, read, and update.

Here is how Notion MCP is leveraged at every stage:

Stage	Notion MCP Action
Idea Analysis	`pages.create()` → Notion Ideas DB with score properties
Human Approval	Agent polls `pages.retrieve()` every 5s until Status = `Approved`
Market Research	`pages.create()` → Notion Research DB with competitor data
Roadmap	`pages.create()` → Notion Roadmap DB with 3 sub-pages
Task Planner	`pages.create()` (bulk) → Notion Tasks DB as a Kanban board
Execution Monitor	`databases.query()` → reads Task statuses to calculate completion rate

What Makes This Different

Most Notion MCP demos use Notion as a passive recipient — an LLM writes a note to it and stops. VentureNode treats Notion as an active agent runtime. The human approval gatekeeping pattern means that Notion is not just storing data; it is controlling the flow of an autonomous system. A human's action inside their own Notion workspace literally resumes a running AI pipeline.

This is a genuine "human-in-the-loop" operating system, not a chatbot writing text into pages.

Honest Self-Assessment (Gap Analysis)

I am not going to butter this up. Here is the honest picture of what works absolutely perfectly and what could be better:

What is strong:

The Human-in-the-Loop architecture is genuinely novel. The async polling pattern where Notion controls pipeline flow is the correct design.
The 5-agent pipeline is real, working code. Not a prototype. Every agent has structured Pydantic output, proper state management, and async error handling.
The open-source marketing landing page and the public GitHub repo make this submission very discoverable.
100% free-tier stack. Zero paid APIs. Anyone can fork and run this.

Where there are limitations:

The FAISS vector memory is local to the Render server. In a proper production system, this would be a persistent vector database on S3.
The Execution Monitor is a read-only agent that generates reports. In v2, it should be able to autonomously create follow-up tasks based on blockers.
The market research is rate-limited by DuckDuckGo's public API. For heavy production use, a proper OSINT API would be needed.

Try It Yourself — Get Your Own AI Co-Founder in 10 Minutes

VentureNode is fully open-source. You don't need to ask permission to use it. Here is how to spin up your own instance:

# 1. Fork & clone the repo
git clone https://github.com/Prakhar2025/VentureNode.git
cd VentureNode

# 2. Set up backend environment
cd backend
cp .env.example .env   # Fill in GROQ_API_KEY, NOTION_TOKEN, NOTION_DB_IDs, CLERK_SECRET_KEY
pip install -r requirements.txt
uvicorn main:app --reload --port 8000

# 3. Set up frontend (in a new terminal)
cd frontend
cp .env.example .env.local  # Fill in NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY, NEXT_PUBLIC_API_URL
npm install
npm run dev

# Backend:  http://localhost:8000
# Frontend: http://localhost:3000

You will need to set up 4 Notion databases (Ideas, Research, Roadmap, Tasks) following the schema in docs/notion-setup.md. The setup takes about 10 minutes and you will have your own autonomous startup intelligence system running in your private Notion workspace.

Live Demo (if you just want to see it): https://venture-node.vercel.app

Made with Groq, LangGraph, FAISS, FastAPI, Next.js, Clerk, and Notion MCP.
Open-source under MIT. Star us on GitHub — contributions welcome.

TruthLayer — How I Built an AI Hallucination Firewall on AWS

Prakhar Shukla — Tue, 10 Mar 2026 15:16:27 +0000

Full article on AWS Builder Center

"An AI that hallucinates in a hospital could cost a life. In a law firm, a lawsuit. In a bank, millions. The question is not whether AI makes mistakes — it is whether you catch them before your users do."

The Problem

In 2025, a law firm submitted a legal brief containing case citations that did not exist. Their AI assistant had fabricated case names, dates, and rulings with full confidence. The lawyers trusted it. The judge sanctioned them.

This was not a failure of AI technology. It was a failure of the infrastructure around AI — there was no layer between the model and the real world that simply asked: "Is this actually true?"

That is what I built.

What TruthLayer Does

TruthLayer is a production-ready verification API deployed on AWS. It sits silently between any AI model and its users — intercepting every response before it reaches a human and certifying whether each claim is verified.

Status	Meaning	Action
✅ VERIFIED	Factually grounded in your source documents	Safe to display
⚠️ UNCERTAIN	Topically related but not fully confirmed	Display with caveat
❌ UNSUPPORTED	Not found in any source — likely hallucinated	Block or flag

One API call. No model changes. No fine-tuning. Sub-second latency.

🌐 Try it free: truth-layer.vercel.app

The Core Innovation: Two Signals, Not One

Every existing hallucination detector uses one signal: embedding similarity. Here's why that fails.

"GDPR fines are up to 2% of revenue" vs "GDPR fines are up to 4% of revenue"

Cosine similarity between these two sentences: 0.97 out of 1.0. Nearly identical to any model. Completely opposite in a compliance audit.

An embedding-only system classifies the wrong answer as VERIFIED. TruthLayer catches it using a second signal.

Signal 1 — Amazon Bedrock Titan Embeddings V2: Claims and source chunks are embedded into 1,024-dimensional semantic vectors. Cosine similarity finds the best-matching source chunk for each claim.

Signal 2 — Entity Contradiction Checker (Custom): A rule-based system that applies multiplicative penalties for three contradiction classes embeddings fundamentally cannot detect:

Contradiction	Example	Penalty
Numerical mismatch	"2% fine" vs "4% fine"	× 0.5
Negation mismatch	"non-refundable" vs "refundable"	× 0.6
Superlative vs specific	"unlimited" vs "1,000/month"	× 0.6

Final Score = Cosine Similarity × Contradiction Penalty

The 2%/4% GDPR claim: 0.97 × 0.5 = 0.485 → UNSUPPORTED. Caught.

The AWS Architecture

Everything runs serverless on AWS — Amazon Bedrock, AWS Lambda, Amazon API Gateway, Amazon DynamoDB, deployed via AWS SAM. Four Lambda functions, four DynamoDB tables, one template.yaml file, one command to deploy.

The embedding cache is the key architectural decision. Early TruthLayer hit Bedrock on every request — a 3-document verification took 3–4 seconds. After adding DynamoDB as an embedding cache, the same verification dropped to 750ms. Documents don't change. Their embeddings shouldn't be recomputed every time.

Scenario	Latency	Cost
First verification (cache miss)	~900ms	Bedrock call
All subsequent verifications (cache hit)	~750ms	DynamoDB only — ~5ms
Monthly cost at 50,000 verifications	—	~$1.50 total

Security

API keys are SHA-256 hashed in DynamoDB — raw keys shown once, never stored. Same model as Stripe and GitHub. Rate limiting enforced at the database level via DynamoDB conditional writes, not the application layer. Each Lambda function holds only the exact IAM permissions it needs. Zero external PyPI dependencies — Python stdlib + boto3 only.

Live Demo

The dashboard tracks verification analytics, claim-level results, source attribution, API key management, and cache performance in real time.

Try it yourself: Go to truth-layer.vercel.app → Get API Key → paste any AI response and source document → see claim-by-claim results in under 1 second.

What I Learned

Embeddings are brilliant — and dangerously incomplete. "$2 million" and "$20 million" score 0.97 cosine similarity. They mean nearly the same thing semantically while being completely different factually. You need both signals.

The cache is as important as the algorithm. Without the DynamoDB embedding cache, TruthLayer was unusable at 3–4 seconds. Caching is infrastructure design, not optimization.

Data staying in AWS changes the enterprise conversation. Healthcare and legal organizations cannot send patient records or contracts to external APIs. Bedrock keeps everything within the AWS ecosystem. Compliance by default.

Full technical breakdown on AWS Builder Center

Stack: Amazon Bedrock · AWS Lambda · API Gateway · DynamoDB · AWS SAM · Next.js 16 · Python 3.9 · Kiro IDE