Maplith for people and resourcing
- 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
Where it goes wrong
Rates kept in a spreadsheet
Assignments made in chat
What your agent does about it
Rates kept in a spreadsheet
Assignments made in chat
Rates kept in a spreadsheet
- 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.
- 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.
- FindingsThe spreadsheet is the real record of rates, with the rows, the chat and the meetings it rests on, and a recommendation.list_findings
- MetricsA metric built on the stale rate carries that caveat with its number.get_metric
- AskWhich rate is current and where it lives, answered with citations, never from rows.ask
- The action gateCorrecting a rate in the system of record: a person approves it, if the business sets it so.request_action
- Record and valueWhat was done, so the next agent’s context shows it.record_action
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
- 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.
- 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.
- 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. - The action gate
request_actionto 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. - Record and value
record_actionwrites what was corrected, so the next task context on the same thing shows it.
Assignments made in chat
- 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.
- 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.
- FindingsAssignments in direct messages that never reached the project system, with the meeting that moved them.list_findings
- SignalsWhen a person approves a finding’s fix, a
fix_approvedsignal.list_signals - Task contextThe job, the assignment and the path between them, marked weak, and what was done last time.get_task_context
- The action gateRecording the assignment in the project system, decided by the key’s policy.request_action
- Record and valueWhat was done, so the next agent’s context shows it.record_action
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
- 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.
- Signals
When a person approves the suggested fix of a finding,
list_signalsreturns afix_approvedsignal andget_task_contextgives the finding and its fix, so an agent polls for its work instead of re-reading the map. - Task context
get_task_contextreturns 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. - The action gate
request_actionto record the assignment in the project system, if the business declared that operation, decided by the key’s policy. - Record and value
record_actionwrites what was recorded, so the next task context on the same thing shows it.
What your agent calls
Findings
liveMetrics
liveTask context
liveThe action gate
liveRecord and value
liveWhere these come from
Map your exports. The first map is free.
Your systems stay the source of truth; your agent acts in them with your credentials.