Work with the person, through Zingposts.

Start here

1. Open Zingposts in a browser tab the agent can control and discover document.modelContext tools.
2. If WebMCP is unavailable, tell the person whether the browser or the agent runtime lacks support; do not pretend to be connected.
3. Use Zingposts WebMCP tools for workspace changes instead of DOM automation.

Sign-in and delegation

• Only setup tools are available. Call get_agent_bootstrap, then start_agent_onboarding if the person has not opened a workspace yet.
• Once the person signs in, safe private tools become available in that browser document. Calls are attributed as a browser agent acting through the signed-in person; no extra agent code is required.
• For a separate browser or work that must continue without the person’s signed-in tab, use a one-use invite or fallback code to create an expiring, revocable agent session.
• The workspace persists. Browser-delegated access ends with the person’s browser session; independent agent sessions expire or can be revoked.

Prefer the person’s current signed-in browser for live collaboration. Independent agent credentials are an advanced option for separate-browser or unattended work.

Focused tool discovery

1. Call get_agent_bootstrap once. While signed out it returns only setup guidance. After the person signs in, rediscover tools and call it again to resume the workspace.
2. Call get_workspace_resume before creating new work. It returns changes since this agent’s durable checkpoint, structured blockers, proposals, and safe next actions.
3. Call activate_capability when a focused typed tool pack is needed. Capability activation does not navigate or change the person’s screen.
4. Use open_for_human_review only when showing the person a listing, board, session, conversation, alert, or trade would help collaboration.

Business tools are not unlocked by routes. Call activate_capability to replace one focused pack; call open_for_human_review only when the person should see a particular page or record.

Human and agent together

• Backend-backed actions may run without navigation while the person browses. The visible state updates after agent changes.
• Use a separate agent-controlled tab when visual navigation would interrupt the person or for longer-running work.
• Read resource versions and include expectedVersion on overwriting updates. Refresh after a CONFLICT result.

The same browser tab is useful for turn-taking and demos. Separate tabs are useful for live cooperation; Zingposts broadcasts workspace changes so each tab refreshes durable state.

Safety boundary

Safe lane: search, compare, organize, research, draft, plan, preview.

• publish a listing
• change public listing media
• send a message
• submit or respond to an offer
• invite a trade participant
• enable notifications
• delete a QA run

Never approve the agent’s own consequential request or bypass Zingposts verification and human review. Never treat a browser click, a supplied confirmed field, or your own approval as the person’s one-time confirmation.

Return later

1. Reopen Zingposts and rediscover the current WebMCP registry; do not rely on a cached catalog.
2. Call get_agent_bootstrap, then get_workspace_resume. Acknowledge a new checkpoint only after the returned changes have been processed.
3. If the person is signed out, ask them to sign in. Use a fresh invite or code only for unattended or separate-browser access.

Open the saved Zingposts URL and rediscover WebMCP tools.
Call get_agent_bootstrap before changing state.
Call get_workspace_resume and process pending human responses, blockers, and proposed change sets before creating duplicates.
Activate only the capability needed for the current objective.
Use Zingposts records as durable truth and preserve citations in research.
Leave consequential actions for exact human review.
Never store invite fragments, authentication codes, or stale tool catalogs.