A community museum is preparing bilingual labels for three acquisitions. The collection records contain verified facts and provisional dates. A first CrewAI trial can give fact checking, writing, and review to separate roles while a curator decides which revisions can go public. Use fictional records for the trial and a simulated publisher that returns a record ID. The expected result is two approved labels and one item held for investigation.
Define what each role delivers
The fact checker extracts the accession number, materials, possible date range, and supporting record IDs. If two records disagree, the checker captures both claims and flags the issue. The writer receives the checked facts, an exhibition glossary, and a length limit. The writer returns Chinese and English drafts and identifies the fact supporting each claim about age or material. The reviewer takes the drafts and evidence and returns findings tied to specific fields.
In the CrewAI prototype, give each agent a role, goal, and backstory that clarify its responsibilities. The fact checker is accountable for traceable claims and preserving uncertainty. The writer makes the object's purpose understandable to visitors. The reviewer looks for unsupported statements, inconsistent translations, and text that exceeds the display budget. Put the input, expected output, and completion criteria in each task. Give the writer only the fields approved for editorial use. A draft writer has no need for a publishing credential or donor contact details.
Start with one object before processing a batch
Run the roles in sequence for a fictional wooden box, M-017. The accession record suggests two possible periods, a conservation report identifies the wood, and the exhibition glossary defines the term used for its finish. The checker preserves both date ranges and their supporting identifiers. The writer produces one label in each language without implying an exact year. The reviewer flags any wording that turns an estimate into a definite claim. The curator decides whether to approve a broader description or hold the label until the records are reconciled.
After that run, add two objects with complete records. Keep checking, writing, and review sequential within an object. Process different objects in parallel when they have independent inputs and outputs. Give each run its own artifact locations and have the collector combine results by accession number. Pin the glossary version before work starts. If a reviewer discovers a missing term, route the suggestion to the curator, update the glossary after approval, and identify which drafts need to be checked again.
Recover from an interruption without reusing stale evidence
Use a Crew for the role tasks and a Flow to coordinate the surrounding steps. Verify what persistence and restart actually do in the chosen version. Keep a business run record that includes the object ID, source revision, glossary version, task status, artifact location, and failure reason. A process can use that record to distinguish a missing review from a completed review that belongs to an earlier draft.
Stop the process after the writer completes M-017 and before review. Start a new process and verify that it finds the current draft and resumes at review. Then repeat the exercise after correcting the accession date. That change invalidates the facts and drafts. A change to the English length limit can retain the fact sheet but requires writing and reviewing the revised copy. Check the object and revision on every recovered artifact before using it.
Set a retry limit for recoverable failures such as a model rate limit. Preserve the last successful result and the reason for the failure. If the retry budget is exhausted, move that object to a human queue and continue with the other objects. The batch report should identify the missing step and responsible reviewer. A finished run can include a held object, but it should show the hold explicitly.
Connect peer review to curator approval
Review facts and readability separately. The factual review checks dates, materials, and whether each claim is supported. The editorial review checks whether both languages communicate the same uncertainty. The display review checks line breaks and whether important text is clipped. Record the field, observed value, expected value, evidence, and priority for each finding. When reviewers disagree, preserve their reasoning and ask the curator to decide against the collection record.
Use the linked Webapp Testing skill if labels and approval controls are available in a preview. Give it a test account and assertions for switching languages, viewing evidence markers, and checking the review state. Exercise a long label at the supported viewport sizes. The curator verifies the facts against the collection records separately.
Bind approval to the accession number, label revision, and approving curator. An edit after approval requires review of the new revision. Give the simulated publisher a stable request identifier and verify that a repeat request returns the same record. Simulate a successful write whose response is lost. After restart, query by the request identifier before allowing a retry. Keep the fact sheet, bilingual draft, findings, decision, and publishing record for each object.
Questions to resolve during the trial
Do the roles need separate processes? A single process can run them sequentially while still enforcing input and tool boundaries. Parallelize where objects are independent and the team can verify artifacts separately.
Can two reviewer approvals replace the curator? Reviewer findings inform the decision. The curator confirms the specific revision and its permitted public fields before release. Mark restricted fields in the source data so the draft and preview can be checked for accidental exposure.
Why rerun a task when its old output exists? The file proves a previous run produced something. Its source and rule revisions establish whether it still applies. Invalidate only the affected work and its dependents, then verify the remainder of the batch still matches its recorded inputs.
What should the team keep from the first run? Save the input snapshots, task definitions, expected and observed results, and the injected failure cases. Ask someone who did not build the workflow to identify the held object from the report and explain why its label is absent from the publishing queue.