Quick start
An empty workspace to a working one, in the order the console is arranged. Import something, then walk the nav from top to bottom.
Before you start
- A workspace. One team's sources, facts, and people. See Set up a workspace.
- A sign-in. Everything except Setup and the sign-in page needs a session.
- A model provider. Embeddings and answers both need one. Set it under Settings, Models.
Import your content
Go to Sources. The page is called Sources & connectors, and a new workspace opens on "No sources connected yet".
Pick a connector from the grid. GitHub, Slack, Google Drive, Confluence, Notion, Jira, Linear, Zendesk, Airtable, Asana, Dropbox, and Trello are in the catalog, and you can upload files directly instead.
Each connector asks for the least it can, usually a credential and a scope. Some examples of what that means in practice:
- GitHub wants a fine-grained personal access token, a repository, and optionally a branch, file globs, and which content types to read (files, issues, pull requests, commits).
- Slack wants a bot token, optionally a user history token, and the channels to track.
- Confluence wants the site URL, an account email, an API token, and a space key.
Scope is explicit everywhere. Connecting Slack does not read every channel, and connecting Confluence does not read every space.
Use Test connection first. It asks the provider whether the credential works, so a typo fails in a second rather than at the end of a sync. Then Connect & sync, or Upload & sync for files.
The first sync
The connect flow runs inline: configure, then syncing, then done. The sync fetches the tracked refs, chunks each document, hashes each chunk, and embeds only the chunks whose hash changed. It moves through queued, syncing, and done, and a failure shows as an error rather than a silent stall.
Re-syncing something that has not moved is close to free. The hashes match, so nothing is re-embedded.
Staying current
GitHub deliveries arrive by webhook, so a push re-syncs immediately. The same
webhook carries the fact-check bot: mention @mari in a pull request
description or an issue comment, or add the mari:factcheck label, and Mari
checks the change against what it knows and replies in the thread. Set the
payload URL and signing secret under Destinations, Bots, and subscribe the
webhook to Pushes, Issue comments, and Pull requests.
Home
The overview. Until the first sync lands you get "Connect your first source", and after it you get the week: a stat row, a digest of what changed, a pulse tile per source, the documents touched most recently, and a live activity feed.
Read the digest first. It is the fastest way to find out whether Mari read what you expected it to read.
Knowledge
The library. Search across everything indexed, filter by source and type, and switch between result types with the tabs above the feed. Slack results arrive as thread-sized chunks rather than single messages.
Open a result and the inspector opens on the right: tags you can edit, a summary and a raw metadata view, the verified facts on that document, related results, a revision timeline, and a link into the graph.
Tag two or three documents you trust as canonical. Tag weights bias retrieval, so this is the cheapest thing you can do to make answers better.
Facts
A fact is an assertion lifted out of a document so it can be owned and checked. The table shows claim, owner, whether it is verified, and status, with filter tabs for verified, needs review, contradicted, and stale candidates.
Add one with New fact: the claim, where it came from, and who owns it. Then verify it, which is a person saying it still holds. Mari can flag that an assertion is old or that something contradicts it. It cannot tell you the assertion is true.
Each row can run an impact analysis to show which documents lean on it, and can raise a review task.
Decisions
The ledger of what the team chose and why. Records run as a timeline, with an "Awaiting sign-off" rail for the ones still unratified, and a filter for the rest.
Capture decision takes the decision, the reasoning behind it, and where it was made. A decision can be signed off, superseded later, or traced for impact. This is usually the thing new people most need and least often find.
Lineage
The graph tying documents, commits, pull requests, and decisions together. The toolbar has three bands: filter by source, relation, and status, then set the view, then act.
Two things worth trying first. Color by repaints the graph by source, staleness, ownership, or health, which is how a stale corner becomes visible at a glance. Find path asks you to pick two nodes and draws the route between them.
From a node you can trace impact downstream or provenance upstream, and the scrubber along the bottom moves the graph to an earlier date.
Workflows
What Mari did while it worked, in two tabs.
Observed is every run the agent harvested: the tools it called, the documents it leaned on, and the outcome. Inspect a run, then codify it if it is worth keeping, which turns the traced steps into a named workflow.
Approved answers is what those runs are promoted into, the wording the bots and chat surfaces serve back. An answer carries the run it came from, so you can always read the working.
Destinations
Where curated knowledge goes out. Three tabs.
- Knowledge chat publishes a chat surface with its own name, title, welcome message, and tool list. It starts as a draft and goes live when you deploy it.
- MCP servers issues a scoped server plus its token and connection snippet, for an agent or editor that speaks MCP.
- Bots sets up the Slack bot and the GitHub webhook. Both cards report an honest status, including "Waiting for first event".
The route is still /publish, which is worth knowing if you have an old link.
Analytics
Read-mostly evidence that the knowledge base is working: headline counts, readability grades per document, glossary health with suggestions you can accept or dismiss, recent audit activity, and freshness by source.
Counters count real events from the day counting started. They are not backfilled.
Sources
Come back here once content is in. This is where each connection reports its last delivery and current sync state, so a source that quietly stopped delivering is visible rather than assumed.
Set a sync schedule per source while you are here. The options run from manual only to every 10 minutes, and daily is a reasonable default for anything without webhooks.
Settings
Six tabs: General, Members, Models, API keys, Audit log, and Design & brand.
Members is where the rest of the team gets in. They inherit the workspace's sources rather than connecting their own. Models sets the embedding model, the provider and its keys, and per-source chunking, with a connection test beside it.
Ask Mari
The agent dock opens on every page. It has the permissions you have, and it can search and read documents, tag them, manage facts and answers, trigger a sync, and move the console around you while the conversation stays open. Source documents stay read-only. Everything it does lands in the audit log.
Good first questions are the ones you already know the answer to, because that is how you calibrate it. "What changed in the handbook this week." "Which facts are stale."
Answers lead with the answer and carry numbered citations, and each number is the document, commit, or thread behind the claim. Follow the citation before you trust the sentence. When the sources do not cover something, Mari says so in one sentence instead of guessing.