Marrinn · The architecture · The Squids
The Squids.
The operators. They think, they act, they report back — each follows your written policy, runs inside the same permission matrix a member of staff would, and hands to a named human on anything that matters. One works a department and can lead other Squids beneath it; one belongs to a single person.
A Squid is a definition, not a prompt.
Two Squids running on the same model behave completely differently, and the difference is not the model. It is what the Squid is bound to, what it is allowed to reach, and what it is forbidden from doing. That definition is a set of documents in the system rather than a prompt somebody typed, which is why the same Squid behaves the same way in March as it did in January.
Six parts, and they are not all written by the same person. A manager decides what a Squid is for. An administrator decides what it is permitted to touch.
The charter
What this Squid is responsible for, in the language the department already uses, and what it is explicitly not for. It is the difference between an operator with a job and a model with a job title.
What it may know
The modules, the connected systems and the documents this Squid reads. Nothing outside that list is in its world. A finance Squid holds the chart of accounts and the fiscal calendar; the brand voice is not its business, and it cannot see it.
Where it must stop
Prohibitions, written as prohibitions rather than preferences. Never write a tax rate. Never contact a client about money without a person releasing it. The department owns this, because the department is what gets audited.
What it may do
It reads records, runs queries, creates and patches them, comments, attaches documents, and moves work through its states. An administrator sets the scope around that: which systems it reaches, which of those actions it may take in each one, a cap on how many, and an approval gate on anything you want a person to see first.
Who it acts as
A Squid is its own principal in the same 235-action permission matrix your people are in — not a person’s login being driven by software. A named human authorises it, and it can never be granted a permission that person does not hold. Every call it makes lands in the audit log naming the Squid that acted, the person accountable for it, and what set it off.
Which model runs it
Whichever one you configured in the Kernel: OpenAI, Anthropic, Google, OpenRouter, or a private model running offline on your own hardware.
The same six parts describe both shapes. A department Squid is shared, and a manager writes its charter. A personal Squid belongs to one person, knows what that person owns, and reaches the tools they already use. Personal Squid →
The split between manager and administrator is deliberate. A manager who has to raise a ticket to change an escalation rule stops changing it, and the policy is stale inside a month. An administrator who has to arbitrate what marketing means by brand voice becomes the bottleneck for every department at once. So the person who owns the knowledge writes the charter, the bindings and the limits, and the person who owns the risk decides what the thing can touch.
Somebody writes it down, and it is versioned.
Three of the six parts above are written by a manager, which raises the obvious question of where. They are documents in the workspace, authored by the person who owns the work, versioned like any other policy you keep. Not a prompt box, and not a setting buried in an admin console.
That is also what decides how a Squid behaves at the edge of what it holds. An operator bounded by writing has somewhere to stop. A model bounded by nothing produces a plausible answer instead, and a plausible answer about your own business is worse than no answer.
A document, with an author
The charter, what it may know and where it must stop are written as documents, in the language the department already uses, by the manager who owns that work. The person who knows how the books actually close is the person who writes down how the books actually close.
Superseded, never overwritten
Every version is kept, with its author and its date, and a new one supersedes the old and says so. Six months from now you can answer what this Squid was told to do in March, which is the question that actually gets asked after something goes wrong.
Written is not the same as in force
A document changes nothing until it is bound to a Squid, and a Squid reads only what it is bound to. That is the whole reason a finance Squid cannot drift into marketing’s business, and why the same document can govern one Squid without touching another.
It tells you it does not hold that
Ask a Squid something its bindings do not cover and it says so. It does not fall back on the general knowledge of whichever model it happens to be running on, because that is the moment an agent stops reporting your business and starts inventing one that sounds like it.
There is a stated order
A department’s own doctrine beats the workspace charter on that department’s subject. A dated correction beats an undated document unless the document is newer. Where the order does not settle it, the disagreement is put in front of a person rather than resolved quietly in the Squid’s favour.
A rejection becomes a rule
When somebody rejects what a Squid produced, the reason is written against that Squid and read before it acts again. That is how the same mistake stops happening twice, and how a Squid earns a longer leash one kind of action at a time rather than being handed one on day one.
The documents live in the Memory layer, beside your records, your organisation profile and the search that reads across them. What is written there is true for the workspace; what is bound here is in force for one Squid. Where the knowledge comes from →
A Squid can lead other Squids.
A department is not one job. So a lead Squid holds the charter for the work, splits it, and sends several narrower Squids at the parts of it at the same time. That is depth, and it is why one operator per department is the starting point rather than the ceiling.
Width works differently. When one department hands work to another, the handoff is a record, never a message, and that single rule is what keeps a chain across four departments something you can still reconstruct a year later.
A lead, and the ones it sends
The lead holds the job, splits it, and runs several narrower Squids in parallel. Each one is given a smaller world than the lead, so the Squid working the numbers cannot see the brand voice, and does not need to.
Read-only unless you say otherwise
A Squid sent out by a lead reads and reports. It does not write unless writing was granted to it by name. The writing, and the handoff to a person, happen at the lead, so there is one place to look when you want to know what actually changed.
It cannot exceed the one above it
A Squid underneath a lead can only be narrower than the lead, never wider. Nothing gains access by being delegated to, which is the usual way a chain of agents quietly ends up holding rights nobody granted it.
The handoff is a record, never a message
Marketing does not tell sales about a campaign. It writes leads, with that campaign as their source. Sales does not tell finance about a closed deal. It moves the deal to won, and finance sees the contract.
A chain you can reconstruct
Two agents talking to each other leave a conversation nobody can audit. Two agents writing to the same records leave a trail with names, times and reasons on it. The record is the interface. The notification is only how a person hears about it.
Each reads only what the last one wrote
No Squid in a chain inherits the thinking of the one before it, only its output. That is what stops a wrong turn early on from being repeated with more confidence at every step after it.
A department that needs one operator gets one. A department whose work splits four ways gets a lead and three underneath it, on the same permission matrix, in the same audit trail, with the same named handoff at the end. The shape changes; nothing about the governance does.
It reads the records, not a copy of them.
The difference between an agent that is useful inside a department and one that is merely fluent is what it is reading at the moment it answers. A Squid does not work from a snapshot somebody exported last quarter, and it does not work from a description of your business typed into a prompt.
It reads live rows through its own login. It carries your organisation’s written profile into every question it is asked. And where it has to find something nobody indexed by hand, it asks in plain language and gets its sources back.
It checks the current row
A Squid reads the live record rather than a copy, so it is never acting on last week’s figure. It sees precisely what its login allows, which is how the same Squid can be useful in a department where most people cannot see most of the data.
It stays inside its own scope
Its bindings decide what is in its world. A finance Squid holds the chart of accounts and the fiscal calendar and cannot see the brand voice. That boundary is what stops a general model behaving generally.
It names where each figure came from
Every number it gives you carries the system it was read from and the moment it was read. A figure nobody can trace is a figure nobody will sign, which matters most on exactly the finance and compliance numbers a Squid is most useful for.
The three sources, and the rules every one of them follows, belong to the layer underneath. Where the knowledge comes from →
A Hospital Squid.
The test of an operating agent is whether it can see the whole case. A pre-approval is not one record. It is an intake request, a clinical document, an order in a system Marrinn does not own, an SLA clock, and a claim that finance will eventually bill from. A chat window can write about all five. It cannot read them.
So the example below names the module every step happens in — and names the three things the Squid deliberately never touches.
The Pre-Approval Squid
A private hospital cannot bill a procedure until the insurer or TPA has approved it. Today a clerk assembles the case, submits it, and chases the answer. Here is the same job as a Squid, and every step names the module it happens in.
-
01
The case arrives
Service DeskAn ordered procedure needing payer sign-off lands in the Intake queue by email or API, and becomes an intake record with a reference the requester can track.
-
02
It reads the whole case
Service DeskDocument ManagementYour EMR · read-onlyProcedure code, payer and urgency from the record. The clinical documentation attached as evidence. The ordered service from the clinical system itself, which Marrinn opens read-only and never writes back to.
-
03
It assembles and submits
Service DeskAccepts the intake record into a work item, sets triage category and priority, and assembles the submission to the insurer. It never authors the clinical justification. A clinician writes that, and the Squid only attaches it.
-
04
It tracks the answer
Approvals & SLAMoves the case through submitted, pending, approved or denied. It fires your existing SLA policy and escalation chain rather than editing any SLA target, so the clock and the reminders are the ones you already set.
-
05
It closes the loop
Marrinn FinanceOn approval it writes the outcome onto the claim the approval unlocks, which is the same record your finance team already bills from. No re-keying, because it was never a separate system.
-
06
A person sees the exceptions
Approvals & SLAGovernance & AuditEvery denial, every case the payer flags for clinical review, and an audit sample of approvals go to a named reviewer. Not the routine ones. Every read and write the Squid made is already in the audit log.
Notice what the Squid never touched: the clinical justification, the SLA target, and the approval decision itself. It did the assembling, the chasing and the filing, in five modules that were already one system. That is the part a chat window cannot do — not because it cannot write, but because it cannot see the contract, the SLA and the claim as the same record.
What a Squid found, and where it stopped.
The useful question about an operating agent is not what it can do. It is what it does when it finds something, and whether the thing it hands you is checkable. An agent that acts and cannot show its reasoning is a liability with good latency.
Below is a finance Squid’s Monday. Four findings, four owners, and one decision it deliberately does not make on its own.
Four findings before anyone opened the ledger.
Each finding carries a severity, a category, a plain-language summary, a recommendation where there is one, and the evidence behind it — so you can see why it was raised rather than taking it on faith.
- HighThree invoices past sixty daysEvidence: the ledger rows, the dates, and the last contact on each.
- MediumA supplier paid twice in MarchEvidence: both journal entries, and the reference they share.
- MediumAn expense above the approval thresholdEvidence: the policy, the amount, and the approval that never happened.
- LowA currency rate stale since the quarter openedEvidence: the last sync, and every figure downstream of it.
Four findings, ranked, each with an owner
They arrive on a board rather than in an inbox, ranked by impact, filtered by whether they are new, acknowledged or resolved. The point of the board is to get to zero: act on it or dismiss it, and the next run shows you what changed rather than repeating the same list at you.
A recommendation you can check
A finding with no evidence is a request to trust a model, which nobody should do with a compliance or finance number. The data behind the insight comes with it, so the first thing you read is the reasoning rather than the conclusion.
It runs inside governance, not beside it
An agent bolted onto a system usually gets its own credentials and its own reach, which is a second permission model to keep in sync and a second thing to audit. A Squid holds a role in the matrix you already maintain.
A queue instead of a report
A monthly report is read once and filed. A board with a count of what is new is a thing somebody clears, which is the difference between noticing a problem and doing something about it.
The handoff has a name on it
Anything that matters goes to the person who owns it, not to a shared mailbox where it becomes everybody’s and therefore nobody’s.
Six off the shelf, and the ground they all stand on.
Each of these is a role rather than a chatbot with a different name on it. Take one as it comes, or have one built for the exact job you want. Either way it is bound by the same permission matrix a member of your staff would be.
What follows the six is what every Squid stands on: one data model underneath them all, a way to start without being asked, and a route out to the systems you already run.
Sales Ops Squid
Does the pipeline work, not a report about the pipeline. On a deal that has gone quiet it writes the next step onto the record, opens the follow-up task against the owner and drafts the chase in that owner’s voice, ready to release. It updates the forecast and the close date from what it just did, and after the meeting it writes the won or lost reason back onto the deal.
Service Desk Squid
Works the queue rather than reporting on it. Every request that lands is classified, given its priority and SLA target, and assigned to the right team, and the ones it can answer it answers outright. The ticket, the contract, the SLA and the invoice are the same records, so it reads the whole account before it replies, closes what it resolved, and escalates the rest with the conversation intact.
Approvals Squid
Routes the item instead of advising on it. It reads the approval history and your written policy, sets the approver chain on the record, sends the request and chases the reminders itself. A step that stalls is escalated a level before the SLA breaks, and every name it routed to carries a confidence score and the reasoning, so the person who receives it can see why it reached them.
Internal Audit Squid
Files the finding, not a slide about it. It reads the audit log, writes the plain-English account of what changed and who changed it, and raises the finding on the record where the change happened, with a remediation task on a named owner. Where a member holds more access than their activity justifies it opens the access change for approval, because a Squid never applies a permission change itself.
Compliance Squid
Keeps the register live rather than annual, and does the keeping. It opens each assessment when it falls due, logs the incident when one happens, attaches the evidence to the control it satisfies and moves the risk rating on what it found, against ISO, COSO, NIST, SOC 2 and GDPR. Findings are raised where the work happens, with the remediation already assigned and dated, instead of in a spreadsheet somebody opens each quarter.
Delivery Squid
Builds the sprint, then commits it. It plans from the backlog, the team’s capacity in hours and its historical velocity, writes the estimates and the assignments onto the items, and opens the sprint for the team to accept or change. It chases stale and long-blocked work by asking the owner on the item itself, and updates each key result from the work that actually moved it.
One brain, every department.
An agent is only as useful as what it is allowed to see, and as what it actually understands. Because all 35 modules share one data model, one permission matrix and one audit trail, an agent asked why a project is late can read the sprint, the approval that held it, the contract it belongs to, the budget line it draws on and the person who owns it — without a single integration in between. That is the difference between an assistant and an operating system.
The large platforms have to bolt on a further layer that teaches their agents what your data means, because the schema was theirs before it was ever yours. Marrinn needs no such layer. The data model was written from your own specification, so the meaning is already the model. And every agent runs on the large language model you choose — OpenAI, Anthropic, Google, OpenRouter, or a private Ollama model on your own hardware — so nothing has to leave your building.
Squids that start on their own, and stop the moment you say.
You write a standing order the way you would brief a person rather than as a line of cron: what to watch, what counts as worth acting on, what to do about it, how often to check and who to tell. The manager who owns the work writes it, not an administrator in a builder. It runs whether or not anybody is signed in, and when there is nothing worth doing it says nothing.
A saved run is bounded when you save it, not argued with while it is running. You fix which records it may reach, which tools it may use and which member’s role it runs as, and that is the ceiling for every firing afterwards. Inside that ceiling nothing is relaxed: the permission matrix still applies, an action into an approval-gated state opens an approval request instead of going through, and every run writes to the same audit trail your staff do.
What arrives on a trigger is treated as data, never as instructions. A webhook body or a customer’s own words in a ticket cannot tell a Squid to do something its standing order does not already allow. One toggle pauses a Squid, deleting the order stops it, revoking the endpoint ends the outside call, and an administrator can stop every scheduled run in the workspace at once.
Squids working with other systems you already run.
A Squid is not confined to the modules it lives in. Marrinn speaks MCP, the Model Context Protocol, in both directions: an agent outside can work on your records through a governed interface, and a Squid inside can reach out and do work in the applications you already own. So this is not all or nothing. Take the five modules you need, keep the CRM your sales team already lives in, and register it as a tool. The Squid reads the relationship history from there, writes the review into Marrinn, and posts one note back where the account manager will actually see it.
Nothing loosens on the way out. A token can never be granted more than the person who created it holds, so a tool call can only do what that person could do. Write access is granted per action, not per system, and read-only is the default. An action into an approval-gated state does not go through, it opens an approval request. Every call is capped, and every call lands in the same audit trail your staff write to. Disabling a tool stops every Squid using it at once. How the tools layer works →
Policy is written down, and so is what happened.
A Squid follows your written policy because the policy is a document in the system rather than a prompt somebody typed. That is also why the same Squid behaves the same way in March as it did in January, and why you can point at the reason it did something.
Severity, category, evidence
Every insight carries how urgent it is, what area it concerns, what was observed in plain language, the suggested next step, and the data points behind it.
An impact score
Findings are ranked rather than listed, so the top of the board is where the money or the risk is, not whatever ran last.
Read-only until told otherwise
A Squid reaches an outside system only where an administrator has registered it and ticked the actions it may take. Read-only is the default and writing is switched on one action at a time.
Approvals are not bypassable
A transition into an approval-gated state does not apply the change. It returns an approval request, the same as a person’s edit would — the gate does not care whether the actor is human.
Every call is logged
Tool calls are written to the audit log naming the Squid that acted and the member whose authority it ran under. There is no separate agent log to reconcile, because there is no separate path — and because both names are on the row, you can filter the log to agent actions without losing who was accountable for them.
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 Handoff
Where an agent stops and a person decides.
The Ports
And it reaches what you already run.
The Squids are one of seven parts.
They are the processes that do work: 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 they reach the software you already run.