When examples train the workflow instead of the model

In classical supervised machine learning, examples change the model.

A training set supplies inputs and expected outputs. An optimization process measures error and adjusts numerical parameters so future predictions move closer to the target. The learned behavior lives largely in the model's weights.

Agentic software can improve from examples in a different way. The foundation model may remain untouched while the surrounding system changes which workflow receives a request, which tools it may use, what evidence it must preserve, and how it recovers when uncertain.

The examples are not training the model. In a practical sense, they are training the workflow.

That analogy is useful as long as we do not take it too literally.

Two kinds of learning

Consider a synthetic request: “Plan a relaxed week around Kyoto.”

A model can extract the destination, infer a plausible duration, and identify the requested pace. That is model behavior. A larger product still needs to decide what happens next.

Should the request enter a brief-first planning flow? Should the traveler clarify whether Kyoto means the city or the wider region? Which route planner should run? When should place research begin? What should happen if too few suitable places can be verified?

Those decisions belong to the agentic system around the model.

Teams improve that system by studying cases and changing several kinds of behavior:

• Router policies decide which workflow owns the request.
• Structured contracts decide what each stage must produce.
• Tool policies decide which external actions are permitted.
• Validators decide which claims require deterministic evidence.
• Recovery policies decide whether to retry, clarify, repair, or preserve a partial result.
• Evaluation suites decide whether the complete behavior is acceptable.

None of those changes requires updating foundation-model weights. Yet the product has learned to handle the case differently.

Workflow selection resembles classification

A router often faces a classification problem.

Platix may receive a destination-and-duration request, a selected set of saved places, a correction to an existing route, or a question about one day. Each request concerns travel, but sending all of them through one universal planning prompt creates avoidable confusion.

A destination-first request benefits from extracting a brief and shaping a route before finding activities. A place-led request already has candidate places and needs geographic grouping, capacity allocation, and ordering. A correction to a living trip needs to preserve existing commitments and stage a revision rather than create an unrelated itinerary.

The router's prediction is therefore not the final answer. It selects the process that is most capable of producing the answer.

This makes ordinary classification concepts surprisingly helpful. We can inspect false routes, missing routes, ambiguous cases, and confidence. A confusion matrix can show whether place-led requests are being mistaken for open-ended trip creation. A per-workflow success rate can reveal that routing is correct while the selected planner is weak.

Without that separation, every bad result gets blamed on “the AI,” even when the model did exactly what the wrong workflow asked it to do.

Clarification is a form of abstention

Classifiers sometimes need an abstain option. A safe system should be able to say that the available evidence does not support a confident decision.

In travel planning, abstention becomes a useful clarification question.

If a traveler names two cities but gives no indication of whether the trip lasts four days or three weeks, route allocation may depend materially on the missing duration. Asking one focused question is better than confidently choosing an arbitrary trip length.

Abstention should remain selective. A planner that asks for every optional detail transfers all the work back to the traveler. A planner that never asks can turn reversible assumptions into false requirements.

The workflow contract therefore distinguishes what is required, what can be recommended, and what can safely remain open. Evaluation cases should test both sides: the system must ask when an essential traveler-owned decision is missing, and it must continue when a reasonable reversible assumption is available.

Structured contracts act like intermediate labels

End-to-end examples are necessary, but a final itinerary alone does not explain where a failure began.

Agentic workflows become easier to improve when they expose intermediate artifacts. A travel-planning case might have expected properties for:

• The interpreted request and its fixed constraints
• The ordered route and night allocation
• The geographic base and usable time for each day
• The candidate-place strategy
• The scheduled activities and practical details
• The final quality findings and disclosures

These are not labels for one neural network. They are contracts between stages.

If the route omits a requested city, there is little value in tuning the day planner. If the route is correct but all selected places appear on one day, the failure belongs to allocation or scheduling. If the itinerary is coherent but the browser never opens it, the planning model is not the problem at all.

Intermediate expectations give each example diagnostic power. They tell us which boundary should change.

The update step is usually human-guided

This is where the analogy with classical training has a firm limit.

Most agentic systems do not automatically calculate a gradient from a failed trip and rewrite their own workflow. Engineers inspect the evidence and decide whether to change a prompt, router, schema, policy, tool adapter, or deterministic rule.

That process is closer to test-driven system design or human-guided program synthesis than conventional model training.

The distinction matters because “the system learned” can hide accountability. Someone still needs to determine whether the expected behavior is correct, whether the new rule generalizes, and whether the change weakens another workflow.

A learned router can make part of the update process statistical. Even then, the labels, fallback behavior, tool permissions, and acceptance gates remain product decisions. Training a classifier does not eliminate the surrounding contract.

Workflow policies can overfit too

Overfitting is not exclusive to model weights.

An engineer can add a narrow keyword rule that fixes one evaluation case and misroutes ten ordinary requests. A clarification rule can become so aggressive that the planner stops making useful recommendations. A recovery path can be tuned to one route shape and fail on loops or repeated destinations.

The defense looks familiar:

• Use a varied corpus rather than one memorable failure.
• Keep a held-out set of cases that did not motivate the change.
• Test positive and negative boundaries together.
• Measure results by workflow and failure category.
• Preserve the first stochastic result instead of retrying it into a pass.
• Run product-level regression after narrower contract tests.
• Introduce routing changes in observation or limited rollout before broad activation.

A case should teach a general distinction. It should not become a disguised special case in production code.

Evaluate routing and execution separately

An end-to-end result combines at least two questions:

1. Did the system choose the right workflow? 2. Did that workflow execute well?

Those questions need separate measurements.

A router evaluation can use synthetic requests with expected strategy families and acceptable abstention behavior. It should not need live place, photo, or route calls. A workflow evaluation can then run against a frozen structured input, independent of how the request arrived there.

Finally, an end-to-end product test confirms that routing and execution still connect correctly through progress, persistence, permissions, and navigation.

This layered approach prevents a strong planner from masking weak routing and prevents a correct router from taking blame for a downstream planning defect.

What a more automated future could look like

Over time, an agentic system can use evaluation evidence more directly.

A routing model could learn from approved strategy labels. A policy optimizer could compare model tiers for different complexity classes. Historical outcomes could suggest which workflows deserve deeper review or which requests are likely to need clarification.

Those changes require care. User behavior is not automatically a quality label. A traveler opening a trip does not prove the itinerary was good, and a lack of edits does not prove it was correct. Private conversations should not become an unreviewed training corpus. Cost reduction should not quietly redefine success.

The safest progression is to begin with purpose-built synthetic cases, explicit contracts, and human-reviewed labels. Automation can then optimize within those boundaries rather than inventing its own objective from convenient telemetry.

The durable lesson

Agentic AI shifts part of learning from the model into the software architecture.

Examples still reveal error. Expectations still define desired behavior. Repeated evaluation still guards against regression and overfitting. What changes is the object being improved: sometimes it is not a matrix of weights, but a policy made of routers, tools, contracts, validators, and recovery paths.

Calling that “training the workflow” is a metaphor, but a productive one. It reminds us that improving an AI product does not always mean finding a larger model or fine-tuning the current one. Often the most important learning happens in deciding which system should act, what it is allowed to believe, and how it should recover when it is wrong.