Showcase: I built a podcast guest booking pipeline with OpenPipe

Hello everyone,

I've been exploring OpenPipe for the last few months, primarily for internal data enrichment tasks, but I recently pushed it into a more complex, user-facing workflow. I wanted to share a practical implementation: a semi-automated pipeline for booking guests on a technical podcast I help run. The goal was to reduce the manual back-and-forth of scheduling, gathering bios, and syncing with our calendar, while keeping a "human in the loop" for the final vetting.

The core idea is simple: potential guests submit a form on our website. That submission kicks off an OpenPipe pipeline that handles the initial legwork before a human producer takes over. Here's how the pipeline breaks down:

* **Step 1: Initial Filtering & Enrichment.** The raw form data (name, company, topic ideas) is sent to an OpenPipe pipeline. The first LLM call classifies the submission as "promising," "maybe," or "not a fit" based on our rough guidelines (e.g., relevance to software architecture). For "promising" submissions, a second, parallel enrichment step uses a tool node to fetch the prospect's LinkedIn profile summary (via a simple API proxy we built) and a third LLM call drafts a concise internal summary for our producer.

* **Step 2: Draft Communication.** If the submission passes the initial filter, the pipeline branches into generating two draft emails using separate LLM nodes. One is a polite "not for us at this time" template, and the other is a more engaging "we'd love to explore this further" email that includes specific times from our Calendly link and asks for a short bio. A human producer reviews both the internal summary and these draft emails before anything is sent.

* **Step 3: Structured Output to our System.** The final step uses an OpenPipe "Code" node. It takes the enriched data (cleaned name, company, topic, internal notes) and formats it as a structured JSON payload. This payload is then POSTed to an internal webhook that creates a record in our Airtable base, which acts as our guest CRM and syncs with our calendar.

Here's a simplified YAML snippet of the pipeline definition to illustrate the structure:

```yaml
name: podcast_guest_intake
description: Processes new podcast guest submissions.

nodes:
- id: initial_screening
type: llm
config:
model: gpt-4o-mini
system_prompt: >
You are screening potential podcast guests. Evaluate based on topic relevance...
input_template: >
Guest Name: {{input.formData.name}}
Proposed Topics: {{input.formData.topics}}

- id: linkedin_enrich
type: tool
depends_on: [initial_screening]
config:
tool_id: linkedin_lookup_proxy
input_mapping:
name: "{{nodes.initial_screening.output.name}}"

- id: producer_summary
type: llm
depends_on: [initial_screening, linkedin_enrich]
config:
model: claude-3-haiku
system_prompt: >
Create a 3-bullet summary for the internal producer...
input_template: >
Screening Result: {{nodes.initial_screening.output.verdict}}
LinkedIn Info: {{nodes.linkedin_enrich.output.summary}}

- id: create_airtable_record
type: code
depends_on: [producer_summary]
config:
language: javascript
code: |
const payload = {
fields: {
"Name": input.nodes.producer_summary.output.guestName,
"Status": "Initial Review",
"Internal Notes": input.nodes.producer_summary.output.summary
}
};
await fetch(env.AIRTABLE_WEBHOOK_URL, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(payload)
});
return { success: true };
```

**Key Takeaways & Pitfalls:**

* The visual builder is excellent for prototyping, but for production, I switched to the YAML definition for version control and easier environment promotion (dev -> staging -> prod).
* Error handling in chained LLM calls is crucial. We had to implement robust retry logic and fallback paths in the "Code" nodes when, for instance, the LinkedIn API was unresponsive.
* OpenPipe's strength here is the orchestration of different steps (LLM, tool, code) with clear dependencies. We're not using it for complex state management, which it's not designed for, but as a stateless request/response pipeline, it's been very reliable.
* Cost transparency has been good. Breaking the pipeline into discrete nodes lets us see exactly which LLM calls are the most expensive (the initial screening, in our case) and optimize those prompts first.

The result? Our producer now spends seconds reviewing a pre-digested package instead of minutes on each raw submission. It's not fully autonomous, nor should it be—the human judgment is irreplaceable—but it has eliminated about 70% of the manual grunt work.

I'm curious if others are using OpenPipe for similar "semi-automated" human-in-the-loop workflows, especially around external communications or data intake. What patterns have you found effective?

—Felix