Start with the work
An agent is valuable when bounded path selection is part of the requirement.
Begin with what must vary. If a person needs one generated response from supplied material, conversation may be sufficient. If one validated event should always follow the same rules, ordinary workflow automation is clearer. If differently worded requests and changing evidence require the system to choose among several deliberately configured lookups or steps, a bounded agent becomes a reasonable candidate. The point is not to avoid agent capability; it is to use that capability where adaptation creates value.
-
Does one supplied request need one generated and reviewed response?
If yes: Use conversation and stop here
Generate or explain once; the person checks the result and decides whether to use it.
If no: continue to gate 02 →
-
Should the same validated event always follow the same rule-based path?
If yes: Use deterministic workflow and stop here
Keep triggers, validation, branches, actions, and receipts explicit and repeatable.
If no: continue to gate 03 →
-
Must current evidence select among different permitted sources, tools, or next steps?
If yes: Consider a bounded agent
Define its goal, available choices, stop conditions, evaluation, monitoring, and fallback.
If no: keep the simpler sufficient shape
-
Could any path change consequential manufacturing or business state?
Always: Define the human authority gate
Technical permission never substitutes for Quality, schedule, acceptance, price, or customer authority.
Apply this gate before technology selection
Text equivalent: First choose conversation when one supplied request needs one reviewed response. Otherwise choose a deterministic workflow when one validated event should always follow the same fixed path. Consider a bounded agent only when current evidence must select among different permitted sources, tools, or next steps. Before any shape may change consequential manufacturing or business state, define the authorized human decision gate.
Compare real operating shapes
The same work order can produce three different—and useful—designs.
Return to the entirely fictional Elm River Precision scenario. Final machining for WO-1842 is complete, H-291 remains an active Quality hold, Friday is a planning date rather than a customer commitment, and the assistant has no hold-release, schedule-write, or customer-email authority. The design changes with the job being asked of the system.
| Manufacturing need | Smallest suitable shape | What the system contributes | Why this shape fits | What the authorized person retains |
|---|---|---|---|---|
| Explain one supplied hold record for an internal discussion. | Conversation | One generated explanation or status draft from the material supplied in the request. | No system path must persist or change after the response; a person can check the source and revise the wording. | Interpretation, any record change, hold disposition, schedule decision, and external communication. |
| When QMS marks H-291 active, create one internal Quality-review notification. | Deterministic workflow | Validate work-order ID, hold ID, owner, and duplicate key; create the same draft task; return a receipt or explicit failure. | The event, validation, branch, and action are known in advance. Model-driven path selection adds no required value. | Quality disposition, schedule impact, task approval, exception handling, and customer communication. |
| Answer differently worded internal status questions when the necessary evidence and next permitted lookup may vary. | Consider a bounded agent | Interpret the request, select only configured read tools, reconcile returned status, preserve gaps, prepare an evidence-linked brief, and stop at the assigned reviewers. | The required path may change with the request, missing records, conflicts, or an active hold; representative cases must show that one fixed flow is insufficient. | Quality releases holds, Production Control assesses schedule, and an authorized commercial owner controls customer commitments. |
A conversation is not a failed agent, and a fixed flow is not unsophisticated. Each is a positive architecture choice when it satisfies the requirement with fewer permissions, branches, failure modes, and recovery obligations. The bounded agent becomes the positive choice only when its permitted adaptation improves the work enough to justify those additional obligations.
Price the operating burden
Every added source, tool, action, and adaptive step creates another promise to keep.
Agent complexity is not the number of boxes on an architecture diagram. It is the set of behaviors the operating team must authorize, validate, observe, recover, and own. A useful design review therefore expands each proposed component into an operating commitment before comparing products.
| Component added | Permission | Validation | Failure state | Monitoring | Duplicate protection | Recovery | Accountable owner |
|---|---|---|---|---|---|---|---|
| ERP work-order source | Read selected WO-1842 status fields only. | Valid work-order identity, permitted fields, source timestamp, and freshness rule. | Not found, denied, unavailable, or stale. | Source called, fields returned, evidence time, and latency. | Not applicable to the read; cache and retry behavior still need definition. | Return a visible stop and use the approved manual lookup. | Production-system owner and Production Control. |
| QMS inspection source | Read selected hold state, reason, owner, and time; no release operation. | Work-order/hold match, current state, responsible role, and conflicting timestamp check. | Not found, denied, unavailable, stale, or conflicting. | Query, returned hold state, conflict, evidence time, and route. | Not applicable to the read; repeated reads must not hide inconsistent results. | Stop the status conclusion and route the record to Quality. | QMS owner and assigned Quality authority. |
| Configured read tools | Execute through a named identity with least access to approved records. | Defined inputs, authenticated call, schema, returned status, and truthful error mapping. | Invalid input, timeout, partial response, uncertain result, or changed contract. | Selected tool, identity class, input type, response status, duration, and error code. | Use correlation IDs so retries and repeated calls remain visible. | Pause, inspect the system of record, repair the contract, and retest failed cases. | Technical service owner with business-source owner. |
| Draft review-request action | Create a draft internal task only; no approval, hold release, schedule write, or email. | Required evidence, named owner, approval signal, and action payload. | Rejected, timeout, unknown completion state, or unauthorized request. | Request ID, approval state, action receipt, failure code, and reviewer outcome. | Idempotency or duplicate key checked before create and before any retry. | Check the target system before retry; cancel or reconcile duplicate drafts. | Workflow owner and receiving Quality team. |
| Optional schedule-risk service | Send only approved identifiers and current evidence fields; receive advisory output. | Input contract, service version, evidence alignment, output status, and task-specific tests. | Unavailable, invalid, stale input, unsupported condition, or uncertain score. | Service/version used, evidence time, result, uncertainty, and later reviewer disposition. | Read-only analysis; repeated calls require trace IDs and comparison rules. | Remove the advisory result and continue the manual schedule assessment. | Service owner; Production Control retains schedule judgment. |
| Additional orchestrated step | Select only from explicitly configured sources, tools, and stop paths. | Representative branch tests prove when the step is chosen and when it must not run. | Wrong selection, omitted evidence, prohibited branch, loop, or compounded earlier error. | Plan branch, sequence, tool results, stop reason, override, and complete-run outcome. | Run and action correlation prevent the new step from repeating prior effects. | Pause the agent, fall back to the manual process, correct, and rerun the full affected path. | Named agent product owner with process and technical owners. |
Use a positive readiness gate
Say yes to an agent when the purpose, evidence, boundaries, and ownership are ready together.
The right gate is not “Is the technology impressive?” It is “Can this team state and test the additional adaptation it needs?” A bounded agent pilot is defensible when all nine conditions below have concrete evidence. A missing condition is a design task, not a reason to disguise the gap with a broader promise.
| Readiness condition | Evidence before a pilot | Not ready yet when |
|---|---|---|
| Bounded purpose | One audience, trigger, useful output, stopping point, and explicitly reserved decisions. | The goal is a broad aspiration such as manage production or handle customer status. |
| Fixed automation is insufficient | Representative cases show that request or evidence variation genuinely changes the permitted path. | The same validated event should always execute the same steps. |
| Approved sources | Named authoritative sources, fields, revisions or currency rules, and data owner approval. | Access is assumed because a connector or model exists. |
| Narrow permissions | A defined runtime identity can use only the minimum records and operations required. | The pilot depends on broad folders, shared credentials, or unbounded system access. |
| Prohibited actions | Hold release, schedule write, acceptance, price, and customer communication are absent or technically blocked. | Instructions merely ask the model not to use an available consequential action. |
| Representative failure tests | Normal, missing, denied, unavailable, stale, conflicting, prohibited, uncertain, and duplicate cases have expected results. | One polished demonstration is the main evidence of readiness. |
| Manual fallback and recovery | Operators can pause, complete the work safely, reconcile uncertain actions, correct the defect, and retest. | The team cannot continue the work or determine what happened when a dependency fails. |
| Accountable owner | Business, technical, source, review, incident, and lifecycle responsibility are named. | Ownership ends with the builder or is assigned vaguely to the user. |
| Measurable value | A current baseline and acceptance rule compare task quality, time, exceptions, review effort, and rework by condition. | The decision depends on generic ROI claims, feature adoption, or output volume alone. |
Separate today's decision from tomorrow's direction
Choose a current operating shape without pretending the agent ecosystem is finished.
| Perspective | Decision this aid supports |
|---|---|
| Daily practitioner or Quality coordinator | Distinguish the system’s proposal from the evidence and the authorized person’s hold, schedule, acceptance, or customer decision. |
| Owner or president | Reject unnecessary complexity while approving a bounded agent when measured variation and value justify its full operating cost. |
| IT, security, or governance | Require identity, least permission, denied-action behavior, tool contracts, complete-run monitoring, duplicate protection, and recovery. |
| Workforce or learning sponsor | Teach employees to recognize conversation, workflow, agent, and human authority without implying that learning authorizes deployment. |
| Operations or continuous improvement | Select the smallest shape, baseline the current process, and demand evidence that adaptive path selection improves the complete handoff. |
Current capability and emerging direction should not be blended. Microsoft’s documentation shows that products now support fixed flows, tool calls, multistep planning, and several agent harnesses. That establishes vendor-described capability, not dependable performance on WO-1842, compatibility with a manufacturer’s environment, automatic ERP or QMS access, or authority to act. Those questions remain task-, configuration-, identity-, evidence-, and test-specific.
Make the next decision measurable
Pilot the operating shape, not the promise.
For each candidate shape, compare the complete handoff with the current method: correct evidence selected, active holds and unknowns preserved, inappropriate branches prevented, exceptions routed, duplicate actions avoided, reviewer corrections, completion time, recovery time, and downstream rework. For an agent, break results out by normal, missing, denied, stale, conflicting, prohibited, and uncertain conditions. Averages can hide the branch that matters most.
The decision after the WO-1842 pilot can be conversation, deterministic workflow, bounded agent, a narrower pilot, repair, or stop. Success is not an agent purchase. Success is an operating shape that improves the defined task, preserves a safe fallback, and keeps consequential decisions with the people assigned to make them.
References
Sources and further reading
- Agents overview — Microsoft Copilot Studio Current product-specific descriptions of multistep adaptation, predictable structured conversations, tools, integrations, and harness-dependent capability; updated October 1, 2026 · Current Microsoft product documentation; capabilities depend on the selected harness and product configuration
- Agent flows overview — Microsoft Copilot Studio Deterministic rule-based paths, triggers, actions, human intervention, monitoring, and capacity; updated August 3, 2026 · Current Microsoft product example of a deterministic flow, not a universal definition of every workflow product
- Challenges to the Monitoring of Deployed AI Systems NIST AI 800-4; pre-deployment evaluation limits, real-world monitoring purposes, and the nascent state of monitoring methods · Cross-sector NIST research on monitoring needs and open challenges, not a manufacturing certification standard
- NIST AI Agent Standards Initiative Emerging standards, protocol, identity, authorization, security-evaluation, and interoperability work for agents; updated April 20, 2026 · Current initiative and research direction; it does not establish that a proposed agent meets a finished standard