Total Recall for Sales: Building DealOS with Walrus Memory and Tatum

Most sales tools summarize a call and forget it. DealOS remembers the deal, learns from the rep, and compounds what works across the organization.

Sales is an experience business, but the software is usually stateless. A discovery call becomes a summary. The summary becomes a CRM note. A quarter later, the next rep repeats the same discovery, hits the same objection, and learns the same lesson from scratch.

We built DealOS for the Tatum × Walrus Memory Total Recall hackathon to close that loop. It is an experience-driven sales intelligence agent with three connected memory layers, persisted on Walrus Memory Mainnet and verified through Tatum Sui Mainnet RPC.

Demo disclaimer: All customer transcripts and the multi-rep organizational dataset in this build are synthetic. They are clearly labeled in the product and must not be read as actual customer performance.

The problem: sales intelligence resets

A sales conversation contains more than a summary. It contains:

• the customer's real pain point and the words they used,
• the objection that stalled progress,
• the stakeholder who controls the budget,
• the buying signal that changed the deal,
• the approach the rep actually used,
• and what happened afterward.

Most systems keep fragments of that. Few keep the relationship between the situation, the strategy, and the outcome. That is why teams repeat themselves.

DealOS treats sales as a learning system, not a transcription pipeline.

Three memory layers

1. Deal memory

For each deal, DealOS remembers calls, facts, evidence, stakeholders, objections, buying signals, requirements, commitments, budget, timeline, and decision criteria.

A memory is not simply a row of extracted text. When a new call arrives, DealOS compares new facts with existing deal memories and reconciles them as:

• CREATE — new knowledge,
• CONFIRM — new evidence for existing knowledge,
• REFINE — improved understanding,
• CONTRADICT — a conflict that must be surfaced.

Previous versions are preserved. The Memory Explorer makes this visible as an interactive graph and a lifecycle timeline.

2. Personal learning

Salespeople capture techniques from books, videos, training, and experience. Those techniques are stored separately in the dealos_demo_learning namespace, synced to Walrus, and recalled semantically when relevant.

Personal learning is not mixed into deal memory or shared organizational guidance.

3. Organizational intelligence

Across deals and reps, DealOS identifies recurring sales situations, records what each rep actually did, tracks observable outcomes, and aggregates the evidence.

The result is an evolving organizational playbook:

• standardized case taxonomy,
• case instances with transcript evidence,
• strategy executions,
• observed outcomes,
• conditional guidance,
• evidence-backed playbook versions,
• approval and versioning.

The organization does not learn by counting which strategy has the most wins. It learns under which conditions a strategy was used and what evidence exists.

Why Walrus Memory

Sales memory has to outlive a single app session, a single model, and a single rep. Walrus Memory gives us a durable, portable semantic layer on Mainnet with three capabilities that matter here:

1. Durable writes — case memories, personal techniques, and approved playbooks are persisted to Walrus.
2. Semantic recall — the agent can retrieve similar situations, not just exact keyword matches.
3. Independent provenance — PostgreSQL remains the structured application source of truth, while Walrus is the semantic memory layer. A PostgreSQL write never pretends a Walrus write succeeded.

DealOS uses three Walrus namespaces:

The application uses:

• rememberAndWait() for organizational case memories and personal techniques,
• analyzeAndWait() for approved playbook versions, letting Walrus extract durable guidance,
• recall() for semantic retrieval in the UI and in recommendation generation.

Walrus writes are tracked independently in OrganizationMemorySync and MemorySync, with status, attempts, errors, blob/job references, and retry actions.

Architecture

Sales call transcript
        │
        ▼
Nemotron analysis (Zod-validated)
        │
        ├── PostgreSQL: call summary + extracted facts
        │
        ▼
Memory reconciliation against existing deal memories
        │
        ├── CREATE / CONFIRM / REFINE / CONTRADICT
        └── memory versions + provenance
        │
        ▼
Case identification (standardized taxonomy)
        │
        ├── case instance
        ├── observed salesperson strategy
        └── strategy execution
        │
        ▼
Walrus Memory Mainnet
        ├── case memory (rememberAndWait)
        ├── personal technique (rememberAndWait)
        └── approved playbook (analyzeAndWait)
        │
        ▼
Outcome tracking on later calls
        │
        ▼
Organization learning engine
        │
        ├── strategy evidence aggregation
        ├── conditional learning insights
        ├── playbook draft
        └── human approval
        │
        ▼
Recommendation generation
        ├── deal memory
        ├── personal learning
        ├── approved playbook
        └── Walrus semantic recall

Structured records stay in PostgreSQL. Semantic memory stays in Walrus. The frontend never calls Walrus directly; the server mediates every write and recall.

How it learned over time

Here is the loop we verified with real services.

Step 1 — A call creates a case

A synthetic discovery call about manual renewal follow-ups produced:

• PRICE_OBJECTION / ROI_UNCLEAR,
• a pain point about 15–18 hours per week of manual work,
• an objection about proving ROI to the CFO,
• a buying signal for a demo,
• and an observed ROI-justification strategy execution.

The case was written to Walrus with provenance and no raw transcript.

Step 2 — The organization approves a playbook

The ROI evidence was aggregated across comparable synthetic cases. The learning engine produced a draft playbook:

ROI Justification for Unclear Value Objections

The draft included conditional guidance, when to use it, when not to use it, suggested questions, exceptions, evidence counts, and a confidence score. A human approved it before it became active.

The approved version was published to Walrus with analyzeAndWait().

Step 3 — A recommendation uses the playbook

A new call was analyzed and matched to the same case subtype. The recommendation cited:

• the deal's ROI requirement and commitment,
• the customer's 15-hours-per-week pain point,
• the personal ROI-first discovery technique,
• the approved organizational playbook,
• and related Walrus organizational memories.

The recommendation was stored as SUGGESTED, not executed.

Step 4 — Acceptance is not execution

When the recommendation was accepted, it stayed accepted. Only when it was explicitly marked executed did DealOS create a real StrategyExecution with status OUTCOME_PENDING.

That distinction matters. An accepted suggestion is not evidence that anything happened.

Step 5 — A follow-up call records an outcome

A follow-up transcript said finance had approved the business case and the customer wanted to move to the proposal.

DealOS recorded:

• outcome OBJECTION_RESOLVED,
• direct transcript evidence,
• source call,
• execution status OUTCOME_RECORDED,
• recommendation status OUTCOME_RECORDED.

The case memory was resynced to Walrus with the new outcome, and the follow-up call created a new BUYING_SIGNAL / NEXT_STEPS case plus a new recommendation.

That is the loop: individual experience → deal memory → case → strategy → outcome → organizational learning → shared playbook → better recommendation → new experience.

Tatum onchain proof

DealOS uses Tatum Sui Mainnet RPC for the onchain side of the memory story.

The Tatum service calls:

• sui_getChainIdentifier,
• sui_getLatestCheckpointSequenceNumber,
• sui_getObject for the configured Walrus Memory account object.

The result is visible in two places:

• /infrastructure — live Tatum Sui Mainnet status.
• /intelligence?tab=walrus — a Tatum mainnet proof card that reads chain identifier, latest checkpoint, and the Walrus Memory account object, with a link to Suiscan.

The Walrus Memory page also links every write to Walruscan:

https://walruscan.com/mainnet/blob/<blobId>

and the memory account object to Suiscan.

Configuration note: Tatum proof requires TATUM_API_KEY in .env. Without it, the UI reports configuration missing rather than faking a successful call.

What shipped

The Memory Explorer uses React Flow and a wrapped per-call layout, so a deal with dozens of memories stays readable. Selecting a graph node highlights the corresponding lifecycle events; selecting a timeline event focuses the graph.

Evidence

The current build has:

• 20 completed Walrus Memory syncs (16 organizational cases, 3 personal techniques, 1 approved playbook),
• three active Walrus namespaces,
• real blob IDs, visible in the UI and on Walruscan,
• case-level provenance (organization, case category, subtype, source call, strategy, outcome),
• an approved playbook with versioned evidence,
• a verified outcome loop that updated a strategy execution and recommendation and resynced the case memory.

Example mainnet blobs from the current demo:

• Case memory: zy89k5okV8Mr7_eBACrZ8T6L_5lxeaPB5h-y9cFoZaI
• ROI case memory: xRbgBI8_YmG0VRYBTSzT3PxeJ4gKICphyOGV6tOq5ys
• Personal technique: rKfW6CPMRJvrCqcR9WGgWA1vtgvltyGXNzME4FE-wNg
• Approved playbook blob: BSeCwPqQJHWZTTn18HC5MgeCwxbo0ZmMbuzv22Qlq8c
• Walrus Memory account object: 0x6b7b706987c258370007e040fe4f9e3a8540a15027292f13fc2e42fdf54bbf41

What we learned

Memory is not a summary. The useful unit is a case with evidence, a strategy, and an outcome. A summary can tell you what happened; memory has to tell you what to do next.

Confirmation and contradiction matter. A CRUD list of facts is not learning. DealOS preserves versions and explicitly represents when new evidence confirms, refines, or contradicts existing understanding.

Context beats a universal winner. ROI justification looked strong in some contexts and failed in others. The playbook is conditional and evidence-scoped, not a leaderboard of “best strategies.”

Execution and outcome are separate. A recommendation being accepted is not execution. Execution is not success. Outcomes must be observed and attributed carefully.

Persistence needs honesty. Walrus and PostgreSQL can fail independently. The UI shows each status, attempts, errors, and retry actions instead of collapsing them into one “saved” badge.

Limitations and next steps

This is a hackathon build. The organizational dataset is synthetic and labeled. There is no authentication or per-user ownership boundary yet; organization scoping is enforced in the data layer, but production multi-tenant authorization is the next step.

Other next steps:

• add real rep identities and access control,
• add retraction/correction workflows for organizational knowledge,
• expand outcome attribution beyond a single deal,
• add more Tatum reads for onchain memory proof and audit trails,
• add approval history and reviewer roles,
• and tighten confidence calibration as real evidence accumulates.

Try it

nvm use
npm install
docker compose up -d
cp .env.example .env
# Fill in OPENROUTER_API_KEY, MEMWAL_PRIVATE_KEY, MEMWAL_ACCOUNT_ID, TATUM_API_KEY
npx prisma migrate deploy
npm run dev

Open:

• http://localhost:3000/deals
• http://localhost:3000/deals/<dealId>/memory
• http://localhost:3000/learning
• http://localhost:3000/intelligence
• http://localhost:3000/intelligence?tab=walrus
• http://localhost:3000/infrastructure

Load the synthetic organizational demo from /intelligence, then search Walrus Memory with:

ROI unclear CFO business case
migration risk phased rollout
ROI-first discovery technique

DealOS is a proof that sales experience can compound. Not as a chat history. Not as a CRM note. As evidence-backed memory that changes the next recommendation.

Built for the Tatum × Walrus Memory Total Recall hackathon.