We Built a Product Knowledge Graph Ingestor with OpenClaw for Marketing

TL;DR

We turned hours of messy customer interviews into a product knowledge graph that feeds marketing and content decisions. The pipeline used OpenClaw to orchestrate agents that convert transcripts into events, validate them, and write graph nodes with provenance. The key lessons: treat qualitative inputs like data, enforce contracts at every hop, and make retries safe. If you need a practical path from conversations to structured insight, this story shows what worked and what did not.

The Problem We Needed To Solve

Customer interviews are gold for positioning, but they are hard to use at scale. We had dozens of recordings, lightly transcribed, and scattered in docs. Marketing asked simple questions we could not answer quickly: which feature gets praised most, which benefit is mentioned with a specific pain, and which competitor comes up in the same breath. We needed to turn qualitative chaos into structured facts without losing nuance.

Two constraints shaped the build:

• The result had to be queryable by agents and humans with traceable citations.
• The ingestion had to be resilient under real team behavior, which meant partial transcripts, edits after the fact, and intermittent network hiccups.

We could not rely on manual tagging. We also did not want a one-shot extraction that dumped JSON once and froze. We wanted an agentic workflow that kept learning as new interviews arrived.

Architecture In Brief

At a high level, we set up three agent roles and one reviewer:

• Intake agent: converts transcripts into events with a compact schema.
• Extractor agent: identifies entities like feature, benefit, pain, and competitor.
• Graph writer agent: writes nodes and edges with idempotency and provenance.
• Reviewer agent: checks contradictions and confidence, escalating edge cases.

We orchestrated the agents on OpenClaw with playbooks. Each event traveled in a CloudEvents-style envelope so downstream steps could validate fields before touching storage. The writer agent used idempotency keys to make retries safe and to collapse duplicates during replays.

Step 1Define a Minimal Schema

We started with a tiny property graph: three node types and two edge types.

• Nodes: Feature, Claim, Evidence
• Edges: supports(Claim -> Evidence), about(Claim -> Feature)

It looked simple on paper, but the choice made queries clean: marketing could ask which claim about onboarding is most supported by interviews, or which feature attracts mentions of speed benefits. That made it practical for content generation and conversion optimization experiments.

We encoded the intake event with a compact contract:

{
  "specversion": "1.0",
  "type": "com.acme.interview.transcript",
  "id": "intvw_2026_09_01_07",
  "source": "meetings://product-research",
  "subject": "segment:onboarding",
  "time": "2026-09-01T17:05:00Z",
  "datacontenttype": "application/json",
  "data": {
    "transcript": "...",
    "speaker_map": {"A": "PM", "B": "User"},
    "language": "en",
    "sections": [
      {"start": 12.3, "end": 180.5, "hash": "c7a1"},
      {"start": 181.0, "end": 420.1, "hash": "f233"}
    ]
  }
}

The key field was sections[*].hash. It seeded idempotency and replay logic later.

Step 2Extract Entities With Guardrails

The extractor agent split transcripts by section so long interviews would not blow context windows. It emitted candidate statements with four fields: subject feature, expressed benefit or pain, a polarity score, and a span pointer into the transcript. We added a rule: no statement without a span and a source pointer gets written.

Errors showed up immediately. The agent often conflated pains and benefits when users compared two products. Our fix was pragmatic. We added an explicit comparator field so the model knew when the speaker was contrasting tools, and we trained a tiny classifier that marked contrast spans. When a contrast was detected, benefits and pains were kept separate and attributed to the right feature.

Step 3Map Interview Transcripts to a Knowledge Graph

This is the heart of the build. We needed a reliable path for how to map customer interviews to a knowledge graph without inflating duplicates. The writer agent received statements and built a (Claim) node keyed by normalized text plus section hash. It then connected claims to the relevant (Feature) nodes. To keep evidence first class, every edge carried a pointer to the exact transcript span and the interview ID.

We learned that normalizing text is delicate. Dropping numbers or weak adjectives helped remove noise, but stripping too aggressively merged distinct claims. The compromise: normalize stop-phrases and punctuation, keep domain terms and counts, and compute similarity using spans rather than whole sentences. That preserved meaning while letting near-repeats collapse.

Step 4Make Retries Safe With Idempotency Keys

Agents retry in the real world. Network blips, backpressure, and crash restarts happen. Building a resilient event ingestion pipeline for marketing meant idempotency was not optional. Our rule:

key = sha1(interview_id + section_hash + normalized_claim)

On write, the ingestor checked this key and performed an upsert. If the node existed, it incremented evidence counts and appended the new span. If it was new, it created the node and edges. Retries became harmless. Replays turned into enrichment.

Step 5Add a Reviewer Agent and Human Checkpoints

We wanted trustworthy extractions, not magical ones. The reviewer agent checked for contradictions at the feature level. If two claims with opposite polarity shared high similarity and close spans, it flagged them. A human reviewer received a compact bundle containing the transcript snippet, candidate claim, and links to source evidence. Only green claims flowed to marketing.

This workflow brought two wins. First, agents stayed autonomous for routine cases. Second, when humans intervened, they did it with context, not guesswork. That kept velocity up and trust intact.

Step 6Log Everything and Make Debugging Fast

We logged event IDs, keys, edge writes, and rejection reasons with structured logs. Each rejection recorded which contract rule failed so we could fix root causes. We also added a small audit table that stored counts per interview, per feature, and per confidence bucket. When numbers drifted suddenly, we checked the last three builds and rolled back prompts or adapters.

A small but priceless practice: keep a playbook of failure patterns. If extractions spike in one language or one long-tail phrase, capture it with a label and a test case. The next time it appears, you will know which adapter, prompt, or classifier to update.

What Broke, and How We Fixed It

• Long interviews exceeded context. We fixed it by sectioning early and using spans, not whole chunks, for similarity and dedupe.
• Users compared tools within answers. We added a contrast detector and a comparator field so benefits and pains did not blur.
• Duplicate claims during replays. Idempotency keys made writes idempotent and turned retries into count increments rather than forks.
• Schema drift when research templates changed. We versioned the event contract and added an adapter that kept keys and provenance stable.
• Slow debugging. We standardized error codes and attached the last failing rule to each rejected event so we could jump to the culprit quickly.

What This Enables For Marketing

Two practical outcomes emerged.

• Content teams can pull structured insights like top three benefits associated with onboarding, with links to interview evidence. That strengthens positioning and social media automation plans.
• Growth teams can run agent-driven experiments. For example, write landing page variants based on fresh claims, then measure lift in conversion optimization without guessing which benefits matter.

To see how this fits into the broader stack, skim the AI marketing automation features to understand what ButterGrow does and how the feature set supports agent workflows. You can find that in our AI marketing automation features page.

For deeper product context, this topic blends with why product knowledge graphs matter for marketing and with how marketing feature stores help operationalize insights. If you want more narrative builds, browse more from the ButterGrow blog.

Implementation Notes You Can Copy

• Use a contract everywhere. Events should validate before writes so bad inputs die early.
• Keep evidence first class. Every claim must point to a transcript span, and every span should carry interview ID and time.
• Idempotency is a non-negotiable. Keys make retries harmless and keep graphs clean, especially when you replay.
• Human-in-the-loop belongs on contradictions. Machines are great at scale, humans are great at judgment.
• Small classifiers beat fragile prompts. A tiny contrast detector stabilized a high-error corner case.

Here is a simple writer outline that shows how upserts and evidence increments work. Use it as a sketch, not a drop-in.

from hashlib import sha1

def make_key(interview_id, section_hash, normalized_claim):
    return sha1(f"{interview_id}:{section_hash}:{normalized_claim}".encode()).hexdigest()

class Graph:
    def upsert_claim(self, key, claim_text, feature):
        # returns node_id, created_flag
        ...
    def add_edge(self, src, dst, label, props=None):
        ...


def write_statement(g, stmt):
    key = make_key(stmt["interview_id"], stmt["section_hash"], stmt["normalized_claim"])
    node_id, created = g.upsert_claim(key, stmt["claim"], stmt["feature"])
    g.add_edge(node_id, stmt["feature_id"], "about", {"confidence": stmt["confidence"]})
    g.add_edge(node_id, stmt["evidence_id"], "supports", {"span": stmt["span"], "interview_id": stmt["interview_id"]})
    return node_id, created

If you are new to agent workflows, you can get started in minutes with the onboarding flow. For teams wondering about setup, check answers to common questions.

Lessons Learned

• Contracts reduce surprise. When everything is an event with a known shape, debugging turns into reading logs rather than guessing.
• Evidence anchors trust. Marketing can trace every claim back to the exact interview span.
• Small adapters save big builds. When inputs shift, adapter layers keep the core stable.
• Humans and agents complement each other. Machines extract at scale, reviewers catch contradictions.
• Keep a failure playbook. Label and test recurrent edge cases so the next regression feels routine.

If you want your qualitative research to power messaging, ButterGrow can host the agents and wire insights into your stack. See get started in minutes to try the onboarding flow and connect the pipeline to your tools.

References

• CloudEvents specification - Overview of the event model we used for envelopes.
• RFC 6455 WebSocket - Background on real time transport options for streaming transcripts.
• Stripe idempotency keys guide - Clear explanation of idempotency patterns we adapted for safe retries.