Prediction, Generation, And Action

The retailer's assistant writes a polished refund message. The customer hasn't received it, and no payment has necessarily moved. The text is an output we can observe. Sending the message and transferring money would be separate changes in the outside world. If we treat those states as interchangeable, we can mistake a convincing response for completed work.

This lesson is about prediction, generation, and action. We'll first name the kind of output or change we're discussing, then follow an action from a proposal to an observed result, and finally examine its choices, controls, and operating value. By the end, you should be able to identify what has actually happened, what remains uncertain, and what evidence is needed before continuing.

Start with prediction. A prediction estimates an unknown outcome or attribute. It can be a numerical forecast, like the retailer's estimate of thirty umbrella sales. It can be a category, such as a transaction classified as potentially fraudulent, or a probability describing an estimated chance. The form varies.

In each case, the system is estimating something rather than establishing that an external action has occurred. Generation creates content. An assistant might draft a customer email, write a summary, or produce an image for an advertisement. A generated sentence can describe an action without carrying it out. If a draft says, “Your refund has

been processed,” those words alone do not prove that a payment system processed a refund. We need evidence about the relevant external state. An action changes a state outside the prediction itself. Sending an email changes a messaging system's state. Ordering inventory submits an order to another system. Moving a robot arm changes a physical position. One product can combine prediction, generated content, and actions.

We need to distinguish the role of each step and the evidence that it worked. Return to our customer message. The assistant has generated a draft. The draft can be inspected and edited while it remains inside the application. At this point, we have observed content. We haven't established that a sending attempt occurred,

that a message was delivered, or that money changed hands. To attempt the sending action, the application can call a sending tool. A tool is a capability that an application can invoke. Examples include search, calculation, a database lookup, and submitting a transaction. Invoking a tool means requesting that capability to perform work.

What happens next depends on the capability, the request, the surrounding system, and the result. For the email, the proposed call needs details such as a recipient and message content. The details passed with a tool call are often called arguments. A model can propose the tool and supply arguments. Application code must still check that the action

is permitted and that the details make sense. The model's ability to produce a plausible proposal doesn't establish permission to carry it out. For example, a system might check whether this application is allowed to send messages for the retailer, whether the proposed recipient is the intended customer, and whether the message refers to the right order. Those are checks around the action.

A well-written email does not replace them. The task and system determine the particular checks required; here, we're identifying their role rather than implementing them. Now suppose the permitted sending request is actually submitted. That establishes an attempt. If the tool returns confirmation of delivery, a particular delivery outcome has been observed. We should record precisely what the confirmation establishes.

It doesn't automatically establish that the customer read the message, agreed with it, or received a refund. Those would require their own evidence. There is another possible result: the expected response never reaches the application. The request may have failed before the tool acted. Or the tool may have performed the action and the response may

have been lost on the way back. The action's status can therefore be unknown. Missing confirmation and confirmed failure are different observations. Keep the sequence explicit. A proposal describes a possible action. Submission starts an attempt. A relevant result can establish a particular outcome. An absent response can leave uncertainty.

Repeating a consequential action while confusing those states can create another effect, such as sending a duplicate message or making a duplicate payment. Here's a first checkpoint. The refund email exists as a draft, but no sending tool has been called. What state have we actually observed? We've observed generated content.

A sending attempt and a delivery outcome have not been established by the draft. If the text claims that a refund happened, the claim also needs separate evidence. Naming the observed state keeps us from reporting completion on the strength of fluent wording. Next, consider how a system chooses its steps. A workflow is an organized sequence,

often with predetermined steps and branches. For a routine return, a workflow might look up the order, check the applicable policy, prepare a message, and send it only when the required conditions are satisfied. A branch might route missing information for further attention instead of continuing. An agent has some ability to

select steps based on the task, its observations, and the current state. An observation is information the system receives, such as a lookup result or a tool status. For the retailer, an agent might choose to retrieve a policy, calculate a quantity, ask for a missing order number, or stop because the evidence needed to continue is unavailable.

Actual systems can combine both approaches. There may be a fixed permission check around a more flexible choice of which approved lookup to perform. The useful question is how much choice the system has, where that choice helps the task, and what limits govern it. Calling something an agent doesn't tell us those details. We need to inspect the choices

and controls in the actual system. The risks also depend on what the system can change. A mistaken draft can be corrected before publication. An email sent to an unauthorized recipient can disclose information outside the conversation. A repeated payment can create a second financial effect. An action can have consequences that editing the next response will not reverse.

Reliable tool use therefore needs permissions and checks of relevant state. Permissions specify what an action is allowed to do. State checks establish information needed to act sensibly, such as whether the intended payment has already been recorded or whether the order being handled is the correct one. The permission to perform a kind

of action does not prove that every proposed use of it is appropriate. Logs help preserve what was requested, which attempts occurred, and what results or uncertainties were observed. A log saying “request submitted” is evidence of a submission, not necessarily of successful delivery. A useful record distinguishes the attempted operation from its confirmed outcome,

so that later investigation can reconstruct what happened. Recovery is what the system does after something goes wrong or remains uncertain. It may inspect an external status, correct a draft, ask for missing information, or hand the unresolved case to an appropriate person or process. Recovery needs to fit the failure. We cannot assume that repeating a call or

changing a sentence will undo an external effect. Stop conditions matter too. The system can stop when it lacks the required permission, can't establish a necessary state, or reaches a defined limit on further attempts. A stop should preserve enough information for the next appropriate step. These controls belong in the surrounding system.

Asking the model to be careful is useful guidance, but it does not itself enforce permissions, record outcomes, or prevent duplicates. Pause and name two checks before a proposed email-sending call runs: one about permission and one about the call's arguments. A permission check could establish whether this application is allowed to send the message.

An argument check could verify the intended recipient and the relevant order or message details. Those are examples of different responsibilities. The model's proposal supplies neither proof of permission nor proof that all the details are correct. You will also encounter the Model Context Protocol, usually shortened to MCP. It provides a standard way for AI

applications to connect to context and tools. A shared protocol helps components communicate. It can work with authorization mechanisms, but a connection alone doesn't determine a user's right to a document or a payment action. Permission and trust still need to be established by the relevant system. Trust concerns whether the connected source or

capability should be relied on for this purpose. For the retailer, a connection might make a policy lookup or an action capability available to the application. That describes a route for communication. We still need to know which material this user may access, which actions are permitted, and how the application handles results. We'll study the request path and access boundaries next.

Here, keep communication, authorization, and trust as separate questions. Now consider a consequential action whose result becomes uncertain. Suppose the retailer submits a permitted supplier payment. The tool times out while the application is waiting. A timeout tells us that the expected response wasn't received within the allowed waiting period. It doesn't, by itself, tell us

whether the payment was carried out. This is the final checkpoint. A tool times out after a payment submission. Should the agent submit the payment again immediately? No. The payment may already have succeeded. Inspect its status, or use a suitable idempotency mechanism before repeating the consequential action.

The next step should be based on the actual state and the guarantees available, rather than assuming that silence means the first attempt had no effect. Idempotency means repeated equivalent requests are handled so that the intended effect is not duplicated under the mechanism's conditions. In a payment example, a suitable

service-supported mechanism can associate equivalent repeat requests with the same intended operation. That can let the system obtain a result without creating another payment under those conditions. It isn't a promise that every tool, every retry, or every different request is automatically protected. The system has to use an appropriate mechanism according to its rules.

Finally, look at the operating value of the whole process. One attempted task can consume several model calls and tool calls. Additional steps can help resolve a difficult case, but they also add resource use, waiting time, and opportunities for failure. Counting generated responses or tool invocations doesn't tell us how many tasks were actually completed successfully.

Imagine ten attempted customer-service tasks. Eight meet the defined completion criteria, and two remain unresolved. Suppose the attempts used thirty model calls and twenty tool calls altogether. Those resource counts include work on the unresolved cases. We should account for all that work while distinguishing the eight successful completions from the ten attempts.

These are illustrative counts, not performance figures for a product. A demonstration might show one agent finishing a task with impressive flexibility. That is evidence about the demonstrated case. To understand operating value, we also need evidence across the relevant workload: what completed successfully, what failed or remained unknown,

how long the work took, and what resources the attempts consumed. We'll develop cost and successful-completion measures later in this module. Return to the retailer's message. A forecast estimates an unknown quantity. A generated draft creates content. A permitted tool call can attempt an action. A relevant confirmation can establish a particular outcome,

while a missing response may leave its status uncertain. Flexible step selection can help, and system controls govern what can happen next. When you evaluate an AI product, identify the output or action, the choices the system can make, the evidence for its current state, and the controls around the next step.

Report the observed outcome precisely. Next, we'll follow one request through the interface, application, model, and supporting services, so these boundaries become part of a complete system map.