Your email

Mail does two jobs, and only one of them belongs in a brain. The first is triage: what is in my inbox right now, who wrote, what is still unread. That is a view over your mailbox, and it stays there. The second is memory: Jane confirmed the move on 11 September, Sam wants the revised deck by Friday, the contract changed in the thread after that one. That is what Cortex takes. So Cortex files what mattered onto the people, companies and projects a thread touched, keeps a link back to the message, and never keeps the message.

​

What you get

A month of forwarded threads, and the pages in your brain read like a record of your dealings rather than a pile of mail. The page for a client contact carries dated lines in her timeline: what she confirmed, what she asked you for, what she told you had changed, each one linking the other people involved and citing the message it came from. Your todo page carries her asks with their dates and a link straight back to the thread. Each day’s note carries one line for each thread that mattered. The company’s page says whatever the thread changed about it. What you will not find is a page called “RE: contract revision”, or a page for every sender, or a person page that reads like a mailbox. A thread gets a page of its own only when the thread is itself the record: a decision made by mail, a complaint, a change to a contract. Most threads produce lines, not pages.

​

What Cortex keeps, and what it never keeps

Kept: the lines and pages it wrote. Alongside them, a short record of the delivery: the subject as the item’s name, the link back to the message in your mailbox, the date, and the list of pages it was filed to. That record is what a citation on a page points at, and it is how you check later what was read and where it went. Never kept: the message. The text of a thread exists in Cortex only while the item is waiting to be filed. It is destroyed the moment filing ends, whichever way it ends: filed and archived, rejected, deleted, or left unfiled for seven days, which closes it. After that there is nothing to download and nothing to read back. The brain’s Sources record says “Body not kept” and offers the link to your mailbox instead. Attachments never arrive at all. They are dropped as the message is read and only their names are carried through, so a filed line can say the revised deck was attached without the deck going anywhere. If an attachment matters, upload it yourself, deliberately. Your mailbox stays the archive. Cortex is the index over it.

​

What you need

• A brain with an address. Any brain can have one: your own, a shared brain, a client brain. An Admin or Owner of the brain creates it under the brain’s Settings, then Ingest sources.
• A verified forwarder. Each brain keeps its own list of the addresses mail may be forwarded from. Your own brain starts with the address you sign in with. On any other brain, add the address you will forward from and confirm it with the code Cortex sends there.
• For the collector route only: a credential on your own mailbox and somewhere to run a small program every half hour.

​

Forward it to your brain

This is the route for everyone. No script, no credential, and it works from your phone.

​

Forwarded by hand, or by a rule

A message you forward by hand carries the original message as text, with the sender, date, recipients and subject written at the top of the body. Cortex reads that block, in the shapes Gmail, Outlook and Apple Mail write it, so the thread is filed under the person who actually wrote it rather than under you. A rule-based forward keeps the original headers intact, so the people on the thread and the thread’s own identity are exact. That is the better of the two if you are setting up a watchlist, but the difference is one of precision, not of where the mail goes.

​

What gets refused, and why nothing bounces

The door is narrow on purpose. A message is refused when:

• it did not come from one of the brain’s verified forwarders, so somebody who learns a brain’s address still cannot put anything in it, and neither can a colleague who has not been added to that brain’s list;
• the brain has an address but no verified forwarder yet;
• the sending domain failed the mail provider’s sender checks, so a forged “from” cannot get in either;
• the address has been rotated or removed;
• in a client brain, the address named a client that does not exist.

A refused message is never bounced. A bounce would tell a stranger that the address exists, so nothing goes back. Instead the refusal is counted on the Ingest sources page, with the date and the sender’s domain, and the message itself is never stored. The same rule applies to every route in. The address a message was sent to chooses the brain, and the address it came from must be on that brain’s list. Nothing in the message, no hint and no setting can send it anywhere else, and an agent asked to file a thread into a brain whose list does not include the mailbox gets the same refusal.

​

Into a shared brain

A shared brain takes mail the same way. An Admin gives it an address; each member who will forward to it adds their own address to its forwarders and confirms the code. From then on any of them can forward a thread by hand or set a rule. What Cortex writes is a little different, because the person who forwarded the thread is a member of the brain, not its subject. Nothing is written about them; the citation names them (“email from Jane Doe, forwarded by Sam Patel”). The people on the thread update their contact and company pages. An ask or a commitment becomes a dated line on the company’s page under Open items (or whichever section the brain’s instructions name), saying who owes what to whom. It never lands on anyone’s personal task list, and the brain’s day notes are not touched. A thread gets a page of its own only when it is itself the record. A shared brain set to Suggest files nothing by itself: every forwarded thread arrives as a proposal in the review queue for a member to accept, which is the check that nothing lands in a shared brain by accident.

​

Into a client brain

A client brain keeps each client in its own folder, so a forwarded thread needs to know which client it belongs to. Two ways:

• Name the client in the address. Put + and the client’s key before the @: clients-k3p9vq2x7m4tbn6shd8afgwz+acme@in.oncortex.ai. The Clients page shows each client’s address next to its name, so you can copy it or set one forwarding rule per client. A key the brain does not know is refused, counted, and the message is not stored.
• Let the people on the thread decide. Forward to the plain address and Cortex reads the addresses on the chain. If exactly one client’s domain is among them, the thread is filed under that client. Your own colleagues never count, whichever domain they write from, so a chain with a colleague and the client on it still resolves. If two clients are on the chain, or none, the item waits in the inbox as “needs a client” for someone to pick one, or is refused outright if the brain is set to reject such items.

The client’s own people are on the chain and that is expected: they are the participants, they are what names the client, and they never have to verify anything. A client mailing the brain’s address directly is refused, since only a member’s verified address is a forwarder. Their mail reaches the brain through a member who forwards it.

​

Let a collector do it

Forwarding needs nothing but a mailbox. A collector is for when you want it to happen on its own, with whole threads and exact participants. A collector is a small program that runs on your side, on a schedule, with your own mailbox credential. It reads only the threads you told it to care about: senders you named, signature requests, anything you tag with a label, and anything you star. A star is the one-key way to say “file this”: it works on a thread of any age, in the inbox or already archived, so you can star and archive in the same breath and the next run picks it up. Everything else stays in your mailbox and is never read past its headers. For each thread with new mail, it takes the new messages only, strips the quoted history out of replies, names the attachments without sending them, and posts the result to your brain with a service credential. Before it sends anything at all, it checks that the mailbox it is reading is a verified forwarder of the brain its credential belongs to. A wrong pairing stops it at startup rather than at delivery. Running it twice files nothing twice: a thread that has gained a reply arrives as a fresh item, and one that has not is recognised as a repeat. Cortex ships a reference collector for Gmail. Microsoft 365 and IMAP are not built yet. It is a more technical setup than forwarding, so the details, along with the shape Cortex expects a thread to arrive in, live in the email contract.

​

Recommended: star and archive

The way we run it ourselves, and suggest you do too:

1. Let the collector watch the people whose mail always matters (your direct reports, your chairman, your outside advisers) and signature requests. Those threads file themselves; you do nothing.
2. For everything else, a star means “file this”. One key in Gmail on the web (s), one swipe on the phone once you set a swipe action to Star (Gmail app, Settings, General settings, Swipe actions). Then archive or delete the mail as you normally would, straight away. The collector finds a starred thread whether it is in the inbox or archived, and whatever the date of its mail, so there is nothing to wait for.
3. Leave the star on. The collector never removes it, and it will not send the same thread twice. A new reply on a starred thread is sent on its own, as a new version of the earlier thread, so what was filed before is updated rather than filed again.
4. Keep your other habits. A star no longer needs to mean “to do”: when a filed thread asks you for something, the filing creates the task on your brain’s task page.

Set it once in the collector’s config: the senders to watch, starred: true, signatures: true, no label. Then schedule it every half hour. Calendar responses (accepted, declined, invitations, cancellations) and out-of-office replies are never sent, whoever they come from. Receipts, itineraries and the like that reach you from a watched sender can be dropped with your own subject patterns (skipSubjects in the config); a skip costs nothing, the thread is never read. Either way, Cortex never holds your mailbox credentials and never polls your mailbox itself.

​

How a thread is filed

Both routes end at the same place: an item in the brain’s inbox, pinned to the Ingest email skill. That skill does the same work whether your agent runs it with you sitting there or Cortex runs it overnight:

1. It looks for the thread’s earlier filing first. If a page already cites this thread, the new messages update that record. There is never a second page for the same thread.
2. It resolves everyone by email address, taken from the message headers rather than from signatures at the bottom. Someone with a page gets it updated. Someone with a real role in your world and no page yet gets one. A one-off sender or an automated notification gets neither.
3. It writes dated lines on each person, company and project the thread was about, and they say something: “confirmed the move to the new supplier”, not “emailed about contract”.
4. Asks become todos. In your own brain, when someone asks you for something with a deadline or a clear next step, it lands on your todo page with the person, the ask, the date and the link. Your own commitments go in the same way. In a shared or client brain the ask goes on the company’s page instead, as described above.
5. The day’s note gets a line for each thread that mattered, in your own brain.
6. Everything cites the link back to the message. The words of the message are never pasted into a page, beyond the odd phrase where the exact wording is the fact: a price, a date, a decision.
7. Then the item is archived, which is what destroys the message.

A thread that arrives with nobody present is filed by Cortex under the brain’s filing mode, so on a brain set to Automatic it files the straightforward ones and parks anything it is unsure about in the review queue with the lines it had drafted. A parked mail item you reject is closed there and then, and its message destroyed with it; it is never put back in the queue.

​

What it costs

A forwarded thread arrives with nobody present, so Cortex files it under the workspace’s monthly ingestion limit, exactly like any other item that arrives on its own. A thread is small next to a document, so it is a cheap item to file. When you hand a thread to your own agent instead, the agent files it with its own tokens and the limit is not touched. How ingestion is paid for has the detail.

​

Keeping it running

• Watch the refused count on the Ingest sources page. It shows how many deliveries were turned away, when the last one was, and which domain it came from. A count that climbs is usually a forward from an address you have not verified yet, or a rule sending from an address you had forgotten about.
• Rotate the address from the Ingest sources page if you think it has leaked. The old one stops working at once and a new one replaces it.
• Remove the address to stop mail entirely. Anything sent to it afterwards is not delivered, and still not bounced.
• Remove a forwarder from the card, and mail forwarded from it is refused from the next delivery on. Ask your agent for the brain’s health check, or run cortex health, and it tells you when a brain has an address but no verified forwarder.
• Nothing lingers. Cortex’s own filing pass closes any mail item that has sat unfiled for seven days and destroys its message, so a brain you stop watching does not quietly accumulate readable mail. Turn automatic filing off for the brain and that pass stops running, so unfiled items then wait for you.

​

What this does not do

• It is not a digest. Cortex does not tell you what is in your inbox; your mail client already does that better.
• It does not send, reply, or mark anything as read. Nothing Cortex does reaches back into your mailbox.
• It does not route by content. The address a message was sent to chooses the brain, the address it came from must be a verified forwarder of that brain, and in a client brain only the +key or the addresses on the chain choose the client. No rule, hint or setting reads the message to decide where it goes. See data and privacy.