The route from model call to enterprise action

An enterprise AI action begins with a model output but becomes real only after application code, policy checks, credentials, APIs and domain systems carry it to a commit point. The enterprise AI action execution path therefore has intermediate states that matter just as much as the model’s original decision.

At 11:18, a customer asks an order-support assistant to change the delivery address for order ORD-74219. The order has not shipped, and the new address is in the same country. The assistant decides that the request can be handled without escalation and produces a structured tool request:

• update_delivery_address
• order_id: ORD-74219
• new_address: …

The model has finished its part, but nothing in the order-management system has changed yet.

Application code still has to decide whether the requested function exists, whether the arguments are acceptable, whether this customer can modify this order, whether the order remains editable, which identity will invoke the order API and what response counts as successful.

The order service may then begin another workflow: update the order record, recalculate delivery eligibility, notify fulfillment and return a new order version. Only somewhere inside that downstream path does the address become business state.

Calling all of this a “tool call” compresses several distinct transitions into one phrase. For production systems, those transitions need to remain visible.

A function call is an execution request, not the business action itself

Current function-calling architectures make this separation unusually clear.

Google’s function-calling documentation describes function calling as a process in which the model determines that a tool is needed and produces structured data identifying the function and its arguments. The application then executes that tool and can return the result to the model. Google describes the model as suggesting the function call.

Microsoft Foundry uses a similar pattern. The model can request a function call, but the application executes the function and submits its output back to the agent. Microsoft also advises validating and sanitizing tool arguments and applying least privilege to the identity used for execution.

Amazon Bedrock exposes more than one execution arrangement. An action group can pass the proposed operation into Lambda-based business logic, or it can use RETURN_CONTROL, giving the application the predicted action and parameters so the application can decide how to handle the invocation.

The model produces an action proposal in a machine-readable form. The execution environment determines what happens to it.

For ORD-74219, update_delivery_address is therefore the beginning of an execution path, not proof that an address was changed.

The tool schema defines what the model can ask for

Before an action can travel anywhere, the model needs a vocabulary for expressing it.

A function definition usually supplies a name, description and parameter schema. Bedrock action groups can be defined with function details or an OpenAPI schema. Microsoft Foundry similarly requires function names, parameters and descriptions so the model knows what it can request.

For the address-change tool, the schema might permit:

• order_id
• street
• city
• postal_code
• country

It can establish that required fields are present and that values conform to the expected structure. It cannot determine whether ORD-74219 belongs to this customer, whether the order remains editable, or whether changing the address after fraud screening requires another review.

The execution layer therefore needs to distinguish between well-formed arguments and an action that is currently permissible.

Microsoft’s Foundry guidance recommends validating arguments and using stronger schema enforcement. For consequential actions, Google also recommends validating a proposed function invocation with the user before execution.

In an enterprise system, that confirmation can sit alongside business rules, authorization and domain validation rather than substituting for them.

Authorization belongs between intention and execution

Suppose the customer confirms the new address. The application still has another question to resolve:

Under whose authority will the change occur?

The model does not need the order-management API secret in its context. The execution component does.

That component might run under a workload identity permitted to update delivery information but unable to alter payment details or issue refunds. Its entitlement can be narrower than the human support representative’s overall application access.

Microsoft recommends least privilege for the identity used to execute Foundry functions. AWS likewise requires the appropriate resource-based permissions when Bedrock agents invoke Lambda-backed action groups.

The model may therefore be allowed to request update_delivery_address while the executor must independently possess authority to invoke the relevant service.

The target system can then apply its own authorization and business-rule checks before changing any state. A tool definition tells the model what operation exists. It should not become the entire permission model for that operation.

The target system owns the commit boundary

At 11:18:04, the executor sends the request to the order-management API.

The API receives:

• order: ORD-74219
• requested address: new address
• requesting workload: order-support-agent
• operation: update delivery address

The service checks the current order state. Perhaps the order is still OPEN_FOR_CHANGE. It normalizes the address, checks whether the shipping product remains valid, updates the order record and advances its version from 37 to 38.

At that write, the proposed address change becomes an enterprise fact.

The execution path can now be described more precisely:

proposed → validated → authorized → submitted → accepted → committed → propagated

At the point of proposal, the model has selected an operation. After validation, the arguments are acceptable. After authorization, the caller has permission to attempt it.

Submission means the request has crossed into the target service. Acceptance means that service has agreed to process it. Commit means authoritative business state has changed, while propagation means dependent systems have received the new state.

A single success flag cannot express all seven.

Accepted, committed and propagated are different execution states

Enterprise actions frequently continue after the first API responds.

The order-management service might commit the new delivery address and then emit an event for the fulfillment system. A warehouse application may consume that event seconds later, and a shipping-label process may update after that.

The original invocation has crossed into systems with their own queues, workers, retries and failure states.

Microsoft’s Foundry guidance addresses long-running tools by advising applications to return status promptly and poll separately rather than assuming the entire operation can remain inside one function-call cycle.

Its Azure Functions integration provides another pattern: agent tool requests can pass through queues, with a CorrelationId used to associate the eventual result with the correct invocation.

Bedrock’s return-control flow uses an invocationId; when the application sends action results back, that identifier must correspond to the original invocation.

Those identifiers allow the execution path to remain connected even when one logical action spans several runtimes.

For ORD-74219, a failure after accepted but before committed is materially different from one that occurs after the order has committed but before fulfillment has propagated the change. The seven-state chain makes that difference explicit.

A successful API response may still be too early for the model to declare success

Imagine that the order service returns:

202 Accepted

The request exists, but that does not necessarily mean the new address is already the address from which fulfillment will ship.

If the assistant immediately tells the customer, “Your delivery address has been changed,” it has converted an intermediate execution state into a final business statement.

A better response might be:

Your address-change request has been accepted. I’m checking whether fulfillment has applied it.

The application then waits for an authoritative completion state.

This becomes especially important in durable or asynchronous workflows. Systems such as Temporal are built around executions that preserve state and continue through worker failures, outages and retries rather than treating a business process as one synchronous function invocation.

An AI application sitting above that workflow does not need every infrastructure detail in the model context. It does need enough execution state to know what result it is safe to report.

Business validation can change after the model has made its decision

The model decided at 11:18 that an address change was appropriate. By the time the order service receives the request, the order might have entered a state where changes are no longer allowed.

The application can check order status before invoking the tool, but transactional state can move between that check and the eventual write.

Domain validation should therefore occur as close as practical to the state-changing operation.

The order service still has to enforce its own rules when the command arrives. Otherwise, the execution path depends on a business-state snapshot that may already be obsolete.

The seven-state model helps here as well: validated does not mean committed. Conditions that were true earlier in the path can be checked again where the authoritative state is actually being changed.

Execution evidence needs to follow the action across boundaries

When something goes wrong with ORD-74219, the investigation should be able to reconstruct more than the final model response.

It should establish which model call proposed the change, which tool and arguments were produced, and whether customer confirmation was required and obtained.

The record should also identify which policy checks ran, which execution identity invoked the API, what request or invocation identifier was assigned and what the order service returned.

Finally, it needs to show which order version committed the new address, whether the fulfillment update completed and what final state was returned to the assistant.

This creates an execution-provenance record for the path from proposed through propagated. It answers a different question from ordinary source provenance.

Which information caused the decision?

And:

How did the decision become an action?

Both matter in a production investigation, but they describe different parts of the system.

Domain systems remain authoritative for business state

Return to ORD-74219.

The model requests update_delivery_address. The application validates the tool name and parameters, and the customer confirms the new address. Policy permits this class of change.

A narrowly scoped workload identity invokes the order-management API. The order service checks the live state and commits version 38. A fulfillment event carries the new address downstream, and the shipping system acknowledges the update.

The application correlates those results back to the original invocation. Only then does the assistant tell the customer:

The delivery address has been changed for order ORD-74219. Fulfillment has received the updated address.

The model initiated the sequence, but it did not directly edit an order record.

Model reasoning selected the action. Schemas constrained its shape. Application controls and credentials governed execution. The domain system decided whether the current state still allowed the change. Downstream workflows carried the committed result onward.

A production AI system becomes consequential when model output can enter that chain. Understanding the route matters because the final side effect is rarely produced by the model call itself.

It is produced by everything that happens after it.