# Maplith for people and resourcing

How the AI agent that plans the work sees the rates kept in a spreadsheet and the assignments made in chat — each workflow a before and after, shown on a fictional company’s exports.

Who does the work, and at what rate, is often decided outside the system that is supposed to know: in a spreadsheet, in a direct message, in a meeting. The system of record falls behind, and every report built on it inherits the gap. Your agent can see it — if it knows which source the business actually uses and how far to trust each one. Maplith gives it exactly that; your agent acts in your systems with your credentials.

LinguaNord ApS is a fictional translation agency built as our first test company: the company, its people, its customers and its translators are all invented, and nothing in the data comes from any customer.

## Between the systems

Recurring problems between the system of record and where resourcing is really decided. Each was raised by a scan of the worked example’s exports.

- **Rates kept in a spreadsheet.** New rates live in a spreadsheet in the shared drive, and the system of record still carries the old ones — so the margin report is wrong. (LinguaNord ApS · raised by a scan of its exports.)
- **Assignments made in chat.** Work is handed out in direct messages that promise to update the system later, and some of it never reaches the system at all. (LinguaNord ApS · raised by a scan of its exports.)

## Workflows

Two workflows from the translation agency’s map. Everything on this page ships today.

### Rates kept in a spreadsheet

The real rates live in a spreadsheet; the system of record still carries the old ones.

**Without Maplith.** New rates were agreed and written into a spreadsheet in the shared drive, flagged as not yet in the system of record, because updating it needs an admin permission. In the worked example a meeting decides to fix the permission, the chat says the spreadsheet applies, a later meeting says the margin report is wrong, and the system of record still carries the old rates.

**With Maplith:**

1. **Findings** — A scan of the exports raises it as a finding: which rates differ between the spreadsheet and the system of record, the chat that says the spreadsheet applies, the meetings where it came up, and a recommendation.
2. **Metrics** — A metric built on the rate field carries the caveat that the system’s rate lags the spreadsheet, and an agent reads the caveat before it quotes the number.
3. **Ask** — `ask`: “where does the current rate for a translator live, and which source should I not rely on?” — answered from the map, citing the objects it rests on, never from rows.
4. **The action gate** — `request_action` to correct a rate in the system of record, if the business declared that operation, decided by the key’s policy — a person can approve each one.
5. **Record and value** — `record_action` writes what was corrected, so the next task context on the same thing shows it.

Worked example: [LinguaNord ApS](/industries#linguanord).

### Assignments made in chat

A meeting moved all assignment into the project system; work was still handed out in direct messages.

**Without Maplith.** A meeting decided that every assignment goes through the project system. In the worked example the assignments kept arriving as direct messages — each promising to update the system later — and some of those jobs were delivered with no assignment on record. Nobody can see who has what without reading everyone’s messages.

**With Maplith:**

1. **Findings** — A scan of the exports raises it as a finding: the assignments made in direct messages, the jobs that never got one on record, the meeting that moved all assignment into the project system, and a recommendation.
2. **Signals** — When a person approves the suggested fix of a finding, `list_signals` returns a `fix_approved` signal and `get_task_context` gives the finding and its fix, so an agent polls for its work instead of re-reading the map.
3. **Task context** — `get_task_context` returns the job and the assignment, the join between them — marked weak, because the assignment is read from chat — and what was done the last time.
4. **The action gate** — `request_action` to record the assignment in the project system, if the business declared that operation, decided by the key’s policy.
5. **Record and value** — `record_action` writes what was recorded, so the next task context on the same thing shows it.

Worked example: [LinguaNord ApS](/industries#linguanord).

## The pieces

| Piece | Tool | What it gives the agent | Status |
|---|---|---|---|
| Findings | `list_findings` | Where the systems disagree, raised by a scan of the exports — each with the evidence it rests on and a recommendation. | live |
| Metrics | `get_metric` | Numbers with a formula in the map’s own field names, and the caveats they inherit from weak joins and findings. | live |
| Signals | `list_signals` | What needs doing, as typed events to poll instead of re-reading the map. | live |
| Task context | `get_task_context` | A single call with everything a signal needs, including the playbooks and what the key may do. | live |
| Ask | `ask` | One question in plain language, answered from the map with citations — never from rows. | live |
| The action gate | `request_action` | Allowed, pending a person, or denied — before the agent acts, with a grant good once. | live |
| Record and value | `record_action` | What was done, so the next judging does not raise it as though nobody had looked — and counted in “What you got”. | live |

## The worked examples

- **[LinguaNord ApS](/industries#linguanord)**, a translation agency. The findings and processes quoted from it come from a recorded scan of its exports. There is no public map or key for it.

Every department: [Solutions](/solutions). The worked examples: [Worked examples](/industries).