Launching today
BackEngine MCP
Make private company knowledge usable for AI
127 followers
Make private company knowledge usable for AI
127 followers
Most companies wire Claude or ChatGPT into Slack, email, calls, tickets, and their CRM over one singular MCP. That's raw pipes into scattered systems. The model reads a slice and guesses at the rest. BackEngine MCP connects to the same tools, but reads everything first, joins all of it into one permissioned record per account, kept current, so Claude and ChatGPT always work from the whole picture. Head-to-head: 67% fewer errors, 2.4x more key facts, 65% fewer tokens vs. direct connectors.
the piece i would want spelled out is what permissioned covers. one record per account answers which customer's data this is. it does not answer which person inside your company may see which parts of it, and those stop being the same problem once the record includes tickets and slack.
support history is full of things that are true and not sharable. an internal note saying do not give this account another refund, a pricing exception someone approved once, a comment about a customer written by a person having a bad day. if an answer is assembled from everything the company knows, someone junior asking a reasonable question can get back a sentence they could never have opened themselves.
the outbound direction is worse, and it is the one i have been bitten by. a drafted reply grounded on the full record will happily repeat the internal note to the customer. inside a helpdesk the internal note and the public reply are one toggle apart, and once a model is grounding on the joined picture, nothing in the text marks which half is quotable.
so does the visibility travel with the source all the way into the answer, so a response respects the permissions of whoever asked, or is it one corpus behind one set of credentials?
BackEngine MCP
@jernej_jan_kocica Happy to walk through security and how we handle data and permissions, since this is a core part of BackEngine and because the data we handle is highly sensitive.
Four things you control.
Whose conversations come in. You tell us which employees to include. You can block one person or an entire team, either across your company or on a single account.
What gets stripped on the way in. You choose what kind of data gets redacted before we process anything. Examples are PII or refund conversations or feedback on people.
Who sees which account. An account is either open to your whole company or locked to a named list of people and groups. That check runs against whoever is asking, every time they ask.
How deep they see. We can give someone the takeaway from a conversation without the raw text underneath. So a junior teammate can learn this account has billing friction without reading the note a colleague wrote about it.
@eli_portnoy that is a fuller answer than i expected, and the fourth one is the good one. takeaway without the raw text underneath is the right shape, because most of the time what someone needs is that this account has billing friction, not the sentence a colleague typed at 6pm.
the one that is still open is the outbound direction. every control you listed runs against whoever is asking, and in the drafting case the asker is authorised. the reader is the customer. so a support agent with full access asks for a reply, the model grounds on the whole record, and the sentence that comes back is accurate, permitted, and not for that customer's eyes.
does a takeaway carry any notion of customer safe, or is that left to whoever presses send?
BackEngine MCP
@jernej_jan_kocica Fair point, and here's how we think about it.
Every line we return is labeled with who said it and where it came from, so internal notes and customer-facing messages stay clearly separate. The model reads those labels and doesn't drop internal material into a customer reply.
That said, nobody should be sending an AI-written reply to a customer without reading it first. A person reviews what goes out.
So the real question is what you want that person working from. We think a reviewer is better off seeing the complete picture of the account than a trimmed-down version of it.
@eli_portnoy labels per line is the answer i was hoping for, and i agree on the reviewer. giving someone less context to protect the customer is the wrong trade.
the one thing i would watch is whether the label survives summarisation. a line keeps its provenance, but once several lines become one takeaway, the sentence a person ends up reading has no source attached any more, and the takeaway is the artifact most likely to get pasted somewhere.
good launch, this was a better conversation than most.
@rafaella_fontes_be The benchmark framing I follow, but "kept current" is the number I'd want next. Pre-processing into one joined record means there's a window between a ticket or a Slack thread landing and the record reflecting it, and for the call-prep use case a transcript from twenty minutes ago is often the thing that matters most. What's the typical lag, and does a query tell me how fresh the record it answered from actually was?
BackEngine MCP
@rafaella_fontes_be @clement_avq Great question.
Most sources, like transcripts and Slack messages come in on webhooks, so they're usually there within minutes. A few sources we pull on a schedule instead, because the system on the other end limits how often we can ask, and those can be a few hours behind.
We update the graph as the data comes in. But in all cases, we make it clear to the AI about any potential gaps, so it knows to grab any fresh sources missing at the time of question.
BackEngine MCP
Hey Hunters! We’re launching BackEngine MCP here today, and this is one of those products that pleasantly surprises me every day I use it (and I use it everyday).
Here’s why I think it matters.
Google made the world’s public information accessible to humans. That problem is largely solved. Anyone can find almost anything that was meant to be found.
BackEngine works on the opposite problem: making your company’s private knowledge safe and usable for AI.
That knowledge comes in two forms.
First, what your company knows: how you work, what you’ve built, the decisions you’ve made, and the context buried across your products and processes.
Second, the dynamic and constantly updating relational information such as what your customers have actually said (in their own words), across every call, ticket, email, and thread. This information exists nowhere else. It cannot be bought.
It belongs exclusively to your company.
Yet most businesses can barely access it themselves. It remains trapped inside the tools that collected it, invisible to the AI that could use it, and painfully manual for the people trying to make better decisions.
BackEngine exists to unlock that knowledge safely.
Our mission is simple: every piece of truth about a customer relationship should be instantly accessible to the person who needs it, at the moment they need it.
Today, we’re taking a major step toward that future with our MCP-first solution.
BackEngine MCP
Hey Product Hunters! 👋
I’m Eli, founder of BackEngine.
Claude is becoming the next work OS.
Not a great LLM. Not a chatbot. The place where work happens.
Microsoft Office owned the workday for 30 years (with Google Workspace making progress). But work is moving to Claude, fast.
Email is already there (Gmail, Superhuman MCPs). Research is there (Deep Research). Dashboards are there (Live Artifacts). Scheduled automations are there (Co-Work Scheduled). Your data is there. Most of mine already is.
This was my morning.
I got to the office. Opened up Claude. Inside was a TLDR on all the emails and slacks I had missed with drafted responses to any that required it. I sent 8 of them.
A few minutes later I got a list of all the people that had visited BackEngine that matched our ICP, with their email address pulled up and a draft ready to go. I sent them.
I then opened up a Live Artifact in Claude that showed me what we had shipped in the past week, what tickets were being worked on, and what was not being worked on.
I then got a summary of everything we had spent money on the past 7 days. One item looked like a billing mistake. I slacked the team to find out if it was real or not.
I then had a case study interview with a customer. As soon as it was done, I asked Claude to find our other case studies and to write a similar one based on the transcript.
And then I asked Claude to summarize the morning and write this post.
A couple of takeaways.
1) Building a horizontal productivity tool in 2026 is a fool's errand. No one is going to leave Claude to use your standalone dashboard, your standalone inbox, your standalone CRM UI.
2) What's worth building: things Claude won't, that live inside Claude.
And now you can access that intelligence directly inside Claude (or any LLM) via BackEngine MCP.
BackEngine pre-process a company’s unstructured customer data - calls, emails, slack, tickets, support history - before anyone asks a question. We do three things no connector or customer pipeline does on its own:
Three things we do that no set of connectors can:
1️⃣ Improve token efficiency
In July 2026 benchmark study, BackEngine used 65-89% fewer tokens to run the same 10 cross-functional business questions when compared to using direct connectors into all of the same data systems independently
Example: Which product features have customers asked for that are gating the most revenue? Prioritize our roadmap based on impact to deals and renewals and build a PRD for the top 3 features.
291.7K tokens using direct connectors vs. 33.1K tokens using BackEngine
2️⃣ Produce consistently correct answers
In the same benchmark study, direct connectors resulted in factual errors 23.2% of the time. That means nearly 1 in 4 questions you ask an LLM, even when connected to your data sources, will still hallucinate an answer.
When using BackEngine, only 1-7.6% of the time did the LLM produce an answer that was not fully factually accurate.
Example: What 5 prospects who have gone dormant are the highest priority to re-engage with a personalized product update?
66.2% accuracy using direct connectors vs. 99% using BackEngine
3️⃣ Portability across systems
If your customer data, calls, and support history live inside one model's memory, you're locked in. Two years ago every company built its AI stack around ChatGPT. Now Claude leads for a lot of teams, Gemini has fans, and new models show up every month.
BackEngine keeps that context in a knowledge layer you own, so you can point any model at it. Switch models, keep your knowledge
❓Why this matters
Deterministic, code-built context pipelines work for some use cases, but they get expensive fast, and they don't scale to multi-agent architectures.
BackEngine's raw material is conversation — unstructured, messy, and everywhere — and it needs no mapping to start.
BackEngine isn't a tool to bolt onto one project. It's the piece of the stack that lets any client engagement scale past a single well-scoped use case into a repeatable, multi-agent system without every new agent requiring its own custom data store.
BackEngine is helping teams:
• Prepare for calls faster
• Catch risk signals earlier
• Track product feedback
• Run better renewals
• And give leadership real visibility into account health
All without adding more reporting or manual updates.
If you’re curious what it looks like in practice:
👉 You can read the benchmark study cited above here:
https://backengine.com/benchmark
We’ll be here all day to answer questions and would love your feedback!
Very excited to try this. One of my biggest criticisms of many LLMs is that I don’t need a trained model for generative purposes, I need a system which will explore an existing corpus and provide me useful information.
BackEngine MCP
@ezra_butler thank you Ezra! means a lot.
It's great to be able to unify all of this data in one place (Claude) and then be able to interrogate it directly, or have an agent act on it! Great job!
BackEngine MCP
@jason_baron thank you Jason, we really appreciate it!