For Automation Agencies

Your client bots forget the client
between every single run.

You've built beautiful GoHighLevel, Make and n8n automations. But every workflow run starts blank — no history, no preferences, no "we already tried that with this client." Memory is the feature your retainers are missing.

Get a Free API Key See the webhook call ↓

Plain REST + JSON · Works from any HTTP module · Per-client namespaces built in

The retainer-killer nobody talks about

Three ways stateless automations quietly bleed your agency:

churn risk

Client asks the AI receptionist about last month's conversation. It has no idea. Client concludes the "AI" is a toy — renewal gets shaky.

margin leak

Your team manually re-briefs every workflow with client context — hours per client per month that you can't bill for.

cross-contamination

You tried a shared vector store once. Client A's data surfaced in client B's bot. Never again — so now nobody gets memory.

Agencies that ship memory charge more and churn less.

"Your AI remembers every conversation, every preference, every past campaign" is a line item clients pay for — and a moat competitors without it can't cross.

The fix

One brain per client.
One HTTP module per workflow.

RJ Knowledge Graph is plain REST + JSON — it drops into GoHighLevel webhooks, Make HTTP modules and n8n nodes exactly like every other API you already use.

Per-client namespaces

Pass agent_id: "client-acme" on every call. Hard isolation — client A's memories can never leak into client B's bot. Audit-friendly.

Webhook-native REST

Two endpoints run your whole memory layer: POST /api/memory/remember to store, POST /api/memory/recall to retrieve. JSON in, JSON out.

White-label ready

Your clients never see us. It's your "proprietary memory engine" — resell it inside retainers at whatever margin you like.

Make.com HTTP module / GHL webhook — store after every call

POST https://rj-knowledge-graph.pages.dev/api/memory/remember
Content-Type: application/json · X-API-Key: kg_your_key

{
  "agent_id": "client-acme",        ← hard namespace isolation
  "content": "Call w/ Dana (CFO): wants email follow-ups only,
              renewal March, budget approved for tier upgrade",
  "memory_type": "episodic"
}

→ entities auto-extracted: Dana, Acme, renewal-March…
→ next workflow run: POST /api/memory/recall
  {"agent_id":"client-acme","query":"how should we follow up with Acme?"}

Copy-paste into any HTTP module. Full API reference →

The 3-step agency playbook

Wire memory into one client

Add store/recall calls to your busiest workflow. Takes one afternoon in Make or n8n.

Demo the difference

"Watch: your AI remembers last month's campaign." That demo closes upsells on the spot.

Roll out + reprice

One namespace per client, one line item per retainer: "persistent AI memory." Pure margin.

"Yeah, but…" — answered.

Can client data ever cross between namespaces?

No. Every memory is written and recalled with an agent_id namespace, enforced at the query layer on every call. Client A queries can only ever touch client A data. You can also run one API key per client for billing separation.

We are not developers — how hard is the integration?

If you can configure a webhook or an HTTP module, you can use this. Two JSON endpoints (store and recall). Most agencies wire their first workflow in under an hour with the docs open.

Can we white-label it in client proposals?

Yes. Clients only ever interact with your automations — the memory layer is invisible infrastructure. Call it your proprietary memory engine; we will not contradict you.

What does it cost at agency scale?

Free tier for pilots, $49/mo Pro covers a typical multi-client agency, $499/mo Enterprise for high volume. Compare that to one hour of un-billable re-briefing per client per month.

What happens if we leave?

Full export per namespace in JSON, GraphML or Cypher, any time. Your client data walks out the door with you — no hostage negotiations.

Your client bots forget the clientbetween every single run.