Can AI track who has not replied to my emails?

The most damaging inbox failures often sit in Sent, not Inbox. A professional asks for a signed document, venue confirmation or client decision, then moves on. The sent message stops being visible while the business dependency remains open. A reminder created manually can help, but it depends on remembering at send time and does not know when a reply arrives. Useful AI turns expected responses into a small open-loops ledger: who owes what, from which message, by when, and whether the thread has moved. This page explains the evidence required to create an expectation, the difference between a response and an outcome, the timing rules that prevent noisy chases and the current product boundary. It tracks replies, not covert opens or assumptions about another person's intent.

How can AI identify an email that expects a response?

The assistant must find a real dependency in the sent message, not treat every unanswered email as unfinished business. Questions, requests and promised decisions are strong signals; greetings, confirmations and FYI notes are not.

“Please confirm the venue by Thursday” contains an owner, expected outcome and deadline. “Attached for your records” normally does not. AI can interpret that difference, while thread metadata establishes who received the message and when. It should also recognise when the user is copied rather than responsible, when several recipients can answer and when the message closes rather than opens a loop.

The resulting record might read: “Waiting on Costas for venue confirmation, requested 24 August, expected by 27 August, source: Re: September client event.” That is more useful than a generic “follow up with Costas” task because the evidence and expected outcome remain visible. The expectation should have its own stable identity so repeated scans do not create duplicates.

What does end-to-end reply tracking require?

Reliable tracking reads both sent and received mail, maintains thread state and updates the open loop when new evidence arrives. Scanning one inbox snapshot cannot answer who still owes a response.

The workflow is:

1. Read a sent message and decide whether a reply or result is expected.
2. Record the recipient, thread, request, source time and explicit or policy-derived deadline.
3. Watch later messages in the same conversation and from relevant participants.
4. Classify each event as no response, acknowledgement, substantive answer, changed expectation or completed outcome.
5. Surface only loops that remain material after the correct interval.
6. Offer a source-grounded follow-up draft or let the user snooze, dismiss or edit the expectation.

This is the proactive side of an assistant that reads email and takes action. A one-time search can find old sent messages; an assistant maintains their business state as the conversation changes.

How should replies and partial replies change the record?

A reply closes the communication wait only when it answers the dependency; otherwise it creates a revised open loop. Thread activity is evidence, but not always resolution.

This distinction prevents both false chases and disappearing commitments. The user must be able to correct the interpretation in one action. That correction should influence the current loop without erasing the original request and later reply.

When should an unanswered email be surfaced?

The best follow-up time comes from an explicit deadline first, a stated user rule second and a visible default last. “No reply after 24 hours” is not universally intelligent.

A client application document may need a same-day chase. A proposal may reasonably sit for a week. Weekends, holidays, time zones and out-of-office messages affect the interval. Recipient relationship matters too: a direct report, external client and regulator should not all receive the same automatic cadence.

The product should state its rule: “Due yesterday,” “waiting three business days,” or “deferred until the recipient returns on 2 September.” It should never manufacture urgency to make the feature look active. The user also needs dismiss, snooze and “no reply expected” controls. Without those, false positives accumulate until the ledger is ignored. A morning view of what needs attention should include only material overdue loops, not a graveyard of every sent message.

What is the current Hank product boundary?

The current product can search email, retrieve threads and prepare replies, but it does not yet maintain the promised sent-mail open-loops ledger. The feature is explicitly on the roadmap and this article must remain unpublished until it has been built and tested.

The existing foundation includes mailbox ingestion, message search, threading identifiers, drafts and living lists. The missing work is decisive: dependable Sent and All-Mail coverage, expectation extraction from outbound messages, state updates from replies, business-day timing, out-of-office treatment and a durable dismissal model. It would be misleading to present those foundations as the completed workflow.

The proof test should seed at least twelve cases: direct request, FYI note, copied user, multiple recipients, late reply, partial answer, out-of-office, reply in a new thread, phone resolution, changed deadline, duplicate scan and no-response dismissal. The reviewer must show the original message, open-loop record, state transition and follow-up draft for each relevant case. Only then can proof move beyond needed.

Who it is not for

Reply tracking is not suitable for covert surveillance, guaranteed read detection or automatic pressure campaigns. Email cannot reliably reveal whether a person read, understood or deliberately ignored a message.

Sales teams needing sequenced mass outreach may be better served by a dedicated engagement platform with consent, deliverability and campaign controls. Support teams should use ticket states and service-level rules rather than infer obligations from ordinary threads. The workflow is also a poor fit when most outcomes happen in calls, messaging apps or portals unless those events can update the same record. Its strongest use is personal operational follow-through: a small number of meaningful requests where forgetting the response would cost trust, time or revenue.

Conclusion: can AI track unanswered sent emails?

Yes, but only by tracking explicit expectations and observable thread outcomes—not by counting unread-looking messages or claiming to know another person's behaviour. The correct system reads Sent and received mail, creates one source-linked open loop, recognises meaningful and partial replies, applies transparent timing and lets the user correct state quickly. It can then prepare a calm follow-up in the original context. The hard part is not drafting the chase; it is preventing false expectations, false completion and false certainty. For this product, that full ledger is still roadmap work. The draft exists now so the workflow and proof bar are ready, but it must not publish until the twelve-case test demonstrates that open loops remain accurate as real conversations change.