ContextDB + your warehouse

Use Snowflake and Databricks signals inside agent conversations.

Snowflake and Databricks are where your company analyzes what happened. An agent mid-call needs something different: a scoped, trusted answer to "may I act on this?" in the time a caller will tolerate. Run both, wired together, each doing the job it is built for.

Short answer: keep the warehouse as your system of analysis and ContextDB as your agents' system of decision. Signed webhook events stream every act, ask, and abstain into Snowflake or Databricks for analytics and evals; batch jobs load warehouse-derived facts into memory with third-party provenance. Neither system pretends to be the other.

The loop

Bring warehouse facts into conversations. Send agent outcomes back.

Snowflake / Databricks churn scores · plan tiers · service history

remember_many nightly load · source third_party

Agent runtime recall grounds · the gate authorizes

Decision events signed webhooks · evidence IDs, no content

Back to the warehouse act · ask · abstain tables · evals

The framing

A warehouse stores business data. It does not manage customer memory.

Data platforms are approaching agent memory from the storage side: managed Postgres with vector search, checkpointed conversation state, agents attached to the data cloud. The ContextDB research paper calls this "giving agents a hard drive when they need a brain": durable storage and similarity search, without the memory semantics above them.

Storage does not decide what is worth remembering, notice when a fact goes stale, distinguish a confirmed instruction from an overheard maybe, or refuse to authorize an action. Those are lifecycle and trust problems. They live in a memory layer, wherever the bytes live.

Question at runtime	Warehouse	Memory layer
What did this caller confirm?	Joinable, eventually	One scoped call, now
May the agent act on it?	Not its job	act · ask · abstain
Who attested, with what evidence?	If you built it	Decision record, always
How did agents behave last quarter?	Exactly its job	Feeds it the events

Pattern 1 · Decisions out

Send every agent outcome back to the warehouse.

Register a webhook endpoint and every decision arrives as a signed event carrying the outcome, reason, and evidence IDs, never memory content. Land the events in Snowflake or Databricks the same way you land any webhook stream, and your analysts get an agent-behavior table nobody had to design: ask rates by project, abstain reasons, confirmation latency, evidence density per action.

# signed webhook event → your ingest → warehouse table
{
  "type": "decision.recorded",
  "data": {
    "decision": {
      "kind": "action_recall",
      "outcome": "ask",
      "reason": "tentative preference only",
      "evidence_ids": ["mem_7f3a"],
      "user_id": "caller-1042"
    }
  }
}

-- then, in SQL:
SELECT outcome, COUNT(*) FROM agent_decisions
WHERE recorded_at > DATEADD(day, -7, CURRENT_DATE)
GROUP BY outcome;   -- act / ask / abstain mix, weekly

Pattern 2 · Facts in

Give agents the latest plan, churn, and service data.

Your warehouse already knows things agents should remember: plan tier, service history, account standing. Load them with remember_many and third-party provenance. They ground conversations immediately, and the gate still knows they were derived from systems, not confirmed by the person, so account-changing actions still ask when they should.

# nightly job: warehouse rows → sourced memories
rows = warehouse.query(
    "SELECT customer_id, plan, last_visit FROM crm_profile"
)

for row in rows:
    await cdb.remember_many(row.customer_id, [
        {"content": f"plan tier is {row.plan}",
         "source": "third_party", "confidence": 0.9},
        {"content": f"last service visit {row.last_visit}",
         "source": "third_party", "confidence": 0.9},
    ])

# third_party grounds the conversation;
# it does not impersonate a user's confirmed yes

Worked example

The churn save, end to end.

A warehouse-computed churn score becomes a sourced memory, grounds a save offer, and the billing change still waits for the customer's yes.

churn save · chat score grounds · yes authorizes

nightly load → churn_score 0.82 · source third_party · renewal in 9 days

Honestly, I'm thinking of cancelling.

recall → high churn risk · save offer eligible

Before you do: your renewal qualifies for two months free on annual. Want that instead?

Hmm. Yes, actually.

confirm → recall_for_action("change billing") → act · decision logged

same score · no yes the gate holds

nightly load → churn_score 0.82 · source third_party

Just checking what plans you offer.

Happy to walk through them. You're on monthly Pro today.

recall_for_action("change billing") → [] · a score is not consent

no silent plan change · the score informed, it did not decide

Pattern 3 · Close the loop

Use real agent outcomes as your evaluation dataset.

Every ask is a labeled example of uncertainty. Every abstain is a labeled gap. Join decisions against downstream outcomes in the warehouse (was the booking kept? was the credit disputed?) and you have the eval dataset teams usually pay to fabricate: real actions, real evidence, real consequences. Use it to tune policies and prove to your risk team that the gate asks exactly when it should.

Ask-rate dashboards

Track how often agents needed a human yes, by project and action type, straight off the decision events.

outcome = ask · grouped weekly

Evidence audits

Sample act decisions and review their evidence IDs against source systems. The trail is already attached.

decision → evidence_ids → review

Policy regression

Replay last month's decisions against a proposed policy change before it ships. The log is the fixture.

decisions as eval fixtures

Questions

The questions data teams ask.

Does ContextDB compete with Lakebase or Snowflake's agent products?

Different layer. Managed Postgres with vector search and checkpointing is storage substrate; ContextDB is memory semantics: provenance, lifecycle, and the action gate. The open SDK can even use Postgres as a pluggable backend. The warehouse keeps every job it has today.

Why not just query the warehouse from the agent at runtime?

Scoping and semantics, not just speed. An agent's memory read must be partition-isolated per org, project, and user, and must answer trust questions the warehouse schema was never designed to encode: source, confidence, confirmation status, and whether this evidence passes policy for this action.

Do webhook events leak memory content into the warehouse?

No. Decision events carry outcomes, reasons, and evidence IDs, never memory content. Analysts see how agents behaved; the remembered facts stay in their partitions. See the security model for the boundaries.

Connect ContextDB to your warehouse.

Open the quickstart With Postgres and friends