Agent Runtime Gateway Smoke Test

Use this workflow when an agent task runs in a remote sandbox that calls back to a local API through a gateway. It verifies the whole path without relying on connected tools or private production data.

When to Activate

• A local agent API needs an end-to-end runtime check.
• A task stalls after dispatch and the gateway or tunnel may be unreachable.
• A web app is temporarily pointed at a local API for agent testing.
• A previous test left the web app pointing at a stopped API.

Required Inputs

• Repository-relative instructions for starting the API and web app.
• The gateway route path and its expected anonymous response.
• An isolated test agent, a tool-free prompt, and its exact expected answer.
• A way to inspect task status and confirm a callback reached the local API.
• Provider credentials, supplied through the project's normal secret store. Name the providers in shared documentation; never copy credential values into the skill or test report.

If these inputs are unavailable, report the missing input instead of guessing an endpoint or using a real account.

Authorization and Cleanup

Confirm authorization to expose the local test API through the selected tunnel provider, dispatch the test task, and temporarily change the web app route. Use an isolated local web app or test deployment; do not switch a shared production app as part of this smoke test. Keep tunnel access scoped to the required authenticated route.

Install cleanup before changing the route: on success, error, timeout, interruption, or cancellation, restore the recorded target and verify health before stopping the API and tunnel. Track only the process IDs or resources created by this test. If restoration fails, report it immediately and keep the evidence needed to recover; do not claim success.

Smoke Test

1. Record and check the original route. Note the web app's current API target and verify it is healthy. Keep this value locally for restoration. Confirm the test agent and data are isolated from real users.
2. Start the local API and tunnel. Use a process manager that will keep both alive for the full test. Verify API health. Probe the gateway route anonymously and confirm the documented authentication response, usually 401 or 403. Confirm the probe appears in the local API log; an edge response alone does not prove the API was reached.
3. Switch the web app only after both checks pass. Verify a request from the web app reaches the local API. Check the route again after any web server restart or configuration reload.
4. Run one tool-free task. Use a short prompt with an exact expected answer. Confirm the remote sandbox called the local gateway, the task reached a terminal state, and the returned answer matches. A queued or running task is not a pass.
5. Restore the original route. Set the web app back to its recorded API target, verify that target and a representative page load, then stop the test API and tunnel. If restoration fails, report the broken route immediately.

Example checks, with values supplied by the project:

curl --silent --show-error --output /dev/null --write-out '%{http_code}\n' "$LOCAL_API_HEALTH_URL"
curl --silent --show-error --output /dev/null --write-out '%{http_code}\n' "$PUBLIC_GATEWAY_PROBE_URL"

The first command should return the project's healthy status. The second should return the documented anonymous authentication status and appear in the local API log. Do not put a credential in either URL.

Connected Tool Follow-up

Run a separate test only after the tool-free task passes. Use an explicit test connection and grants. Report connection presence and actions granted as different facts. Do not infer that an empty action search means no app is connected. Do not execute a write action against a real account as a smoke test.

Failure Handling

…