Claude's Corner: Fed10 -- AI Lobbyists That Actually Passed Legislation

Fed10 is an AI legislative intelligence platform built by three ex-lobbyists who passed legislation before they could vote. They dropped out of Harvard, Williams, and Berkeley to automate the $500/hr policy consulting job they used to do by hand -- monitoring every bill across all 50 U.S. states, drafting amendments, and mapping advocacy strategy in seconds.

Jun 11 at 11:11 AM8 min read

Claude's Corner: Fed10 -- AI Lobbyists That Actually Passed Legislation

TL;DR

Fed10 monitors every U.S. bill in real time and flags regulatory threats before they hit -- built by three ex-lobbyists who passed legislation as teenagers, then dropped out of Harvard, Williams, and Berkeley to automate the job. The tech stack is replicable but the domain expertise and legislative relationship graph are a genuine 2-3 year moat.

5.4

Build difficulty

Three college dropouts walk into a government hearing. One was appointed by a governor before he could legally vote. One had a rejected Amazon offer at 17. One ran a state party government affairs desk as a teenager. Together they passed legislation affecting 344,000 people annually -- then dropped out of Harvard, Williams, and Berkeley to automate the job they used to do by hand.

That is Fed10. And if you are in any industry that gets regulated -- which is every industry -- this is one of the more interesting YC W26 bets to come out of the batch.

Related startups

What They Actually Build

Fed10 is a real-time legislative intelligence platform for corporate policy teams and government affairs professionals. The product monitors every bill introduced across all 50 U.S. state legislatures and Congress, classifies whether a given bill poses a threat or opportunity to a specific client business, drafts amendment language in response, and maps out exactly who you need to call and what you need to say to get it handled.

They call it AI agents that replace your policy consultants. The positioning is aggressive but defensible: a senior policy consultant in D.C. runs $500/hr and a retainer at a Beltway firm easily clears $30K/month. Fed10 pitch is that the research half of that job -- monitoring hearings, reading bill text, tracking committee movement, identifying impact vectors -- can be done in seconds by software that never misses a session.

The target buyer is the head of government affairs at a mid-size company with regulatory exposure that cannot justify a six-figure consulting relationship. A fintech being squeezed by state money-transmission laws. A gig economy company watching labor classification bills. A health tech startup trying to stay ahead of state-level AI regulation. These companies need to know when a bill drops, not three weeks later when a consultant bills them for the discovery.

The Founding Story Is the Moat

The three founders -- Armand Iorgulescu (CEO), Zayan Islam (CTO), and Winston Wei (COO) -- are not AI researchers who discovered the policy space via a pitch deck. They are actual ex-lobbyists who did this work themselves in high school and passed real legislation. They drafted and shepherded AB367 through Nevada, ultimately affecting hundreds of thousands of people annually. Armand became the youngest Governor appointee in the state. Zayan was running code while learning how to work a committee room. Winston was staffing Nevada Democratic Party government affairs.

This matters enormously for what they are building. Legislative language is famously ambiguous. What sounds like a consumer protection bill might be a targeted attack on a specific business model. What reads as an environmental regulation might be a carve-out that exempts incumbents. You need domain knowledge to separate noise from threat -- and these founders have it in a way that a generic AI team does not.

They enrolled in elite universities and promptly dropped out to build this. That is a useful signal about conviction.

How It Works: The Technical Architecture

Fed10 is at its core a multi-layer data pipeline with an LLM reasoning layer on top. Here is how the system breaks down:

Ingestion layer. The platform continuously scrapes and ingests legislative data from primary sources: Congress.gov and the Congressional Record at the federal level, plus each state official legislative information system (LIS). This is messy, inconsistent, annoying work -- every state has a different schema, different update cadence, and different levels of API accessibility. Some states publish structured XML; others still put bills in PDFs. You need robust parsers for all of it, plus logic to detect amendments, substitutes, and committee substitutes as distinct events.

Structuring and tagging. Raw bill text gets run through a classification pipeline. This step extracts: the industry vertical(s) affected, the type of regulatory action (new requirement, amendment to existing law, enforcement change, reporting obligation, preemption), the effective date, and the jurisdictional scope. This is where NLP gets genuinely hard -- you are doing named entity recognition on statutory language written by lawyers who are actively trying to be ambiguous.

Client-side matching. Each client defines an exposure profile -- a structured description of their business model, revenue streams, geographic footprint, and regulatory surface area. The platform runs a matching algorithm that scores incoming bills against this profile in real time. High-scoring matches trigger alerts. The scoring model needs to balance recall (do not miss threats) against precision (do not flood clients with noise), which is a continuous tuning problem requiring human feedback loops.

Impact and response generation. For flagged bills, the system generates: a plain-English impact analysis, proposed amendment language the client can submit to the committee, and an advocacy strategy brief -- identifying the bill sponsor, key committee members, their positions, likely vote timelines, and suggested outreach messaging. This is where the LLM layer earns its keep.

Relationship graph. The advocacy strategy component is the most differentiated piece. Building it requires a knowledge graph of legislators, their committee assignments, their voting history, their donor networks, and their stated policy positions. Cross-referencing that against who a client knows via LinkedIn or CRM integrations surfaces the warmest path to influence. This graph is expensive to build and maintain but becomes a compounding asset once it exists.

Why Now

Two things converged to make this the right moment. First, state legislatures have become dramatically more active on technology regulation. Between 2023 and 2026, states introduced thousands of bills touching AI, data privacy, gig work, fintech, healthcare, and social media. The federal gridlock that used to absorb regulatory pressure has redirected it to state capitols where companies have less monitoring infrastructure and less lobbying presence. A startup can get wiped out by a state bill they never saw coming.

Second, LLMs finally crossed the threshold where they can produce useful legislative analysis rather than plausible-sounding nonsense. The combination of improved reasoning capability and legal fine-tuning means you can now get an LLM to correctly parse amendment-upon-amendment chains, identify the operative language in a 200-page bill, and draft a technically correct substitute provision. That was not true in 2022. It is true now.

Fed10 is building into both of those tailwinds. The timing is right.

Difficulty Score

ML/AI: 7/10 -- LLMs on legislative text sound easy until you discover that statutory amendments are written as strike everything after section 2(a)(iii) and insert. You need preprocessing that understands amended versions of law, not just raw bill text. The impact classification model also requires labeled training data from actual policy experts.
Data: 8/10 -- 50 state legislative information systems plus federal sources, each with their own quirks, access restrictions, and update patterns. Getting comprehensive low-latency coverage is a serious engineering problem. Many states do not have real APIs.
Backend: 5/10 -- Standard microservices architecture, event-driven pipeline, relational plus vector store. Nothing exotic once the data layer is solved.
Frontend: 3/10 -- B2B SaaS dashboard. Tables, filters, a feed, alert settings. Standard work.
DevOps: 4/10 -- Needs high-reliability alerting since a delayed notification defeats the product purpose. Standard cloud infrastructure handles this fine.

The Moat

What is real: The founding team domain expertise is genuinely hard to replicate. Engineers who have never worked a committee room will build a worse impact classification model and a worse advocacy strategy layer than people who have actually done it. The relationship graph, once built to depth, becomes a compounding asset. B2B trust in regulated industries is slow to earn -- a general counsel at a Fortune 500 is not going to run legislative risk management on a platform they have never heard of without significant references.

What is not a moat: The core tech stack -- legislative data ingestion plus LLM analysis plus B2B SaaS delivery -- is replicable by a competent team in 6 to 12 months. The data sources are mostly public. LLM capabilities exist at commodity prices. There is nothing in the underlying infrastructure that confers a durable technical advantage on its own. The moat is data quality, model tuning, and distribution.

The real risk: Bloomberg Law, LexisNexis, and Quorum all have legislative monitoring products. What Fed10 has that they do not is the advocacy strategy layer and the willingness to go deep on AI integration. But those incumbents have enterprise relationships, brand trust, and distribution that Fed10 still needs to build. The other risk is scope creep -- every regulation in the world appears in their materials. International legislative monitoring at meaningful depth is an order of magnitude harder than U.S. coverage alone.

Replicability Score: 42 / 100

The tech stack itself -- data ingestion, NLP classification, LLM response generation, B2B SaaS dashboard -- sits around a 25 out of 100 on its own. You could clone the infrastructure in a few months. What pushes it to 42 is the domain expertise required to tune the models correctly, the relationship graph that takes years to build at depth, the enterprise trust curve in regulated industries, and the founding team actual policy credentials. This is not a decade-of-R&D moat, but it is a real two-to-three year head start that is hard to replicate without founders who have actually moved bills through committee.

Build it wrong -- with an engineering team that has never read a committee substitute -- and you get a product that generates noisy alerts and useless amendment drafts. Build it right, with people who know what section 2(a)(iii) as amended means and why the timing of a committee hearing matters, and you have something that enterprise policy teams will pay serious money for.

Fed10 has the right people for the right problem. The rest is execution.

© 2026 StartupHub.ai. All rights reserved. Do not enter, scrape, copy, reproduce, or republish this article in whole or in part. Use as input to AI training, fine-tuning, retrieval-augmented generation, or any machine-learning system is prohibited without written license. Substantially-similar derivative works will be pursued to the fullest extent of applicable copyright, database, and computer-misuse laws. See our terms.

Build This Startup with Claude Code

Complete replication guide — install as a slash command or rules file

# How to Build a Fed10 Clone with Claude Code

## Step 1: Define the Data Schema

Start with Postgres + pgvector. You need tables for bills, clients, alerts, and legislators.

```sql
CREATE TABLE bills (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  source TEXT NOT NULL,
  jurisdiction TEXT NOT NULL,
  bill_number TEXT NOT NULL,
  title TEXT,
  full_text TEXT,
  status TEXT,
  introduced_date DATE,
  last_action_date TIMESTAMPTZ,
  committee TEXT,
  sponsors JSONB,
  tags TEXT[],
  embedding VECTOR(1536),
  raw_source_url TEXT,
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE clients (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  business_description TEXT,
  industries TEXT[],
  jurisdictions TEXT[],
  keywords TEXT[],
  alert_email TEXT,
  profile_embedding VECTOR(1536),
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE alerts (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  client_id UUID REFERENCES clients(id),
  bill_id UUID REFERENCES bills(id),
  threat_score NUMERIC,
  impact_analysis TEXT,
  amendment_draft TEXT,
  advocacy_brief TEXT,
  status TEXT DEFAULT 'pending',
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE legislators (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  jurisdiction TEXT NOT NULL,
  chamber TEXT,
  party TEXT,
  committees TEXT[],
  contact_info JSONB,
  embedding VECTOR(1536)
);
```

## Step 2: Build the Legislative Data Ingestion Pipeline

Set up async crawlers for each data source. Congress.gov has an API key program. For states, use LegiScan which covers all 50 states with a unified API.

```python
import httpx
import asyncio

async def fetch_federal_bills(api_key: str, offset: int = 0):
    url = "https://api.congress.gov/v3/bill"
    params = {"api_key": api_key, "limit": 250, "offset": offset, "sort": "updateDate+desc"}
    async with httpx.AsyncClient() as c:
        resp = await c.get(url, params=params)
        return resp.json().get("bills", [])

async def fetch_state_bills(api_key: str, state: str):
    url = "https://api.legiscan.com/"
    params = {"key": api_key, "op": "getSearch", "state": state, "query": "*", "year": 2}
    async with httpx.AsyncClient() as c:
        resp = await c.get(url, params=params)
        return resp.json().get("searchresult", {}).get("results", [])
```

Use Celery + Redis for job queuing. Run ingestion every 15 minutes per jurisdiction. Store raw text in S3, metadata and embeddings in Postgres.

## Step 3: Build the Classification Engine

Use Claude to classify each bill against your industry taxonomy. Prompt engineer carefully for structured JSON output.

```python
import anthropic
import json

client = anthropic.Anthropic()

INDUSTRIES = ["fintech", "healthtech", "gig-economy", "ai-ml", "data-privacy", "energy", "b2b-saas"]

def classify_bill(bill_text: str, title: str) -> dict:
    prompt = f"""Analyze this bill and return JSON with:
- industries: list from {INDUSTRIES}
- regulatory_type: one of [new_requirement, amendment, enforcement, reporting, preemption]
- severity: low/medium/high/critical
- summary: 1 sentence plain English

Title: {title}
Text: {bill_text[:3000]}

Return only valid JSON."""

    msg = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=512,
        messages=[{"role": "user", "content": prompt}]
    )
    return json.loads(msg.content[0].text)
```

Generate embeddings for each bill using `text-embedding-3-small`. Store in pgvector.

## Step 4: Build the Client Matching Algorithm

Hybrid scoring: semantic similarity + keyword boost + jurisdiction filter.

```python
def score_bill_for_client(bill_embedding, client_profile_embedding, 
                           bill_tags, client_industries,
                           bill_jurisdiction, client_jurisdictions,
                           bill_text, client_keywords) -> float:
    # Hard filter: jurisdiction
    if bill_jurisdiction not in client_jurisdictions:
        return 0.0
    
    # Cosine similarity via dot product (normalized vectors)
    import numpy as np
    similarity = float(np.dot(bill_embedding, client_profile_embedding)) * 100
    
    # Keyword boost
    keyword_hits = sum(1 for kw in client_keywords if kw.lower() in bill_text.lower())
    keyword_boost = min(keyword_hits * 10, 25)
    
    # Industry overlap boost
    industry_overlap = len(set(bill_tags) & set(client_industries))
    industry_boost = industry_overlap * 8
    
    return min(similarity + keyword_boost + industry_boost, 100)
```

Bills scoring above 65 trigger alert generation. Tune this threshold per client based on feedback.

## Step 5: Generate Impact Analysis and Amendment Drafts

For high-scoring bills, call Claude to produce the three components: impact analysis, amendment language, and advocacy brief.

```python
def generate_alert_content(bill_text: str, bill_title: str,
                            client_name: str, client_industries: list) -> dict:
    system = """You are a senior legislative analyst and lobbyist.
    Be specific, direct, and practical. Flag compliance costs and deadlines.
    Use proper legislative drafting style for amendments."""

    user = f"""Analyze this bill for {client_name} (industries: {", ".join(client_industries)}).

Bill: {bill_title}
Text: {bill_text[:5000]}

Provide three sections labeled exactly:
IMPACT_ANALYSIS: (how this affects the client, specific costs and timeline)
AMENDMENT_DRAFT: (proposed amendment language in statutory style)
ADVOCACY_BRIEF: (3 bullet points: who to contact, what to say, by when)"""

    msg = anthropic.Anthropic().messages.create(
        model="claude-opus-4-7",
        max_tokens=2000,
        system=system,
        messages=[{"role": "user", "content": user}]
    )
    return parse_sections(msg.content[0].text)
```

## Step 6: Build the Legislator Knowledge Graph

The advocacy brief layer needs a graph of legislators and relationships. Use Postgres recursive CTEs for pathfinding.

```sql
-- Who does this client know, and how many hops to the target committee chair?
WITH RECURSIVE paths AS (
  SELECT source_id, target_id, 1 AS depth, ARRAY[source_id] AS path
  FROM legislator_relationships
  WHERE source_id IN (SELECT legislator_id FROM client_contacts WHERE client_id = $1)
  
  UNION ALL
  
  SELECT p.source_id, r.target_id, p.depth + 1, p.path || r.target_id
  FROM paths p
  JOIN legislator_relationships r ON r.source_id = p.target_id
  WHERE p.depth < 3 AND NOT r.target_id = ANY(p.path)
)
SELECT path FROM paths WHERE target_id = $2
ORDER BY depth LIMIT 1;
```

Seed the graph from official committee assignment data, LegiScan legislator endpoints, and OpenSecrets for donor overlap signals.

## Step 7: Deployment, Alerting, and Reliability

Deploy on AWS ECS or Railway. The critical SLA: bill-to-alert in under 30 minutes for introductions, under 5 minutes for passage events.

```yaml
services:
  api:
    image: fed10-clone:latest
    env: [DATABASE_URL, REDIS_URL, ANTHROPIC_API_KEY, LEGISCAN_API_KEY]
    
  ingestion-worker:
    image: fed10-clone:latest
    command: celery -A tasks worker -Q ingestion --concurrency=4
    
  alert-worker:
    image: fed10-clone:latest
    command: celery -A tasks worker -Q alerts --concurrency=2
    
  scheduler:
    image: fed10-clone:latest
    command: celery -A tasks beat --loglevel=info
```

For notifications: Sendgrid for email, Slack webhooks for enterprise clients, and a REST API for CRM integrations. Set up dead-letter queues to catch any missed alerts and page your oncall if the ingestion lag exceeds 20 minutes.

The one thing to get right is latency. If a dangerous bill passes committee on Monday and your client finds out Friday, the product has failed.

Install for: