agent wrote adjustments to the wrong entity after the entity-switch call failed silently

TL;DR

A silent entity-switch failure leaves the agent authenticated to entity A while believing it is in entity B, so every adjustment lands in the wrong books. Inventory the agent's writes since the switch attempt and reverse each one in the wrong entity, then repost correctly in the right entity. Fix the switch call to return and assert the active entity from the API response, and gate every write on that assertion, so a failed switch stops the job instead of misposting.

agent wrote adjustments to the wrong entity after the entity-switch call failed silently

Use this when

• Adjustments intended for one entity appear in another entity's ledger.
• The agent's log shows an entity switch with no confirmation of the new active entity.
• The wrong entity's balances moved during the agent's run window.

Not for this skill when

• Postings are wrong by account or department within the correct entity. That is a mapping issue, not an entity-switch failure.
• The agent intentionally posts to multiple entities. Then per-write entity selection needs the same verification, applied per write.

Steps

1. List every write the agent made after the switch attempt, with entity, journal, accounts, and amounts. Verify: the misposted population is complete
2. Reverse each misposted entry in the wrong entity with clear memos, and confirm the wrong entity's balances return to pre-run values. Verify: the wrong entity shows no net effect from the agent
3. Repost the adjustments in the intended entity with the original references. Verify: the intended entity now carries the adjustments and its balances are correct
4. Fix the entity-switch call to read the active entity from the API response and assert it equals the target before proceeding. Verify: a simulated switch failure now halts the job loudly
5. Add the entity assertion as a precondition to every write in the agent's posting path. Verify: writes cannot proceed when the active entity is unverified

Variant phrasings

agent wrong entity after entity switch failed silently

The silent-switch phrasing.

entity switch verification precondition journal posting

When adding the precondition.

Compatibility: Multi-entity ERP APIs with entity or company context switching, in NetSuite OneWorld and similar platforms.

Why it happens

Entity context is ambient state: it changes what every subsequent call means without appearing in any single call's parameters. A switch that fails silently is therefore maximally dangerous, because the agent continues with full confidence in a false premise. Verifying ambient state before acting is a general principle, and entity context is its sharpest application, since the blast radius is an entire company's books.

Edge cases / pitfalls

• Some APIs scope by header or token rather than a switch call; the same verification applies to whatever carries the context.
• Reversals in the wrong entity may need local approval there; coordinate with the entity's owner rather than posting unilaterally.
• Log the active entity with every journal the agent posts; the audit trail should make entity attribution trivial.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2AFLgIbIg-QGEYhkO9rpCg