Use code for the routine. Save AI agents for the exceptions

The idea behind the workflow

Tehilla Broder shared a mental model for orchestrating agentic workflows. In my LinkedIn post about Broder's workflow model, I described why it felt close to how we analyse AI-human conversations at Aiso: leave agentic analysis to the weirdest cases and use deterministic or local algorithms wherever feasible.

The practical distinction is between a task with a known procedure and a task that needs the system to decide what to investigate next. Counting validated records has a known procedure. Resolving a conversation that changes topic several times may need interpretation and additional checks.

A model call is not automatically an agent. A fixed prompt that returns intent labels in a defined schema can be one bounded step in a workflow. An agent chooses follow-up actions or tools. Give that extra freedom to cases that need it.

Keep repeatable work in code

Parsing a supported export format, checking required fields, preserving message order and calculating totals do not need an agent to invent a procedure each time. Write the procedure once and test it against representative records.

An LLM can help build that code. The runtime can still be deterministic. Code written with model assistance and a model making decisions during every run are different engineering choices.

Local processing also does not necessarily mean deterministic processing. A local semantic model may make errors. Choose the method for each task, then record how it behaves and where it fails.

Use models where the conversation needs interpretation

A marketer wants to know what a customer is trying to buy, which constraints shape the choice and why a brand enters or leaves the shortlist. Those signals are not always explicit in one sentence.

A person may begin with a broad request, add a budget later and reject an option because of a requirement mentioned several turns earlier. Our article on how request state evolves across AI conversationsexplains why the session matters.

Use bounded extraction for that meaning: defined fields, allowed labels, evidence turn identifiers and an explicit unknown value. Validate the returned structure with code. Keep the source evidence alongside each interpretation so a reviewer can inspect the claim.

Define what earns an agent investigation

Route a record for investigation when its evidence conflicts, it does not fit the current categories or the extraction fails a meaningful validation rule. A model's self-reported confidence alone is a weak routing rule. Check it against reviewed examples before relying on it.

Give the agent a narrow question, access to the relevant turns and a limited set of tools. Set a budget for calls or time. Require a structured result with evidence, or an unresolved status when the case cannot be settled.

For example, a customer asks for a hotel near a conference, then discusses dinner and returns to accommodation with an accessibility requirement. The investigation should determine which turns belong to the hotel decision and which constraints remain active. It should not turn the dinner request into another hotel purchase.

This is an illustration, not a measured client result. The useful output is a decision episode with traceable evidence. A polished summary alone cannot tell you whether the classification was right.

Validate the result before counting it

Check that evidence identifiers exist, labels belong to the schema and duplicate records do not inflate totals. Review a sample of ordinary cases as well as the exceptions. A flawed routine extractor can send confident mistakes down the normal path.

Keep a user request, an assistant recommendation, a visible citation and a reported purchase as separate fields. They answer different marketing questions. A recommendation does not establish that a sale happened.

Once records pass the checks, calculate aggregates with code. Include the unresolved count and denominator in the report. That makes it possible to distinguish a change in customer behaviour from a change in the extraction method.

Measure the tradeoff on your own workload

This design aims to reduce unnecessary model work and make the processing path easier to inspect. It does not guarantee speed, accuracy or lower cost. Compare it with your current workflow on the same reviewed examples.

• Track cost and processing time per conversation.
• Measure errors on ordinary cases and unusual cases separately.
• Record the share routed to investigation and the share left unresolved.
• Version the prompts, models, schemas and code used for each run.

Move repeated exceptions into the routine path once you have a reliable rule or a tested extractor for them. The agent becomes most useful at the boundary of what the system already knows how to handle.

What marketers get from this approach

You need useful findings you can trace back to real conversations: buyer needs, comparison criteria, objections and recommendation context. A selective workflow gives each of those findings a clearer route from source evidence to report.

Start with a repeatable path. Add bounded interpretation where language requires it. Send exceptions to agents with a clear investigation brief. Keep validation and reporting under your control.

Source and credit

This article expands Benjamin Tannenbaum's LinkedIn commentary, supplied as a screenshot, which credits Tehilla Broder for the mental model. The architecture and hotel example here are Aiso commentary and illustrations. They are not a reproduction of Broder's original post or evidence of measured performance gains.