How it avoids repeating itself

The handled list

Each agent keeps a private list of the items it has already dealt with. When it reads unread mail or unread Telegram chats, anything on that list is filtered out before the agent ever sees it - so the model does not have to remember anything, and cannot get it wrong.

The list belongs to one agent and one account. Two agents watching the same inbox each keep their own, so both will see every message. That is intentional, but it does mean two agents told to reply will both reply.

When something gets added to the list

It depends on whether the action can be taken back:

• Irreversible actions are recorded the moment they happen. Once a reply is sent, that is written down immediately. If the run crashes three steps later, the reply is still never sent twice.
• Merely reading something is recorded only if the whole run succeeds. If a run fails halfway through, the items it had read but not yet acted on go back in the pile and appear again next time.

The second rule is the safer trade. A failed run means work probably did not get done, and it is better to look at something twice than to silently drop a customer email the agent never got round to.

Test runs do not mark anything as read

Because a test run is a real run, anything it actually sends is recorded. But simply reading during a test does not add to the handled list, so testing does not hide messages from the next real run.

Deleting an agent wipes its list

Rebuilding an agent from scratch gives it an empty handled list, so it will treat everything currently unread as new and act on all of it. If that inbox has two hundred unread messages, be careful what you publish next. Editing an agent, even heavily, keeps the list intact - only deleting clears it.

Two other kinds of memory

The handled list is always on, is maintained for you, and is about specific messages. For everything else the agent has two memories of its own, and they are good at different things.

• Exact state (the Memory tab). Values the agent stores on purpose and gets back verbatim next run: the last order id it confirmed, the reference numbers it already reported, how many reminders it has sent a client. It does this through memory_get and memory_set tools that are on by default (Keep exact state in Settings). Everything it stores appears on the agent’s Memory tab, where you can read it, change it or delete it - reset the “last processed id” after a bad run, or seed a value before the first one. The agent sees your edit on its next run.
• Remember past runs (Settings). Optional, and fuzzier: the agent ends each run with a short note to its future self and reads the most relevant notes back next time. Right for continuity of judgement - “I decided this supplier is not a fit” - and for “don’t report the same thing twice” when the things have no stable reference to compare. It adds a little to the cost of every run.

A rule of thumb: if you could write the value in a spreadsheet cell, it belongs in exact state. If it is a sentence, it belongs in past-run notes. You do not choose the mechanics - describe what to remember in plain English (“keep the id of the last order you confirmed”) and the agent picks the right one.

Sharing state between agents

A key that starts with shared: is visible to every agent in the workspace, so one agent can hand something to another: a finder agent records the tenders it has seen under shared:tenders_seen, and a summariser agent reads the same list. Shared keys show up on every agent’s Memory tab with a shared badge. Deleting one affects all of them, which is why Clear all only removes the agent’s private keys.