PitchPilot

Inspiration

Creating presentations is one of the most time-consuming parts of turning an idea into reality. Founders, students, researchers, marketers, and professionals often spend hours researching information, organizing thoughts, designing slides, and rewriting content before they can present their ideas clearly. Thus, we wanted to build an AI-native platform that acts like an intelligent research analyst and presentation strategist combined into one product. The idea is that you could type a single idea and instantly receive a fully researched, professional presentation. We also wanted to explore the power of AI infrastructure platforms like TrueFoundry to orchestrate multiple AI agents, route models intelligently, and build resilient enterprise-grade AI systems.

What it does

PitchPilot is an AI-powered research and presentation generation platform. Users simply enter an idea, topic, or startup concept such as "AI-powered smart glasses for elderly healthcare". PitchPilot then automatically

• researches the market
• analyzes competitors
• gathers trends and statistics
• generates strategic insights
• creates a structured presentation outline
• writes slide content
• generates visuals and charts
• exports professional presentation decks

The app can generate investor pitch decks, business proposals, school presentations, market research reports, product strategy decks, sales presentations, etc. PitchPilot also uses multi-agent AI workflows where specialized agents collaborate together. The agents are Research Agent, Analysis Agent, Outline, Planner Agent, Slide Writer Agent, Visual Recommendation Agent, and Quality Review Agent. The result is a professional presentation generated in minutes instead of hours.

How we built it

PitchPilot was built using a modern AI technology stack powered mainly by TrueFoundry. We used Next.js, Tailwind CSS, and shadcn/ui for the frontend while FastAPI and Python async workflows handled the backend services. For AI infrastructure, we used TrueFoundry’s AI Gateway, vLLM model serving, GPU autoscaling, observability, tracing, model routing, and failover systems to make the platform scalable and reliable. We also used LangGraph to coordinate multiple AI agents that work together during the research and presentation generation process. MongoDB Atlas was used for storing user data and semantic research caching with vector embeddings. To generate presentations, we used PptxGenJS and a PDF export pipeline. For gathering research and online information, we integrated tools like Tavily, Exa AI, and Firecrawl. PitchPilot intelligently chooses different AI models depending on the task — smaller models are used for fast tasks like creating outlines, larger reasoning models handle deeper strategic analysis, and backup models automatically activate if another model or provider experiences downtime.

How does your agent behave when an MCP server starts erroring out?

PitchPilot treats MCP failures as a first-class production concern, not an edge case. When an MCP server begins erroring out, the system detects it immediately and responds in layers:

Detection:

Health checks monitor error rates and response latency on every MCP call. A single timeout or 5xx triggers a retry; repeated failures trigger quarantine of that endpoint.

Recovery:

Unhealthy MCP endpoints are temporarily removed from the routing pool. Workflows dynamically reroute to backup MCP services or cached results, and partial task completion is preserved through checkpointing so no work is lost.

Degradation:

The agent never fully crashes due to an MCP failure:

async def get_mcp_tools(url: str, key: str) -> list:
    try:
        mcp = MultiServerMCPClient({...})
        return await asyncio.wait_for(mcp.get_tools(), timeout=10.0)
    except (asyncio.TimeoutError, Exception):
        # Degrade gracefully — skip MCP tools, agent continues without them
        return []

• If a research MCP fails → cached research or alternative providers are used, generation continues
• If a visualization MCP fails → the deck is still generated and delivered without visuals
• MCP errors at startup → agent loads without those tools, logs a structured warning via TFY observability tracing, and continues serving requests
• Users receive transparent status updates — they see which features are degraded, not a generic failure message

PitchPilot continues generating presentations even during partial MCP infrastructure outages. Core output is never blocked by a tool layer failure.

How does your agent behave when an LLM server goes down?

LLM server failures are the most critical failure mode for PitchPilot since the entire pipeline depends on inference. The system handles this at three levels:

Gateway level:

TrueFoundry AI Gateway continuously monitors inference health per provider. When a model server goes down, the gateway detects failed calls, scores provider health in real time, and automatically reroutes traffic to standby models with no code changes required:

# TFY Gateway failover chain — configured in dashboard:
# Primary:            DeepSeek-R1
# Fallback:           Llama 3 70B
# Emergency Fallback: GPT-4.1

PLANNER_MODELS = [
    "bedrock/global.anthropic.claude-sonnet-4-6",  # primary
    "openai-main/gpt-5-mini",                       # fallback 1
    "flash/gemini-3-flash",                         # fallback 2
]

async def make_graph():
    for model_name in PLANNER_MODELS:
        try:
            return create_deep_agent(name="pitchpilot", model=llm(model_name), ...)
        except Exception:
            continue

Orchestration level:

Each sub-agent call is wrapped in retry logic with exponential backoff:

from tenacity import retry, stop_after_attempt, wait_exponential

@retry(stop=stop_after_attempt(3), wait=wait_exponential(min=1, max=8))
async def run_subagent_with_retry(agent, instruction):
    return await agent.run(instruction)

Isolation level:

The 5 sub-agents run in parallel and are isolated from each other. If one agent's model goes down after retries, the other 4 still return their results. The planner assembles whatever is available rather than discarding everything.

Here are the key production behaviours:

• Exponential retry — 1s → 2s → 4s backoff before declaring failure
• Circuit breakers — models that breach error thresholds are quarantined automatically
• Checkpoint restoration — partial results from completed agents are preserved, not lost
• Asynchronous recovery — queued tasks resume on healthy infrastructure as soon as it's available

This prevents single-model dependency failures from affecting the overall user experience.

How does your agent behave when OpenAI or Claude errors out or browns out?

Brownouts are harder to handle than full outages. The model is technically responding but slowly or with degraded quality. PitchPilot was designed as a multi-provider system specifically to handle this scenario.

Brownout detection:

Slow responses are treated as failures before they become full outages. A 30-second timeout per model call ensures a browning-out Claude doesn't hang the entire pipeline:

def llm(name: str) -> ChatOpenAI:
    return ChatOpenAI(
        model=name,
        base_url=GATEWAY_URL,
        api_key=GATEWAY_KEY,
        timeout=30,       # brownout protection — don't hang indefinitely
        max_retries=2,    # client-side retry before gateway failover kicks in
    )

Automatic rerouting:

TFY Gateway tracks provider health scores in real time. When latency spikes or error rates rise above threshold, traffic automatically shifts away from the degraded provider — to alternative cloud providers or locally hosted vLLM models — before a full outage occurs.

Priority-based degradation:

Not all tasks are equal, so the system degrades intelligently:

• Critical path (outline generation, slide writing) → always routed to the healthiest available model, never skipped
• Optional enhancements for slides (advanced visual descriptions, design tips) → temporarily skipped during instability to protect core throughput
• Core output (10-slide deck + pitch copy) → always delivered to the user even if some agents degrade

Additional production protections are:

• Provider health scoring — TFY Gateway maintains per-provider error rate and latency metrics updated in real time
• Adaptive routing policies — routing weights shift dynamically based on live health scores, not static configuration
• Brownout detection heuristics — p95 latency thresholds trigger rerouting before error rates spike
• Cached inference — repeated or similar requests can be served from cache during provider instability

Challenges we ran into

One of the biggest challenges in building PitchPilot was making multiple AI agents work together reliably during long research and presentation workflows. Research data from the internet can sometimes be noisy, inaccurate, or conflicting, so we had to create validation pipelines, fact-checking systems, retry mechanisms, and hallucination reduction methods to improve accuracy and consistency. Another major challenge was balancing speed and cost, since generating a presentation requires many AI tasks running one after another, which can become slow and expensive without proper optimization. We also faced infrastructure issues such as external APIs timing out, rate limits from LLM providers, unstable model servers, and inconsistent output formatting between different AI models.

Accomplishments that we're proud of

We were able to build a platform that has a multi-agent presentation workflow which integrates resilient AI failover systems and reduce hours of manual research into minutes. We were also able to create dynamic model routing using TrueFoundry.

What we learned

Through building PitchPilot with TrueFoundry, we were able to learn how important orchestration, scalability, and reliability are when creating production-grade AI applications. We learned that managing multiple AI agents together is challenging but extremely powerful, especially for handling complex workflows like automated research and presentation generation. Using TrueFoundry helped us better understand observability, monitoring, model routing, failover systems, and GPU scaling for AI workloads. We also learned that smaller specialized models can sometimes perform better and faster than larger models for specific tasks, and that strong validation, retry logic, and backup systems are essential for building reliable AI products.

What's next for PitchPilot

Our next goals are:

• real-time collaborative editing
• voice-based presentation coaching
• live web data integration
• AI-generated diagrams and visual storytelling
• multilingual presentation generation
• Google Slides integration

Built With

• fastapi
• firecrawl
• langgraph
• mongodb
• next.js
• python
• tailwind
• tavily
• truefoundry