What an agent fix looks like

A visitor cannot enable the Spanish version of their store. Here is how a person can take that report through investigation, an approved change and a reply in HappyToHelp.

1. The customer asks. Their widget message appears in your inbox. Open the conversation and read what they reported.
2. You grant an investigation. Pair a computer you control from Local computers, open the conversation's Local panel, choose Investigate and state the scope. The connector receives that conversation's context. The investigation instruction permits reading, not changing the customer system.
3. The agent proposes a fix. Read its finding and evidence. A proposed follow-up action and suggested reply are proposals; neither runs or sends itself. In this example the agent finds that the Spanish setting is disabled.
4. You approve the change. Review the proposed action's instructions and Resolve mode, then press Run. That approval creates a child task linked to the original investigation and proposal. Resolve permits the operational change described in your instruction and leaves the reply for you.
5. The agent changes the setting. Read the resolve report and its evidence. A report that says an operation ran is not an independent check. Keep the case open while you establish whether the customer system now behaves correctly.
6. You request a separate observation. Send a new Investigate task that reads the customer system itself, without repeating the change. Compare its evidence with the resolve report before treating the problem as fixed.
7. You press Send. Select the confirmed reply with Use, review it in the composer and press Send. The visitor receives the message in the widget. Replaying that exact admitted message request does not create another message.

If a new visitor message arrives while you are reviewing a draft, its earlier conversation position cannot authorize a send. Read the new message and request a fresh investigation. The earlier proposal remains available to inspect.

If you revoke a computer while work is running, HappyToHelp withdraws authority and records Authority revoked · local outcome unconfirmed. Revocation does not prove a process on that computer stopped. An offline computer leaves work queued; reconnecting with revoked credentials cannot run it. Pairing codes expire and are single use; a paired computer remains authorized until you revoke it.

An unverified resolve result needs your input and cannot supply a sent reply. An uncertain reply receipt needs review: inspect the transcript before taking any further action. HappyToHelp does not automatically replay that uncertain delivery; a message may already have reached the visitor.

The maintained journey exercises these steps against the emitted application, the real local connector and a disposable customer-system fixture. Its model provider boundary is scripted. Browser checks use a fresh local installation, automatic local owner entry, the dashboard and the widget at desktop and phone widths. These checks do not establish a live provider result, a change to a real customer's system, a hosted installation or model-answer quality.

See Local agent to connect your own account. Start with a throwaway target you control and inspect its state before and after each grant. The connector's host tools still have the permissions of that computer; conversation scope and mode instructions are not an operating-system sandbox.