Reusing an orchestration decision: a LangGraph email-triage agent

A second system built on the same framework decision as the personal finance agent — not because LangGraph is the only tool that could route email, but because the requirement shape was the same recurring, partly-deterministic process, and the decision had already been made once, against explicit criteria, for the right reasons.

This is the companion case study to the finance-agent architecture decision. Rather than re-running the same framework evaluation from scratch, this case study tests whether that decision generalises: does it hold up against a structurally different inbox workflow, built for the same household, on the same infrastructure?

The requirement: routine inbox triage, not one-shot summarisation

An inbox that nobody is reading closely enough, twice a day, by hand, breaks down into a similar shape of distinct jobs-to-be-done as the finance agent did:

Ingestion — polling the inbox on a fixed schedule, not on every new message
Intent routing — separating bills and statements, action items, and noise before any extraction work happens
Structured extraction — pulling key data and attachments out of the messages worth keeping
Persistence — writing what was extracted into a queryable knowledge base, not just a label
Task extraction — turning action items into tasks assigned for human review, not silently filed
Flagging — marking anything important enough to need a backup copy kept
Narrative generation — a daily plain-English summary of what came in and what needs attention

Like the finance agent, this is a recurring batch process against accumulating data, not a single generative request — the same axis that made LangGraph the right fit the first time.

Why the same framework, not a fresh decision

The full three-way evaluation against CrewAI and a single-agent design was not repeated here — it lives in the finance-agent decision tree. What was checked instead was whether the requirement shape was the same kind of fit, or a superficially similar one that would have justified a different tool:

Cron-triggered, not event-triggered on every email — the same "same sequence runs again on a fixed cadence" shape as the finance agent's folder-watcher trigger
A fixed pipeline order today (ingest → route → extract → persist → notify), with intent-based routing already a first-class part of the graph rather than a future phase — the one place this system is further along than the finance agent was at the same stage
No multi-agent debate or negotiation required between steps — classification and extraction are deterministic concerns, not collaborative ones, which is the same reasoning that ruled out CrewAI the first time

The reuse is the point being made, not a shortcut taken to avoid writing it up twice: a framework decision made against explicit requirements should generalise to a second workload with the same shape, without needing to be re-justified from zero.

Current state: what's actually running

A single LangGraph graph, cron-triggered twice daily, against a shared PostgreSQL knowledge base. Each run polls the inbox, routes each message by intent, extracts structured data and attachments from anything worth keeping, and persists the result. Messages flagged as important are marked for backup rather than left to expire with normal inbox retention. Anything resembling an action item is turned into a task and assigned into Obsidian for human review, rather than acted on autonomously.

Each run closes with a narrative step — a plain-English daily summary of what came in, what was extracted, and what now needs attention — the same narrate-from-structured-data pattern used in the finance agent's reporting graph, applied to a different data source.

Future state: where the conditional-edge case actually shows up first

The finance agent chose LangGraph partly for conditional-edge routing it had not yet built. This system is closer to needing it:

A. Priority-based routing

Not every flagged message should wait for the next scheduled run. Conditional edges routing anything time-sensitive to an immediate notification, rather than the next twice-daily cycle, without changing the rest of the graph.

B. Cross-agent linkage

Invoice and statement emails currently sit in this system's own knowledge base, separate from the finance agent's ledger, which still ingests from manually exported CSVs. Routing relevant attachments into the finance agent's ingestion pipeline directly would close that gap — two graphs today, a shared boundary tomorrow, not a merge into one.

C. Conversational Q&A

The same deliberately-last, deliberately-single-agent pattern as the finance agent's Phase D — ad-hoc questions against the email knowledge base, answered only once the extraction and routing it depends on is trustworthy.

Where this case study leans on the other one

This system did not independently re-derive the LangGraph decision — it inherited it, and this write-up is explicit about that rather than presenting a second framework bake-off that did not happen. The risk in reuse is applying a past decision to a workload that only superficially resembles the original; the check above (cron cadence, deterministic ordering, no multi-agent negotiation) is what justifies the reuse rather than assuming it.

As with the finance agent, the implementation work here was done with AI-assisted development (Claude Code). The same gap applies — legible, working code without yet the fluency to debug the framework unaided — and the same remedy applies: closing it through formal study rather than continued reliance on AI-assisted implementation alone.

See where this framework decision was originally made, against explicit requirements.

Read the finance-agent case study →