Marrinn · The suite · Personal Squid
Personal Squid.
A department Squid runs a process. A personal Squid works for one person. It reads the systems you already use, answers from the data you are allowed to see, and gets the work into Marrinn — so you stop opening five applications to find out what matters this morning.
An operating system is what you use instead of the things underneath it.
Nobody opens the filesystem. That is the whole idea of an operating system: it stands in front of everything else, so you ask it rather than going to find things yourself.
Five tabs, one answer
The mailbox, the CRM, the ledger, the ticket queue and a spreadsheet. The answer to “what needs me today” is spread across all of them, and assembling it is the first hour of the day.
A sixth place to look
Most platforms solve this by becoming another destination. A new dashboard, a new inbox, a new notification stream. You have not removed a tab, you have added one.
You ask. It goes and looks
Your Squid reads the mailbox and the systems you use, under your own access, and comes back with what matters. You did not open any of them.
The others become storage
When one surface answers for all of them, the rest stop being places you visit. That is the difference between a platform and an operating system.
One per person, not one per department.
The Squids that run your finance function or your service desk are shared, and a manager writes their policy. A personal Squid is yours. It knows your targets, your accounts, your open goals and your working hours, because Marrinn already holds all four.
- It knows your role without being told, from the org chart, your OKRs and what you own in the CRM
- It sees exactly what you see and never a record more, through the same permission matrix you log in under
- It sounds like you because the voice is derived from mail you actually sent, not from a form you filled in
- It has a do-not-do list that you write, in your own words
“What came in over the weekend that I need to deal with?”
An investment company, Monday, eight in the morning. The head of investor relations has not opened her mailbox.
Four systems, none of them opened by a person.
Mail to the investor-relations address already arrives in Marrinn as a request with a clock on it. Everything else it needed, it went and got.
- The mailbox for what actually arrived, read under her own connection
- The CRM for who each sender is and what the relationship looks like
- The fund administration system for the commitment, read at the moment she asked rather than from last night’s sync
- Document management for the file each request refers to
Four things, ranked, each one traceable.
Not a summary of her inbox. A list of what needs a decision, with the evidence attached to each one.
- A capital call query from an investor whose identification has expired. The CRM says the relationship is live; the compliance file says the document lapsed. Both values, both timestamps
- A subscription document waiting on counter-signature, with six hours left on its service level
- A redemption request above her own authority. It opened an approval request rather than moving it
- A drawdown notice that bounced, because it went to a fourth spelling of an investor she already has three records for
It drafted her reply to the investor and it did not send it. It did not approve the redemption. And every figure in front of her names the system it came from and the moment it was read. Where the knowledge comes from →
“Get the good ones into the CRM, with everything you can find on them.”
The same machinery, pointed outward. A sales rep connects the prospecting tool they already pay for, and the agent does the part nobody enjoys.
It finds and enriches
The rep’s own prospecting connection is read: companies matching the brief, with the firmographic and signal data that tool is good at. Read-only, under the rep’s own authorisation.
It checks what you already have
Every company is checked against the CRM before anything is created, inside that rep’s own team boundary. Which ones are already accounts, which are somebody else’s, which were contacted and went quiet.
It resolves the near-duplicates
The same company written two ways across two systems is understood to be one company. This is the step that decides whether an import improves the CRM or quietly ruins it.
It creates the records
Accounts and contacts, created under the approval policy that already governs that transition. Where the policy says a person signs off, it opens a request instead of writing.
The enrichment lands as fields
Not a summary the rep reads once and loses. Values on the record, so the forecast, the pipeline dashboard and every future query can use them.
It drafts the first touch
One draft per company, in the rep’s own voice, sitting in the rep’s own drafts folder. Nothing is sent. That decision stays with a person.
Notice where the data went. Out of the prospecting tool and into your CRM, under your own approval policy. Nothing left the building, and nobody was contacted, which is why this works on day one rather than after a governance review.
It borrows your access. It never gets its own.
An agent with its own credentials is a second set of permissions to keep in step with the first, and a second thing to audit. A personal Squid holds a token that belongs to you, which is why the governance question mostly answers itself.
It acts for you, as itself
It is bounded by your role: it can see and do exactly what you could see and do by logging in, and never a record more. A personal Squid is not a way around your own permissions. It is still its own principal though, so the log shows the Squid that acted and you as the person it acted for — not you appearing to have done it yourself.
You authorise your own
Your mailbox and your tools are connected by you, through the provider’s own consent screen. No administrator ever handles your credentials, and no colleague’s Squid can use them.
Narrowed at the source
Permission is requested as narrowly as the job allows — the right to compose a message rather than the right to send one. Drafts-only is enforced by the access that was granted, not by a policy we promise to apply.
Approvals are not bypassable
A change into an approval-gated state does not apply. It returns an approval request, exactly as your own edit would. The gate does not care whether the actor is a person.
What it did is fully audited
Every call lands in the audit log naming your Squid as what acted and you as who it acted for: what it touched, when, and which approval it took or asked for. There is no separate agent trail to reconcile, and nothing it did is ever recorded as though you had done it by hand.
What you said stays yours
Your thread is private by default rather than readable from an admin console. Access in an emergency needs a second named approver, tells you it happened, and is written to the log itself.
Said precisely, because this is the part worth being precise about: your questions are not readable through Marrinn without a logged exception that notifies you. On a deployment you host yourself, your own administrators still control the hardware underneath, and no software claim can change that.
Built from parts that were already there.
A personal Squid is not a separate product bolted to the side. It is the operating system underneath, pointed at one person instead of one department.
The Squids
The operators. One shape works a department, the other works for a person.
The Handoff
Where you and your Squid meet, in both directions.
The Ports
How it reaches your mailbox and the tools you already pay for.
The Memory
What it knows, and the rules every source of it follows.
The Core
The permission matrix it borrows, and the audit trail it writes to.
The Kernel
The model behind it, including a private one on your own hardware.
Bring us the report that takes two days a month.
We will build it live on your own data during the demo. If it does not work, you will know within the hour.