Can AI remember what I promised in an email?

Promises are often written casually and remembered formally by the recipient. “I will send the revised schedule on Friday” may occupy one line in a long thread, yet missing it can damage a client relationship. A conventional task manager helps only if the sender stops and creates a task. An AI commitment tracker can notice the obligation in Sent, retain who it was made to and bring it back before the deadline. That requires more precision than extracting verbs. The system must establish speaker, certainty, condition, deliverable and timing, then follow later messages that amend or cancel the promise. This page sets out the correct workflow, common attribution traps, evidence model and current product boundary. It concerns promises the user made, not every request another person sent them.

How can AI identify a promise made in email?

The assistant must identify a definite obligation owned by the user, including its recipient, outcome, timing and conditions. “I will send the valuation by Friday” is a promise; “we may send something soon” is not yet one.

Language alone is insufficient without sender and quotation context. A sent message may quote a client's promise, forward another person's plan or say that a colleague will deliver the work. The system must know which mailbox identity belongs to the user and separate new prose from quoted thread history. It should also distinguish an offer—“I can send this if useful”—from a commitment accepted later.

The stored task should be concrete: “Send Naledi the revised valuation,” due 28 August 2026, from the exact source message. If the email says “after the committee approves,” the condition belongs in the record. Removing it creates a false unconditional deadline.

What does the complete commitment workflow look like?

A promise becomes useful when it creates one current, source-linked obligation that changes as the conversation changes. A one-off extraction is only the first step.

For the message “I will send Costas the final venue pack by Friday,” the correct flow is:

1. Read the outbound message and establish that the user's own words contain a firm commitment.
2. Extract the deliverable, recipient, explicit deadline and any condition.
3. Create one task with a stable link to the sent message.
4. Surface it at an appropriate time before breach, not immediately as a noisy alert.
5. Watch later thread events for completion, changed timing or cancellation.
6. Allow the user to complete, edit, defer or reject the interpretation.

This is deeper than chat history. A business-aware assistant remembering clients and promises keeps the operational obligation separate from the full email while preserving their connection.

Which wording creates dangerous false positives?

Conditional, tentative, quoted, delegated and historical statements must not be flattened into firm tasks. The safest extractor is deliberately conservative about ownership and certainty.

Dates create another trap. “Tomorrow” depends on sent time and timezone. “Before our meeting” depends on the correct calendar event. “Next Friday” may be culturally ambiguous. A reliable record keeps the exact phrase beside any calculated date. If the calculation materially affects client delivery, asking one precise question is better than silently choosing.

How should later email update a promise?

The latest clear evidence should control the current task, while prior versions remain attributable. Commitments are living state, not immutable sentence extractions.

If the recipient replies, “Tuesday is fine instead,” and the user agrees, the deadline moves. If the user later sends the promised attachment, the system can propose completion only after confirming that the document and recipient match the obligation. If the work is completed by phone or in another system, the user needs a quick manual completion route.

Duplicate control matters because the same promise may appear in quoted text across ten replies. Thread identity, source message and semantic matching should converge on one obligation. Corrections must be transparent: current due Tuesday, originally promised Friday, changed by the later message. That provenance helps a professional answer “What did I originally commit to?” without corrupting today's to-do list. It also provides the context needed for a calm draft if the deadline is at risk and complements tracking who still owes a reply.

What is the current Hank product boundary?

The product can create tasks and already extracts the user's commitments from trusted meeting notes, but automatic outbound-email promise capture is not complete. This page is a specification-quality draft, not a claim that the sent-mail ledger works today.

The current meeting-notes path uses a configured source and instructs the model to extract only what the user personally said they would do. Each accepted commitment becomes its own source-identified task. That proves part of the model: owned obligations can materialise as separate list items without collapsing a meeting into one vague to-do.

Email requires additional work: dependable Sent and All-Mail access, quoted-text separation, message identity, thread-state updates, deadline calculation and completion inference. The proof packet must test direct, conditional, delegated, quoted, cancelled, completed and changed-date statements. It should also repeat ingestion to demonstrate deduplication. Until that implementation and evidence exist, proof.status remains needed and the route remains draft-only.

Who it is not for

Commitment capture is not a substitute for project management, contractual milestone control or team accountability systems. It protects personal promises made through communication; it does not establish every obligation of an organisation.

Teams with complex dependencies, assignees, approvals and shared schedules should write confirmed work into their project system. Legal or regulated commitments may require formal records beyond an email-derived task. The workflow is also unsuitable when the mailbox is shared and sender identity cannot be attributed reliably. A conservative assistant should skip uncertain ownership rather than fill the list. Its strongest fit is a client-facing professional whose reputation depends on a manageable number of promises made personally across email and meetings.

The same pattern appears in AI assistance for independent consultants, where scope changes, promised deliverables and invoice follow-ups need different treatment even when all three arrive through email.

Conclusion: can AI keep track of email promises?

Yes, if it treats each promise as an attributable, changing obligation rather than a phrase to highlight. The correct record states what the user agreed to do, for whom, by when, under which condition and from which sent message. It then follows later evidence, preserves revisions and surfaces the task before breach. The most important quality measure is precision: one missed commitment is harmful, but dozens of false commitments make the entire list unusable. The current product demonstrates the pattern for trusted meeting notes but does not yet complete sent-email capture. Publication must wait for the outbound workflow and its evidence. Once tested, the page should prove one real promise from sent sentence to completed, source-linked task.