Aniket Hingane

Posted on Dec 26

The Future of Venture Capital: Building an Autonomous Analyst with Agno, MCP, and A2A

#ai #agents #python #mcp

How I Built a Multi-Agent System That Automates Due Diligence

TL;DR

In this extensive engineering log, I document my journey of building VC-Agent Pro, a serious attempt to automate the intellectual labor of Venture Capital due diligence. By leveraging the Model Context Protocol (MCP) for standardized tool access and an Agent-to-Agent (A2A) messaging layer, I created a swarm of agents that can research a startup, analyze its market, and synthesize an investment memo—all from a single URL. This isn't just a chatbot; it's a glimpse into the future of "Service-as-Software". You can find the full open-source code here: GitHub - VC-Agent Pro.

Introduction

I observed recently that the conversation around AI is shifting. We are moving away from "chatting with a bot" and towards "agents doing work." As per my experience in the industry, the biggest bottleneck in high-stakes decision-making—like Venture Capital—is not a lack of data, but the time it takes to synthesize it.

I wrote this because I wanted to test a hypothesis: Can we build a system that doesn't just summarizetext, but actively investigates a business?

In my opinion, the current generation of RAG (Retrieval Augmented Generation) apps are passive. They wait for you to ask. I wanted to build something active. Something that, once triggered, goes off and thinks on its own, spawning sub-agents to act as specialized analysts, just like a real investment firm would staff a deal team.

From my perspective, the key to this isn't just "better prompts"—it's better architecture. That's why I chose to explore the combination of Agno (for orchestration), MCP (for connecting to the world), and A2A (for agents talking to agents).

What's This Article About?

This article is a deep dive—a really deep dive—into the engineering decisions, architectural patterns, and code required to build a production-grade multi-agent system.

I put it this way coz I want to move beyond the "Hello World" of AI agents. We aren't just calling a weather API here. We are building:

A Protocol-First Architecture: Decoupling the brain (LLM) from the hands (Tools).
A Simulated Enterprise Environment: Where agents define "contracts" to communicate.
A User-Facing Product: That hides the complexity behind a sleek "AG-UI".

I think this guide will be valuable if you are an engineer looking to understand how the pieces of the "Agentic Stack" fit together in late 2024.

Tech Stack

To solve this problem, I selected a stack that prioritizes modularity and standard protocols.

Orchestration: Python (Custom Agent Loop & Agno Concepts). I chose Python because it is the lingua franca of AI.
Data Layer: Model Context Protocol (MCP). This is crucial. Instead of writing custom scrapers for every site, I used MCP to standardize how my agents "see" the world—whether that's searching the web or querying a SQL database.
Communication: Agent-to-Agent (A2A) Protocol using Pydantic. Strictly typed messages ensure our agents don't hallucinate the format of the work, even if they get creative with the content.
Frontend: Streamlit. For the "AG-UI" (Agent-UI). I needed something that could stream events in real-time to show the user that work is happening.

In my opinion, picking the right stack is 90% of the battle. By using MCP, I future-proofed the application. If I want to switch from Brave Search to Google Search later, I don't change a line of agent code—I just swap the MCP server.

Why Read It?

You should read this because the era of "Single Agent" apps is ending. The future is "Agent Swarms".

As per my experience building this, the complexity grows exponentially when you add a second agent. Race conditions, infinite loops, and "telephone" games (where context is lost between agents) are real problems. I observed these failures firsthand so you don't have to.

I documented every step, every failure, and every design decision. If you are serious about building AI that contributes to the real economy, this architecture is a blueprint you can adapt.

Let's Design

Before I wrote a single line of code, I sat down and mapped out the "Cognitive Architecture".

I thought about how a real VC firm works. You have:

** The Partner (Orchestrator)*: They don't do the grunt work. They know *what needs to be done and who should do it. They hold the "State" of the deal.
The Associate (Researcher): They are the diggers. They go to Google, Crunchbase, and GitHub. They bring back raw data.
The Analyst (Market Expert): They look at the numbers. They compare the startup to competitors in the database.

In my design, the Orchestrator is the only one who talks to the User. The user says "Check out Stripe.com".
The Orchestrator then creates a workflow_id and spins up the swarm.
It sends a typed AgentMessage to the Researcher: "Get me the product breakdown."
It sends a message to the Market Analyst: "Who are the competitors?"
The sub-agents use MCP to execute these tasks safely.
Finally, the Orchestrator aggregates the results into a standardized InvestmentMemo artifact.

This "Hub and Spoke" model, in my opinion, is superior to a "Chain" model because it allows for parallel execution. The market analysis doesn't need to wait for the product research—they can happen simultaneously.

Let's Get Cooking

Now, let's get into the code. This is where the rubber meets the road. I've broken this down into the core components that make the system tick.

1. The A2A Protocol (The Language of Agents)

I realized early on that if agents just talk in English paragraphs, things get messy content-wise. We need structure.

# backend/core/a2a.py

from pydantic import BaseModel, Field
from typing import Dict, Any, Optional, List
from datetime import datetime
import uuid

class AgentMessage(BaseModel):
    """Standardized Agent-to-Agent Message Protocol"""
    id: str = Field(default_factory=lambda: str(uuid.uuid4()))
    sender: str
    recipient: str
    intent: str  # e.g., "request_research", "provide_analysis"
    payload: Dict[str, Any]
    timestamp: datetime = Field(default_factory=datetime.now)

I implemented this strictly. Every communication must wrap payload in this envelope. This allows us to log every interaction, replay the thought process, and debug exactly why an agent did X. As per my experience, if you don't type your agent comms, you're building a house of cards.

2. The MCP Client (The Hands)

For the agents to interact with the world, I built a simulated MCP client. In a full production deploy, this would connect to a local MCP server process, but for this PoC, I mocked the interface to demonstrate the pattern without requiring you to install 5 different sidecars.

# backend/core/mcp_client.py

class MCPClient:
    def call_tool(self, tool_name: str, arguments: Dict[str, Any]) -> Dict[str, Any]:
        """Simulates calling an external tool via MCP"""
        print(f"[{self.agent_name}] 🔌 Connecting to MCP Server... Calling: {tool_name}")
        # ... logic to route to specific tools ...

In my opinion, this abstraction is beautiful. The agent doesn't know how web_search works. It just knows it exists. This is the power of the Model Context Protocol.

3. The Orchestrator (The Brain)

This is the most complex piece. The Orchestrator manages the state machine.

# backend/agents/orchestrator.py

class Orchestrator:
    def run_analysis(self, startup_name: str) -> AgentState:
        # Initialize the shared state
        state = AgentState(workflow_id=str(uuid.uuid4()))

        # Step 1: Delegate to Researcher
        msg1 = AgentMessage(
            sender="Orchestrator", recipient="Researcher", 
            intent="research", payload={"target": startup_name}
        )
        tech_result = self.researcher.process(msg1, state)
        state.update_artifact("tech_analysis", tech_result)

        # Step 2: Delegate to Market Analyst
        # ... market analysis logic ...

        return state

I wrote this logic to be sequential for clarity, but in a production version (which I've experimented with), I would use asyncio.gather to run these steps in parallel. However, strictly sequential logic is easier to debug when you are first learning the A2A patterns.

Let's Setup

If you want to run this yourself, I've made it incredibly easy. I bundled everything into a repository structure that separates the "Brain" (Backend) from the "Face" (Frontend).

(Full details can be found at the GitHub Repo)

Clone the Repo:

git clone https://github.com/aniket-work/vc-agent-pro.git
cd vc-agent-pro

Install the Dependencies:
I kept the requirements minimal so you don't spend hours fighting dependency hell.
```
pip install -r requirements.txt
```
Verify Structure:
Ensure you see the backend/ and frontend/ folders. If you see images/, you're good to go.

Let's Run

Now for the magic moment. We need two terminal windows.

In Terminal 1 (The Brain):
Start the FastAPI server. This spins up the agents and listens for instructions.

uvicorn backend.main:app --reload

You'll see the logs light up: INFO: Uvicorn running on http://127.0.0.1:8000.

In Terminal 2 (The Face):
Start the Streamlit AG-UI.

streamlit run frontend/app.py

Navigate to localhost:8501. You will see the "VC-Agent Pro" dashboard. Enter a startup URL (e.g., https://stripe.com) and hit "Start Analysis".

Watch the Console:
You will see the "A2A" messages flying back and forth:

[Orchestrator] 🔌 Connecting to MCP Server...
[Researcher] Analyzing search results...
[MarketAnalyst] Found 3 key competitors...

In my opinion, watching these logs is the most satisfying part. It feels like watching a digital organism think.

Closing Thoughts

Building VC-Agent Pro taught me that the future involved much more than just "chatting". The code I wrote here—using A2A and MCP—demonstrates a pattern where AI can perform complex, multi-step knowledge work that was previously the domain of junior analysts.

I think we are only scratching the surface. Imagine adding a "Legal Agent" that checks for compliance, or a "Finance Agent" that reads uploaded PDFs. With the modular architecture I've laid out, adding those is just a matter of creating a new class and registering it with the Orchestrator.

I observed that the line between "Software" and "Service" is blurring. This tool isn't just software; it's a service. It performs labor. And that is a very exciting, and slightly terrifying, future.

Disclaimer

The views and opinions expressed here are solely my own and do not represent the views, positions, or opinions of my employer or any organization I am affiliated with. The content is based on my personal experience and experimentation and may be incomplete or incorrect. Any errors or misinterpretations are unintentional, and I apologize in advance if any statements are misunderstood or misrepresented.

DEV Community