Use a Task Routing Worksheet Before Choosing an AI Model

Proposed October 2026 task-routing worksheet: we recommend making three separate decisions for each piece of AI work. Set what software rules should handle, what an AI model should judge, and what a person must approve. Start with intake sorting, draft record updates, reply drafting or scheduling proposals. Use the public guidance below as context for this proposed workflow, not as evidence of measured results at a firm. Ask your firm's designated attorney to decide any professional-responsibility questions before implementation.

What the public guidance says

Anthropic's Building effective AI agents (published December 2024, with a note that much of the tooling landscape it describes has since changed) is vendor guidance, not independent evidence of results. Three of its points matter here. It recommends finding the simplest solution possible and adding complexity only when needed, which may mean not building an agentic system at all. It says agentic systems often trade latency and cost for better task performance, so the trade-off should be considered deliberately. And it describes routing, where an input is classified and sent to a specialized follow-up step, as working well when classification can be handled accurately, either by an LLM or by a more traditional classification model or algorithm. It also describes programmatic checks, which it calls gates, on intermediate steps.

Two other sources shape the controls. The Measure function of the NIST AI RMF Playbook provides risk-measurement guidance. It says measurement should start with the most significant risks, and that risks which will not or cannot be measured should be properly documented. Its text also says current AI systems are dependent on the context in which they were developed, so reliance on local evaluations and continuous monitoring will be necessary. It adds that measurements which go beyond averages across test cases, or focus on pockets of failure where costs may be significant, can improve the reliability of risk management. The OWASP AI Agent Security Cheat Sheet, says authorization should be enforced in the execution component outside the agent's context. It also says agents should undergo structured security testing before production deployment and after material changes to prompts, tools, memory, retrieval, policies or model providers.

Three dials, not one

We recommend keeping workflow rules, model choice and human approval as three separate decisions. Write each decision beside the task so a change of model does not silently change who can approve an action.

1. Software rules. Define required fields, permitted record types, available actions and who may approve each action. Use code to check these rules before execution. Ask the builder to show where those checks happen and what happens when a check cannot run.
2. Model choice. Compare candidate models on specific judgment tasks, such as sorting a message or drafting a summary. Test whether each candidate meets the task's agreed requirements. Include review effort and incorrect answers in that comparison rather than assuming a smaller model is adequate or a larger one is safer.
3. Approval. We recommend that a person sign off on actions that are outward-facing, confidential, deadline-related or hard to undo.

We recommend retaining permission and approval checks regardless of the model selected. Do not treat a change to a more capable model as permission to remove those controls.

On approval, OWASP's guidance is specific. The component that executes the action must verify that the approval belongs to the current actor and the exact tool call, that it remains valid, and that it has not already been consumed. A simple “user confirmed” flag is described as insufficient. Changes to the target or parameters require new approval, and unknown tools or missing approval requirements should fail closed. Our own recommendation, building on that: do not rely on a prompt instruction such as “ask before sending” as the control. Put the check in the code that performs the send.

A recommended sequence

The following steps are our recommendations, not requirements drawn from any one source.

1. Inventory tasks, one line each. Write the tasks before looking at any model list: “classify a new inquiry,” “create a draft lead record,” “draft a reply,” “propose a calendar slot.”
2. Tag each task as rule, judgment or plan. Use rules for defined checks. Treat a judgment task as one decision with an expected answer. Separate a proposed multi-step plan into its component actions, then test whether a different model or a person is needed. Avoid using task labels as automatic permission to act.
3. Score reversibility honestly. Do not assume a CRM write is reversible. It may be, but only if the answers to these questions are acceptable. Does the write trigger an automation, such as a client-facing email sequence or a task assignment? Does it sync to another system? Does it overwrite a value without keeping history? Does it change who gets notified or what a deadline report shows? Treat a write as reversible only when the prior value is kept and every downstream effect can also be undone. Otherwise place it in a higher tier.
4. Assign a lane and a written escalation rule. For example: if a required field is missing, the matter type is outside the tested set, the input format is unfamiliar, or the message touches a category your attorneys flagged as sensitive, hand the task to a stronger model or a person. If you plan to use a model's own confidence signal as a trigger, test that signal first rather than assuming it is calibrated. Also write the downward rule, so expensive steps are not used for routine work by default.
5. Use approved test cases. Ask a named reviewer to approve the inputs and expected outcomes described below.
6. Set acceptance by risk tier. See below.
7. Record and review the results. Set an activity-record purpose and keep only the information needed for that purpose. Start with task identifier, model version, outcome, approval reference and escalation status. Exclude confidential content and secrets unless the firm has approved a specific need and handling process. Ask someone other than the builder to review failures and samples on a schedule the firm sets.

Approved test cases

We recommend that a named responsible person, ideally an attorney or operations lead rather than the builder, sign off on the test set and on the expected outcome for each case. Write the expected outcome before the run, not after seeing the output. A suggested mix:

• Use typical cases. Start with fictional records approved by the firm. Use real past material only after the firm's designated reviewer confirms that de-identification, purpose, destination and retention are acceptable. Do not send client material to another service merely because it is a test.
• Include edge cases. Test missing fields, mixed topics, returning clients who write as new inquiries, and unfamiliar formats. Define the expected review or escalation outcome for each one.
• Test the stop path. Include cases the system should refuse or send to a person, and verify that no consequential action occurs while review is pending.
• Include hostile inputs. Test fictional messages that try to override the workflow instructions or request an unauthorized action. Define the expected refusal or escalation and verify that execution remains within the approved permissions.
• Keep past failures in the test set. Use approved, appropriately handled examples of earlier errors and record the expected corrected outcome. See the related failure-ledger and regression-set guide for that proposed method.

Version the set and re-run it when you change a prompt, tool, memory, retrieval source, policy or model provider. That list follows the material changes OWASP names; we would also re-run it after any change to a model version, which is our addition.

Risk-based acceptance, not a universal pass mark

We do not recommend a single pass count as a general acceptance line. Our inference: a small sample can expose obvious failures, but a clean result does not show how often a workflow will fail on later inputs, and an average can hide one category that fails every time. That is the pocket-of-failure concern in NIST's text. Treat a bake-off as a screen that decides whether a supervised pilot is justified, not as proof of production reliability. Instead of one threshold, we recommend writing acceptance criteria per tier, set by the risk owner before the test runs.

• Tier 1: proposed internal work with limited consequences. Use a draft category tag as an illustrative case, but verify its downstream behavior before classifying it as low risk. Ask the risk owner to set an error tolerance, required case coverage and pilot limits before testing. Investigate every flagged case and record unresolved limits.
• Tier 2: proposed changes to records others rely on. Route writes to a review queue until both output quality and downstream behavior meet the agreed criteria. Test notifications, synchronization and overwritten values. Require investigation and correction of failures in categories the firm has designated as sensitive before expanding scope.
• Tier 3: proposed outward-facing or hard-to-undo actions. Keep the system in draft-or-propose mode and require approval for each exact action. Test changed parameters, reused approvals, unavailable approval checks and unknown actions. Verify that these cases stop execution rather than relying on draft quality as permission to send.

NIST's Playbook text says risks that will not or cannot be measured should be properly documented. We recommend that the firm also record its reasoning for each of those decisions; that part is ours, not NIST's.

An illustrative example

This is a hypothetical walkthrough for an estate-planning firm, not a client deployment or a result. A new inquiry arrives by web form or voicemail transcript. Rules validate the fields and restrict the matter type to the firm's approved list. A model classifies the inquiry (new plan, probate question, existing client, not a matter) and extracts names. The agent writes a draft record in a staging status that does not start any client-facing sequence. A reply to the prospective client is drafted but sent only after a staff member approves that exact message. Any inquiry touching a category the attorneys define, such as an imminent deadline, a dispute or a vulnerable person, escalates to a person immediately. Which categories those are, and what the firm may say or store at intake, are decisions for the firm's attorneys.

Common pitfalls

• Choosing the model first. Start with the task inventory, risk assessment and required controls before comparing model options.
• Using a public launch as firm-specific evidence. Use local evaluation on approved cases before choosing a pilot scope. Do not substitute popularity or an external benchmark for the firm's own acceptance decision.
• Putting mandatory controls only in instructions. Check authorization in the component that performs the action, and verify the stop behavior when that check fails.
• Assuming a free or bundled service is appropriate for client data. Review destinations, retention, permissions and terms before authorizing any confidential material. Ask the firm's designated reviewer to resolve uncertainty.
• Keeping an expensive route without comparison. Compare another route only within the same approved task and control boundary. Retain the existing route when the alternative has not earned acceptance.
• Approving once. Set change triggers and a review date, and pause expansion when evidence no longer matches the approved configuration.
• Leaving review unowned. Name who examines results, who can pause the workflow and who decides whether testing is sufficient for the next stage.

Compare measured effort within the approved scope

We recommend recording cost and elapsed time for each candidate on the same approved case set. Include retries, additional service requests and staff review time. State the date, configuration and assumptions beside the comparison. Avoid promising lower cost or faster service before measurement, and do not trade away permission checks to improve a cost figure. Treat a favorable comparison as evidence about those tests, not as a guarantee about later work.

Build it or hire it

Ask whoever builds the workflow for the task inventory, route decisions, approved test cases, acceptance criteria and activity-record format. Request a demonstration of the stop and escalation paths using fictional material. Keep the pilot limited until the named risk owner can explain what was tested, what remains unknown and what would cause a pause.