An AI That Keeps Working After You Close the Chat: File Events, Schedules, and Channels

Every AI chat has the same shape: you open a window, you describe the task, you paste the material, you read the answer, you close the window. It is a good shape for a question. It is a poor shape for a job — because a job is mostly the same task recurring on new material, and the part a chat can't do is be there when the new material shows up.

Chat is a session; work is standing

Filer keeps the chat — every folder has a chat panel, and a lot of one-off work happens there. But the thing that makes a folder agent different is that it is not only a chat. An agent attached to a folder is a standing arrangement: you describe once what should happen in that folder, and from then on the agent fires when its folder gives it a reason to, whether or not Filer's window is in front of you. The conversation becomes the exception; the folder doing its own work becomes the rule.

Three triggers

Besides you typing in the chat, three things can wake a folder agent up:

A file event. Something is added to, changed in, or removed from the folder — a recording lands, a spreadsheet is updated, a policy document is overwritten. The agent runs against that file. This is how a folder becomes a pipeline: each step's output is a new file, and the next step's trigger. See the doc-diff-notify usecase for a change-watch built exactly this way.
A schedule. A time, not an event. "Every weekday at 6 pm" is typed in plain language into the folder's schedule list (in the Filer AI tab), runs on your machine's own clock, and does not care whether anything happened in the folder in between — it reads whatever is there. This is the scheduled-report usecase.
A message. An inbound message on a channel connected to the folder — Telegram, Slack, Discord or email, through the bundled plugins — is treated as work arriving. You forward a lead, or ask a question from your phone, and the folder's agent answers from what the folder holds. See the messenger-remote-checkin usecase.

All three route through the same agent with the same instructions and the same boundary. Nothing about the trigger changes what the agent is allowed to do — only when it starts.

Writing the instruction once

The description lives in a small text file inside the folder, .filer/AGENTS.md, written in plain language. Filer creates it when you add an agent; you edit it like any note. Here is a real one, verbatim, from a folder that collects status notes while its owner is away:

# Away-time status digest

This folder collects short status notes while I'm away from my desk.

On a scheduled run:
1. Read every .txt file directly in this folder.
2. Write a one-paragraph digest of what's new to reports/{date}.md.
3. Send the same digest as a Telegram message.

That is the whole program. It does not say how to read a text file, how to format a date, or what a Telegram message is — the agent knows those. It says what this folder is for, what to do when its trigger fires, and where the result should go. A schedule is added to the folder once ("every day at 5 pm"), and from then on the digest arrives whether or not anyone opens Filer that day.

Instructions, not code

The file is prose because the reader is a model, not a runtime. A step written the way you would explain it to a colleague — "read every note, write one paragraph, send it to me" — is the correct level of detail. Filename patterns like reports/{date}.md are the one convention worth learning.

Where the output goes

By default, back into the folder: a summary file next to the source, a report under reports/, a converted copy alongside the original. That is deliberate — the folder is the record, and File Explorer is already the place you look for records. When you want to be told rather than to go and look, the same agent can also send the result out through a channel plugin, which is how a scheduled digest ends up on your phone. Both destinations are just lines in the instruction file; the agent does not need a second configuration to use them.

Every run — what triggered it, what it read, which tools it called, what it wrote — is recorded in the folder's activity history inside Filer, so "what did it do while I was out" is a list, not a guess.

Guardrails

An agent that acts on its own needs limits that hold without you watching. Filer's are the same ones that apply when you are watching:

The folder is the boundary. An agent can only write inside its own folder tree, enforced in code — the same rule described in the previous post. A trigger cannot widen it.
The trust level still applies. The actions Filer gates — deleting or moving a file, running a command, rolling back — wait for approval on an unattended run exactly as they would in chat, unless the folder's level allows them; and if nobody is there to approve, they do not happen. Set the level to match how unattended the folder will be.
Cascades are tagged. When one agent's output lands in another agent's watched folder, Filer records which agent caused the event and detects cycles, so two folders cannot trigger each other forever.
Failures retry, then stop. A run that fails is retried a few times with increasing delay and then marked as an error in the activity history rather than looping.

What it needs

A Windows PC with Filer installed and a model source configured (local, your own API key, or a company server)
A folder where the recurring work already arrives, with an agent added to it and a few lines of instruction
For schedules: a time in plain language. For channels: one of the bundled messaging plugins connected to the folder

How it works, step by step · More from the blog

Give a folder a standing job

Download Filer