An exhibition contractor wants to turn client requests into internal production tasks. Sales owns the client identifier, the project system owns the installation schedule, and the warehouse owns the current stock figures. For a first trial, pick one request and stop at a draft that an authorized project lead can review. Use the same request to compare connection methods, orchestration runtimes, and the checks that must pass before the system creates a task.
Inventory the actions that cross a system boundary
List the operations by what they do. Find a client by account number, find the schedule by project number, and check stock by item code and warehouse zone. Creating a task requires the project identifier, an assigned owner, and a decision on the draft. For each action, record which direction data travels, the required fields, the permission scope, the expected output, and how to tell whether it succeeded. A connector listing gives you a candidate to test. Count a capability only after you have tried the specific action with the permissions the pilot will use.
A daily sales export might be sufficient if the workflow can tolerate yesterday's data. Installation dates and stock may need a fresh query. Compare a direct API, a managed connector, and an MCP tool where those routes exist. A direct integration gives the team control over field mapping and error handling, and it puts maintenance of that integration on the team. A managed connector can reduce setup if it supports the precise action and acceptable permission scopes. For MCP, check whether the host can discover the tool, pass the right identity, and keep write access distinct from read access. Save the same sanitized request and response for each route so the comparison can be repeated.
Run the same failures through each framework
Build a baseline that uses explicit rules for matching project numbers, merging results, and checking approval. A model can extract candidate fields from an incoming note. If a client abbreviation maps to two companies, route the candidates to the project lead instead of asking the model to choose an account silently. Add model planning when the range of requests requires meaningful choices about the order of queries or which data to retrieve. Write down which choices remain under policy regardless of the runtime.
Give each candidate framework three identical cases. A normal request creates a draft. A rate limit pauses the inventory step, and the run should resume from its last valid result. A timeout after approval leaves the outcome of a create call uncertain, and the runtime should check for an existing task. Compare how each framework persists state, prevents unapproved writes, exposes timing and error details, and allows recovery after a process restart. Ask an engineer who did not build the prototype to reproduce one failure using the logs. The maintenance decision should include that effort as well as the amount of integration code.
Turn the workflow into checkpoints
Resolve the client and project first, and report any ambiguous fields. Read the schedule and inventory in parallel after those identifiers are confirmed. Each lookup returns a snapshot with a query time and the keys it actually used. Join the results against the project request and build a draft. Bind approval to a version of that draft. Before creating a task, recheck information that could have changed. If the scheduled date moved or stock fell below demand, show the difference and let the lead approve the revised plan.
Use a stable business request ID across the entire run. Pass that ID or a supported idempotency key on the write. After a timeout, query the target by its external reference before repeating the request. If you cannot determine whether the task was created, send the record to reconciliation with the last known result. Resume from the first incomplete checkpoint whose inputs are still valid. Preserve the draft and the versions of the inputs used to make it so a second run can explain any change.
Exercise a real approval path in a preview
Use a fictional exhibition client and project E-104. The installation starts Thursday and requires twelve bases. Let inventory report fifteen during drafting and nine while approval is pending. The workflow should detect the change before it writes, record both snapshots, and tell the lead what action is available. Next, return an inventory error and verify that the draft identifies the missing information. Finally, simulate a successful task creation followed by a dropped response. Restart the run and check that the target contains exactly one task.
Use the linked Webapp Testing skill when the preview is ready. Give it the approval page, a test account, and visible assertions about the stock difference, approval state, and repeated submission. Verify the actual number of stored tasks separately against the service fixture. For a project with two booths, give each work order a child identifier. Swap the two stock responses in a test and verify that the approval screen flags the mismatch before a write.
Keep the action inventory, field mapping, access scopes, sanitized fixtures, and test evidence together. Store access tokens in the mechanism supported by the host. Keep customer contact details out of troubleshooting logs when a request ID suffices. On the draft, let a reviewer trace extracted fields to the original brief and distinguish those fields from inventory numbers returned by the warehouse. Use separate credentials and data for preview and production, and enable only the tested actions in the pilot.
Common integration questions
How many connections should the first workflow support? Start with the operations needed to produce a usable draft. A read-only connection can contribute inventory even if it cannot create tasks. Add more actions when the workflow has a specific use for them and a fixture that can verify them.
Can we change frameworks later? Keep the business schema, operation contracts, and preview scenarios independent of the runtime. Reuse those artifacts to compare restart behavior, approval, and write recovery before switching.
What should happen when a connector update changes a field? Replay a known item lookup in preview. Compare permissions, payload structure, and field values. Update the mapping, then rerun the stock change and error scenarios. If you cannot reconcile writes already attempted, pause automatic creation until the project lead reviews the pending records.