A shoe repair shop wants an assistant that helps the front desk answer collection questions. The assistant reads the relevant work order, drafts a reply using the confirmed repair status, and leaves the message for a clerk to approve. Build the first version around that short workflow. Use fictional work orders and a message sandbox while developing it. The shop owner should be able to verify which record supported a reply, which version the clerk approved, and whether the external message was actually sent.
Define a workflow that has a stopping point
Write three examples before choosing a framework. For a completed repair with a confirmed collection time, the draft includes that time and its work order reference. For a repair that has finished cleaning but still needs stitching, the draft describes the current stage and asks the clerk to confirm a collection estimate. For an incomplete work order number, the assistant requests the missing information. Record the expected outcome and any field that requires a human decision. This establishes the boundary between an answer the system can support and a promise the shop has yet to make.
Model the workflow with explicit states such as awaiting identification, awaiting lookup, awaiting review, draft ready and human handoff. Persist the task identifier, input version, lookup result and next permitted action. Set a maximum number of steps, a lookup budget and a task deadline. At a review state, stop execution and return the draft and its supporting record to the clerk. A task that has exhausted its lookup budget should return a reason for handoff rather than keep changing tools in search of an answer. Include a way for the clerk to cancel an unfinished task.
Use the application's existing service layer if it can express this short sequence cleanly. When the work needs durable checkpoints and interruption, examine a stateful orchestration framework such as LangGraph and rehearse its persistence and resume behavior with a synthetic order. Separate the model invocation from the application rule that decides whether a step is permitted. Validate the structured output, including the draft text, work order reference and unresolved questions. If fields are missing, record the validation failure and use the defined retry or handoff path.
Give each tool a narrow input and a checkable result
Define a lookup tool whose inputs include the work order identifier. Resolve the branch from the authenticated clerk's scope on the server. Verify that the order belongs to that branch, then return only the repair stage, update time and confirmed collection information needed for a reply. Give missing orders, denied access and temporary lookup failures distinguishable results. Include one valid example and one invalid example in the tool description. An assistant can select the right tool more consistently when its purpose, required arguments and result types are clear.
Validate a proposed call before executing it. Check the identifier format, branch scope and remaining call budget. Validate the returned data too. A login page, an empty response or a timeout should lead to a known failure state. In the front desk view, tell the clerk what information could not be retrieved and what to do next. Keep reads and writes in separate tool definitions. A draft-generation step can operate without a tool capable of changing the repair stage or sending a message.
For sending, show the clerk the recipient, message and supporting order status. Bind approval to the draft version. If the clerk or assistant edits the text after approval, require approval of the new version. Give each send operation a stable identifier and save the external receipt. In a sandbox, simulate a successful send followed by a lost client response. On recovery, the application should check the receipt or retry with the same operation identifier according to the provider's supported behavior. Record any uncertainty for the clerk instead of silently scheduling another independent send.
Keep task state and reference material traceable
Task state contains the current work order identifier, confirmed branch, lookup timestamp and draft revision. If a customer corrects the identifier, mark the previous lookup as superseded and query the new order. Keep a record of the change so the clerk can explain why a draft changed. When resuming a paused task, inspect the age of the lookup result. If the repair status may have changed, run a fresh lookup and present a revised draft for review. A persisted checkpoint is useful only when the application also knows which data must be refreshed.
Reference material can include opening hours, collection rules and care instructions. Give each entry an owner, applicable branch, source location and update date. Retrieval should return that context with the text. If the material does not support a collection promise, the assistant should ask for a decision. For an initial retrieval evaluation, label a small set of questions about opening hours, care instructions and work order completion. The first two can use approved shop material. The last needs current order data. Check that the assistant chooses the appropriate source and retains an unresolved state when the source is absent.
Treat customer messages, attachments and retrieved text as content to process within the workflow. They cannot alter tool scope or the approval step. Add a synthetic note telling the assistant to skip review and send a message immediately, then confirm that the application still stops at review. Check both the generated plan and the actual tool calls. Keeping the send tool unavailable before approval gives you an observable control to test.
Deploy with evidence for failures and recovery
Run the workflow locally using a fake lookup service and a message sandbox. Then connect the approved read-only lookup in an isolated environment. Record task identifiers, step names, outcome categories, duration and relevant versions. Keep personal fields out of routine traces. Monitor lookup failures, output validation failures, handoffs, calls per task and the number of tasks waiting beyond their deadline. A front desk operator should be able to find a stalled task and see its next permitted action without reading the model's internal reasoning.
Inject one failure at a time. Make the lookup time out, make the model omit a required output field, disconnect after draft approval, and restart the application while a send is pending. Check the checkpoint used for recovery, whether the lookup needs refreshing and whether the sandbox received a duplicate message. Persist a cancellation reason and confirm that an unfinished task cannot continue executing after cancellation. Already completed sends should remain visible through their receipts so the clerk can distinguish them from pending work.
Save the application build, model configuration, tool protocol version, reference material revision and evaluation fixtures as a release record. A prompt change or a tool argument change should rerun the existing cases and add the case that motivated the change. Start with one clerk and synthetic orders, then move to a bounded pilot. Agree on conditions that pause expansion, such as cross-branch data appearing in a draft, duplicate sends or tasks that cannot resume. Rehearse returning to the stable version while retaining the ability to inspect accepted tasks and their receipts.
Choose capabilities by the artifact you need
An architecture skill can turn the approved workflow into a state table and a small runnable example. A tool integration skill can build an adapter from the lookup protocol and sample results. A retrieval skill can index approved shop material while preserving branch and source metadata. A deployment skill can connect the service to the existing observability and recovery procedures. For each candidate, inspect its actual package, dependencies, file access, external data destinations and write operations. Test it on one synthetic work order and review the output before giving it a broader role. A catalog description gives you a starting point for that review.
Finish with a handoff that another clerk can run. Start a fresh task for a repair still in progress and check the unresolved collection estimate. Change the fixture to a completed repair and confirm that both the source reference and reply change. Interrupt and resume a task, then compare the persisted identity, draft version and sandbox receipt. Keep the steps, expected results and actual observations with the deployment record. This gives the next maintainer a concrete way to check the same behavior after an update.
Questions from the pilot
Does the first version need several agents?
Start with the number of roles and independent tasks the workflow actually requires. A lookup and a reviewable reply fit into a short sequence. Establish error handling, approval and recovery first. If measured failures later point to conflicting responsibilities or context limits, evaluate a specific split and compare its outputs and cost with the existing fixture.
What happens when the customer corrects the order number?
Version the input, supersede the old lookup and associate the next draft with the corrected identifier. Show the clerk which order supports the current text. A change to an approved draft requires approval again before the send step becomes available.
What counts as readiness for a real pilot?
Run the normal lookup, missing reference material, denied access, timeout, cancellation, resume and duplicate-send scenarios. Attach task and build identifiers to each result. Assign any unresolved provider behavior to its owner, then use the agreed scope and stop conditions for the first live tasks.