One organization, one brain.
One LeapMemory tenant becomes your company's shared memory. Everyone speaks into it, from every channel. The system keeps their exact words and knows who said what.
✓Mike, engineering: "Ridgeline moves to Postgres. Main reason is the Meridian audit requirement."
✓Emily, support: "Meridian asked when the audit export lands."
The answer comes back in Mike's exact words, with his name on it.
Every channel, one company memory.
Your integration is a thin forwarder. Whatever the team already talks through, forward each message as a turn with a speaker_id. Turns go in, recall comes out. No memory logic lives in your code.
- Slack
- Support desk
- Company agent
ridgeline
one tenant, its own databases
- Every word kept verbatim
- Tagged with who said it
- One graph for the company
- Recall and briefing, free
Clone it. Ask it. Get the original words back.
The demo ships a fictional company called Ridgeline: 30 turns of a team at work, Sarah in sales, Mike in engineering, Emily in support. Five small scripts, Python standard library only, about $5 in credits.
$ git clone github.com/leapmemory/lm-org-memory-demo $ cd lm-org-memory-demo $ cp .env.example .env $ python3 create_org.py tenant ridgeline ready $ python3 import_history.py # polls until every turn is indexed $ python3 ask.py "why did we choose postgres?"
Q: why did we choose postgres?
what the company knows:
- Postgres was chosen driven by the
Meridian audit requirement.
- Ridgeline database decision is Postgres.
- Ridgeline is fully migrated to Postgres.
who said it, word for word:
[mike] Decision made. Ridgeline moves to
Postgres. Main reason is the Meridian
audit requirement, transactional audit
tables are simple in Postgres and a
nightmare in Mongo.
Three months later nobody at the company has to remember. The memory does, in the engineer's own words. brief.py returns the same company as one injectable block. Load it at session start and a new hire's assistant already knows the customers, the decisions, and the history.
The new hire already knows.
A new assistant session at Ridgeline starts with the company briefing. The first question gets a real answer with a name on it, not a guess.
The briefing loads at session start. Recall answers the rest. Both free.
One company, several memories.
One tenant per company is the default. When some knowledge should not reach everyone, use more tenants. People write into the tenants they belong to, and each assistant loads only the briefings its user is entitled to. The separation is structural: separate databases, not a filter on shared ones.
- Salesdeal notes, customer promises
- Engineeringdecisions and trade-offs
- Supporttickets and workarounds
- Legalcontract terms
- Executivesboard context
-
ridgelineSalesEngineeringSupportLegalExecutives -
ridgeline-leadershipExecutives -
ridgeline-legalLegalExecutives
A key scoped to ridgeline returns 403 scope_denied against ridgeline-leadership. There is no query path between them to get wrong.
Each tenant is complete on its own: its own graph, its own briefing, its own history. Knowledge meant for two tenants is written into both, and each keeps a full, independent copy.
Write down, read up.
A person writes into every tenant they belong to. Their assistant briefs from every tenant they are entitled to. Nothing else exists. Access is not a rule checked at query time, it is which databases you were ever connected to.
ridgeline
ridgeline-leadership
ridgeline-legal
Different departments, different databases. Three tenants means three separate sets of databases with nothing between them. Elsewhere this is a namespace label and a filter on one shared store. Here there is nothing shared to filter. Each tenant runs with engine-enforced isolation, its own databases and credentials, with dedicated infrastructure available on demand.
Run it on your team's real traffic.
Clone the demo, point it at one tenant, and see what a week of your own messages becomes. Questions about running it for your team? Write to us, a human answers.