Give a connection only the permission it needs.

Four permissions, four different decisions

• Read: opens the evidence and action records your account may read. This is the default for a new connection.
• Work handoffs: changes the named owner of an existing work entry and saves a handoff note. The assistant must show an exact preview before you confirm.
• Free checks: lets a connector request a free check within the existing allowance, when that service is enabled for the account.
• Paid questions: lets a permitted connection place a buyer question using one existing credit after a separate preview.

A work handoff does not approve a draft, publish a page, invite a colleague or run a measurement. Naming an editor records responsibility. It grants no account access. Questions and free checks keep their existing availability and account limits.

Choose permissions when you create a connection in your account. Optional boxes start unchecked. Existing connections keep the permissions they already have. A read connection made through the account sign-in flow remains read only. A new connection does not turn on an unavailable service.

Read the exact handoff before confirming

Ask the assistant to find the work entry in your chosen client account. Its preview should name the client, the work, the current owner, the proposed owner and the full handoff note. It also shows the existing work state, dates and zero credit cost. Check those details against the work you intended to assign.

The note needs 10 to 500 characters. Use it to explain what the next editor should check and who will review the result. The owner's name needs 1 to 120 characters. A name is a work label; no message is sent to that person.

For example, a fictional handoff could assign Alex Example to check a source paragraph and return the proposed correction for review. The work would keep its current approval state and evidence. Assigning Alex would not prove that the paragraph had changed or that an AI answer had improved.

Confirm only that preview. It expires after 15 minutes. If someone changes the owner or work state before the save, the action is refused. Read the current entry and request a fresh preview rather than relying on the earlier one.

Keep the client boundary in view

A connection uses your existing workspace access. Owners, admins and members may hand off work in the clients they can edit. A client viewer may read the assigned client's evidence and action records but cannot change the work. Supplying a different client identifier gives no additional access.

Use the workspace directory to check the client and role before an action. The save checks the connection permission and workspace role again. Revoking access while a preview is open prevents its confirmation.

Read what happened, including a refusal

Connection action history keeps the complete supported request and output, the account, the action, its start and finish times, and its outcome. Open the input and output beside each record. Follow Older action records to continue through the history, or download the complete file for that client.

A preview is a proposal. A refused action includes the reason it could not proceed. A completed work handoff contains the saved owner and note. A completed question request confirms that the question was placed; open its account record to check delivery. A started or uncertain outcome needs an account check before another attempt.

The history covers work handoffs, question previews, question orders and free-check requests made through supported connections. It does not reconstruct earlier activity or turn ordinary evidence reads into executions. An empty history therefore says only that no supported action has been recorded there.

Retry without repeating the edit

Keep the same request identifier and exact confirmation when a work handoff reply is interrupted. A completed request returns its saved result. Changing its owner or note while reusing that identifier is refused. This makes the retry traceable to the original handoff.

The handoff and its completed action record are saved together. If that record cannot be stored, the edit does not commit. For a question or free-check request whose result is uncertain, first inspect the account. Its history retains that uncertainty; it does not claim the underlying service failed.

The change review guide explains the separate evidence needed for approval and publication. Use it after the editor returns the work.

Use the same record through your existing tools

The connector exposes set_work_owner only to a connection with work permission. Its first call previews the handoff; the confirmed call includes the returned preview_hash. get_action_history reads saved actions without an edit or spending permission.

The API uses POST /api/v1/accounts/me/work-owner for the same two steps and GET /api/v1/actions to read history. Follow the returned cursor until it is empty. The API reference lists the fields and failure responses. No new credential is needed to read history through an existing authorized read connection.