Read the agreement and the request separately
Harbour Software has agreed to support Maple's launch from 09:00 to 17:00, America/New_York, on 26–30 October 2026. The agreement covers launch-blocking issues in the agreed integration. It excludes general weekend coverage. Priya approves changes to the terms; Alex owns the support rota.
Maple then asks for support until 20:00. No approval of that request is recorded.
| Source | What it establishes |
|---|---|
| Original agreement, 20 October | Support from 09:00 to 17:00 on the stated dates, timezone and scope. |
| Customer request, 21 October | A request for 20:00. It does not establish an agreed extension. |
| Operating record, checked 21 October | The original hours and the pending request. |
Ask: “What support have we agreed, and where does that answer come from?”
The supported answer is 09:00–17:00 under the original agreement. The customer's 20:00 request is still pending. Keep the dates, timezone and scope with the hours; leaving them out changes what the answer means.
Follow the later agreement
On 22 October, Priya agrees support until 18:00 on the same dates, in the same timezone and for the same scope. She explicitly says that coverage until 20:00 has not been agreed. Alex is to update the rota.
The operating record still says 17:00. A suggested edit would change it to 18:00 and cite Priya's later agreement, but the edit is waiting for review.
| Question | Answer supported by the example |
|---|---|
| What is the current customer commitment? | Support until 18:00 under Priya's later agreement. |
| Is the operating record current? | No. It still says 17:00. |
| Has the suggested record edit been saved? | No. It is waiting for review. |
| Was the customer's request for 20:00 accepted? | No. The later agreement explicitly excludes it. |
| Has Alex updated the rota? | The supplied records do not establish that. |
The agreement with the customer and the approval of an edit to its saved record are separate events. A pending edit does not undo Priya's agreement. Nor does the agreement prove that the rota or operating record has been updated.
Give the next person sources they can use
A useful handoff states the agreed hours, links the later agreement, identifies the stale operating record and names Alex's outstanding rota check. The next person should open the sources through their own account and ask their connected agent to read them in a fresh conversation.
If a necessary source is outside their access, ask its owner for an authorised summary or the appropriate access. Do not copy restricted information into the handoff to make the test pass.
Check the saved correction
In Mensara, an agent can propose a precise correction with its supporting evidence. The Mind's rules determine whether a permitted change saves immediately or waits for review. After it is applied, open the current record and confirm that it says 09:00–18:00 with the right dates, timezone, scope and source.
That read-back establishes the saved record's wording. Alex's rota remains a separate check. See how to correct saved information for the process.
Try one handoff you can verify
Choose a harmless example with an original decision, a later request and a clearly authorised amendment. Write down the expected answer before asking the agent. Check that it distinguishes current agreement, saved record, pending work and missing evidence. Then repeat the question in a fresh conversation using the intended teammate's access.
Start with one useful question. If you are considering Mensara for your team, join the waitlist.
Practical guides for people and agents