cuneifyApply

Stop answering the same question twice.

cuneify catches the answer the moment an expert gives it and presses it into your wiki as a reviewed, cited update. The next person who asks finds it in the docs, not in the inbox of the one person who remembers.

Works with Confluence, with every change reviewed in GitHub.

cuneify results screen: Dan Okafor, senior commodity manager, identified as the expert, next to a new wiki section on the approved alternate for connector 4471-220, generated from his conversation with Priya.
A conversation about a part on allocation, pressed into a wiki update and credited to the person who answered.

The problem

The answer exists. It’s in someone’s head.

The knowledge that matters lives with a few veterans: which alternate is approved, what a supplier promised in the last escalation, why a part was qualified. The rest is scattered across inboxes, spreadsheets, and a wiki nobody has touched since the last shortage.

  • Every hard question routes through the same few people.
  • Every new hire pulls them into the same onboarding calls.
  • Every internal chatbot ships with their knowledge missing.
  • Every time one of them leaves, the knowledge leaves too.

LLMs didn’t fix the documentation problem. They exposed it.

Every company plugged a chatbot into its wiki. The chatbot answers confidently from pages that are stale, half-finished, or were never written.

Models get better every month. Your docs don’t, because the knowledge that matters is still said out loud and never written down. Meanwhile, retention policies delete the chat threads where it was.

A brain is only as good as what you feed it.

Ur, about 2100 BC

The first writing was bookkeeping: tallies of goods delivered and owed. Supply chain is the oldest documentation problem there is.

How it works

Capture, not search.

Other tools try to make the wiki you have easier to search. cuneify works upstream of it: it catches the answer at the moment it’s given, so the wiki keeps up with the team.

  1. 01

    Find who actually knows.

    Ask in Claude or ChatGPT through MCP, or in the cuneify app. If the wiki has the answer, you get it with the page it came from. If it doesn’t, cuneify points you to the person who owns the topic, based on who wrote and maintained the pages, not the org chart. It also shows you where only one person knows the answer.

    Sourcing wiki Β· 7 people Β· 8 topics3 topics with one owner

    Hover or tap a name or topic. Dan is the only person who knows two of them.

  2. 02

    Capture the answer as it’s given.

    The expert answers the way they always do. cuneify reads the conversation, pulls out the part worth keeping, and drafts it as a clean wiki section, credited to the person who said it.

    cuneify conversation view: Priya asks whether connector 4471-220 has an approved alternate now that it is on allocation, and Dan explains which Kessler part is qualified and who to call.
  3. 03

    Review it, then merge it.

    The draft becomes a proposed change to the right page. A teammate approves it like a pull request, but it reads like a normal wiki page. Nothing ships unreviewed.

    cuneify review screen: the new approved-alternate section for connector 4471-220, pending review, with Reject and Approve and Merge buttons.

The next time someone asks, the answer is already in the docs.

Integrations

Fits the stack you have.

Not a new wiki, and not another chat window. cuneify sits between the tools your team already uses and steps in at the two moments knowledge usually gets lost.

  1. 1

    Someone asks a question

    In Claude or ChatGPT through MCP, or in the cuneify app.

  2. 2

    The wiki answers, if it can

    With a citation to the page it came from.

  3. 3

    cuneify routes to the right expert

    By who actually owns the topic.

    Today

    DM the wrong person, or wait two days for a meeting.

  4. 4

    Expert and asker talk it through

    In a meeting today. Slack threads are next.

    Today

    the conversation evaporates when the thread auto-deletes.

  5. 5

    cuneify drafts the update. Your team approves.

    Cited, reviewed, then merged to the wiki.

  6. Next person gets the answer.

Principles

Three rules we don’t break.

Documentation only helps if people trust it. So cuneify borrows the trust model software teams already rely on: version control and review.

  1. Rule I

    It never writes to your wiki on its own.

    Every change is a proposal. A person on your team approves it before it lands.

  2. Rule II

    Every change traces back to a person.

    Who said it, in which conversation, and who approved it. A git log for what your team knows.

  3. Rule III

    Every answer cites its source.

    If the docs can’t back an answer up, cuneify says so and points you to the person who can.

Put what your team knows on the record.

We’re working with a small group of teams as design partners, starting with supply chain.

  • A pilot on your own wiki, set up with you by the founders.
  • No charge until your team has approved its first updates.
  • A direct line to both founders, and a say in what we build next.

All we ask in return is honest feedback. You’ll hear back from a founder directly.

We only use this to get back to you. See our privacy policy.