agent called the sandbox ERP endpoint instead of production and the correction job failed

TL;DR

Sandbox and production URLs differ by a subdomain or a flag, and an agent configured once for testing keeps pointing there. First establish what the correction job did in sandbox: nothing harmful, or writes that must be reversed or ignored there. Then point the agent at production explicitly, verify the endpoint identity from the connection response, and add guards so the mistake cannot recur: separate credentials, a config that names the environment, and a pre-run check that refuses sandbox for production jobs.

agent called the sandbox ERP endpoint instead of production and the correction job failed

Use this when

• The agent's correction job produced no production effect or its results exist in the sandbox system.
• Connection logs or the agent's config show the sandbox host or tenant.
• The failure message references sandbox data, limits, or empty result sets.

Not for this skill when

• Production itself is erroring or down. The endpoint is right; the service is not.
• The job was meant for sandbox, such as a test correction. Then the environment is correct and the failure is something else.

Steps

1. Stop the agent's correction job immediately to bound any further sandbox writes. Verify: no new sandbox activity occurs after the stop
2. Inventory what the job wrote to sandbox: journals, updates, or nothing, with ids and timestamps. Verify: the sandbox impact is fully listed
3. Decide the sandbox disposition with the team: reverse test writes that could confuse future testing, or leave clearly labelled test data. Verify: sandbox is left in a known, documented state
4. Reconfigure the agent with production endpoint and production credentials from the approved store, and verify the connection identity, tenant, and data counts against known production figures. Verify: the agent demonstrably talks to production before any write
5. Rerun the correction job in production, and add permanent guards: distinct credentials per environment, environment in the job config and logs, and a pre-run environment check. Verify: a sandbox-pointed config now fails fast with a clear message

Variant phrasings

agent called sandbox endpoint instead of production ERP

The wrong-environment phrasing.

agent correction job wrong tenant environment guard

When adding the guards.

Compatibility: ERP sandbox and production environments consumed by agent integrations.

Why it happens

Sandbox exists so testing never touches real books, and its URL is deliberately similar to production's, which makes misdirection a configuration accident waiting for a tired copy-paste. Agents are more exposed than humans because they do not glance at a banner or notice that the data looks thin; they execute. The guards, distinct credentials, named environments, and pre-run identity checks, replace the human glance with machine checks that never get tired.

Edge cases / pitfalls

• Some providers offer a company or tenant id in the API response; checking it against the expected production id is the strongest identity proof.
• Sandbox data refreshes can wipe the test writes, which is convenient, but never rely on a refresh as cleanup; label and reverse properly.
• Keep sandbox and production credentials in separate vault entries with naming that makes the environment unmistakable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstmfQcNRz6H3jRVOQtB_A3w