Most people use AI for startup research like this:
“Give me 10 promising AI startup ideas.”
A few seconds later, you get a polished list.
The problem?
You have almost no idea which conclusions are backed by evidence, which are assumptions, and which are simply the model confidently connecting dots.
So I tried something different.
Instead of asking one AI agent to find startup ideas, I built a small Startup Intelligence team using Hermes Agent.
The system uses four specialized AI agents that research markets, investigate competitors, audit evidence, challenge each other’s conclusions, and ultimately rank promising B2B AI SaaS opportunities.
And rather than producing another Markdown document full of ideas, the workflow produces structured research containing:
- Market opportunity scores
- Companies and competitors
- Customer pain and unmet needs
- Evidence-backed claims
- Source URLs and supporting passages
- AI advantages and workflows
- Low-cost validation experiments
Here’s how the system works.
🎥 Full video walkthrough
The Problem With Asking One AI Agent to Find Startup Ideas
Startup research looks easy until you actually need to decide where to spend your time and money.
A few signals can be surprisingly misleading.
💰 Funding can look like customer demand.
A market receiving hundreds of millions in venture capital doesn’t necessarily mean customers are willing to pay for another product.
📈 Growth claims can look like market validation.
Especially when the numbers come directly from vendors.
🏢 Customer logos can look like retention.
A logo doesn’t tell you how much the customer pays, how heavily they use the product, or whether they’ll renew.
⚔️ A long competitor list can make a market look saturated.
But those companies may target completely different buyers, workflows, or budgets.
Generic AI research tends to compress all these signals into something like:
“This is a rapidly growing market with strong demand and significant opportunity.”
That sounds convincing.
But as a founder, it doesn’t tell me what I actually need to know:
Is this opportunity strong enough to investigate further?
So instead of optimizing the system for generating ideas, I optimized it for reducing uncertainty.
Building an AI Startup Intelligence Team
I created four separate Hermes Agent profiles.
Each agent has:
- its own role
- its own instructions
- its own research skill
- its own memory
- a clearly defined responsibility
The architecture looks roughly like this:
┌─────────────────────┐
│ Startup Director │
└──────────┬──────────┘
│
Defines scope + rubric
│
┌───────────────┴───────────────┐
▼ ▼
┌───────────────────┐ ┌─────────────────────┐
│ Market Researcher │ │ Competition & │
│ │ │ Signals Analyst │
└─────────┬─────────┘ └──────────┬──────────┘
│ │
└───────────────┬───────────────┘
▼
┌─────────────────────┐
│ Skeptic Editor │
└──────────┬──────────┘
▼
Evidence-backed
research package
The important part isn’t simply having four agents.
It’s giving them different judgment lenses.
Let’s look at each one.
1. Startup Director — The Orchestrator 🧭
The Startup Director acts like the project lead.
Its first job isn’t browsing the web.
Instead, it converts an ambiguous founder question into a bounded research problem.
For example:
Find five promising B2B AI SaaS startup markets in North America with meaningful evidence of customer demand and new company formation between January 2025 and August 2026.
Before delegating research, the Director creates two important artifacts:
brief.md
rubric.md
The brief defines things such as:
- geography
- buyer
- industries
- time window
- company scope
- exclusions
- deliverables
- known unknowns
The rubric defines:
- source tiers
- scoring dimensions
- claim statuses
- evidence requirements
- counter-evidence requirements
- final output structure
This matters because otherwise different agents can quietly interpret the same research question differently.
One might optimize for funding.
Another might optimize for TAM.
Another might optimize for how many startups exist.
The rubric establishes the rules before the evidence is collected.
2. Market Researcher — Is the Pain Real? 🔎
The Market Researcher investigates whether there is meaningful evidence that customers actually have the problem.
It looks for signals including:
- buyer pain
- willingness to pay
- customer demand
- company formation
- funding
- adoption
- traction
- hiring signals
But simply finding a claim isn’t enough.
The research needs to preserve where that claim came from.
That distinction becomes extremely important later when another agent audits the research.
3. Competition & Signals Analyst — What Already Exists? 🧩
The second researcher approaches the same markets from another direction.
Instead of primarily asking:
“Is there demand?”
It asks:
“How is this problem being solved today?”
That means researching:
- startups
- incumbents
- internal tools
- agencies
- spreadsheets
- existing software
- adjacent products
It also investigates whether market attention is translating into something stronger:
adoption, payment, retention, or recurring usage.
This distinction matters.
A market can be extremely popular on X, LinkedIn, Product Hunt, or Hacker News while having surprisingly little evidence that businesses are paying to solve the problem.
The Market Researcher and Competition Analyst therefore examine overlapping markets but with different objectives.
4. Skeptic Editor — Try to Break the Thesis 🛡️
This might be the most important agent in the entire workflow.
Most AI pipelines optimize for generating an answer.
The Skeptic Editor optimizes for finding reasons that answer might be wrong.
It doesn’t simply read the summaries produced by the other agents.
It examines the underlying:
research files
claims ledger
source URLs
supporting passages
claim classifications
counter-evidence
Then it asks questions like:
- Does this citation actually support the claim?
- Is this vendor-reported or independently verified?
- Does the evidence cover the correct market?
- Does it fall inside the requested time window?
- Are we confusing funding with customer demand?
- Is a company-reported metric being presented as independent evidence?
- What evidence contradicts the recommendation?
If a source supports only a weaker statement, the claim gets narrowed.
If the evidence quality is poor, confidence gets downgraded.
And if there isn’t enough evidence?
The answer can simply become:
UNKNOWN
That’s a feature, not a failure.
An AI research system should be able to admit uncertainty.
Orchestrating the Agents With Hermes Kanban
There was another architectural problem.
Separate Hermes profiles don’t share conversation history.
That means I needed a durable coordination mechanism.
This is where Hermes Kanban becomes useful.
The Startup Director creates two independent research tasks:
Market Research
Competition & Signals
Because neither depends on the other, they can run in parallel.
The Director then creates another task:
Skeptical Review
But this task has both research tasks as parents.
Conceptually:
Startup Director
│
┌────────┴────────┐
▼ ▼
Market Research Competition
│ │
└────────┬────────┘
│
BOTH COMPLETE
│
▼
Skeptic Editor
The Skeptic Editor therefore doesn’t start synthesizing conclusions while half the research is still missing.
This creates an actual dependency graph rather than simply launching several agents and hoping they coordinate.
What Did I Ask the Agents to Research?
For this experiment, I asked the system to compare five specific B2B AI SaaS startup markets in North America.
The industry scope covered:
🏥 Healthcare & Life Sciences
💻 Software Development
🎧 Customer Support & Contact Centers
📊 Finance & Accounting
🛍️ Retail
I also explicitly excluded:
- generic wrappers around foundation-model APIs
- consumer applications
- AI infrastructure
- chips
- data centers
- model providers
- undifferentiated chatbots and copilots
The goal wasn’t:
“Which AI industries are growing?”
That’s too broad to be useful.
The agents instead compare specific combinations of:
Buyer + Pain + Workflow + AI Advantage
That’s much closer to the level at which a founder can actually validate an opportunity.
Every Important Claim Needs Evidence 📚
One requirement fundamentally changed the quality of the output:
Every important market claim needed to be backed by a source.
The claims dataset preserves fields such as:
claim
status
company / market
claim type
source URL
source title
publication date
retrieval date
source tier
supporting passage
This makes the research auditable.
Instead of seeing:
“Companies are increasingly adopting AI for this workflow.”
You can inspect the exact evidence that caused the system to make that statement.
And that means another agent—or a human—can challenge it.
The Final Output Isn’t Just a Report
The Skeptic Editor produces several structured CSV files.
markets.csv
experiments.csv
competitors.csv
companies.csv
claims.csv
This makes the results much more useful than one huge research document.
markets.csv
This contains the ranked opportunities.
For each market, the dataset can include:
- market definition
- opportunity score
- target buyer
- workflow
- recommendation
- companies
- customer complaints
- unmet needs
- AI advantage
- evidence quality
Now I can compare opportunities instead of reading five unrelated research reports.
companies.csv
This captures the companies discovered during research.
For example:
- Company
- Product
- Buyer
- Market
- Differentiation
This helps answer:
Who is already attacking this problem, and how?
competitors.csv
Competition isn’t limited to startups.
The real alternative could be:
- an incumbent SaaS platform
- an internal operations team
- an agency
- a spreadsheet
- a manual workflow
Understanding the status quo is often more useful than counting startups.
claims.csv
This is effectively the evidence ledger.
Every important conclusion can point back to the evidence supporting it.
That creates a useful chain:
Recommendation
↓
Market finding
↓
Claim
↓
Source
↓
Supporting evidence
This makes the final recommendation much harder to fake with confident language.
The Most Useful Output Might Be experiments.csv 🧪
Finding an interesting market still doesn’t mean you should build a product.
So every promising opportunity gets converted into a small validation experiment.
The experiments can contain:
Hypothesis
Target buyer
Procedure
Channel
Sample size
Cost / effort
Success threshold
Failure threshold
Decision rule
Evidence required
This changes the final question.
Instead of:
“Should I build this startup?”
The system asks:
“What’s the cheapest experiment that could prove this opportunity weaker or stronger?”
That’s a much better founder question.
AI Agents Should Reduce Uncertainty, Not Manufacture Confidence
After building this workflow, this was my biggest takeaway.
The value of multi-agent systems isn’t simply that you can run more AI agents.
Four agents producing four versions of the same answer isn’t necessarily better than one.
The advantage appears when agents have:
different responsibilities + independent evidence + explicit dependencies + durable state + adversarial review.
Then you’re building something closer to a research process.
The final system doesn’t claim:
“I found the perfect startup.”
Instead, it tells you:
- what appears promising
- what evidence supports that conclusion
- what evidence contradicts it
- what remains unknown
- what you should test next
That distinction matters.
Because when you’re deciding where to spend months building a product, a confident answer isn’t enough.
You need a process that’s harder to fool.
