Fontanini Advisory Services
Not signed in
Assigned inModule 4

Agentic Email Processing

A worked design for email triage, and where its boundaries are set.

Time to read: about 6 minutes

Agentic Email Processing

How a unified config file turns your inbox from a pile of unrelated messages into a prioritized, project-aware briefing. The system drafts, but never sends. That is a design decision, not a limitation.


The Supervisor-Worker Pattern

One triage agent reads every email and routes it, and specialized workers handle enrichment, prioritization, and drafting. A daily digest surfaces what matters, and it is your one checkpoint: you approve or adjust suggested drafts there. The human checkpoint is the point of the architecture.

Gmail API Fetch Triage Agent reads config + classifies + assigns Enrichment Worker project context + history Prioritizer Worker urgency + deadlines + weight Drafter Worker tone-aware + confidence-gated Daily Digest human checkpoint config.yaml single source of truth

One File. Every Automation.

The config is not a settings file; it is the system's understanding of your practice. When you update a project here, every downstream automation inherits the change. This is the Setup Frame applied to systems, not conversations. The config is version-controlled and access-controlled like any other critical system file. Changes are committed to Git (a system that records every change and who made it), reviewed before deploy, and auditable after the fact.

rebellion-config.yaml
# Unified config: one file, all automations projects: - id: "death-star-assault" name: "Death Star Assault Planning" type: "military-operation" status: "active" priority_weight: 10 contacts: - name: "Mon Mothma" role: "Alliance Commander" relationship: "strategic-leader" comm_style: "Formal, measured. Prefers complete briefings." - name: "Admiral Ackbar" role: "Fleet Commander" comm_style: "Direct operational language. Dislikes ambiguity." active_threads: - "Exhaust port vulnerability analysis" - "X-wing squadron readiness" - "Stolen plans verification" deliverables: - description: "Attack run briefing" due: "before Yavin approach" status: "in-progress" email_rules: classify_as: "requires-response" max_draft_confidence: "low" # High-stakes operation. Never auto-draft. - id: "smuggler-recruitment" name: "Independent Contractor Pipeline" status: "cultivating" priority_weight: 6 contacts: - name: "Han Solo" relationship: "prospect" comm_style: "Casual. Allergic to formality. Do not oversell." - name: "Lando Calrissian" relationship: "warm-referral" comm_style: "Charming but cautious. Wants to know what's in it for him." email_rules: max_draft_confidence: "medium" # Han responds to directness, not polish
Priority Weight

A 1-10 score that influences digest ranking. The Death Star assault outranks supply logistics. When two emails arrive at the same time, the system knows which one you see first.

Communication Style

Per-contact tone guidance. Mon Mothma gets formal briefings. Han Solo gets directness. The drafter reads these notes before generating a response. Same principle as giving Claude context about your audience.

Draft Confidence

The trust calibration. "Low" means the system produces a skeleton with placeholders. "High" means it drafts a near-ready response. Strategic relationships stay at "low" because the cost of a wrong tone is higher than the time saved.

Active Threads

What the enrichment worker uses to pull relevant context. When an email from Ackbar arrives, the system knows to surface the exhaust port analysis and squadron readiness status alongside it.


What the System Produces

The emails are invented, and so is this run: it shows how the design handles a typical morning. Five emails arrive overnight. The triage agent classifies each one, the enrichment worker pulls context, the prioritizer ranks them, and the drafter generates responses where confidence allows. Click each email to see what the system surfaces.

The Design Principle

Notice what the system does not do. It does not reply to Mon Mothma, guess at Maz Kanata's intent, or skip the human checkpoint for high-stakes relationships. The value is not in what it automates. The value is in how it organizes your attention so you spend your judgment where it matters most.


Build Sequence

Each phase adds one capability. You can stop at any phase and still have a useful system. The sophistication of the architecture follows the complexity of the problem, not the other way around.

01

Config Migration

Week 1

Move from per-client files to one unified config. Existing transcript processing reads from the new file. Validate that output quality is identical. Change nothing else.

02

Email Triage

Weeks 2-3

Build the triage agent. It classifies email against the config and writes a digest. No drafting. Backtest against three days of history, then run live for a week. Target: 85% classification accuracy.

03

Enrichment Layer

Week 4

When an email matches a project, pull active threads, deliverable status, and contact communication style. The digest now includes a "Context" block per email.

04

Draft Responses

Weeks 5-6

Generate drafts where confidence allows. All drafts go to the Gmail drafts folder. Track: used as-is, edited then sent, or discarded. Target: 40% usable with minor edits. Zero relationship-damaging drafts.

05

Daily Digest

Weeks 7-8

Connect all workers to a morning briefing. "Here is what you are working on today, ranked by priority." The inbox becomes a curated briefing rather than an unfiltered stream.


Config Review Cadence

A config is only useful if it reflects current reality. Three rhythms keep it honest.

Event-Triggered
New engagement starts, project closes, key contact changes role. Update same day.
Biweekly
15-minute scan. Is every project status accurate? Are active threads current? Update dates, commit to Git.
Annual
60-minute structural review. Are the categories right? Are priority weights calibrated? Should "cultivating" relationships be promoted or archived?

What This Teaches

Every design decision in this system maps to a principle from the program. The same skills you are building in conversation with AI apply to building systems with AI.

Conversation Architecture

Config as Setup Frame

The config file is a Setup Frame for an automated system. The quality of the context you provide determines the quality of every output.

Conversation Architecture

Backtest as the Loop

Running three days of historical email through the triage agent and refining the rules is the Loop applied to systems. Test, evaluate, adjust, repeat.

Verification

Polished Drafts Are Dangerous

The drafter produces plausible responses. The more polished they look, the less critically you evaluate them. The human checkpoint exists because AI predicts what is plausible, not what is true.

Verification

Trust Calibration

The max_draft_confidence setting is explicit trust calibration. High confidence for scheduling acknowledgments. Low confidence for strategic relationships. You set the threshold before the system runs, not after.

Building Systems

Intentional Friction

"Drafts, never sends" is a design decision. The goal is to remove the noise between the human and the decision, not the human.

Building Systems

Start Manual, Then Isolate

Phase 1 changes nothing except how the config is structured. Each subsequent phase adds one capability.