Hand off a social publishing task by transferring the exact approved payload, its execution status, and ownership of the next action. Give one executor responsibility for submission. The receiving agent should verify account access and reconcile any earlier attempt before creating a post.
Use the review document and ledger below to manage the handoff alongside Groniz's returned post records. Your agents and operators maintain these records; Groniz does not provide them as a built-in handoff feature.
For choosing how each agent connects, start with the publishing setup guide. Keep the approved content, destination, and timing intact when the receiving agent uses a different supported interface.
Transfer the approved version
A summary such as "publish the launch post tomorrow" loses the information an executor needs. It may omit a final link edit, the account ID, or whether another agent already sent the request.
Send the complete final body and media references. Keep the reviewed version unchanged during execution. If a receiving agent proposes a rewrite, different image, destination, or time, review that change before scheduling it.
Include the destination's integration ID, a readable label for comparison, and the provider settings checked during preparation. Preserve the exact ISO timestamp and the timezone the reviewer intended. A settings snapshot is evidence of the previous check; the receiving executor still needs to compare it with the current schema.
The human approval guide explains how to tie authorization to the final content and action.
Put the details in a handoff packet
This fictional example shows how an operator can record a text-only handoff. The identifiers and approval are illustrative. Prepare the actual Groniz request separately using the current schema.
handoff_id: example-launch-014
revision: 3
sender: drafting-agent
executor: delivery-agent
body: |
Our September release notes are ready.
Read the update: https://example.com/releases/september
destination:
label: Example Company
integration_id: illustrative-integration-id
media: []
provider_settings:
snapshot: "Illustrative only; insert actual schema-checked values"
schedule:
iso: "2026-10-06T09:00:00Z"
display_timezone: UTC
approval:
reviewer: example-editor
scope: "This body, destination, no media, and this schedule"
permitted_action: "Create one scheduled post"
execution:
state: not_attempted
pending_attempt: none
accepted_post_ids: []
Replace every illustrative value before use. For a post with media, include the uploaded Groniz .path, an understandable asset label, and the approved source file reference where appropriate. An optional checksum helps compare file versions; it does not establish media rights or replace editorial review.
Do not include credentials in the packet or conversation. Each executor should authenticate through its own approved runtime setup. Give the receiving agent the approved content and permission for the defined action while keeping credentials in its runtime setup.
Assign one executor
Maintain a small ledger next to the packet. Your team can use a shared document or task record, provided ownership changes are explicit and both agents can see the current state.
| Ledger field | What it records | Why the next agent needs it |
|---|---|---|
| Packet ID and revision | Exact reviewed version | Prevents execution of an older draft |
| Current executor | Agent or operator allowed to submit | Avoids simultaneous creates |
| Attempt state | Not attempted, in flight, accepted, or uncertain | Determines whether creating is appropriate |
| Attempt details | Time, destination, and reviewed request reference | Supports reconciliation |
| Accepted post IDs | IDs returned by Groniz | Connects the task to remote records |
| Observed delivery state | Queued or confirmed published, with check time | Separates acceptance from publication |
These fields and states belong to your team's ledger. Before the next executor takes over, the previous one must give up responsibility for submission. If an earlier request remains in flight, record that fact and resolve it before another create.
Verify access without changing the packet
The receiving agent should first discover available tools or commands, confirm which Groniz account it can access, and find the destination integration by ID. It then retrieves the current settings schema and compares the required values with the packet.
If the destination is missing or requirements have changed, report exactly what differs and resolve it before submitting. Avoid silently substituting an account or dropping a setting to make the request fit.
For media, verify that the uploaded reference matches the approved asset. If an upload still needs to happen, the executor must have access to the approved file, upload it, and use the returned .path. Record the resulting reference before submission so a later agent can identify what was used.
Reconcile before creating
Read the attempt state and inspect existing remote records before issuing a create. If the previous agent recorded an accepted post ID, locate that record and compare its destination, content, and schedule with the packet.
If a request timed out, mark the outcome uncertain until reconciliation resolves it. The post may be queued even if the transcript contains no receipt. Use the recovery guide to continue from the observed remote state.
Once a new authorized submission succeeds, write the returned post ID into the ledger. Report it as queued when that is the observed result, and verify publication separately at the appropriate time. The handoff is complete when the next owner can see what was approved, what was attempted, and what Groniz actually returned.
To prepare a destination for this workflow, connect it in Groniz, then build the first packet from a real integration discovery result.
Top comments (0)