Purchasing work rarely finishes in one conversation. A supplier may answer a scope question tomorrow, an internal approver may be unavailable for several days and a project date may change while the request waits. A useful agent needs a durable task specification, rather than a vague instruction to keep working until everything is done.
This article proposes a bounded procurement pilot that preserves pending questions, ownership and restartable state. It does not authorise external messages or purchasing, and it does not claim that a vendor's long-horizon feature already implements the proposed workflow in your account.
Use the long-horizon announcement as a test prompt
Salesforce's 14 September 2026 announcement describes an Agentforce long-horizon runtime with memory, durable execution and dynamic steering. It identifies Hunter as the first agent using it, with Hunter in pilot and a November general-availability target in that announcement. Customer-built long-horizon agents are described as a future expansion. Source: Salesforce Agentforce portfolio announcement
That is a dated product direction, not evidence of a currently available procurement agent that can run your multi-day process. Check current capabilities, account access and the exact integration before selecting a platform. The announcement itself cautions that purchase decisions should depend on currently available features.
The proposed pilot can be specified independently of the eventual implementation. Its central question is whether work resumes from a reliable task record, with current authority and no duplicate actions, after the conversation or worker stops.
Give each pending item its own owner and condition
Separate supplier questions from internal decisions. A supplier response can provide evidence, but does not approve the organisation's purchase. An internal approval can authorise a proposal, but may not resolve a missing scope answer. Keep both dependencies visible.
Define what event allows progress: a verified answer linked to the question, an authenticated approval for the exact proposal or a confirmed project revision. A later message saying sorted is not sufficient if it cannot be matched to the pending item. Preserve incomplete answers and ask the designated owner what remains unresolved.
Also bound the goal. The agent should stop or hold when the required authority expires, the scope changes or a source cannot be verified. It should not invent new suppliers, broaden recipients or change the purchasing objective merely to reach a completed status.
Persistent procurement-task specification
Use this complete proposed specification for a fictitious quotation review. The pilot prepares evidence and proposals only; actual external communications and purchasing follow separately authorised processes.
Task: TEST-PROCUREMENT-A, collect answers to approved scope questions for TEST-RFQ-A and prepare a review pack. Accountable owner: designated procurement lead. Boundary: no order creation, supplier substitution or unapproved recipient contact.
| Task state | Required durable record | Permitted progress condition | Hold or stop rule |
|---|---|---|---|
| ready_for_collection | Approved question list, supplier reference, source versions and task scope | Owner-approved retrieval or authorised communication path | Missing scope or recipient authority holds work |
| waiting_for_answer | Question reference, known send or request outcome, responsible follow-up owner | Verified response matched to the question | Unrelated or incomplete answer stays pending |
| waiting_for_review | Source-linked answer, unresolved facts and exact proposal version | Authenticated reviewer decision for that proposal | No decision inferred from a supplier answer |
| ready_for_execution | Exact approved action, actor, target and current source state | Application permission and version checks pass | Changed payload or expired authority requires fresh decision |
| outcome_unresolved | Attempt reference, last known operation state and reconciliation owner | Authoritative result establishes what occurred | No blind repeat action while first outcome is unknown |
| complete | Required questions resolved, review record and verified permitted outcomes | Owner-approved closure criteria satisfied | A summary alone cannot close missing evidence |
| paused_or_cancelled | Trusted owner decision and reason, affected pending operations | Resume only under an explicit current owner decision | Stop new actions and reconcile anything already in flight |
Store task reference, objective, approved scope version, question references, supplier and project references, current state, event history, source evidence, approval records, operation references, next condition, decision owner and closure criteria. Keep credentials and unnecessary conversation content out of the task record. Store required evidence through the approved restricted access path.
Resume contract: reload the durable task, inspect previous operation outcomes, verify current source versions and recheck permissions. Do not use remembered conversation as an approval record. If an answer or project requirement changed, mark the affected proposal superseded and obtain the necessary review.
Acceptance fixtures: normal answer and review; missing question reference; partial answer; duplicate response; worker restart after a potentially successful action; and an owner cancellation while work waits. Confirm state transitions, preserved evidence, blocked unauthorised actions and reconciliation before retry. All actions are stubbed in this test.
The specification is accepted when a replacement worker or authorised colleague can resume the task from its stored evidence and explain why the next step is permitted. The goal is observable continuity with bounded authority, not an agent that acts indefinitely without review.
Keep tool requests distinct from action outcomes
OpenAI's function-calling guide separates the model requesting a function, application execution and the returned output. In the pilot, the durable record should capture those stages rather than storing a single assistant sentence that says the question was sent. Source: OpenAI function calling
If an operation reports success, verify the evidence required by the organisation's process. If a response is lost after a possible send or write, store unresolved outcome and reconcile its reference. A resumed agent should not repeat the action merely because its conversation lacks the success message.
Approvals must also survive in a trusted form. Record reviewer identity, exact target and payload, applicable scope version and current validity under the owner's rule. Recheck them at execution time; multi-day work creates opportunities for the underlying request to change.
Test failure handling without assuming persistence exists
n8n's Error Trigger documentation describes linked error workflows for automatic execution failures. That can supply a notification path where n8n is part of the implementation, but does not itself provide the durable procurement-state model above or establish the same behaviour during manual tests. Source: n8n Error Trigger
A failure notification should identify the task and known outcome without exposing unnecessary source content. The owner needs to distinguish a failed retrieval from an uncertain action result. Configure and test the actual path instead of assuming a platform's error feature means the business task can safely restart.
Keep the task record authoritative when a worker fails. The recovery process should inspect its latest trusted events and associated system outcomes. If those records disagree, hold the next action and identify the repair owner.
Work through normal, missing and duplicate progress
In a hypothetical normal case, the supplier answers an approved delivery question with a verified reference. The task moves from waiting for answer to waiting for review. The procurement lead approves the resulting scope proposal, and the pilot prepares the review pack without creating an order.
In a missing-reference case, a reply discusses delivery but cannot be matched to TEST-RFQ-A or its question. The task remains pending with a clear evidence gap. It does not attach the answer to the most similar open purchase just to continue.
In a duplicate case, the same verified response arrives through two collection events. The task records one answer with both event references under its duplicate rule. If a restart occurs after a potentially completed action, the worker reconciles the operation before any repeat. Continued activity is not the same as correct continuity.
FAQ about procurement tasks that last several days
Can remembered conversation replace a task database?
Not for this proposed design. The task needs durable, trusted references for state, evidence, approvals and outcomes. Memory can help interpretation, but should not become the sole authority for what happened or what is permitted next.
Does a supplier's answer allow the agent to approve the purchase?
No. It resolves an evidence question only to the extent the answer supports it. Internal approval and any purchasing execution follow separate authority and exact-proposal checks.
What should happen when the owner changes the goal?
Record the new trusted scope and identify which proposals or approvals are affected. Hold dependent actions until the revised task is reviewed. Do not silently reinterpret an earlier approval as permission for the new objective.
If your business needs help defining this process, explore Custom AI agents, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.