The product

# How Maplith works

Maplith builds a map of how your company works and keeps it current. Your AI uses it as its brain. Four steps, the same for every company.

[Build your first map, free](https://app.maplith.com/login) · [See the MCP tools](https://maplith.com/agents)

1 · Learn

## It learns how your company fits together.

Connect the systems you already use, or upload exports. Maplith finds what your business is made of, such as customers, orders and returns, where each one lives, and how far each link between systems can be trusted.

helpdesk ticket → order the demo web shop’s map

**78 %**

of helpdesk tickets link to their order

**22 %**

have the order number left blank, so your AI knows not to rely on the link

From the map of Acme Commerce, a fictional web shop

2 · Notice

## It notices what needs doing.

Tell it what matters to you, such as a product that is sold out but still advertised. Maplith checks after every scan, and daily or weekly for a connected system, and tells your AI when it happens.

A rule, written by you the demo web shop’s rule

**rule**

A product that is sold out and still advertised

**stock**

is zero, in the web shop

**ad spend**

over the last day is above zero, in the ad platform

**per**

product, through links Maplith tested against your data

3 · Brief

## It briefs your AI for the task.

For each task your AI gets one brief, so it never starts from zero. It works with the AI you already use: ChatGPT, Claude or any assistant that speaks MCP.

The brief, for one task the demo web shop’s support case

**what**

A damaged order sent back within 30 days, and a refund the customer asked for

**where**

The order in the web shop, the conversation in the helpdesk

**how**

Your returns playbook, step by step

**limits**

Label the return on its own; a refund above the limit needs a yes from a person

4 · Decide

## You decide where it matters.

Your AI asks before it acts. You choose what it may do on its own and what needs a yes from a person. Approve in Maplith, and every request, decision and outcome is logged.

Refund 328 DKK for a damaged return the demo support loop

**proposed**

by the assistant

**approved**

by a person

**carried out**

once, and logged

### Your data stays yours

Maplith keeps the map, not copies of your tables. Your exports are kept only as long as it takes to build the map.

### Nothing to replace

Your tools stay as they are. Nothing is migrated: your AI does the work in them, with its own access.

### Any AI you choose

Works with the assistant you choose. The app and your map are hosted in the EU; model inference runs in the United States.

In detail

## Every part, for the people who will run it.

The four steps rest on the parts below. Your AI reaches each one through the tools on [the agents page](https://maplith.com/agents). The [docs](https://maplith.com/docs) go deeper on each.

Atlas — Acme Commerce the demo map

dashed edges are weak joins, and weak joins become findings

The map

## Where everything is, and how it connects.

Business objects grouped by domain — Customers, Sales, Finance — with field-level documentation written for agents: what each field means, which system owns it, where else it is found, what one row of the object is, and whether a field holds personal data, and of what kind. Joins are measured, not guessed: the engine tests pairs of columns across your exports and publishes a join with its direction, its cardinality and how well each side matches; the model names it, and a join the model proposes beyond those is tested the same way or marked untested. A join that holds only partly is shown with its caveat — that is where the business loses information.

support_conversation Communication · intercom/conversations.csv

**fields**

12 documented, 0 flagged as personal data

**joins**

11, among them to the customer and the conversation’s messages

**tags**

Free text in the helpdesk export: the link to tags and to the policies rests on it, not on an id.

From the demo map · get_object support_conversation and list_findings

A map that holds still

## What you confirm stays confirmed.

In the glossary you confirm what your business calls things: a term’s name, the files that are it, what one row of it is, and the joins between terms. A later scan never renames, re-grains or removes what you confirmed; where it disagrees, it raises a proposal and you decide. The same holds for everything your agents build on: what a scan adds applies, and what it would drop becomes a proposal with its evidence, rather than disappearing from under a rule or a key. Every scan is kept as a version of the map, and an admin can make an older one the current map again — as a new version, with a signal that tells your agents it happened.

### A later scan disagrees with a term you confirmed

proposal

It raises a proposal, with its evidence, and you decide.

Confirmed by you: never renamed, re-grained or removed by a scan

Findings

## What the map exposed.

Cross-system discrepancies with concrete evidence: refund times typed in rather than measured, shipping costs that never reach the margin, a support team that is never assigned a conversation. Every finding ships with file-level evidence, a recommendation, and a lifecycle — open, planned, automated, dismissed — and keeps its identity across rescans, so findings become a work queue, not a report that gathers dust.

### Refund times that are typed in, not measured

finding

- open
- planned
- automated
- dismissed

In our test company: all 566 refunds take exactly 2 days

Processes

## How work actually flows.

Discovered from the dates in your exports: tables with an ID and a date column are enough, and an event log you already have is read too. The steps, their order and the times between them are computed, never guessed; a model only gives each step a readable name. The happy path with step counts and median times between steps, and every deviating variant with the steps it skipped.

1. Conversation opened
2. Assigned to an agent
3. First reply from an agent
4. Closed

**support conversations never closed**

83 of 1852

**purchase orders created but never received**

19 of 207

**customers who opened a support conversation**

1347 of 10724

In our test company: the demo map’s processes.

**objects**

19

**relations**

50

**processes**

4

the demo map, built from one company’s raw exports

Metrics

## Numbers with receipts.

Grounded KPIs: name, unit, a formula written in the map’s own field names, the exact {object, field} grounding — verified against the map, so an invented metric cannot exist — and the caveats inherited from weak joins and findings. An agent reads the caveats before it computes or cites the number. Besides the metrics the map proposes, an admin can define one of their own in the same grammar, and draw a line to be told when it crosses.

Median Refund Turnaround unit days

**formula**

`MEDIAN(refund.refunded_at - refund.requested_at)`

**grounding**

refund.refunded_at · refund.requested_at

**caveat 1 of 1**

Refund turnaround is a hard-coded 2 days, not a measured workflow duration, so the metric may be an artefact.

From the demo map · get_metric

Signals and your rules

## What needs doing, without re-reading the map.

Every scan writes what changed as typed signals: a finding that appeared, a process step that slowed, a tracked number that crossed your line, something the map depends on that stopped working. On top of that you write your own rules from the map’s names, in dropdowns — “stock is zero and ad spend over the last day is above zero, per product” — and each is judged per group when a scan finishes and, for a connected system, daily or weekly between scans. A rule reaches its groups only through joins Maplith tested against your rows. When a rule cannot be judged, the person who set it up is told, and Business map › Activity shows the rules and signals that were most active in the last 30 days.

rule_fired A rule you wrote holds for a product

- Stock is zero
- Ad spend over the last day is above zero
- Per product, through joins Maplith tested against your rows

Next: get_task_context

Ask

## Ask the map in plain language.

“Which systems hold customer data, and which joins between them can I trust?” One question, one answer written from the part of the map the asker may see — citing the objects, joins, findings and figures it rests on, with the rate Maplith measured for each join, and saying plainly what the map could not establish. It answers from the map, never from your rows. For one known thing, the direct tools are quicker, and your agent is told so.

```
> ask "Which systems hold customer data, and
  which joins between them can I trust?"
```

Task context and playbooks

## One call equips an agent for one task.

For any signal, one call returns what it touches: the objects and their personal-data flags, the verified route between them, the process step, the open findings, the metric behind the number, what was done the last time, and the operation a rule suggests with the key’s policy for it. It also carries your playbooks — the steps, checks and exceptions your people wrote down. Maplith can draft a playbook from a procedure you upload with your exports, such as a returns policy; it stays a draft, marked as Maplith’s words, until an admin puts it in use. Playbooks reach any MCP client as resources, as prompts, and as a skill file. They are guidance, not enforcement: what an agent may do is the key’s policy.

get_task_context one signal, one call

**objects**

what the signal touches, with personal-data flags

**route**

the verified route between them

**process**

the process step

**findings**

the open findings

**metric**

the metric behind the number

**last time**

what was done the last time

**operation**

what a rule suggests, with the key’s policy for it

**playbooks**

the steps, checks and exceptions your people wrote down

The action gate

## Your agent asks before it acts.

You declare the operations your agents carry out — pause an ad set, create a purchase order, issue a refund, reply to a case — and set per key whether each needs a person’s approval, which amounts are always a person’s decision, and how many a day. The agent asks first and hears allowed, pending or denied; anything without a policy is denied. An allowed answer can carry a signed grant that is good once and bound to the exact target and parameters, so the executor that holds your credentials can refuse anything else; revoking the key, or changing its policy, revokes the grants it has not spent. Every request, decision and outcome lands in the action log, and every privileged change in your workspace lands in one audit trail.

request_action before the agent acts

**allowed**

can carry a signed grant, good once, for the exact target and parameters

**pending**

waits for a person’s approval

**denied**

anything without a policy

What you got

## Counts, not estimates.

The workspace overview says what came of it over the last 7, 30 or 90 days: signals raised and acted on, how fast, actions by outcome, requests through the gate and how people decided them — and the value your agents reported, when your own systems stated it. Maplith counts; it never estimates a value or claims that a number moved because an agent acted.

Intake

## Connect a system, or upload exports.

A connected system rebuilds the map without new uploads, on a schedule you choose. Exports need no integration project: CSV, Excel, JSON, PDF text, mailbox archives, transcripts, Markdown procedures — and helpdesk conversations, Intercom’s conversation export first, flattened into tables like any other export.

- CSV
- Excel
- JSON
- PDF text
- Mailbox archives
- Transcripts
- Markdown procedures
- Helpdesk conversations

Questions

## What people ask first.

### [What is a company brain?](https://maplith.com/docs/what-is-a-company-brain)

The knowledge a business runs on, in people’s heads and across its systems, made available to the AI agents it already uses. Maplith builds one from your systems.

Read the article

### Why not just ChatGPT or Claude?

Use them. Maplith makes them better at your company. Without it, they guess where your data is and how your systems connect, and you explain your rules in every chat. It also costs less: on an earlier synthetic test company, a question took 6,154 tokens with the map against 26,851 reading the raw exports, and the gap grows with your data.

### Do I have to change my systems?

No. Connect the systems you already use, or upload exports from them. Nothing is migrated, and your tools stay as they are.

## See your own map. The first one is free.

[Build your first map](https://app.maplith.com/login) · [See the MCP tools](https://maplith.com/agents)
