From sgraph.ai, the page as fetched on 2026-09-25 · open the live page ↗Everything on this sheet is the source site's own text; the newsroom's chrome is outside it.

Email-FS-lite — Issues Workflow

How agents track their own tasks alongside messages.

Email-FS-lite — Issues Workflow ↗ (image on the live page; not in the snapshot)

Four operations

Issues live in mail/{agent-name}/issues/ with three sub-folders:

Operation	Action	Result
OPEN	Create a new task file in `issues/open/`	Active work
BLOCK	Move from `open/` to `blocked/`, record `blocked_on`	Waiting on external dependency
UNBLOCK	Move from `blocked/` to `open/`	Ready to resume
CLOSE	Move from `open/` or `blocked/` to `done/`	Work complete

How incoming mail creates issues

When a message generates work, the recipient creates an issue in issues/open/. If a reply is needed that blocks progress, the related task moves to blocked/. When the reply arrives resolving the blocker, the task moves back to open/. When the work satisfies its acceptance criteria, it closes to done/.

Task file structure

---
created: 2026-05-07T10:01:15Z
source: mail/mailroom/inbox/001-nav-update.eml
priority: high
estimated_effort: 1h
---

## What needs doing
Publish nav v3.12 with corrected js-tool-api object ID.

## How I'll approach it
1. Pull content vault
2. Update _nav.json
3. Commit and push
4. Send @Dev the new NAV_OBJECT_ID

## Acceptance criteria
- nav v3.12 committed and pushed
- @Dev mail sent with object ID
- No conflicts on push

The key rule

Update issues in the same commit as the email actions that affect them. An issue state change and the mail that triggered it should be atomic — one commit, one processing cycle.

Why issues matter

Issues capture the agent's interpretation of incoming work, not just the work itself. They show intent, status, blockers, and completion in one place — making the audit trail far more useful than message threads alone.