Marrinn · The architecture · The Handoff
The Handoff.
Where an agent and a person meet, in both directions. Approvals, escalations, clarifying questions and finished work land on the record itself — in the same notification bell, digest, activity feed and audit trail a person’s own request uses. The gate does not care whether the actor is human.
The six moments an agent has to stop.
An agent that never pauses is not trusted with anything that matters, so it is given nothing that matters to do. The useful question is not how autonomous it is. It is what happens at the six moments where a person has to be in it.
Below is one procurement Squid working an ordinary week. Every stop is a real mechanism in the platform, not a message someone has to remember to read.
It never sends a message you have to trust. It writes to the record you already work.
Each row is a different reason the agent stopped, and a different person it stopped for. None of them had to be watching.
- ApprovalA purchase order over the thresholdThe transition into the approved state does not apply. It opens an approval request on the record, with the quote and the budget line already attached.
- EscalationNobody decided in two daysThe policy escalates to the named deputy on a tier you set. Not a reminder into the same silence, a different person.
- A questionTwo suppliers, one unclear clauseIt comments on the item and @mentions the contract owner. The thread stays on the work, so the answer is where the next person will look for it.
- A handoffThe clause needs LegalAssigned to a named person, not a shared inbox where it becomes everybody’s and therefore nobody’s.
- A reportNine orders it did completeThey are in the activity feed and the daily digest, each one already reversible, each one attributable.
- A findingDuplicate supplier recordsIt goes to the findings board with a severity, the evidence behind it and a recommendation — a board someone works, not a notification someone dismisses.
The record is the surface. The channel is just how you hear about it.
A pending request appears on the work item with approve and reject beside the evidence, in the notification bell, in the activity feed as a history row, in the daily email digest, and in the audit log as a decision with a person’s name against it. Watchers who are not assigned still see it. That is the same path an employee’s own approval takes, which is the point: there is no second approvals system to keep in step, because there is not a second one at all.
You are not buying a second product to hear from it
The place people and agents meet is the platform they already work in. No separate chat licence, no seat tier, and nothing that stops working because a contract with a third vendor lapsed.
The gate does not care whether the actor is human
A Squid’s transition hits the same approval policy an employee’s edit hits. Not an agent-shaped exception bolted beside the real rules, which is where the real rules go to rot.
Every handoff has a name on it
Work is assigned to a person, escalated to a named deputy, and answered by whoever was @mentioned. Nothing lands in a queue that belongs to everybody.
Turn every channel off and it still works
On a closed deployment there is no outbound anything. The bell, the record, the feed and the audit log are all inside the building, so the layer does not depend on reaching the outside world at all.
Built out of the mechanisms your staff already use.
None of this is an agent feature. It is the approval engine, the notification service and the audit trail the platform already runs, with an agent allowed to be one of the actors. That is why it cannot drift out of step with how people work.
Approval policies
Gate a state transition, set who may decide, add reminders, and escalate to a named person on a tier you choose. Written once and applied to people and agents alike.
Bell and digest
In-app notification plus a daily email digest, firing on assignment, mention, approval raised, decided, reminded or escalated, SLA breach, and state change.
Comments and mentions
The conversation about a work item lives on the work item. An @mention pulls a specific person in, and the reply is still there for whoever picks it up next.
The findings board
What an agent noticed arrives ranked, with severity, the evidence and a recommendation, and is worked to a status. A board someone owns beats an inbox everyone ignores.
Activity and audit
Requested, approved, rejected, escalated: each one a history row on the item and an entry in the audit log, with the actor named, agent or otherwise.
You can start it too
The gate runs both ways. A person hands work to a Squid by asking for it, and the request becomes a record with an owner and a history rather than a message that scrolls away.
An instruction that keeps running
A persistent objective with a condition, a cadence and a fallback: what to watch, what to do when it slips, and who to tell if it slips again. The same shape as an approval policy, pointed at an agent.
Wherever you already are
Outbound events let a deployment push into whatever your organisation runs. The channel is a delivery choice, never the place the authority lives.
Seven parts, one operating system.
Read the seven from the bottom and it is an operating system: a kernel, a data model, memory, a way to see, processes that do work, a place those processes meet people, and ports to everything outside.
The Kernel
The model, and it is your choice.
The Core
Every module on one data model.
The Memory
One version of the truth, across systems you do not own.
The Lens
Where the records become an answer.
The Squids
The operators, and one can lead others.
The Ports
And it reaches what you already run.
The Handoff is one of seven parts.
It is where the system meets the people in it: the squids are the operators, the handoff is where they stop and a person decides, and the ports are how the whole thing reaches the software you already run.