The Cunning Edge

The Rundown Router: Using Human-Defined Context to Automate Email Routing and Operational Accountability

A hurricane is making landfall, and your corporate inbox is flooding with hundreds of messages meant for different operators across the office. Amid the chaos, low-priority traffic and spam (including an ad for your coworker’s favorite coffee shop) bury critical information. Your customer’s vessel, the Obscure Steamboat, is living up to its name as time-sensitive terminal updates disappear into the shared inbox. Every hour that ship sits unscheduled at a dock costs thousands of dollars in demurrage fees, all because a single email went unseen. This is the worst-case scenario every shipping agent on the Mississippi River fights to avoid. When everyone is responsible for everything, no one is responsible for making sure the right information reaches the right person.

Because this industry is notorious for highly unstructured data, standard inbox filters and traditional keyword-based approaches are poorly suited to the problem. While standard text-based emails are present, they are heavily interspersed with emails containing multi-page attachments. These attachments are frequently unsearchable, rotated scans of documents (often containing dense tables), forcing every operator to manually audit the messy files just to flag updates relevant to their vessels.

Given an LLM’s ability to interpret unstructured language and infer relationships between entities such as people, places, and project scopes, this operational bottleneck is well suited to an agentic AI approach. I’ve named this solution the Rundown Router.

The “Rundown” is the live organizational context that drives the system. Written in plain English by human users, it’s stored in a machine-readable format like a simple JSON file or database depending on the size of the organization. This allows operators to easily change routing rules on the fly using standard human descriptions, even with complex time constraints (e.g., “Mike is keeping an eye on the vessel NORD RIVER while Brody is out of the office for the next two days”). The AI does not define these organizational rules; the organization does. Its role is to interpret that human-defined context and apply it consistently to incoming information. By providing this flexible Rundown as part of the AI agent’s decision context, modifying enterprise routing rules becomes quick and intuitive.

The “Router” component of the Rundown Router is the agentic decision-making layer. It evaluates both the live, state-driven Rundown and the incoming email payload to determine the appropriate destination. The orchestration layer then executes that decision. While the primary shared inbox remains completely intact, everything sent to the Rundown Router is actively triaged and forwarded according to the Rundown’s contextual rules. By running this automated triage layer in parallel with the traditional inbox, the system provides a crucial layer of infrastructure redundancy, making a catastrophic “double failure” where a critical update is missed by both humans and the AI highly unlikely.

The Rundown Router separates organizational policy from AI decision-making. Humans define the organization’s current responsibilities and routing rules through the Rundown; the AI interprets incoming information against that context; and the orchestration layer executes and records the resulting decisions. This separation allows the system to adapt to changing operational conditions without giving the AI authority to redefine the rules it is responsible for enforcing.

Architecturally, the Rundown Router executes its workflows across two distinct core pipelines: the Inbound Processing Pipeline and the Outbound Processing Pipeline.

Inbound Email Process

When an incoming email arrives, the raw message is immediately written to the Local Store (Mail Archive) before any processing begins. This design choice ensures that if any downstream pipeline component or model inference fails, the original data is securely preserved locally as an untouched historical backup and the process can be tried again at a later date.

Next, the system hands the data off to the AI via a locally hosted API endpoint. Instead of sending sensitive data to a public third-party API, a self-hosted local model handles the following three tasks in a secure environment:

1. Understanding intent: Translating chaotic, conversational text streams.
2. Fixing scanned files: Straightening out misoriented or upside-down attached images.
3. Stripping out text: Reading raw, unsearchable document tables and converting them to an LLM-readable format.

The orchestration layer then combines the processed email contents with the Rundown and provides them to the AI agent as decision context.

Once the AI returns its routing decision, the orchestration layer executes the final delivery and auditing tasks:

• Personal Inboxes: The orchestrator forwards the message directly to the responsible agents. Operators receive these updates instantly via the mail client of their choice (Outlook, Gmail, Apple Mail), dramatically reducing the need to dig through a shared inbox.
• Decision Log: The orchestrator writes the complete transaction payload to a tracking database. Recording the routing decision, supporting context, confidence level, and model-provided rationale creates a persistent audit trail. This provides total operational transparency and mitigates team accountability gaps.

The Decision Log is essential for human-in-the-loop oversight and serves as the data backbone for a web dashboard. When the AI assigns a low confidence score to an ambiguous email, the orchestrator flags the record and routes it into an escalation queue visible on this interface. Because the database records the routing decision, supporting context, confidence level, and model-provided rationale, the Operations Manager can instantly review the system’s logic, override the decision manually with a single click, and patch the Rundown parameters.

This tracking ledger creates a continuous feedback loop: it provides immediate safety guardrails for high-stakes operational errors while generating real-world historical data that can be used to evaluate and improve the agent’s routing accuracy over time.

Outbound Email Process

The outbound pipeline extends the Rundown Router beyond inbox triage, applying organizational policies to outgoing communication while maintaining a complete operational record.

As with inbound messages, the orchestrator first saves a raw copy to the Local Store (Mail Archive) before triggering any automation. It then routes the outbound payload to the AI through a private, locally hosted API endpoint, keeping sensitive information such as contract rates, client lists, and strategic negotiations within the organization’s infrastructure. The self-hosted model analyzes the message for two purposes:

• Recipient Identification: Identifies who the email is going to, but never changes or adds external addresses.
• Information Extraction: Scanning the email text and attachments to convert everything into LLM-readable format.

The AI then interprets the email against the current CC’ing Instructions, a separate Rundown that defines organizational communication policies. The orchestration layer executes the resulting distribution list:

• Mail Server: Delivers the original message to its intended external recipients.
• Personal Inboxes: Automatically CCs the internal teams and individuals identified by the AI, keeping the appropriate personnel aligned.
• Decision Log: Records the distribution decision and its supporting rationale, creating a persistent audit trail for administrative transparency.

Together, the inbound and outbound pipelines turn the Rundown Router into more than an email-routing system. The same architecture allows organizations to define communication policies in human-readable terms, have AI interpret those policies against unstructured information, and rely on deterministic infrastructure to execute and record the result.

For technical implementation and architectural decisions regarding the Rundown Router, please refer to The Rundown Router: From Architecture to Implementation.