Knowledge Atlas by Fini

Hey Product Hunt :wave: Deep here, co-founder of Fini. Over the past few months we spent 300+ hours with our customers just watching how they maintain their knowledge. One thing was constant: everyone hates it. Support teams lose 20 hours a week updating the help center by hand. A feature ships, a policy changes, and someone on the CX team spends their Friday rewriting articles. Every one of those updates is "urgent." The deeper problem: when an AI support agent gives a bad answer, the model is almost never the reason. The knowledge is. Stale articles, contradicting articles, missing articles. You can't prompt-engineer your way out of bad source data. So we built Knowledge Atlas, a self-learning knowledge base that updates itself: - Connect your sources (help center, PDFs, past tickets, Slack) and Atlas builds a structured tree of cited articles - Every resolved ticket becomes a new article automatically - Conflicts between articles get caught and flagged before customers ever see them - Every answer traces to exactly one source And there's no RAG underneath. Search is LLM-native: the agent navigates the tree and reads whole articles the way a person would, instead of retrieving chunks and stitching them into blended answers. Our compliance-heavy customers in banking and healthcare care about that single-source traceability more than any accuracy stat. Wefunder is already live on it: 22% increase in autonomous resolution, 30% increase in knowledge coverage, same team. The knowledge compounds now instead of decaying. We'll build a free Atlas from your real docs in 24 hours, so you can judge it on your own knowledge instead of a polished demo. I'll be here all day. Ask me anything, especially the hard questions about why we walked away from RAG. Show more

the part that gives me pause is "every resolved ticket becomes a new article automatically." a resolved ticket isn't the same thing as a correct or generalizable answer, sometimes a resolution is a one-off workaround, a support agent's judgment call that shouldn't be policy, or honestly just the AI getting lucky on an edge case. auto-promoting that into a permanent cited article feels like it could bake exceptions in as rules over time, which seems like exactly the kind of slow-drift problem you're trying to solve with the conflict flagging. is there a review step before a ticket-derived article goes live, or does it publish straight into the tree and rely on the conflict detector to catch it later

@akash_29  that review screenshot actually answers it well, the diff view with reject/publish as separate steps is basically the guardrail I was asking about. good to see it's not just a policy statement but an actual UI gate. appreciate the detail

"fully autonomous in 30 days" for banking support is the line that'd make our compliance team nervous, not because the accuracy number is wrong but because autonomous means nobody signed off on the specific answer that went out. in a regulated industry the audit trail of who approved what usually matters as much as the answer being correct. does a human ever get a say before an article it wrote itself starts getting cited to customers?

The promotion gate reads solid, and Gal's thread pushed you to show the diff and reject UI, which helps. The failure I'd watch is the opposite direction: retirement. Auto-generating articles grows the base fast, but a resolution that was correct in March becomes a confidently-cited wrong answer the day a policy changes. In our own self-updating knowledge store, adding was trivial and detecting that a new article contradicts and should supersede an old one was where the real engineering went. Does Atlas check a new article against existing ones for conflict, or is the loop mostly additive?

Conflict detection as the mechanism is more robust than a plain TTL, that makes sense. The case that burned us wasn't two articles that obviously overlap, it was two that never shared keywords but still contradicted: an old refund window buried in a policy doc versus a newer one sitting in an FAQ. Nothing textual linked them, so a naive same-topic check slid right past it. Are you clustering on meaning or on citation overlap to decide two articles are really about the same thing?

Auto-writing help articles from resolved tickets is the maintenance loop everyone skips, so the input-quality gate is what I would trust-test first. When a ticket gets resolved with a workaround or a wrong-but-accepted answer, what stops that from becoming a canonical article the AI then cites confidently? And the conflict flagging: is that just detecting two contradictory articles, or does it also catch an article that has gone stale against a product change no one has filed a ticket about yet?

Sounds very interesting, I have not seen per resolution pricing. I would be more cautious about the setup/onboarding. If it needs to tie into your APIs, this is basically like a full-on product integration vs. an additional extension. What is the typical onboarding time for a customer from signup to full autonomy for a SaaS? I would think it would take lots of time from your CTO to get it done.

clarifies it, thanks. the audit trail piece is good. still wondering about volume though - if a team's got hundreds of resolved answers generating article updates per week, does the review queue actually get worked through, or does it pile up and people start rubber-stamping to keep up?

@galdayan Hi Gal, thank you for your question. CTO of Fini here. There is a strict relevancy filter (checking generalizability, correctness, etc) before a candidate resolution is suggested for review. Only a certain (usually single-digit) tuneable percentage makes it past that filter. Post that, a human has to check the draft update that was created before approving it and turning it live. We got inspiration from Pull Requests - so indeed we have gated this appropriately as our clients have stringent requirements for accuracy.

@galdayan great obsrvation Gal, and people are really skeptical about it as well. To give clarity: 1. Yes, considering a resolved ticket might be correct every time, that's why we have a test suite + a separate AI agent evaluating each answer before suggesting any article update. 2. And Yes, there is a review step for every suggestion our AI agents takes before updating an article. It shows the diff suggestion to a human agent, and then human agents takes the last and final action (screenshot attached)

@galdayan I'm glad it makes it clear Gal. Thank you so much :)

@omri_ben_shoham1 Hey Omri, Yes. Always. Whenever a new get's written from resolved answers, or if there is any update in the existing article... it's always flagged for review for a human agent to check and update, and then submit the changes by themselves with exact audit details of who took the action, when and what the action is. I hope that clarifies things :)

@dipankar_sarkar Hey Dipankar, yes. This is in fact one of the main thing what Knowledge Atlas does. Just like finding diff of an article, it finds conflicting articles on the same topic, and suggest a merge with automatic content update based on the freshness, and resolved answers combined, and then flagged for review for a human agent to check, do any updates and approve/reject

that audit trail detail is the part that actually matters to me, knowing exactly who signed off and when. good to hear it's not just "reviewed" in some vague sense. curious how that review queue holds up once you've got hundreds of articles updating a week, does the human step ever become the bottleneck?

@dipankar_sarkar Great question Dipankar, and that's actually the first step Knowledge Atlas does every time. With all the sources and knowledge dump, Atlas's AI agents creates a knowledge tree first, with articles and sub-articles, and name them based on what each article really mean. So if there are 2 articles coming from diff sources inside the tree, they gets merge on the node (sub-article) level, with the same process of identifying the conflict, and then flagged for review. So yes, Atlas create this tree based on the meaning first and then resolve it through human intervention.

@noctis06 That's a great great question, Noctis. So when Knowledge tree get created through all the sources, we ask our customers to put their policies, PRDs, all the other documents through different channels (screenshot attached), so Atlas becomes a single source of truth of a company's knowledge. When there is a stale article against a fresh one in policy, it immediately flags in based on the meaning of the article for a human to review, do the updates then and there and publish it.

@adam_el_gerbi We achieve full autonomy in 30 days after a customer signs up. After that, there could be of course fine tuning and feedback loops happen with our team of AI engineers to increase the resolution rate upto 90% as AI act on case to case basis the complexity and the use case. We typically achieve 90% resolution in 60 days from start date.

@omri_ben_shoham1 Another great one Omri! Volume never becomes a bottleneck as we have an (another) ai agent just for that, where you can create clusters, assess and analyze hundreds of article updates through simple prompts and give instruction to that ai agent on how and what to resolve and it does the job and gives a report on what has been done based on your instructions.

thanks — the human-in-the-loop review for stale-vs-fresh conflicts makes sense. The case I'm still chewing on is the one with no conflicting article to trigger a flag: a ticket closed with a plausible-but-wrong workaround has nothing to contradict it, so it just becomes the canonical answer Atlas cites. Is there a confidence or verification signal on the source resolution itself — e.g. did the customer confirm it actually fixed the issue — before it graduates into an article, or does every resolved ticket qualify?