Separate automatic work from autonomous choices
A local museum compiles weekly activity registrations and answers open-ended visitor questions. The report follows defined fields and aggregation rules. A visitor question may first require an exhibition page, then an accessibility note chosen in response to what is missing. Both can execute automatically, but they do not need the same degree of autonomy. This example designs the two paths without connecting a real reservation system or running an unattended service.
The source covers task-path analysis, workflow orchestration and agent upgrades. Whether the path changes is useful, but not sufficient by itself. Failure consequences, tools, evidence quality, observability, cost and maintenance also matter. A workflow can contain branches and model calls; an agent still needs boundaries. Skills package reusable methods rather than constituting a competing execution system that replaces both.
Scenario one: map known paths and unresolved choices
Split the weekly report into reading an authorized export, validating fields, aggregating by activity, listing exceptions, obtaining acceptance and saving. A missing date enters an exception queue; an unknown amount is not zero. These are predetermined branches. Even if a model polishes the prose, the main path can stay fixed rather than asking it to choose tools afresh every time.
For visitor support, distinguish classification, relevant-source retrieval, a decision about further evidence, and an answer or staff handoff. A family-event question and a wheelchair-route question need different material. Consider a bounded agent when meaningful next steps cannot usefully be enumerated in advance. Length, scheduling and natural-language output do not independently make a task agentic.
Create a decision table with path predictability, accessible evidence, necessary tools, failure impact, latency, budget and owner. Choose the simplest sufficient approach: deterministic script, workflow with model steps, or dynamic retrieval inside a fixed outer process. Missing evidence and out-of-scope questions go to staff. Greater autonomy cannot compensate for absent facts.
Compare designs on the same samples. For reporting, check fields, totals and traceable exceptions. For support, check whether sources justify the answer and whether it stops when necessary. Do not compare only human-like tone or a single call's speed. Record acceptable end-to-end outcomes, human correction and cost, leaving untested long-term stability unknown.
Scenario two: connect state as well as modules
A graphical node and a natural-language method both need input-output contracts. Retrieval returns material, source dates and gaps; drafting uses that evidence; review checks statements and boundaries. Associate artifacts through task_id and input revision. Distinguish ready, running, awaiting staff, successful and failed states. A completion message does not establish that a report was saved.
Keep deterministic validation and approval gates in the fixed reporting path. Dynamic support receives only approved read-only tools, not permission to alter reservations or send notices because the question becomes complicated. External text is evidence, not authority: an instruction on a retrieved page to ignore policy cannot change tool access. Log necessary evidence while excluding irrelevant visitor identifiers and credentials.
Define timeout, retry and recovery behavior. Reading a source can have bounded retries. A save timeout requires inspecting whether the report already exists before creating another. Resume from actual durable state rather than describing process memory as a restart guarantee. Parallel modules need a clear join condition so one successful artifact cannot conceal another required failure.
Skills may supply retrieval, writing or review methods inside modules. They do not create connections, credentials or schedulers automatically. When extracting methods from an existing workflow, identify reusable logic and operational facilities remaining in the original system. Start migration with read-only or draft comparisons and keep a return path. Do not let both pipelines send real notices during a trial.
Scenario three: upgrade only the uncertain portion
Bound the support agent's tools, retrieval rounds, total time and spend. At the limit it returns verified information and unresolved questions. A rehearsal might allow three retrieval rounds to test stopping; that is a local fixture policy, not a universal recommendation. Repeatedly querying the same tool without new evidence should trigger a stop rather than an endless loop.
Proactive operation needs an explicit trigger and notification policy. “Generate a proposed change summary when the source revision changes” is a bounded design. “Be proactive” does not establish unlimited monitoring or authority to contact people. Without a real event source and scheduling configuration, no continuous service exists. Unattended work especially needs boundaries, failure signals, a pause mechanism and an owner. Never stopping is not a useful success criterion.
Run isolated shadow samples first, then a limited pilot with human review. Inject unavailable evidence, contradictory pages, tool refusal, interruption and budget exhaustion. Check the resulting state. If dynamic execution costs more without improving accepted outcomes, return to a fixed path or reduce the agent's scope. An upgrade fits the task; it is not a competition to maximize autonomy.
A concrete visitor-question trial
Ask: “Can I use the east entrance with a stroller for Sunday's family exhibition?” Retrieve the approved activity page first. If it gives only opening times, do not infer entrance access. Consult the current accessibility material next. Conflicting dates or entrance rules remain unresolved and go to staff. Separate known timing, supported access information and unknown restrictions rather than making a personal guarantee.
Include variants with no entrance evidence, a retrieval timeout and an outdated page. Preserve actual calls, citations, stop reason and staff intervention, not just the final answer. Before execution, label these as expected behavior. After a real trial, report observations. This tutorial claims no passed test for the fictional museum.
Verify a Skill rather than trusting its name
The source's six cards include repeated tools, not six independent capabilities. This guide has not established matching SkillPI source and runtime evidence for those names and adds no guessed links. Search separately for path analysis, stateful orchestration or bounded retrieval. Inspect pinned SKILL.md, license, host tools, dependencies and data destinations, then associate a candidate with its exact step.
A discovery helper can find candidates without deciding the architecture or certifying the target. “Autonomous operation” in a listing does not demonstrate persistence, budgets or recovery. Installation also depends on host version rather than one universal folder. Keep package price separate from model, tool, infrastructure and maintenance charges. Do not promise that a package is necessarily free to run or saves tokens.
The LangChain documentation repository on GitHub offers inspectable workflow and agent patterns for comparing predetermined paths with dynamic tool choices. Its custom-workflow description also supports mixing different node types. This example preserves fixed rules and uses a hybrid design rather than installing a framework or connecting a tracing service. A concrete implementation still needs version, dependency and operating review.
Troubleshooting and frequently asked questions
Must a repeatedly failing workflow become an agent? First check fields, credentials, failure handling and rules. Dynamic choice does not repair bad input. Why does an agent keep retrieving? Inspect stopping criteria, whether new evidence is obtained and what tools return. Why does recovery save duplicates? Check task identity, idempotency and actual persistent state rather than only editing the prompt.
Can the system return to a workflow? A hybrid and fallback route can be designed, while connection and state compatibility require validation; installing a proactive package does not switch everything automatically. Can a nontechnical owner choose? They can describe paths and acceptance, with relevant expertise reviewing permissions, recovery and concurrency. What makes a design better? Compare the same tasks and standards for results, cost and operational burden, and state untested scope.
Sources
The English source supplies path analysis, orchestration and upgrade scenarios. This independent museum example does not present the source's twenty-project claim or card counts as research conducted here. Workflows and agents and the custom-workflow description are the inspectable GitHub technical references.