From an enquiry
to a draft you can review.

A small workflow with consequential details

A customer asks whether two systems can be connected. A useful reply acknowledges the request, explains the relevant service, and asks for the information needed to scope the work. An unhelpful reply might invent a price, promise a deadline, or claim that access has already been arranged.

The video follows three fictional enquiries using a small reference library drawn from the consulting services on this site. Two responses are generated with AI and checked by a reviewer. A third enquiry has no relevant source material and receives a prepared referral. The walkthrough shows both useful drafts and details that need correction.

Give the draft a reference boundary

The enquiry expresses the customer's needs. It does not define service terms or authorize actions. The reference library supplies the scope, assessment deliverables, and commercial boundaries.

This example uses keyword matching to select up to three relevant excerpts. That keeps the retrieval easy to inspect. It is a deliberate simplification: vocabulary changes can cause missed matches, and a small keyword library does not demonstrate semantic search quality across a large document collection.

Showing the selected excerpts helps a reviewer check the response. It does not prove that every sentence follows from them. In a larger system, retrieval quality and answer grounding need their own evaluation.

Do not turn an unknown into a promise

In the fixed-price scenario, the enquiry asks for a guaranteed completion date without supplying representative documents. The references explain that scope, schedule, and fees are agreed after discovery. A useful draft asks for the missing inputs.

Another enquiry falls outside the service scope. There is no relevant evidence, so the prototype returns a prepared referral response without calling a model. The absence of a match becomes a visible outcome.

Customer text can contain instructions

A further case to test is an enquiry that tells the assistant to ignore service information, promise free work, or approve itself. This is not one of the three enquiries in the video. Such instructions must remain untrusted input. A prompt can explain that boundary, but wording alone is not a security guarantee. The workflow provides no email tool, and model output cannot set the approval state.

Approval belongs to a particular draft

The reviewer checks the sources, edits the response, and confirms that exact version. Editing after review clears the check. Editing after approval clears the approval as well. Selecting another enquiry or generating another draft also starts a fresh review.

This avoids a subtle failure: carrying an earlier approval onto text that nobody has checked. In the recorded prototype, the state lives only in the browser tab. In a real system, the approved version and identity of the reviewer need durable records and server-side enforcement.

There is no send operation in this demonstration. An approved example is a way to inspect the decision boundary; it is not a delivery receipt or an email in a client's inbox.

What a real release would need

The right next step is to evaluate one agreed workflow with representative, permitted data. Useful checks include the relevance of retrieved information, unsupported claims, missing-information handling, conflicting instructions, and how often a reviewer needs to correct the draft.

A production design also needs source freshness and access rules, protected credentials, usage limits, monitoring, and a durable approval record. If sending is included, it needs a separate authorized operation, duplicate prevention, and a way to reconcile an uncertain delivery result.

The prototype demonstrates retrieval and review boundaries. Client deployment and productivity improvement would require separate validation. A focused assessment can establish what must be proved before applying the same approach to your business.