A library is assembling next month's event calendar from applications submitted by its branches. Facilities staff check rooms and times, editors check the English and Chinese descriptions, and a librarian approves the final calendar. Start with six fictional applications. Include two requests for the same room and time, a mismatch between the minimum ages in two languages, and a withdrawn event. Write the expected decision for each application before trying any agent framework.
Compare runtimes on a shared fixture
Build a serial baseline that checks the room, checks the copy, reports discrepancies, and waits for approval. Use deterministic rules for overlapping reservations and a model only where editorial judgment helps. Record total duration, model calls, the resulting decisions, and the work a librarian must do after a failure. Hold the input, model, limits, and acceptance criteria constant when comparing alternatives.
A LangGraph prototype can represent room and copy review as separate nodes feeding a merge step. Test whether an operator can see the outcome of each node and resume after interrupting the process. A CrewAI prototype can assign the facilities reviewer and copy editor distinct roles and outputs. Check whether a malformed result is caught and whether each role receives only the inputs it needs. An AutoGen prototype can test conversational handoffs for teams evaluating an existing AutoGen workflow. Give the conversation a termination condition, a turn limit, and an output contract. Record the versions and official documentation used. Confirm which version your team can maintain before deciding to carry a prototype forward.
Treat restart after approval, validation of branch outputs, and prevention of duplicate writes as acceptance requirements. Compare runtime, learning effort, and troubleshooting time once a candidate meets them. If the largest delay comes from waiting on the room database, additional model roles may increase cost without improving turnaround. Keep the serial baseline in the comparison so the added coordination has a measurable purpose.
Define the handoffs before starting parallel work
Assign an event ID and application revision. The room reviewer returns the event ID, room, time range, conflict reference, and schedule revision. The editor returns the event ID, locale, field, proposed change, and reason. Give each reviewer a separate output location. The editorial task needs the proposed public copy and policy excerpt. It does not need the applicant's phone number or private notes.
Have the merge step match event ID and input revision. Keep the room finding and the editorial suggestion distinct so the librarian can act on both. If copy review fails, preserve the room result and mark the event as awaiting review. A copy edit invalidates the editorial result and the merge decision. A change to the date also invalidates the room check. Carry this dependency information in the run state so a restart cannot treat a stale result as current.
Dispatch tasks and reconcile partial results
Use one run identifier and track each branch as queued, running, complete, failed, or waiting for human input. Log the input revision, start and finish times, worker, output location, and failure category. Set time limits for the branch and the overall run. If a branch times out, retry it within the defined budget and retain the completed branch. Once retries are exhausted, show the missing evidence in the librarian's queue. The merge step should refuse to mark the event ready until both required checks pass.
Replay event L-013, proposed for Thursday at two in the lecture room. The room reviewer finds a children's reading event already booked. The editor notices that the Chinese description says ages ten and up and the English version says eight and up. The merged report should preserve both findings and their evidence. Move the event to Friday and revise the age wording, then interrupt the copy reviewer. Verify that the facilities result remains available and that the resumed copy result refers to the new application revision. Replay a late result from the previous revision and confirm that the merge rejects it.
Test the approval boundary with a simulated publisher
Save the event ID, revision, approver, and approval time. A simulated publisher returns a public record ID for each successful write. Change the schedule after approval and verify that the old approval cannot publish the revised event. Then simulate a successful write followed by a dropped response. Query by the run's external reference before allowing another attempt, and confirm that the publisher has only one record. Reviewers should be able to suggest edits without credentials that can publish the calendar.
When selecting a supporting skill, describe the evidence you need. An orchestration advisor can review a dependency sketch and flag which steps can run independently. The linked Webapp Testing skill can exercise the preview, check that both conflicts are visible, and verify how approval controls react to a stale revision. To verify persistence, interrupt a worker and inspect the stored run state separately. Use test accounts and a preview environment for destructive or state changing cases, and retain the fixture and version with the evidence.
Questions that come up in review
Why can two completed branches still fail to merge? Compare their event IDs and revisions. A correct review of an older application is still stale. Trace the input path and cache before changing the reviewer prompt.
When is parallel work faster? Measure the independent room and copy checks and the cost of starting workers, validating outputs, and merging them. For a short calendar, the serial baseline may be easier to operate. Parallel execution helps when the branches can proceed independently and the savings exceed coordination overhead.
How do we stop a conversation from cycling? Define the artifact that counts as completion, specify a maximum number of turns, and record the stopping reason. When a room cannot be confirmed, hand it to an operator instead of allowing agents to keep guessing.
What belongs in the selection report? Keep the fixture, expected and observed results, versions, unresolved cases, and the owner for maintenance. The next operator should be able to rerun the same failure and decide whether an upgrade changed the outcome.