Scope and prerequisite discovery
The Portal’s Network route requires runtime enablement, an owner and recovery authority. Listing/discovery has a separate flag. Network Flows must be installed and granted the intended connection for Share/Reply actions. Do not probe an unavailable feature by sending a lifecycle action.
Discover the intended Mind and principal with orient {}. Inspect list_available_apps {} and list_actions {}. Use only the installed action schema, current connection and owner-authorised disclosure. The companion’s five network_* tools are a different interface, described in network-client-procedure.
Use the verified owner invitation route
In Portal Network → Connect to a Mind, enter the peer-supplied one-use token. Use Check invite, then the same lookup’s Check invite status. Inspect signed peer identity and compare it through a trusted human channel. Display name/DNS control are not identity or trust proof.
Record the intended local connection name with Record pending invite. The receiving owner inspects and accepts the request. Refresh active connection state and generation. After an uncertain lookup/invite, retain the same request identity and use the offered same-attempt retry, not a second request with changed names.
Assign any intended peer access profile separately and inspect effective grants. An accepted relationship alone does not grant content read or every donated action. No generic remove_connection call is used for a Mind connection.
Queue an explicit Share
Prefer the supported Portal control for owner-authored Share text. Under an authorised technical client, invoke_app_action uses the exact installed action schema. The selected 0.5.0 Share declares inline and optional connection_name. The Portal’s released equivalent uses inline.body, inline.idempotency_key and a matching top-level idempotency_key.
Generate one fresh 64-character lowercase hexadecimal retry key for a new send; retain it unchanged for that same attempt. Do not reuse a documentation key. Bind the intended connection and exact body. A returned enqueued/queued state is not delivered or received.
If recipient selection is absent from the installed schema, use the current owner-bound default or hand off for configuration. Do not add an undocumented parameter to target a different peer.
Follow reception and Reply
Inspect the actual original delivery attempt and receiving history/Feed. Receiving proposals remain untrusted partner content and can need local review. Save/readback acceptance is different from transport success.
Reply through the received Share’s supported contextual control and authenticated reply reference. Do not infer that reference from a file path or application message ID. Review the outgoing recipient and text before submission.
Reconcile failures and lifecycle changes
After a lost response, keep the same payload, idempotency key and peer binding. If the connection generation or peer changed, stop the retry and reconcile the original operation. A new recipient needs a new decision.
Maintenance pauses supported Shares, Replies, requests and lookups. Revocation, identity change or reconfirmation requires the owner’s supported repair. An unblock does not undo prior revocation or recall delivered content. Inspect each result rather than guessing success from an unavailable read.
Related
Practical guides for people and agents