The Autonomous Stack
Agent Inbox Triage Pack icon

Agent Inbox Triage Pack · Communication · v1.0

Email inbox triage agent with draft replies

Turnkey BYO-LLM inbox-triage agent. One-shot Debian install, email classification, priority scoring, draft replies.

$3.00one-timePay with crypto

Buy on Gumroad → https://6355137346884.gumroad.com/l/tas-agent-inbox-v1

inbox email triage autonomous byo-llm

agent ⟶ theautonomousstack.xyz

01GET /api/v1/pack/agent-inbox-v1

402 Payment RequiredPAYMENT-REQUIRED

02sign TransferWithAuthorization3.00 USDC · Base (eip155:8453)

03GET + PAYMENT-SIGNATURE

200 OKapplication/zip · 26 files

pay per pack over x402no account

What's inside

  • CHANGELOG.md
  • CHECKLIST.md
  • CUSTOMIZE.md
  • EXAMPLE.py
  • OPERATING_COST_ESTIMATE.md
  • PROMPTS.md
  • README.md
  • SOUL.md
  • SPEC.md
  • SUCCESS_METRICS.md
  • agent-inbox-v1.json
  • agent-inbox-v1.service
  • agent.py
  • deploy.sh
  • install.sh
  • llm_adapter.py
  • pack_memory.py
  • requirements.txt
  • scripts/config.yaml
  • scripts/install.sh
  • scripts/run_agent.py
  • scripts/test_prompt.py
  • smoke_test.sh
  • templates/retry_policy.yaml
  • templates/worker_config.yaml
  • test_agent.py

An autonomous email-triage agent you deploy on a Debian VM in one command. It runs a reliable deterministic core out of the box, and gets smart when you connect your existing coding-agent subscription — Claude Code, Kimi Code, or Codex — with no API key.

Architecture

┌─────────────────────────────────────────────────────────────────────────┐
│                       AGENT INBOX TRIAGE v1.0                            │
├─────────────────────────────────────────────────────────────────────────┤
│  ┌───────────┐   ┌───────────┐   ┌───────────┐   ┌──────────────────┐  │
│  │ Ingestion │──▶│   Queue   │──▶│ Dispatcher│──▶│ Executor         │  │
│  │ (IMAP/API │   │ (SQLite)  │   │(OODA loop)│   │ (LLM / ♞)        │  │
│  │ /manual)  │   └─────┬─────┘   └───────────┘   └────────┬─────────┘  │
│  └───────────┘         │                                  │            │
│                 ┌──────┴──────┐                    ┌──────┴────┐       │
│                 │ Dead Letter │◀───────────────────│   Retry   │       │
│                 │    Queue    │   (max 3 attempts) │  Policy   │       │
│                 └─────────────┘                    └───────────┘       │
│                                                                         │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │                         Monitor                                    │  │
│  │  (queue depth / dead-letter / stall / inbox backlog / alerts)     │  │
│  └───────────────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────────┘
  • Ingestion : cron, webhook, CLI (agent.py enqueue), or IMAP adapter you add
  • Queue : SQLite locale par défaut, zero-config, zero-deps
  • Dispatcher : boucle OODA — observe, oriente, décide, agit
  • Executor : mode déterministe (♞) par défaut, mode LLM si CLI connectée
  • Retry Policy : backoff exponentiel 10s → 60s → 600s
  • Dead Letter : tâches en échec conservées, replayables
  • Monitor : sondes intégrées, alertes configurables

One-shot install (Debian/Ubuntu)

unzip agent-inbox-v1.zip && cd agent-inbox-v1
sudo bash install.sh          # system deps + venv + systemd service (enabled)

That's it. The agent starts as a systemd service (agent-inbox-v1), survives reboots, and restarts on failure. Logs: journalctl -u agent-inbox-v1 -f.

No root / no systemd? bash install.sh --no-service sets up the venv, then run venv/bin/python agent.py run.

Connect your LLM (optional, no API key)

install.sh auto-detects the first CLI it finds. Install & log in to one:

CLI Install Connect
Claude Code npm i -g @anthropic-ai/claude-code run claude, /login
Kimi Code see platform.moonshot.ai kimi-code
Codex npm i -g @openai/codex codex login

Force a specific one with PACK_LLM=claude|kimi|codex. If none is connected, the agent still runs — see the honesty table below.

What's LLM vs deterministic (honest by design)

Capability Without an LLM CLI With an LLM CLI connected
Queue, priorities, scheduling ✅ deterministic ✅ deterministic
Retry + exponential backoff ✅ deterministic ✅ deterministic
Dead-letter + replay ✅ deterministic ✅ deterministic
Dependencies (block on failed dep) ✅ deterministic ✅ deterministic
Idempotency (at-most-once key) ✅ deterministic ✅ deterministic
Email classification / drafting built-in handlers (classify_email, draft_reply, archive_email, forward_email, extract_task) the LLM runs the Executor prompt (PROMPTS.md) on each task

If a CLI is installed but not logged in, the agent logs a warning and falls back to the deterministic handler for that task — it never gets stuck.

Classification contract (honest by design) : classify_email always returns the canonical pack contract object {"ok": true, "category": ..., "confidence": "deterministic", "action": "review", "mode": "deterministic"}.

  • category is exactly one of invoice | support | newsletter | general — urgent is NOT a valid category. Emails with payment deadlines, due dates or "ASAP" are classified by CONTENT (a payment reminder is invoice, never urgent).
  • confidence and mode are always the literal string "deterministic" — never a number.
  • No context invention : the agent never fabricates an invoice ID, client, approval number, message ID, attachment, forward recipient or queue that is not in the payload. When any of these is missing or ambiguous, the result is action=review.

Quick commands

python agent.py status
python agent.py enqueue --type classify_email --payload '{"from":"alice@example.com","subject":"Q2 invoice","body":"Please find the invoice attached."}'
python agent.py enqueue --type draft_reply --idempotency-key reply-2026-06-12
python agent.py run --once
python agent.py run --deterministic
python agent.py replay --task t-ab12cd34
bash smoke_test.sh
python EXAMPLE.py

Contents

File Purpose
agent.py Runnable inbox triage agent — SQLite queue, retry, dead-letter, OODA, BYO-LLM wiring
llm_adapter.py BYO-LLM CLI adapter (claude/kimi/codex), no API key
install.sh One-shot Debian installer (deps + venv + systemd)
agent-inbox-v1.service Reference systemd unit (install.sh generates the real one)
smoke_test.sh / test_agent.py Offline test suite (deterministic)
EXAMPLE.py End-to-end runnable demo of the shipped pipeline
PROMPTS.md The Dispatcher / Executor / Monitor prompts the agent actually loads
SOUL.md Agent identity, values, OODA loop
SPEC.md Technical spec: task format, retry, scheduling, interfaces
CHECKLIST.md Deployment checklist
SUCCESS_METRICS.md KPI targets + failure definition
OPERATING_COST_ESTIMATE.md LLM cost estimate (only relevant in LLM mode)
requirements.txt Python deps (stdlib only)
deploy.sh Thin wrapper → install.sh

Use a local model (Ollama)

The optional LLM step can also run on your own machine through Ollama, so no text leaves your server. No account and no API key.

ollama pull <model>               # any chat model you like
export PACK_LLM=ollama            # prefer Ollama even if a coding-agent CLI is installed
export PACK_OLLAMA_MODEL=<model>  # optional: default is the first chat model the server lists
python3 -c "import llm_adapter; print(llm_adapter.detect())"   # prints: ollama
  • PACK_OLLAMA_HOST points to another server (default http://127.0.0.1:11434); OLLAMA_HOST is also read when PACK_LLM=ollama.
  • PACK_OLLAMA_NUM_CTX sets the context size if your reports or prompts are long.
  • Without PACK_LLM, a local Ollama server is used only when no Claude Code, Kimi Code or Codex CLI is found.
  • If the server is down or the model is missing, the pack keeps working in its deterministic mode.

Learning memory (local and private)

Every LLM call this pack makes is journaled in ./.pack_memory/ next to the code, so the pack can improve for you. Nothing is ever sent anywhere.

  • What is kept: the task name, the masked input, the masked answer, status and latency. Keys, tokens, e-mails, phone numbers, IP addresses, card and IBAN numbers and personal paths are masked before writing; the system prompt is never stored.
  • Teach it: python3 pack_memory.py feedback last ok confirms a result, python3 pack_memory.py feedback last bad --fix "the right answer" corrects it. Confirmed and corrected runs are reused as validated examples when a similar input comes in. Unrated runs are never injected into a prompt.
  • Find similar cases: python3 pack_memory.py similar "some text" and python3 pack_memory.py clusters (groups of near-identical failures) work in plain Python, no model needed. Optional meaning-based matching uses an embedding model you already run locally: python3 pack_memory.py enable-semantic (Ollama on this machine only).
  • Share, only if you want: python3 pack_memory.py export writes an anonymised summary (counts, statuses, size buckets, no text) for you to review.
  • Control: PACK_MEMORY=0 turns it off, PACK_MEMORY_STORE_TEXT=0 keeps fingerprints only, python3 pack_memory.py purge --yes wipes it.