This document supplements the original Envoy design specification. It captures decisions that are now considered settled direction.
Envoy and PopIt3 are independent systems.
Mail flow:
External → Hotmail → PopIt3 (POP3) → Dovecot (IMAP) → Envoy
Envoy only depends on IMAP and notes. How mail arrives (WebDAV/SMTP/etc.) is irrelevant.
Email is both interface and audit trail.
Envoy should:
- send completion/summary replies
- include what it did and why
- optionally include cost
- allow users to override by replying
Processing is iterative, not single-pass.
gather → gather → gather → process → act
Each step may request more documents or finish.
Never pass full documents between steps.
Pass only:
- note keys
- Message-IDs
Load content only when needed.
Temporary orientation notes may be stored at:
mail/<Message-ID>/working
Deleted after completion.
All LLM responses must be structured JSON.
No plain-text-only replies.
{
"status": "gathering | complete | escalate",
"add_notes": [],
"add_emails": [],
"drop": [],
"write_notes": [],
"move_emails": [],
"delete_emails": [],
"send_emails": [],
"working_note": "...",
"next_model": "cheap | full",
"reasoning": "..."
}Writes occur only on completion.
After N iterations:
Envoy sends itself a continuation email containing JSON state.
This enables:
- crash recovery
- pause/resume
- visible progress
- manual abort
- natural rate limiting
Cheap model for gathering. Full model for reasoning.
LLM selects next tier.
Batch only within same thread. Otherwise process sequentially.
Design must support:
- iteration limits
- cost tracking
- idempotency
- explicit recipients
- escalation
- confirmation emails
End of supplement.