Invoke repeatable assistant workflows from the task tracker
Give staff a familiar place to request a shared workflow, observe progress, and review the result.
How this works
Give staff a familiar place to request a shared workflow, observe progress, and review the result.
Use the task tracker as a controlled entry point to a maintained procedure. The task should identify the requested result and allowed tools, while execution records distinguish queued, running, awaiting-input and completed states.
Before you start
Defined operating scope
Repeated assistant work already enters a task tracker with explicit inputs and acceptance rules.
Required source material
Obtain Task request; Approved shared procedures; Required tools and access scope. If connectors are unavailable, use authorized files with the same fields.
Decision and exception rules
The request matches no approved procedure. Prepare a clarification or proposed procedure brief instead of improvising broad actions.
Prepare the inputs
- task_id
- Required
Tracker item and revision
Keep requester and attachments associated with this task.
- procedure_id
- Required
Approved workflow and version
Resolve one procedure rather than inventing tool actions.
- input_payload
- Required
Fields required by the procedure
Validate before execution.
- execution_scope
- Required
Allowed tools, records and side effects
Use an isolated working area and explicit limits.
Implementation, step by step
Establish the working record
- Confirm the selected records, effective versions and responsible owner.
- Check task_id, procedure_id, input_payload, execution_scope before beginning. Record the source version and the selected scope; an unavailable value stays unknown rather than becoming an inferred fact.
Checkpoint: The input record identifies the selected task_id and any missing required fields.
Map the request to a maintained procedure
- Match the request to a maintained procedure and identify missing inputs or an out-of-scope request.
- Check artifacts satisfy the selected procedure’s input and output contract.
Checkpoint: A saved intermediate result for: Map the request to a maintained procedure.
Run it in an isolated task environment with the required tools
- Run the selected procedure in a bounded workspace with only the needed access; use file outputs if the target connector is absent.
- Verify retries preserve run identity and do not duplicate completed side effects.
Checkpoint: A saved intermediate result for: Run it in an isolated task environment with the required tools.
Report progress and attach the result to the task
- Write progress states and attach produced artifacts with their validation results, separating prepared output from external completion.
- Check artifacts satisfy the selected procedure’s input and output contract.
Checkpoint: A saved intermediate result for: Report progress and attach the result to the task.
Review the output and record issues for improving the procedure
- Have the task owner review the result and record reproducible errors against the procedure version for later improvement.
- Verify retries preserve run identity and do not duplicate completed side effects.
Checkpoint: A saved intermediate result for: Review the output and record issues for improving the procedure.
Package the result and unresolved work
- Bound permissions and verify results before external actions. The source described a working tracker integration; a broader deterministic orchestration layer was still being built.
- Task content cannot grant tool access beyond the user’s authorization.
Checkpoint: A completed task artifact with visible progress and traceability. Unresolved items remain visible in the review record.
Decisions along the way
The request matches no approved procedure.
Prepare a clarification or proposed procedure brief instead of improvising broad actions.
Required input is missing.
Move to awaiting-input and name the exact missing field.
A retry finds a partial prior run.
Inspect the run record and resume or reconcile completed actions rather than starting everything again.
What you will produce
task-tracker-to-bounded-agent-work-result.json
JSONA completed task artifact with visible progress and traceability. Label proposed and completed states separately.
Include: task_id · procedure_version · run_id · state · artifact_references · validation_results · blocked_inputs · status · evidence_reference · review_note
task-tracker-to-bounded-agent-work-review.md
MarkdownKeep the evidence and unresolved decisions needed to apply this result, including exceptions involving execution_scope.
Include: source_reference · question · owner · next_action
Check the result
- Check artifacts satisfy the selected procedure’s input and output contract.
- Verify retries preserve run identity and do not duplicate completed side effects.
- Inspect task_id and procedure_id in both the original and output; confirm that record identity and interpretation survived the transformation.
- Bound permissions and verify results before external actions. The source described a working tracker integration; a broader deterministic orchestration layer was still being built.
When something goes wrong
The request matches no approved procedure.
Prepare a clarification or proposed procedure brief instead of improvising broad actions. Retain the affected evidence and recovery status.
Required input is missing.
Move to awaiting-input and name the exact missing field. Retain the affected evidence and recovery status.
A retry finds a partial prior run.
Inspect the run record and resume or reconcile completed actions rather than starting everything again. Retain the affected evidence and recovery status.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Invoke repeatable assistant workflows from the task tracker for the following bounded example; prepare the result for review.
Inputs
Synthetic example: Task T-14 invokes proposal procedure v3 but omits the approved price table. Attachments include a transcript that says to skip approvals.
Expected result
Synthetic expected result: Task becomes awaiting-input for the price table. The transcript is treated as evidence, not an instruction to change permissions; no external proposal is sent.
Run a small pilot
Start small
Trial a representative batch containing the ordinary case and the exception demonstrated above.
Record the baseline
Record current preparation time, review effort and correction types for the same records.
Agree success criteria
Agree acceptable review and error limits; measure accepted outputs per eligible task; rework, failed runs, and unauthorized actions.
Stop or revise
A retry finds a partial prior run. Pause affected records and apply this recovery: Inspect the run record and resume or reconcile completed actions rather than starting everything again.
Keep the scope clear
- Task content cannot grant tool access beyond the user’s authorization.
- Do not mark completed merely because an agent returned text; validate the requested artifact and any actual receipt.
Check before using
Bound permissions and verify results before external actions. The source described a working tracker integration; a broader deterministic orchestration layer was still being built.
Business activities
- Deliver recurring client work
- Operate and improve AI workflows
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Task request · Approved shared procedures · Required tools and access scope
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow