# I Built a Team of AI Agents to Find Startup Opportunities

> Source: <https://dev.to/vivek_shetye/i-built-a-team-of-ai-agents-to-find-startup-opportunities-3309>
> Published: 2026-08-11 18:37:09+00:00

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:

Here’s how the system works.

Startup research looks easy until you actually need to decide where to spend your time and money.

A few signals can be surprisingly misleading.

A market receiving hundreds of millions in venture capital doesn’t necessarily mean customers are willing to pay for another product.

Especially when the numbers come directly from vendors.

A logo doesn’t tell you how much the customer pays, how heavily they use the product, or whether they’ll renew.

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.

I created four separate Hermes Agent profiles.

Each agent has:

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.

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:

The rubric defines:

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.

The Market Researcher investigates whether there is meaningful evidence that customers actually have the problem.

It looks for signals including:

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.

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:

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.

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:

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.

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.

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:

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.

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 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.

This contains the ranked opportunities.

For each market, the dataset can include:

Now I can compare opportunities instead of reading five unrelated research reports.

This captures the companies discovered during research.

For example:

This helps answer:

Who is already attacking this problem, and how?

Competition isn’t limited to startups.

The real alternative could be:

Understanding the status quo is often more useful than counting startups.

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.

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.

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:

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.
