More than generating a reply
An operational email rarely needs only well-written text. An operator may need to reconstruct the conversation, extract locations and shipment details, identify missing information, apply handling rules, request a price, recall previous customer context, and prepare a response that does not expose internal reasoning.
The information arrives as unstructured language, but several decisions inside the workflow are operational or financial. That made a fully generative approach the wrong fit.
The model could help understand the message. It could not become the source of pricing, policy, or final accountability.
Implementation and orchestration
I built the workflow using the Anthropic SDK for language-model integration and Microsoft Graph for Outlook email integration. Application code connects those services with customer context, knowledge retrieval, and the existing pricing service.
Authority path
Application code controls the sequence: intake, classification, thread reconstruction, extraction, validation, retrieval, pricing, context assembly, drafting, and delivery. The model does not independently discover or invoke arbitrary tools.
That constraint keeps integration behavior inspectable. Required-field rules remain deterministic, pricing does not depend on model-selected actions, and only the context assembled for the current task enters the drafting step.
Prompt design for distinct tasks
The workflow separates classification, structured extraction, and response drafting. Extraction produces candidate shipment facts for application code to validate; drafting uses the assembled conversation, customer context, and validated pricing to prepare an editable response. Each step has a defined purpose and a limited role in the overall workflow.
Grounding and context management
A useful draft needs more than the latest email. The workflow grounds generation in three sources of context, using retrieval-augmented generation (RAG) to bring relevant historical correspondence into the drafting step.
Conversation history
The thread is reconstructed chronologically so the draft can see what has already been asked, provided, or changed.
Customer memory
Explicitly stated locations, contact information, common requirements, and service preferences can be reused. Profile updates are extracted separately and merged without allowing an empty model output to erase known values.
Similar correspondence
Vector retrieval surfaces a small set of related historical conversations and their human-written responses. That helps with tone and handling patterns, but historical prices never become current financial authority.
Human control at the boundary
The model creates two separate artifacts: internal operator notes and a proposed customer response. The notes contain extracted facts, warnings, missing information, and relevant context. The proposed response remains concise and editable.
Generating a draft does not send it. Delivery is a separate operator-controlled action.
When a response is sent, the system retains the original draft, the final approved version, whether it was edited, and its relationship to the originating message. The difference between draft and final language becomes evidence for improving prompts, retrieval, rules, or memory.
Useful does not require autonomous
Reducing model authority does not remove the need to secure and operate the surrounding system. Sensitive correspondence, retrieval quality, prompt-injection surfaces, timeouts, retries, provider failures, and access control still matter.
The most useful design was not the most autonomous one. Probabilistic interpretation sits at the edge, deterministic services remain at the core, and human judgment controls the final external action.