Ask the Agent to Prepare an Update

An AI assistant can help organize a hosting update, but the available tools and permissions determine what it can actually do. In one session it may only read your local files. In another it may have an approved connection to a hosting service. Do not assume a familiar chat interface implies the same powers everywhere. Ask which tools are available and what account or project they are connected to before discussing a live change.

A good first request is read-only: inspect the approved release folder and explain what would be published. The agent can list public files, compare them with the sitemap and identify missing assets. It can prepare a plain-language release plan that names the target site. This lets you review something concrete before any public change. The agent should distinguish the source it inspected from assumptions about the hosting environment.

For a real update, name the exact website, intended change and scope. Ask for the current state to be checked before applying changes. A local file from last month is not proof of what the live service contains today. If other people have made updates, the assistant needs to reconcile them. Preserving current work is part of a competent release process, not an optional technical detail that can be skipped because a new draft looks better.

After the update, ask for evidence from the actual public address and any affected business flow. A readback from a hosting tool confirms one kind of result; a browser check confirms what visitors receive. Both may be useful. The amount of verification should fit the change. Replacing one sentence does not call for rebuilding the entire infrastructure, while changing a form connection requires more than reading the sentence in a preview.

Keep a short handoff note: what changed, why it changed, where the editable source lives and what was checked. An agent can draft that note as part of the work. Connector setup, API access and MCP are covered in their own course, where you can understand how sessions reach external tools. Here the important distinction is between preparing a release and actually applying one through an authorized, verified connection.

The activity asks you to choose a clear first request for an agent helping with a site update. Optional practice is reading the prepared request in change-brief.md. You are not asked to connect an account or grant deployment access. Understanding the inspection, plan, apply and verify sequence gives you a practical way to direct future help while keeping the business target and evidence visible.