Memory: what Routario remembers

Think about what it would take for a new employee to start helping you on day one. They’d need to know who your customers are, where your sites are, which supplier ships which product. That context — built up over months — is what lets them act with judgment rather than starting from zero every time.

Memory is Routario’s version of that context. It is the connected picture of the things your business deals with, kept in one place so that automations can act on what you already know.

The card-and-lines picture

The easiest way to think about Memory is a stack of cards, each one representing a single thing your business cares about — a customer, a supplier, a delivery site, a signed contract. Each card carries facts: the name, address, industry, payment terms, whatever you know about that thing.

Cards are also connected by lines: this contact works at that company; this site belongs to that client account. Follow the lines and you can answer questions like “give me everything we know about Acme Ltd” — the company card, the contacts who work there, the documents filed against them, the sites they operate.

This is Memory: cards, facts, and lines between them.

Where Memory comes from

You rarely fill Memory in by hand. Routario assembles it from what you already have:

Your contacts — when you add a contact or a company, the information lands in Memory automatically.
Tables — records you store in Custom Tables become cards in Memory and are available to automations.
Documents you drop in — upload a contract, a brief, or a supplier email and Routario reads it, adds what it learns to the cards it already has, and keeps every other name the document mentions on the document itself.
Notes you write on a record — a note on a contact, a company, a deal or a table row stays on that record, and Memory reads it too, like any other document: the names, identifiers, dates and amounts it mentions are noticed, search finds it, and a note on a contact or company is linked to that card. It is listed in Memory as Note on …, from A note on a record — a Something lands in memory trigger can listen for exactly those. Editing a note replaces what Memory read from it; deleting it archives that copy.

The note shows you right away how it connected. What Memory caught is marked in the text: a dashed underline for something it only noticed (hover: Noticed by memory · IČO), a tinted link for something that is a card (Card · Bosch, which opens the card). Under the note, a Job that read it shows as a solid token (Read by Tender radar), next to how many cards it connects to and Open in graph, which opens the graph centred on the note. A note Memory is still reading says so and fills itself in a few seconds later.

The result is that Memory grows as you work, not as a separate data-entry task.

Reading is not the same as keeping

Routario reads everything, but it does not make a card for every name it reads. A leaflet that names forty brands, or a newsletter that names a dozen people, would otherwise bury the handful of companies and people you actually deal with. So a name a document mentions stays on that document, where search finds it, until something keeps it:

you — one click on Make it a card on the document;
a Job — each Job brings the rules it needs. The memory curator keeps the people your team emails with and their companies; a Job that answers customer questions can keep the products they name; a Job that books invoices keeps their suppliers and the companies the invoices name.

Identifiers — postal codes, phone numbers, email addresses, company and VAT numbers, IBANs and account numbers, order and invoice numbers, barcodes — are never cards. Memory recognises them in the text itself, checking the check digit wherever the number has one, and keeps them on their documents as waypoints. A waypoint connects the documents that share it: search for an IČO or an invoice number and you get every document that carries it. When a card already carries the same identifier (a company whose IČO a Job recorded, a contact with that email), the document is linked to that card as well. Memory never decides on its own whose an identifier is.

Dates work the same way. Every date a document prints (3. 3. 2026, 12 March 2026, March 2026) is linked to that day, and the day to its month and year. On a document, click a date or a month under Connected to → Carries to see every document dated then. The two combine, so you can list every document from March 2026 that carries a given invoice number.

An amount counts too, but only with its currency: “12 400,00 Kč” on an invoice and “-12 400,00 CZK” on the bank statement that paid it are the same waypoint. A bare number stays plain text.

Memory also reads what a file says about itself. A PDF’s or Office document’s title, author, company, created and modified dates and page count are shown under Came in in the document’s story, next to its size and type. The author and company are kept as names the document mentions, like any other name. See Settings → Memory → What Memory keeps for the rules your workspace runs, and Tune what Memory learns for how they work.

Memory’s guess

Memory also guesses what kind of document each one is, from one short list that is the same in every workspace (Invoice, Receipt, Delivery note, Price list or catalogue, Message, Photo, …), and notes its shape: a table, text or an image. The guess is made in the same pass that reads the names, with no separate call, and is shown on the document as Memory’s guess. Filter the Memory list by it, or click it to see every document that shares it. It is only a guess. It never routes a document, never starts anything, and never replaces what the document’s source said it was. See Tune what Memory learns.

What a Job read a document as

Memory notices what a document mentions and guesses its kind. It does not decide what the document is — the Job that reads it does. When a Job’s flow reads a stored document with an Extract step, the result is kept as that Job’s reading of the document: the recipe it used, what that recipe says the document is, and the fields it took out. The document’s story lists each one under Read: a solid token, opex invoice, marked with the Job’s briefcase (hover it: Read by Invoice Intake), then which Job and which version of its recipe read it, and the fields it took out. The rows it produced are under Produced. Each Job, recipe and row opens in a new tab.

A document can carry several readings. Two Jobs that read the same email differently both stand, and neither overwrites the other or the type Memory guessed. When a Job reads a document again with a different recipe version, its new reading replaces the old one on the page, and the old one is kept.

A document’s story

In Memory, everything that came in is one list, newest first, and each row says in one line what happened to it: Supplier bill from Pekárna Novák · read by Invoice Intake → a row in Opex invoices, or From Jana Nováková · handled by Zero inbox keeper, Follow-up keeper (failed) when a Job’s flow ran on it without reading anything out of it. Filter it by kind, by where it came from, or by the Job that read it. Search memory… finds a document by its text, the names it mentions, the values a Job read from it, and any identifier, date or amount it carries.

Click a row and its story opens beside the list, in the order it happened (Open full page shows the same story on its own page):

Came in. The channel and which one (the mailbox, the flow), when, and the email it came attached to or the files attached to it.
Read. Each Job’s reading, then memory’s guess, marked guess. A guess never routes, decides or overwrites anything.
Handled. The Jobs whose flows ran on it without recording a reading, such as an inbox-sorting agent that acts on every email and takes nothing out of it. Each shows when its latest run started and how it ended (completed, failed…), with a link to the run. Only when no Job has read it or handled it does the story say No Job has looked at this yet.
Produced. The rows a reading wrote.
Connected to. The cards it names, each opening the real record (a contact in Contacts, a deal), then everything exact it carries, each leading to the other documents that carry the same, then the names memory noticed that are not cards yet. Your own company and colleagues are never offered as new cards.
Since. Earlier readings a Job replaced.

On the full page, the Source tab shows the file itself, formatted (a Word document as pages, a spreadsheet as a grid), with the text Memory read from it underneath. See See a document’s original in Memory.

The three words look different everywhere. What memory noticed (a mention, a waypoint, its guess) is quiet: a dashed outline, and Noticed by memory on hover. What a Job read is solid and carries the Job’s mark. A card is the chip with its type icon. When memory noticed a name and a Job read it too, for example the supplier on an invoice, the two halves are joined into one pill.

A card’s page

A card exists because something points at it, and its page shows what, beside its facts and the cards it is linked to:

Records. What you manage that points at it: its own record (a contact or company in Contacts, a deal, a task), the deals and tasks linked to it, the table rows whose reference column names it, and the rows a Job wrote from a document it read the card in.
Read by. Each Job’s reading of a document with a field that names the card — Invoice Intake read faktura.pdf as Supplier.
Documents. Every document that reaches the card, newest first, each saying how: it names the card, memory noticed it under a name not linked yet, or it carries one of the card’s own details (its IČO, email, EAN…), which leads on to every other document that carries the same.

Open in graph starts the graph on the card. A person or company you manage in Contacts opens on its Contacts page; View in Memory there opens this one.

Finding a thing: search and ⌘K

Press ⌘K (Ctrl+K on Windows), or click Search or jump to… at the top of any page, and type a name. Each thing comes back once, however many places know about it. Before, a supplier could appear three times: as the company in Contacts, as its card in Memory, and again through the documents that name it. Now the result opens its real record (the company in Contacts, the deal) when there is one, and the card’s page otherwise.

Beside each result are the same marks the rest of Memory uses:

Card, with the type’s icon, when the result is a card;
mentioned in N, the documents that name it, whether or not they are linked to the card yet. This is the same number as Mentioned in N on the card’s page;
the Job’s mark and a count, for each Job that read it. Invoice Intake 3 means Invoice Intake read three documents with a field naming it. When the thing is both mentioned and read, the two halves are joined into one pill.

For example, searching Pekárna shows Pekárna Novák s.r.o. once, under Companies, marked Card · mentioned in 2 | Invoice Intake 1, and then the documents whose text matches.

A name memory noticed that nothing keeps as a card comes back on its own, under Mentioned, with only its quiet mentioned in N mark. Opening it lists every document that mentions it, and from any of those you can Make it a card. A noticed name that is already a card’s name is part of that card’s result, not a second one.

For every group the palette searches — tables, dashboards and the rows of data products too — and why a teammate may see fewer of them, see ⌘K: what it finds and who sees what.

When nobody reads a kind of document

A document no Job has read is unclaimed. When unclaimed documents keep arriving in the same form — from the same sender, with the same guess and shape, laid out alike — the memory curator notices and asks you in the Inbox whether to turn on a Job that would read them: 48 unclaimed price lists and catalogues from 2 senders since August. Turn on Leaflet check? Preview lists the documents that Job would read and, where it reads with an Extract step, what reading them would cost. Turn on adds the Job as a draft with its trigger off, for you to activate; Not now declines, and the curator does not ask about those documents again for 90 days. It proposes a Job from the catalog when one would claim the documents, and asks only a few questions a week. Nothing is installed until you say yes.

How automations use Memory

When a flow runs, it can reach into Memory to pull facts about the things it is working with.

A few examples of what this looks like in practice:

Personalising an email. A “silent customer” flow finds contacts who haven’t ordered recently. Before sending each email, a Get memory item step pulls what Routario knows about that contact — their name, their usual product category, who their account manager is — and the email step uses those facts to write something that sounds like it was written for them, not mass-mailed.

Routing a new document. A document arrives in your inbox. A Something lands in memory trigger, set to PDFs from email, fires — and only for those, so a newsletter or a pasted note never starts a run. A step looks up the company mentioned on the document and finds their account owner. The document gets filed and the owner gets a notification — without anyone lifting a finger.

In both cases the automation acts with context it got from Memory, not from a lookup the user had to set up in advance.

Reading what is already there. Turning a Job on, or changing its recipe, only affects documents that land from then on. To bring the past along, open the Job’s Readings panel: Re-read shows how many documents the Job would read today and what that costs before anything runs, and Prune withdraws readings the Job no longer wants. Nothing is deleted: a withdrawn reading is kept, rows only it produced go to the table’s Trash, rows someone edited stay, and the last run can be undone.

Ask Memory a question

Reaching into Memory from a flow is one way to use it. The other — the one people underuse — is to just ask. Open Memory and type a question the way you’d ask a colleague who has been with you for years: “what’s Acme’s payment term?”, “when did I say I’d get back to them?”, “who’s the technical contact there?”

Routario finds the answer in your own documents and shows it to you with the exact sentence it came from. Two things make this more useful than a search box:

It understands what you mean, not the exact words you typed. Ask “when did I suggest meeting them?” and Routario finds the line “let’s do the 14th” buried in an old email — even though none of those words match. You can ask in English about a note written in another language. You phrase the question however feels natural; Routario does the matching.

It only answers from what is actually there. Every answer is backed by a real quote from a real document. If Routario does not have the answer, it says so and points you at the closest thing it does know — it will never invent one. An answer it cannot trace back to a source is an answer it will not give.

Where it shines: the stuff you never filed. You forwarded a supplier’s email weeks ago and moved on — you never made a card for it, never typed the details into a form. Today you ask “how long did that supplier want before starting?” Routario surfaces the exact line — “I’d like another two to three weeks” — and shows you which email it came from. That fact was never a field you filled in; it was sitting in the prose of a note you had forgotten, and Ask reached it anyway.

This is the difference between Memory as a filing cabinet and Memory as something you can actually interrogate.

Always-available facts

Some Memory values are available in every single run without any lookup step at all. These come in as template variables you can drop into any field:

{{ workspace.name }} — the name of your workspace (useful in email signatures, report headers)
{{ user.firstName }}, {{ user.email }} — the person who started the run

These are the simplest form of Memory: facts that Routario always knows, always in scope.

What Memory is not for

A few things that often get confused:

This belongs in Memory	This does not
A customer’s address	A log of every delivery made to them
A company’s payment terms	A history of every invoice sent
Who a contact works for	Every email you exchanged with them
A site’s location	Every visit or inspection record

Run history, audit logs, and activity feeds are separate. Memory is the stable, factual picture; history is the running record of what happened.

Working with contacts

Contacts is the primary surface for browsing and editing the people and companies in Memory. Changes you make there — adding a phone number, updating a company name, linking a contact to an account — flow back into Memory immediately and are available to every automation from that point on.

Where to go next

See a document’s original in Memory — the file itself, formatted, next to what Memory read from it.
Tune what Memory learns from your documents — what Memory guesses about a document, and which names it keeps as cards.
Merge duplicate cards — and undo it — when the same customer ends up on two cards, put the halves back together (and undo it if you were wrong).
Template variables — the full list of {{ workspace.* }}, {{ user.* }}, and other values always in scope during a run.
Working with contacts — browse, edit, and link the people and companies in Memory.
Get memory item — the step that reads a note or document from Memory and returns the facts and contacts it mentions.