Solutions · People and resourcing

Maplith for people and resourcing

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.

The workflowsfigures from the worked examples
Rates kept in a spreadsheet
5 of 12 translators have a new rate only the spreadsheet knows
Assignments made in chat
8 assignments in direct messages · 3 never recorded
LinguaNord ApS
Where resourcing is decidedProject systemShared driveChatMeetingsA spreadsheet that wins
Between the systems

Where it goes wrong

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.
01

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
02

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
Workflow 01

Rates kept in a spreadsheet

The real rates live in a spreadsheet; the system of record still carries the old ones.
Without Maplith
  • Know that the spreadsheet exists and which version is current.
  • Compare it with the system of record, row by row.
  • Trust a margin report built on the old rates.
With Maplith
  • A finding with the rows, the chat and the meetings it rests on.
  • A metric that carries the caveat with its number.
  • An answer on which rate is current and where it lives.
  • A decision on correcting the system, by the key’s policy.
  1. FindingsThe spreadsheet is the real record of rates, with the rows, the chat and the meetings it rests on, and a recommendation.list_findings
  2. MetricsA metric built on the stale rate carries that caveat with its number.get_metric
  3. AskWhich rate is current and where it lives, answered with citations, never from rows.ask
  4. The action gateCorrecting a rate in the system of record: a person approves it, if the business sets it so.request_action
  5. Record and valueWhat was done, so the next agent’s context shows it.record_action

Worked example: LinguaNord ApS

The full workflow, step by step

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.

Workflow 02

Assignments made in chat

A meeting moved all assignment into the project system; work was still handed out in direct messages.
Without Maplith
  • Read direct messages to learn who has which job.
  • Compare them with the project system, job by job.
  • Find out when the customer asks who is on it.
With Maplith
  • A finding with the messages, the jobs and the meeting it rests on.
  • The context in one call, with the weak join marked.
  • A decision on recording the assignment, by the key’s policy.
  • A record the next agent sees.
  1. FindingsAssignments in direct messages that never reached the project system, with the meeting that moved them.list_findings
  2. SignalsWhen a person approves a finding’s fix, a fix_approved signal.list_signals
  3. Task contextThe job, the assignment and the path between them, marked weak, and what was done last time.get_task_context
  4. The action gateRecording the assignment in the project system, decided by the key’s policy.request_action
  5. Record and valueWhat was done, so the next agent’s context shows it.record_action

Worked example: LinguaNord ApS

The full workflow, step by step

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.

The pieces

What your agent calls

Where the systems disagree, raised by a scan of the exports — each with the evidence it rests on and a recommendation.
list_findings
Numbers with a formula in the map’s own field names, and the caveats they inherit from weak joins and findings.
get_metric
What needs doing, as typed events to poll instead of re-reading the map.
list_signals
A single call with everything a signal needs, including the playbooks and what the key may do.
get_task_context

Ask

live
One question in plain language, answered from the map with citations — never from rows.
ask
Allowed, pending a person, or denied — before the agent acts, with a grant good once.
request_action
What was done, so the next judging does not raise it as though nobody had looked — and counted in “What you got”.
record_action

Map your exports. The first map is free.

Your systems stay the source of truth; your agent acts in them with your credentials.

Markdown version · Worked examples · Docs · llms.txt