LaunchPilot

Inspiration

Small creator teams and growth managers are surrounded by social performance data, but the hardest part is not collecting numbers. The hard part is turning those numbers into a confident next step: what changed, why it might have changed, what to test next, and how to explain that decision to a team or client.

LaunchPilot started from that gap. We wanted to build an AI workroom that does not just summarize a CSV, but helps a human move from growth signal to evidence-backed hypothesis to an approval-ready experiment.

What it does

LaunchPilot is a multi-agent campaign planning workroom for content and growth teams. A user uploads social media performance metrics as a CSV, then works with an agent through a conversation-first interface.

The system analyzes the campaign data, finds meaningful growth signals, grounds its reasoning in evidence from Elastic, generates hypotheses, drafts next-week content experiments, and asks for human approval before anything becomes a committed plan. Approved outputs become a Growth Brief and calendar-ready experiment items.

The core loop is:

Signal → Hypothesis → Experiment → Approval → Brief → Continuity

How we built it

The product has three main services:

• A Next.js frontend for the LaunchPilot workroom UI
• A Java 21 / Spring Boot backend that owns CSV import, WebSocket streaming, approval handling, and persistence
• A Python FastAPI agent service built around Google ADK and Gemini

Elastic Cloud Serverless is used as the evidence engine and primary data store. The agent retrieves campaign context and supporting evidence from Elastic, while the backend writes imported content metrics and approved outputs. We also instrumented the agent flow with OpenInference/OpenTelemetry for traceability through Arize/Phoenix.

The agent architecture is intentionally round-based. It does not automatically run the whole pipeline after one message. A user can ask for analysis, discuss the signal, request hypotheses, revise the experiment plan, and only then approve the final output.

Challenges we ran into

The biggest challenge was making the system feel like an agent without letting it become a black box. We had to separate conversational freedom from product safety. The agent can reason and propose, but deterministic gates validate artifacts and the human controls final approval.

Another challenge was designing the frontend contract. Instead of exposing many workflow-specific APIs to the UI, we designed a simple stream contract: the frontend sends message.send, and the backend returns normalized StreamMessage.blocks[]. That made the interface feel like one continuous workroom while still supporting structured artifacts, tool activity, approval gates, and receipts.

We also had to handle real integration boundaries across Gemini, Elastic, Java, Python, and the browser UI while keeping the demo reliable enough for a hackathon submission.

Accomplishments that we're proud of

We are proud that LaunchPilot is not just a chatbot wrapper. It has a real multi-service architecture, a conversation-first workflow, human approval, Elastic-backed evidence retrieval, and structured outputs that can become briefs and calendar events.

We are also proud of the product shape. The interface lets a marketer stay in one thread while the system exposes enough evidence, tool progress, and review gates to make the agent's work inspectable.

What we learned

We learned that useful agents need boundaries as much as they need autonomy. For this use case, the best experience was not “AI does everything,” but “AI proposes the next best experiment and the human approves what becomes operational truth.”

We also learned that Elastic works well as more than a search layer. In this project it became the shared memory and evidence substrate for campaign metrics, prior briefs, runtime context, and approved plans.

What's next for LaunchPilot

Next, we want to connect real social platform APIs, add richer campaign memory across multiple cycles, and improve the approval workflow so teams can compare experiment variants before committing them. We also want to expand the observability layer so judges, developers, and users can inspect why an agent made a recommendation.

Built With

• arize
• elasticsearch
• fastapi
• gcp
• googleadk
• python