Teach your assistant how you work
Your assistant's memory of how you work is trapped in one thread and one vendor. Put your operating context where the work lives, so every session knows it.
The repair counter at a bike shop runs on one standing instruction: before you promise a customer a date, check the supplier's stock note, because half the parts are back-ordered this season. The owner has given his assistant that instruction three times now, once per chat, because every new thread starts blank. This morning he types it a fourth time. The instruction is sound. The trouble is that it lives nowhere his assistant can find it twice.
Your assistant is good at following how you work, right until the conversation ends. What it picked up in one thread does not carry to the next one, or to the assistant a colleague uses, or to your phone tomorrow. This is about giving the way you work a home outside the chat, so an instruction you set once keeps being followed without you re-explaining it.
Why does your assistant forget how you work?
It is not forgetfulness so much as where the memory is kept. Two walls stand between a good instruction and the next time you need it.
Memory is trapped per thread. Most of what an assistant knows about your preferences lives inside the current conversation. Start a fresh chat and that context is gone; the assistant is bright but new to the job again. The instruction you gave on Monday does not travel to Tuesday on its own.
Memory is trapped per vendor. Even where a chat remembers across sessions, that memory belongs to one product. Switch assistants, or let a teammate work from their own, and none of it comes along. Historis takes the opposite stance: you keep your history and your rules, and you bring your own assistant to them, whichever one you use today.
So the fix is not a better memory feature inside the chat. It is structural: put your operating context in the shared place both you and your assistant read from. When the instruction lives with your contacts and your history, a new session does not start blank, it starts by reading what is already written down.
Is it a fact or a behavior?
Before you write anything down, it helps to sort it. Almost everything you would tell an assistant is one of two things, and each has its own home. A fact is something that is or was true. A behavior is something to do when a situation comes up. The grammar gives it away: 'X is Y' is a fact, 'when X, do Y' is a behavior.
| What you want to record | Fact or behavior | Where it lives |
|---|---|---|
| Marie prefers a call over an email | Fact about a contact | A note on her record |
| The supplier's cutoff for next-day parts is 3pm | Fact about the business | A knowledge note |
| Before promising a repair date, check the stock note | Behavior | A rule |
| Contacts tagged VIP get the preview before each launch | Behavior | A rule |
Get this split right and the rest is easy. Facts go where you can read them back on the contact or across the business; behaviors go where your assistant can pick them up at the moment it acts. The rest of this piece is about the second column: what a rule is, and how the right one surfaces when it matters.
What is a rule your assistant can follow?
A rule in Historis is short markdown you write once. It has a title, a body that states one behavior in plain imperative language, a handful of keywords, and, optionally, the specific contacts it concerns. It carries an active toggle, so you can retire a rule for the off-season without deleting it, and a scope, so it applies org-wide or only to one team. Here is the repair-counter instruction, written as a rule:
# Check stock before promising a repair date
When someone asks when a repair will be ready, check the supplier's
stock note for the part before you commit. If it is not in stock,
give a range, never a firm day.
You would tag that rule with keywords like repair, stock, and delivery, the words a draft about a repair is likely to contain. Keep one behavior per rule: a rule that tries to say three things is harder to surface and harder to read back. A second rule, scoped to the people it names, might read:
# Offer VIP contacts the preview
When you log an order or an enquiry from a contact tagged VIP, offer
them the private preview before the next collection goes on sale.
That one you would link to the handful of contacts tagged VIP, so it surfaces on their entries specifically, not on everyone's. Keywords catch a topic; linked contacts catch a person. Most rules lean on one or the other, and the good ones read like something you would actually say to a new hire.
How does the right rule surface at the right moment?
A rule is only useful if it shows up when you need it, not when you go looking for it. So the moment your assistant is about to write something down, it can ask which of your rules apply to the draft. That call is find_applicable_rules.
The server does something deliberately simple with the draft. It breaks the text into words and lines them up against each rule's keywords and linked contacts. The rules that overlap come back in full, most specific first. Your assistant reads them, applies what genuinely fits the situation, and then, when it records the entry with create_event, it notes which rules it used as applied_rule_ids. That last step is the point: the entry itself says which instructions shaped it, so weeks later you can see not just what was written but why.
Nothing here reads your mind. The match is word overlap you could predict by hand, and the deciding is done by your assistant, not the server. The practical upshot is short: your assistant gets handed the relevant instructions at exactly the moment they apply, then records which ones it leaned on.
Where do durable facts go instead?
Behaviors go in rules; facts need a home too, and it is a different one. The simplest is the oldest: a note on a contact's record. Marie prefers a call, this client always pays late, that supplier ships on Thursdays, these are person-facts, and a line on the contact is the right place for them. It is the default, and for most facts it is all you need.
Some things are bigger than one contact. A decision you made about pricing, an observation about how a season went, a reflection you want to keep for next year, those belong in a knowledge note: written down, tagged as a decision, a reflection, or an observation, and linked to the contacts and events it concerns. Your assistant can add one for you and search across them later, by full text always, and by meaning when your organization runs its own embedding worker. Like every entry an assistant makes, a note it writes is marked ◆, the mark of entries added by an assistant: dated, signed, and correctable, so you always know what came from you and what came from it. The rule of thumb holds all the way down: facts go in notes, behaviors go in rules.
What rules are not
It is worth being plain about the boundary, because the honest version is more reassuring than a promise of magic. A rule is retrieved text, not an automation engine. Nothing fires on its own. The server never reads a rule and acts on it; it stores the markdown, matches it by keyword and contact, and hands it back. Your assistant is the one that reads the instruction and decides what to do, and if your assistant does not ask for the rules, nothing happens at all.
That is a limit, and it is also the whole appeal. A rule does exactly what you can read on the page, no more, and it changes nothing behind your back. You are not wiring up triggers and hoping they behave; you are writing down how you work, in words, and trusting an assistant you chose to follow them. When you want the full account of why that separation is the safe one, the no-server-side-AI architecture lays it out.
Teach it once
The repair-counter owner does not have to type his instruction a fifth time. Written as a rule, it waits with his data, and the next assistant to log a repair, in a new thread, on any device, gets handed it at the moment it applies. That is the shift: your way of working stops living in a chat window that resets, and starts living in the memory of your business, every entry dated and signed. Connecting an assistant to read and write it is the same five-minute setup as everything else. Teach it once, and every session starts knowing it.
Frequently asked questions
- How do I make my assistant remember how I work?
- Write the instruction down where the work lives instead of re-typing it into each chat. In Historis, a recurring behavior becomes a rule: short markdown your assistant retrieves before it logs something, tagged with keywords and linked to the contacts it concerns. Because the rule lives with your data rather than in one thread, a new session or a different assistant reads the same instruction.
- What is the difference between a note and a rule?
- A note records a fact: something that is or was true, like a contact's preference or a supplier's cutoff time. A rule records a behavior: what to do when a situation comes up, like checking stock before promising a date. The test is the grammar. If it reads 'X is Y' it is a note; if it reads 'when X, do Y' it is a rule.
- Does my assistant apply rules on its own?
- No. Nothing fires by itself. Before your assistant writes an entry, it can ask which rules apply; the server returns the matching ones as text, and your assistant decides what to do with them. If your assistant never asks, nothing happens. Rules are instructions it retrieves and applies, not an engine that runs on the server.
- Can I write rules without using an assistant at all?
- Yes. The Rules screen in the app lets you write a rule by hand: a title, the markdown body, its keywords, the contacts it links to, an org-wide or team scope, and an active toggle. A rule you write there is retrieved exactly the same way as one your assistant drafted for you. The app and the assistant are two doors into the same list.
- Where should durable facts about a contact go?
- A plain note on the contact's record is the simplest home for a person-fact, and it stays the default. For something larger than one contact, a decision you made, an observation about a season, a reflection worth keeping, there are knowledge notes: tagged and linked to the contacts and events they concern, and searchable later. Facts go in notes; behaviors go in rules.