Outlook listener with AI orchestration

Process study · proposed method

Automate repeat work. Investigate the exceptions.

Explore how shared fixtures, bounded agent tasks and independent replay review could reduce repeated work in an Outlook project.

Establish the baseline

Permitted shared mailbox
Routing rules and triage categories
Examples of approved replies

Evidence to retain

Reviewed event and action contract
Reusable replay and recovery fixtures
Accepted changes and unresolved findings

Why work this way?

The process, and what it could improve.

Proposed method · no measured savings claim

Cost

Keep repeat work out of the reasoning loop.

Characterize common messages once. Reuse approved fixtures and deterministic routing where they are sufficient; reserve model work for cases that need interpretation.

What to compare: Total model charges, retries and human review effort per accepted message, on the same replay set.
The tradeoff: Rules and fixtures take work to maintain. Fewer model calls are useful only if routing and recovery still pass.

Compare the same scope and acceptance criteria. Include setup, coordination, failed attempts and human review alongside the successful model call.

Design the work

One problem. A coordinated agent team.

Proposed task plan

A model reasons. A harness runs its agent session and tool loop. Orchard coordinates the work, context and handoffs across them.

Orchard orchestratorScopes work · delegates · synthesizes evidence

CONTROL

Implementation lead

Example session

Model familyClaudeHarnessClaude Code

Design Graph subscriptions, a durable queue, and an idempotent event processor.

Bounded task assigned

Counterproposal agent

Example session

Model familyGPTHarnessCodex CLI

Assume notifications can be lost. Propose a delta-query reconciliation path and try to break the queue design.

Opposing assumption assigned

Independent reviewer

Example session

Model familyGeminiHarnessGemini CLI

Inspect permission scope, replay behavior, and the send-approval boundary against agreed criteria.

Evidence criteria assigned

Shared project contract

Rules · skills · hooks · MCP configuration

Adapted to each harness

01 / 04 · Dispatch

Split the work. Preserve the question.

One objective, distinct responsibilities

Build an Outlook listener that survives duplicate events, subscription expiry, and ambiguous requests.

Synthetic mail and approved mailbox scope. Drafts require review before sending.

Implementation leadlistener-design.md + webhook implementation

Counterproposal agentdelivery-failure-matrix.md + replay fixtures

Independent reviewerreview-findings.md + contract-test results

Illustrative execution planAssignment Evidence Review

Model families and pairings are illustrative. Assignments here are manual examples, not measured model comparisons or automatic cost optimization.

Trellis / shared knowledge

Mailbox contract

Permitted fields, routing categories, retention and tenant consent.

Failure knowledge

Observed retry patterns, duplicate fixtures and reviewed recovery decisions.

BEAM / coordination

Bounded tasks, ownership notices, findings and handoffs between sessions. A queued message and a processed receipt are distinct states.

Recall → work → retain decisions

Tools / execution

Microsoft Graph sandboxQueue / event fixturesRepository + test runner

Access follows the configured harness, credentials and approved scope.

Inspect the example work orderJSON

An illustrative work-order format for this scenario. Changing an example session updates this document; no agents run from this page.

{
  "example": "outlook-listener",
  "objective": "Build an Outlook listener that survives duplicate events, subscription expiry, and ambiguous requests.",
  "boundary": "Synthetic mail and approved mailbox scope. Drafts require review before sending.",
  "sessions": [
    {
      "role": "proposer",
      "model_family": "Claude",
      "harness": "Claude Code",
      "task": "Design Graph subscriptions, a durable queue, and an idempotent event processor.",
      "expected_artifact": "listener-design.md + webhook implementation"
    },
    {
      "role": "challenger",
      "model_family": "GPT",
      "harness": "Codex CLI",
      "task": "Assume notifications can be lost. Propose a delta-query reconciliation path and try to break the queue design.",
      "expected_artifact": "delivery-failure-matrix.md + replay fixtures"
    },
    {
      "role": "reviewer",
      "model_family": "Gemini",
      "harness": "Gemini CLI",
      "task": "Inspect permission scope, replay behavior, and the send-approval boundary against agreed criteria.",
      "expected_artifact": "review-findings.md + contract-test results"
    }
  ],
  "project_contract": [
    "Rules",
    "Skills",
    "Hooks",
    "Tool configuration"
  ],
  "shared_context": [
    "Mailbox contract",
    "Failure knowledge"
  ],
  "evidence_required": [
    {
      "label": "One logical action per message",
      "evidence": "Replay duplicate and reordered notifications; inspect the action ledger."
    },
    {
      "label": "Recovery after a delivery gap",
      "evidence": "Expire the subscription and recover missing changes with a controlled fixture."
    },
    {
      "label": "No unintended sending",
      "evidence": "Show the approval check on every path that can send or change a downstream record."
    }
  ],
  "release_owner_gate": "Mailbox owner accepts the permission scope, recovery evidence, and sending policy before activation."
}

The process principle

Reduce repeated work without hiding the exceptions.

Scope of this exampleRequires Microsoft 365 consent and a deployed listener. Sending replies or changing external records stays behind an explicit approval step.

A proposed implementation workflow, not a connected mailbox or packaged listener. Microsoft Graph reference

Outlook listener

Different tools.
Shared project context.

Where the work changes.
How to judge the difference.