An agent starts researching a launch, another drafts an email, and a third checks the website. Before long, you have several conversations open and no clear record of which draft is current or who is allowed to send it.
The useful starting point is a project with a defined result. Decide what must exist when the work finishes, which tasks can happen separately, and what needs your approval. Then give each agent a smaller job within that plan.
Consider a small business preparing a website refresh alongside a monthly customer newsletter. This hypothetical example shows how to divide the work without losing track of the sources, decisions and finished drafts.
Give each project an outcome, an owner and a source pack
A project needs a short brief that someone can read without searching through old chats. Name the outcome, the source material and the person who will accept the result. Keep unrelated work out of it.
For the website refresh, the result might be a reviewed draft of a service page and a list of facts that still need checking. It should not quietly expand into editing the live site, contacting customers or buying software. The newsletter needs its own brief, audience and final draft.
Both projects might use the same approved service descriptions. Give each agent the relevant version and date; do not assume that separate conversations automatically share current information. Grouping work by project is an organizational practice, not proof that the software enforces data separation or access restrictions.
Write down where the working files belong and which file is authoritative. If an agent creates a revised draft, the next agent needs to know whether to use that version or an older attachment. Keep one clearly named final document for each project, with research notes stored separately.
The public doesn’t see these collaborations.
MORE NEWS: The Rialto Theatre has quiet power in Downtown Tucson
DEEPER DIVE: Gibson Food Hall: Tucson’s new home for local flavor
Write a brief before assigning an agent
“Handle the website” leaves too much open. A bounded assignment is easier to review because it specifies an output and the limits on producing it.
Use this short brief for each task:
- Project and outcome: Which project does this serve, and what should it achieve?
- Deliverable: What file, draft or other artifact should exist at the end?
- Approved inputs: Which documents and versions may the agent use?
- Exclusions: What must stay outside the task?
- Permitted actions: What can the agent do, and what must remain manual?
- Dependencies: What must be finished before this task starts?
- Evidence: What sources or checks must accompany the result?
- Human reviewer: Who decides whether the result is acceptable?
- Stop condition: When should the agent pause and report a problem?
For the website project, a filled brief could read:
“Prepare a draft service fact sheet for the website refresh. Use only the approved service descriptions dated October 1 and the current FAQ supplied in this project. Produce a table with each fact, its source passage and any contradiction. Save a new draft in the project folder. Do not change the source files, edit the website or contact anyone. No earlier task is required. Return the table to the business owner for review. If a source is missing or conflicts with another source, mark the affected fact unresolved rather than choosing an answer.”
That assignment gives the agent a source set, an output and limits. It also gives the reviewer a concrete definition of completion. The dates and documents in this example are placeholders for a real source pack, not product requirements.
Run independent tasks in parallel
Parallel work is useful when each task can finish without waiting for another agent’s output. In the website project, one agent could extract service facts while another identifies customer questions the supplied FAQ does not answer. Both can work from the approved source pack without editing the same document.
Writing the final service-page draft is a later task because it depends on the reviewed facts and unanswered questions. Starting it early may leave you with polished copy built on assumptions that another agent is still checking.
The newsletter can proceed separately if its topic and source material do not depend on the website changes. If it announces a revised service, however, that part should wait until the business owner has confirmed the details.
Give each shared file one writer at a time. Other agents can return comments or separate research notes. Name one person to combine the results and resolve disagreements before work continues. More agents also mean more outputs to reconcile, so add a helper only when its task is genuinely separable.
Separate permission to draft from permission to act
An instruction to prepare an email does not have to include permission to send it. Likewise, permission to draft a service page is not permission to publish it. Reviewing the quality of an output and authorizing an external action are separate decisions.
Before using an agent on an important account, check what it can actually do without asking. Start with a harmless test and watch where the software pauses. Written instructions and technical permission controls are different things; use both where available. If the setup cannot reliably restrict an action, keep that action manual and outside the agent’s assignment.
For the newsletter, a useful initial boundary is to prepare a draft and return it for review. Keep purchases, deletions and changes to external systems outside the task unless you have deliberately authorized them and checked the relevant controls.
When an agent needs help signing in or navigating a website, pause the task and handle the human step yourself. Give control back only when it is clear which account and page the agent will use. Avoid pasting credentials into task briefs or shared project notes.
Check the result against evidence
Ask for a result you can inspect. A research task should return its sources and unresolved questions. A document task should return the actual file. An authorized update to a record should include a read-back of the changed record, not just a claim that the update succeeded.
Before accepting a result, check the following:
- The expected artifact exists, opens and covers the scope in the brief.
- Important claims trace to the approved inputs, with source versions or dates recorded where relevant.
- Missing information and contradictions remain visible rather than being filled with guesses.
- The work stayed within its permitted actions, and any proposed external action remains separate from the draft.
- The named human reviewer has checked the result and recorded what still needs attention.
For example, suppose the hypothetical service-page draft says support is available every day, but the source pack says weekdays only. Correct the draft against the source and check the newsletter for the same mistake. An additional agent review can help locate discrepancies, but its agreement is not independent proof that the claim is true.
Keep the brief, conversations and outputs associated with the right project so this review is possible. One implementation example is ShiftHands, which describes grouping agents by project, each with its own chat, history and model. Agents run on an Apple-silicon Mac with macOS 13 or later, kept on with ShiftHands open; browser access, including on a phone, is for monitoring, chat and approvals, not cloud execution. Approval behavior depends on agent settings; not every file change or send is gated.
A useful completion note answers four questions: What was produced? Where is it? What was checked? What remains unresolved? Keep failures in that note. An inaccessible source is a limit to report, not an invitation to fill the gap with a plausible answer.
Schedule only a task you have already checked
A recurring task needs the same boundaries as a one-off task, plus a schedule and a clear rule for reporting exceptions. Run it manually first and review the output before letting it repeat.
For the website project, a report-only routine might check whether supplied service descriptions have changed since the last review. Define the input location, schedule and time zone, where the report belongs and who will read it. Specify what happens when an input cannot be reached or a result does not arrive.
Check the tool’s execution requirements and how it handles missed runs. Access from a phone does not necessarily mean the phone runs the agents or that a task continues when its host computer is off. A schedule is not evidence that a run completed.
Do not silently repeat an action after an uncertain result if it could create duplicate sends or changes. First inspect the destination to establish what happened, then decide whether another attempt is appropriate. Keep sending the newsletter and publishing website changes separate from the report-only routine unless those actions receive their own authorization.
Start with one contained task, a small source set and a result you can check yourself. Apply the brief and acceptance checklist before adding another agent or a recurring schedule. Expand the setup when the handoffs are clear, not merely because the software can run more agents.
