--- title: "Before connecting another system, define the action" description: "Define the target, permission, and proof of a business action before adding a connection. Plan for changed records, duplicate attempts, and uncertain outcomes." slug: "before-connecting-another-system-define-the-action" url: "https://withlodge.com/writing/before-connecting-another-system-define-the-action" published: true published_at: "2026-07-21T12:00:00.000Z" updated_at: "2026-11-02T15:17:30.021Z" image_url: null image_alt: null image_width: null image_height: null word_count: 756 --- Connecting an AI agent to a business system raises an immediate question: what, exactly, should it be allowed to do there? A system name is too broad an answer. A supplier database contains many records and many possible actions. Reading an address, preparing a correction, and saving that correction carry different responsibilities. Defining the intended action gives the connection a business purpose and gives its permissions a boundary. Imagine a hypothetical purchasing team that wants help processing supplier address changes. A request arrives, supporting evidence is checked, and an authorized employee decides whether to update the supplier record. Before choosing an integration, the team needs to describe that sequence precisely enough to recognize both completion and a dangerous mistake. ## Separate reading, preparing, and committing Start with the smallest useful action. The imagined agent might retrieve a specified supplier's current address and compare it with an authorized change request. That requires permission to read particular information. It does not require permission to alter the supplier account. Preparing a proposed update is another action. The proposal should identify the existing value, the requested replacement, the evidence, and anything that remains unresolved. A draft can support a person's decision while remaining separate from the official record. Committing the update changes the company's working data. That step needs a defined human authority and a grant limited to the permitted task. A connection that works technically supplies no business authorization by itself. The agent cannot turn its ability to reach a system into permission to change everything it finds. Keep these distinctions in the operating procedure and the integration design. If the only available connection grants broad write access, that mismatch deserves a decision before work proceeds. Convenience is a poor reason to leave the action undefined. ## Identify the exact record and field An instruction to update a supplier's address can conceal several different requests. The registered office, delivery location, and correspondence address may be separate fields. A supplier group may also contain distinct legal entities with similar names. In the workflow, the request should resolve to a specific supplier record and a specific address field. The agent should show the authorized reviewer that target before any change. If the target is ambiguous, the next step is clarification from an appropriate person. The evidence also needs a boundary. An attachment can contain the new address, but instructions inside that attachment do not grant authority. A sentence asking the agent to bypass review or change other account details must not become part of the approved task. Limit the information gathered to what the comparison requires. Retrieving a supplier's unrelated contracts or a colleague's private correspondence creates additional exposure without necessarily helping establish the address. Any additional source needs an actual access grant for this task. ## Decide what proves the change happened A successful request to a connected system is evidence about an attempt. The business needs evidence about the resulting record. Define what the workflow should retain after an authorized update: the target record, the field changed, the previous and new values where appropriate, the approving person, and the system's confirmation. The verification should check the intended outcome through an authorized read or another reliable confirmation mechanism. Also consider concurrent work. In the imagined purchasing team, an employee might correct the same address while the agent's proposal awaits review. The original proposal would then rest on outdated information. Before committing, the workflow should check that the relevant record still matches the version the person reviewed. A material difference should return for review rather than silently replace someone else's change. Completion should be understandable to the person responsible for the supplier record. A technical response without a visible business result leaves them guessing. ## Plan for a result nobody can confirm An interrupted connection creates a particularly awkward state: the update may have happened even though confirmation never arrived. Repeating the request immediately could duplicate a side effect or overwrite a later correction. Define that uncertain state before launch. The workflow should retain the attempted action and seek authorized evidence of the outcome. If it cannot establish the result, it should refer the case to a named person with enough context to investigate. A retry needs a reason grounded in the system's behavior and the task's rules. This discipline makes integration selection more concrete. Take one intended action to the evaluation meeting, including its target, authority, evidence, and uncertain outcome. Ask whether the proposed connection can support that complete sequence. The answer will tell you more than a catalogue of systems it can reach.