Marrinn · The architecture · The Ports
The Ports.
And it reaches what you already run. MCP in both directions, plus the tools layer — so a Squid can do work in the CRM, the EMR or the ticketing system you already own, granted per action, capped, and written to the same audit trail.
The four systems you are not replacing.
The reason a platform purchase stalls is rarely the platform. It is the four systems the platform expects you to switch off, each of which is load-bearing for somebody who was not in the meeting.
So the question worth answering is not whether ours is better than yours. It is whether a Squid can do its work in yours. Below is an ordinary estate, and none of it moves.
Keep the CRM. Keep the EMR. Keep the ledger.
This is the layer that makes the platform additive rather than all or nothing. Take the modules you need, keep what already works, and the Squids operate across both sides.
- The CRMTwelve years of history in itAnd a sales team who know it. Nobody is retraining them this quarter.
- The clinical systemRegulated and certifiedIt is not moving, and no serious person is going to ask it to.
- The ticketing systemEvery integration already builtSwitching it means rebuilding the six things wired into it.
- The accounting ledgerYour accountant’s systemNot really yours to change, and the year end is not negotiable.
A governed connection, in both directions
Marrinn speaks MCP as a server, so your own agent gets governed access to your records through the same enforcement path as everything else. And it speaks MCP as a client, so a Squid connects out and does work in those four systems. An administrator registers each one, supplies credentials that are stored encrypted and never shown again, and ticks the actions it may take.
Additive instead of all or nothing
You take five modules and keep the CRM. That is the whole argument, and it is only credible if the agents work across the boundary — which is what this layer is for.
Write access is a decision, not a default
Read-only is where a registered source starts. Anything that writes is ticked on deliberately, one action at a time, by an administrator who had to think about it.
Both sides run on your host
The deployment is yours, so the endpoint is yours. There is no shared cloud endpoint in the middle of the connection and no vendor sitting between your agent and your records.
An on-prem source stays on-prem
Mark a source local-only and nothing from it is ever sent to a cloud model. Pair that with a private model on your own hardware and the whole path stays inside the building.
The same enforcement path, wearing a different protocol.
The safe version of an integration layer is a boring one: not a new set of permissions, not a new audit stream, not a new way in. Everything true of the API is true here, because underneath it is the API.
Your agent, governed
An external agent connects to your deployment and calls its tools using the same per-workspace token used everywhere else. Scope it to the minimum role and no prompt, however worded, can make it write.
A Squid reaching out
An administrator registers each external system under the tools layer — an MCP server, or a REST API described by named endpoints — and chooses what a Squid may do in it.
Four kinds of tool
Read a record or follow a relation, run a query and get the rows a saved view would, create or patch, or move a record through a state subject to the policy on that state.
Only your modules
Tools are generated from the modules a workspace has enabled, so a deployment running five modules exposes the tools for those five and nothing else.
Write-only credentials
Credentials for a registered source are stored encrypted and never shown again. Editing a source leaves them alone unless you deliberately replace them.
A workspace source, or your own
An administrator registers the systems the company shares. Separately, a person can connect an account that is theirs — their mailbox, their prospecting tool — through that provider’s own consent screen. No administrator handles those credentials, and no colleague’s Squid can use them.
Synced, or read live
A data source is catalogued and synced, so what gets read is the last sync. A tool call is a pass-through: it reaches the system at the moment of asking. When a figure has to be current rather than nightly, that difference is the whole answer.
Seeing is not acting
A data source lets Marrinn read an outside system, and it is opened read-only and never written back. A tool source is the separate, deliberate decision to let a Squid act there.
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 Handoff
Where an agent stops and a person decides.
The Ports are one of seven parts.
They are the edge of the system: the kernel is the model you choose, the core is every module on one data model, The Memory is what they all agree on, and the ports are how it reaches the software you already run.