在此页面上
Imagine asking an assistant to arrange a workshop. It may check the relevant calendars, choose a time within your instructions, reserve a room and send the invitation to the people you named.
The invitation goes out. The room is booked. The task is complete.
What should the assistant still be allowed to do?
Remembering the workshop could be useful when you prepare the agenda. Keeping the authority to rearrange calendars or invite more people is a separate choice. A completed task should have a visible ending, including an ending to the authority granted specifically for it.
That is the design position we take here. Clear endings make it easier to delegate substantial work in the first place.
Give the task a boundary it can use
“Arrange the workshop” carries an objective. A workable delegation also needs enough detail to recognize completion: the participants, the acceptable dates, the room requirements and the actions the assistant may take.
These details let the assistant make ordinary decisions without returning for permission at every step. If you have authorized it to choose a room that meets the stated conditions, it should finish that choice. Repeated confirmation of already authorized work transfers the burden back to you.
The boundary becomes important when the situation changes. A room that requires moving an unrelated meeting is a different decision from selecting among available rooms. Adding a participant changes who receives the invitation. An assistant should recognize where its existing instruction ends and make the remaining choice concrete.
A task can carry a short, readable description of this boundary: what it may use, what it may change and what counts as done. The person should be able to revise it while work is underway.
Access can outlive the reason for using it
Technical access and task authority operate at different levels.
A calendar connection might remain available because you use it for many tasks. That does not give one completed workshop request continuing authority over every calendar event the connection can reach.
At the protocol level, OAuth 2.0 defines access-token scope and a token lifetime. Those controls help delimit access. A token's remaining lifetime, by itself, cannot tell an application that your particular workshop has been arranged.
The application needs to enforce that task boundary where actions execute. A polite sentence in a chat saying the task is done is insufficient if an old worker, a queued retry or a follow-up routine can still act under its authority.
This distinction lets useful connections remain available without treating every past instruction as permanently active. Finishing a task need not disconnect an account used by other authorized work. It should close the authority associated with that task.
Completion needs a receipt
A completion message should identify the result a person can inspect: the calendar event, the room reservation and the invitation that was sent. It should also identify an unfinished part when there is one.
That record matters when an external service gives an uncertain response. If an invitation request times out, the assistant should check whether the invitation exists before sending another. A missing success message is not proof that nothing happened.
There should be a similarly clear record of what remains active. If you also asked the assistant to collect replies until Wednesday, that is continuing work with its own endpoint. The workshop setup can be complete while the explicitly authorized follow-up remains active.
Illustrative task states. A receipt check resolves an uncertain action before any retry; continuing work needs an explicit place in the delegation.
The result should be easy to read without understanding the machinery: the workshop is arranged; these replies are still being collected; collection ends on Wednesday.
Memory and authority need separate controls
After the task ends, you might want to retain the event details, delete the temporary room shortlist and keep the method that made scheduling easier. You might also decide to remove all of the task's retained context.
Those are choices about information. They should not silently restart the permission to act. Equally, ending action permission does not by itself erase a stored copy of the work.
An assistant should make the effects legible. Closing a task should stop further actions under that task’s authority. Deleting retained information affects what the system can later recall. Canceling a reservation changes an external result and requires the appropriate instruction. These operations have different consequences for the user.
The distinction becomes especially useful when several people or AI tools are involved. Handing another tool the workshop brief should not automatically hand it every permission the first tool had. The recipient needs the authority appropriate to its role.
An ending that survives interruption
The boundary has to hold after a process restarts, a connection returns or a delayed message arrives. A closed task should stay closed. Recovering the history should help explain what happened, without making an old instruction executable again.
This is a useful standard to apply to Zortex's context across AI tools: continuity should preserve the information needed to resume legitimate work, along with the boundaries that say which work has ended. Carrying context between assistants makes those boundaries more important.
When you delegate, you should be able to leave the task alone. When it finishes, you should be able to leave it finished.
