CMP42 // USE CASES // PRODUCT-LED B2BUSE CASE 02 OF 04
// Use case 02 · Product-led B2B teams

READ THE ACCOUNT.
THEN WRITE THE NOTE.

You want an agent that reads a real customer’s history before it drafts the renewal note. Not the generic ChatGPT summary that gets the account name wrong. That agent needs a graph, not a HubSpot export.

// The problem

THE EXPORT IS NOT THE ACCOUNT.

In a product-led business, the story of an account is spread thin: who signed up first, who became the champion, which deal is up for renewal, what the last review deck said, what the customer asked for on the last call. Some of it is in the CRM. Much of it is in documents, recordings and notes.

The common shortcut is to pipe a CRM export through a Zapier hop into whichever agent shipped this week. The agent receives rows of text. It cannot tell a champion from someone copied on an email, so it guesses. It fills in a field that was never declared. It mentions a pipeline stage that does not exist. Not because the model is bad — because the source was not built for the reader.

The result is a renewal note that sounds confident and is subtly wrong. Someone on your team catches it, or a customer does.

// Export vs graph

WHAT THE AGENT ACTUALLY RECEIVES.

A conceptual comparison of two ways to give an agent customer context. It describes the shape of the input, not any vendor’s features.

Export pasted into a promptCMP42 Context graph
ShapeFlat rows and text, read as one blobTyped objects with named edges, read like a database
RelationshipsImplied by column names; the agent infers themExplicit: a contact owns a deal, authored a document
FreshnessA snapshot from whenever the export ranThe current graph, with every object versioned
Missing dataEasy to paper over with plausible guessesDeclared fields only; writes are validated against your Models
CitationsHard to trace a sentence back to its sourceEvery object and field addressable by URI
Writing backCopy the draft somewhere by handMCP tools such as write_note, attributed and versioned
// How it works in CMP42

FOUR PIECES, ONE RENEWAL.

Context

The account as a graph

Company, contacts, the renewal deal, product briefs, meeting recordings and notes — connected by typed edges in the Context graph. Tools like get_context and list_related let an agent walk it.

Models

Only the fields you declare

Lean defaults for contact, company, deal, task and activity. The renewal-relevant fields your team actually uses are declared explicitly in Models — nothing more. If it is not in your ontology, it is not on the contact.

Processes

A renewal note with a human step

Wrap the draft in a Process: the agent reads and drafts, the account owner approves, the approved note is written back. Every run is logged and replayable against a past snapshot.

MCP

Any agent your team prefers

Claude Desktop, Claude Code, Cursor, Cline or a custom agent on the MCP SDK read the same tools. For the rest of your stack, REST and GraphQL expose the same operations with the same auth and audit trail. MCP tools →

// Scenario

BEFORE THE RENEWAL CALL.

Illustrative scenario

Drafting the Aspen renewal note

“Aspen” is a fictional customer. The steps show how the concepts fit together; tool names and the process format are illustrative and will be shaped with the Design Partners.

  1. The account owner asks her agent to draft the renewal note for Aspen ahead of next week’s call.
  2. The agent calls get_context on the Aspen renewal deal and list_related for the people and documents around it. It sees who owns the renewal, the current renewal plan document and the notes from the last two calls.
  3. It drafts the note from that history and lists the source objects it used. When it tries to set a deal stage your Models do not define, write-time validation returns a clear error and it corrects itself.
  4. A Process step routes the draft to the account owner. She approves it; write_note stores it, attributed to the agent and approved by her.
  5. Next quarter, the team replays the same process against last month’s snapshot to check whether the note would have said something different.
processes/renewal-note · sketchIllustrative
# illustrative — the idea, not the final syntax
process: renewal_note
steps:
  - agent: read_account   # get_context + list_related
  - agent: draft_note     # cites source objects by URI
  - human: approve        # account owner signs off
  - agent: write_note     # attributed + versioned
observe:
  run_history: replayable against a past snapshot
  cost: token spend per run
// What you get — and what you do not

GROUNDED DRAFTS. NO BLACK BOX.

What changes

  • Drafts grounded in the real account, with the source objects listed.
  • A human approval step exactly where your team wants one.
  • An audit trail per run: what the agent read, what it wrote, at what token cost.
  • One graph for every agent — the renewal assistant today, the support bot next quarter.

What CMP42 deliberately does not ship

  • No proprietary “AI insights” layer. Bring the model you trust. Why →
  • No dashboards that go stale on Tuesday — until you write them yourself.
  • No 200-field contact object. Defaults are lean; extension is explicit.

Name the tool your renewals need

Design Partners can propose and name one MCP tool that ships to every future customer. Tell us on the 15-minute call what your renewal workflow is missing.

→ Apply to be a Design Partner