AI Multi-Intent Requests: Split Work Without Losing Asks

“Move visit V-204 to Thursday, send the revised brief to the supervisor, and tell me whether the replacement part is available.” One message contains several desired outcomes. A single label such as schedule_change can route the message correctly while leaving two of those outcomes unhandled.

AI multi-intent request handling identifies the separately requested outcomes in a submission, preserves the context each needs and proposes linked work items for validation. It is an intake problem before it is an execution problem: first establish what the requester asked for, then decide what the system may do.

The design below is a recommended operating pattern with constructed examples, not a tested customer implementation or a claim about any model’s accuracy.

Separate requested outcomes from an execution plan

A requested outcome is something the requester expects to receive or have changed. An implementation step is work the organization chooses to perform to deliver that outcome. Confusing the two can produce unnecessary tasks, duplicate approvals or commitments the requester never made.

“Move V-204 to Thursday” is one requested outcome. Checking availability, collecting approval and updating the schedule may be three implementation steps beneath it. Do not report those three steps as three independently requested changes.

There is a research basis for treating splitting as more than classification. DialogUSR research studies splitting multi-intent utterances into individual queries while recovering information omitted or referred to indirectly. That supports checking whether each extracted request retains its meaning; it does not establish the reliability of your production workflow.

Likewise, the legacy Rasa multi-intent documentation distinguishes predicting combined intent labels from defining how subsequent actions handle them. Recognizing two labels is not evidence that both outcomes were completed.

Split when the completion evidence differs

Use separate child outcomes when each needs a distinct disposition, owner or proof of completion. A schedule change and a stock-status answer can finish independently. Each should remain visible even if the other becomes blocked.

Keep one outcome when the words describe one result

“Move the visit to Thursday morning” is not a rescheduling request plus an unrelated morning request. “Check availability and let me know” can be one information outcome with a checking step and a response step. A conjunction is a discovery cue, not a reliable split rule.

Start with the organization’s supported request types. If a message exceeds the supported complexity or contains an unknown action, retain the complete submission and route it for review. Never silently truncate the list to fit a configured limit.

Build a source-to-outcome coverage manifest

Store the original submission as a parent record with an immutable source revision. Ask AI to propose outcomes and the passages supporting them. A reviewer then checks both directions: every proposed outcome must have support, and every requested outcome in the source must have a disposition.

This is stronger than counting sentences or requiring every word to belong to a child. Background, greetings, constraints and explanations are not necessarily separate tasks. The purpose is semantic coverage, not text segmentation for its own sake.

Keep non-action constraints in the manifest too, attached to the outcomes they constrain. An instruction not to notify the customer must not become a notification task. Use the negation-handling guide for that interpretation boundary rather than treating positive action labels as sufficient.

Walk one compound request through the boundary

Consider the opening example. The following interpretation is illustrative; actual routing, authority and service targets depend on the organization.

1. Visit change: propose moving V-204 to Thursday. The scheduling owner must clarify the date if the intake context does not establish which Thursday, then obtain the required authorization. Completion needs a verified schedule result, not merely an accepted model interpretation.
2. Revised brief delivery: propose sending the correct revised brief to the designated supervisor. Confirm the recipient and document version. If “revised” means the brief reflecting the approved schedule change, this outcome depends on the first; do not invent that dependency if the message leaves it unclear.
3. Part-availability answer: determine which part the requester means, consult an authorized inventory source and prepare the permitted response. Reporting availability is not an instruction to reserve or buy the part.

The parent can now show three outcomes instead of one overloaded ticket. If the part is unidentified, that child enters clarification. The visit change need not automatically stop unless the requester’s intent or business policy makes the outcomes conditional on each other.

Before dispatch, show the reviewer a compact comparison: original passage, proposed outcome, inherited context and missing information. For an ambiguous message, ask a targeted question such as, “Should the brief be sent only after the new visit time is approved?” Repeated extraction cannot supply an answer the source does not contain.

Keep interpretation, permission and execution separate

The AI component proposes the outcome list, evidence mappings and uncertain relationships. Deterministic checks enforce supported types, required fields, valid record references, duplicate identities and allowed transitions. People resolve ambiguous meaning and consequential decisions. Systems persist the accepted manifest and execute only authorized operations.

A valid schema proves that fields have the expected shape, not that the request list is complete. Evidence-span checks prove a passage exists, not that it supports the proposed interpretation. Use human-reviewed examples and risk-appropriate review to assess meaning.

Accept the manifest before releasing children

Use a parent progression such as Captured → Proposed → Needs review → Accepted → In progress → Closed, with explicit clarification, rejection and reconciliation states. Persist the accepted interpretation revision before dispatch. A changed source or corrected interpretation creates a new revision; it must not silently alter work already released.

Each child needs its own authorization and state. Approval to reschedule does not authorize sending a document or making a purchase. Apply access and routing policy to the complete request as well as each child; splitting must not hide a restricted overall purpose.

Make retries refer to accepted identities

Assign stable child identities when the manifest is accepted. Do not derive them solely from array positions: a revised model response can reorder the same asks. Match proposed revisions to existing children and record explicit additions, merges, splits or supersessions.

Use a stable operation identity for each authorized child action. If a schedule write times out, reconcile that action against the destination record before retrying. Do not rerun the entire parent and send a second brief because one child’s acknowledgment is missing.

Close the parent only when every outcome is accounted for

Define closure as a coverage rule, not “the first task succeeded.” Every accepted requested outcome must have either verified completion evidence or an explicit permitted terminal disposition, such as requester withdrawal, rejection or an acknowledged inability to fulfill it. Distinguish “closed with an unresolved service outcome” from “fully fulfilled.”

• Partial completion: preserve completed child results and keep the remaining owners and blockers visible. Report which outcomes are complete, not simply that the request is done.
• Unavailable tool or source: retain the affected child in a visible waiting state with an owner and retry policy. Do not substitute an inferred answer.
• Human rejection: store the reason and terminal disposition. Do not keep regenerating the proposal until it receives approval.
• New clarification: version the manifest, assess impacts on released work and request additional approval where needed. Completed work does not become unexecuted just because interpretation changed.
• Duplicate submission: compare parent and child identities with existing work before creating new actions. Similar wording alone does not prove the requester intended the same operation.

For upstream capture and routing, the email-triage workflow supplies the surrounding intake pattern. This manifest adds an accounting boundary inside the message, not a replacement inbox architecture.

Test omission, over-splitting and field leakage separately

Build a reviewer-labeled evaluation set containing single asks, compound asks, repeated asks, shared targets, different targets, dependencies, alternatives, corrections and unsupported requests. Include cases where “and” belongs inside one outcome and cases where a trailing sentence introduces another.

Measure requested-outcome recall as correctly represented requested outcomes divided by all reviewer-labeled requested outcomes. Measure proposal precision as supported proposed outcomes divided by all proposed outcomes. Score target and qualifier correctness separately: detecting “send brief” is not a pass if the recipient or document version is wrong.

Also track parent exact-match interpretation, premature parent closure, duplicate child actions, clarification volume and partial-completion age. Define the denominator for each. An illustrative release criterion might require human review for all financial or external-communication outcomes; set actual gates from consequence and observed errors, not a universal confidence score.

Where Workhint fits

After the requested outcomes are accepted, each needs an owner and a permitted route. Workhint’s Workflow Engine describes role-based approval routing and required information before work advances. Its workflow automation software page describes structured intake and tracking process stages, owners and next actions.

Those capabilities are relevant to the downstream work. They do not establish that Workhint provides a native compound-request parser or implements the coverage manifest and parent-closure rule above. Treat extraction, accepted-child identity and cross-system reconciliation as requirements to assess explicitly, not features inferred from a product description.

Frequently asked questions

Should every sentence become a work item?

No. Split by separately requested outcomes, not punctuation. Background and constraints may support several outcomes without becoming executable tasks.

Is multi-intent detection the same as planning?

No. Detection identifies outcomes already requested. Planning chooses the steps needed to deliver an accepted outcome. Keep those records distinct so generated steps do not look like new user instructions.

Can independent outcomes proceed while another needs clarification?

Only when meaning, authority and policy allow independent progress. Preserve the blocked child and do not close the parent as fully fulfilled. If the request is conditional or all-or-nothing, hold the affected group until that relationship is resolved.