Selected work

Operational AI

Making AI Useful Without Making It Authoritative

I designed an email operations workflow that uses a language model to interpret and draft, while application code, authoritative services, and a human operator remain responsible for consequential decisions.

Role
System architect and application engineer
Scope
Mailbox intake, structured extraction, business rules, retrieval, customer memory, pricing, drafting, and reviewed delivery

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.

Language is not business truth

The language model extracts candidate facts from the latest relevant message: locations, quantities, dimensions, contact information, and service requirements. Those values are not accepted without context.

Application code checks required fields, separates blockers from declared assumptions, applies handling constraints, flags risky language, and decides whether enough information exists to request pricing.

The model interprets

Unstructured messages, candidate facts, conversation context, internal summaries, and proposed customer language.

The system decides

Validation, business rules, authoritative pricing invocation, persistence, permissions, and whether an external action is allowed.

The model never invents a price. Pricing enters its context only after the application has validated candidate inputs and called the existing pricing authority.

An orchestrated workflow

Authority path

Mailbox + model interpretationRules + authoritative servicesOperator review + send

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.

Context without overreach

A useful draft needs more than the latest email. The workflow combines three bounded sources of context.

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

The architecture reduces model authority, but it 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 all remain engineering concerns.

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.