Conditional Task Logic for Agent Jobs That Depend on Earlier Results

Agents get described as autonomous and adaptive, able to read a situation and respond to it. An agent job without the right conditional logic rarely crashes; instead it finishes. It returns an answer, logs a success, and moves on, and the answer is wrong. That is the harder failure to catch, because nothing in the system flags it. A workflow that fails loudly gets fixed the same day. A workflow that completes quietly with the wrong result can run for weeks before anyone notices the pattern.

Traditional workflow automation runs on a fixed script: trigger, condition, action. An agentic workflow is supposed to do something different: read what the last step found and decide what comes next. Skipping that step leaves the agent with no way to know when it's guessing.

The failure modes that appear when conditional logic is missing are specific, and they repeat. None of these are edge cases. They are the default outcome of skipping the design work this article is about.

The three control structures that underlie all conditional agent logic

Every pattern of conditional logic in an agent workflow reduces to a combination of three primitives: conditionals, loops, and branching. Confusing them is the most common source of bad design choices, because each one solves a different problem and fails in a different way.

A conditional evaluates one or more conditions and sends execution down exactly one path. The clearest example is a ticket urgency check: high urgency escalates to a human, medium urgency attempts automated resolution, low urgency gets queued for batch processing. One input, one evaluation, one path taken.

A loop repeats an operation until a condition is met, and it comes in two forms that behave very differently. A conditional loop keeps going until it hits success, a maximum attempt count, or a timeout. The retry-on-API-failure pattern lives here, and the risk lives here too: without a hard exit condition, a conditional loop becomes an infinite loop.

Branching, sometimes called fan-out/fan-in, spawns multiple parallel paths and brings the results back together afterward. Branching buys speed, but it introduces its own problems: race conditions between the parallel paths, and the question of what happens when one branch fails while the others succeed.

Deterministic routing: the right default for any condition you can write in code

Deterministic routing is the first pattern to name, underused because practitioners tend to reach for an LLM first even when a simpler rule would work. If a condition can be expressed as a rule, a regex match, a field value, a threshold check, deterministic routing is the correct and cheaper choice. Using an LLM to make that decision is the most expensive way to pick between options that were already knowable in advance.

Deterministic routing evaluates structured inputs against logic that was written ahead of time. An IF node checks whether a pull request failed its tests. A regex match identifies whether an email came from a known vendor domain. A threshold check routes a transaction above a certain risk score to human review. None of these decisions require interpretation. They require a rule, and the rule either matches or it doesn't.

The strongest case for this pattern in production is the audit trail it produces. Because the branch logic lives in code, every decision is reproducible, debuggable, and loggable without a single inference call. A governance reviewer can read the code and know why a given input went down a given path, with no ambiguity about what the system was thinking, because it wasn't thinking; it was following a rule.

The obvious objection is that rules break on inputs nobody anticipated: a malformed email, an ambiguous field, an edge case the rule set never covered. The fix is not to throw out deterministic routing. The fix is to pair it with a fallback branch that sends unmatched inputs to LLM classification or human triage, instead of letting them fall through to a silent default.

Composio's Tool Router shows this pattern already embedded in the tools practitioners use, often without anyone naming it as such. When an agent says "send an email," the Router decides whether to use Gmail, Outlook, or SMTP based on the user's authenticated connections. There's no conditional logic written into the agent's code for that decision, and no LLM call either. It's a dispatch rule, applied automatically.

Deterministic routing is the baseline every other pattern in this article should be measured against. The other three patterns earn their place only where a rule genuinely can't cover the case, starting with inputs too ambiguous to reduce to a rule.

LLM-as-router: classifying genuinely ambiguous inputs, with a confidence gate

LLM-as-router earns its place in one specific situation: the input is unstructured or genuinely ambiguous, and no rule set can classify it reliably. It is not a general upgrade to deterministic routing, and treating it as one is how a job ends up slower, more expensive, and harder to audit than it needs to be.

The pattern works like this: the agent sends the input to an LLM classifier, which returns a label and a confidence score. High confidence proceeds down the appropriate branch. Low confidence routes to a human for triage.

A regex can't classify any of these reliably, and this is exactly where an LLM's ability to interpret intent does real work.

The confidence gate is what separates a production-grade router from a demo. Routing anything below threshold to human triage is the correct behavior, and skipping that step is how LLM-as-router introduces the exact silent misfires this article opened with.

There's a governance cost that comes with this pattern that deterministic routing doesn't carry. Audit logs need to capture the model, the prompt, and the confidence score at the moment of decision, not just the final label.

Some routing decisions can't be made from the classifier's judgment of the input alone, because the information that matters hasn't been fetched yet. That's the case the next pattern handles.

Retrieval-then-route: making routing decisions that depend on fetched context

Some decisions depend on context the agent doesn't have yet. The agent has to fetch it first, then evaluate the condition against what it found. Collapsing the fetch and the routing decision into a single step produces a misroute, or worse, a hallucinated answer built on nothing.

A coding agent deciding whether to open a GitHub issue, send a Slack alert, or escalate to a human needs one piece of information first: did the pull request already fail its tests? Skipping the retrieval step causes the conditional to evaluate the wrong thing.

Retrieval Augmented Generation (RAG) is the mechanism that makes this pattern work: by connecting an agent to external knowledge sources, RAG grounds its responses in current, verifiable information instead of whatever the model happens to remember, which cuts down on hallucination and improves factual accuracy.

The scale of integration available makes this pattern practical. Slack provides 145. An agent asking "did the PR fail tests?" has genuinely fine-grained options for both the retrieval and the response, without anyone having to hand-build each integration.

The failure mode specific to this pattern is quieter than a missed rule: the retrieval step succeeds, but it returns stale or incomplete data, and the routing decision proceeds on a false premise. That's why retrieval-then-route requires logging the retrieved context itself, not just the decision that followed it. Retrieval-then-route earns its place only when the fetched data genuinely carries the decision.

Some decisions can't be evaluated from outside. They require the agent to judge its own output and decide whether it's good enough. That judgment is the fourth pattern.

Reflection loops: letting the agent grade its own output and decide whether to retry

Reflection loops close a gap none of the other three patterns can close: evaluating the quality of the agent's own output. Without a hard iteration cap, they become the main source of runaway latency and cost in a production job.

The mechanism: after completing a task, the agent checks its own output against a criterion. Based on that check, the agent decides to accept the result, revise it, or escalate to a human. The conditional logic here runs on the agent's own output, not on an external input or a fetched fact.

Codex Goal Mode is built on this pattern. Goal Mode went GA on May 21, 2026, included in ChatGPT plans starting at $20 a month on the Plus tier, with no separate Codex-only subscription required, putting a persistent reflection-loop objective within reach of a non-enterprise budget.

Claude Code's Agent Teams run a structurally similar idea, distributed across more than one agent. Agents share a task list and message each other directly, so one agent's output becomes the evaluation input for another. That's distributed reflection across a team, rather than a single agent grading its own work in isolation.

Every loop needs a clear exit condition: success, a maximum attempt count, or a timeout. Past that cap, latency climbs and accuracy gains disappear, so the agent should escalate to a human. That cap is a governance control, not a performance tweak, and it's what makes a reflection loop auditable.

Reflection loops carry a real cost in transparency. The fix is to log the evaluation criterion and the score at every iteration, not just the final answer that gets returned.

None of these four patterns operates alone in a real production job. They compose, and how they compose is itself a design decision.

Composing the Four Patterns in a Real Agent Job

A production agent job rarely runs on one pattern. It runs on a deliberate sequence of two or more, each one handling the kind of decision it's suited for, then handing off cleanly to the next.

Consider a coding agent working through a single task end to end. It receives a natural-language task description, and LLM-as-router classifies the intent and routes it to the right toolchain. Finally, it routes the outcome based on a simple pass/fail boolean, sending the result to either a merge action or a Slack escalation, which is deterministic routing doing the final, cheapest step in the chain.

The sequencing follows a clear principle. Running an LLM classifier at a point where a rule would have worked is a cost and reliability penalty with nothing to show for it.

Multi-agent orchestration adds another layer on top of this. Pattern selection stays a live problem at scale. It recurses, one level up.

Picking the wrong category of tool for the use case is the most common reason automation projects fail, and the same failure occurs at the pattern level inside a single agent job. A reflection loop running where deterministic routing would have done the job is a more expensive agent, and a harder one to audit.

The governance requirements that conditional logic introduces in production

Conditional logic doesn't just change what an agent does next. It changes what the operator running that agent has to log, monitor, and be ready to explain to a security or compliance reviewer.

A purely deterministic workflow produces a simple audit trail, because each step executes a predefined action and the log mirrors the code line by line. Without all four pieces, a misroute becomes invisible after the fact. There's no way to reconstruct what happened.

Reflection loops need their own kind of logging, broken out by iteration. The evaluation criterion and score from each individual iteration have to be part of the permanent record.

LLM-as-router decisions carry a similar requirement, for a different reason. Because the same input can classify differently across separate runs, the log needs to capture the model, the prompt version, and the confidence score at the exact moment of decision. That's the specific governance gap a confidence gate is built to close.

Human escalation paths aren't a nice-to-have in any governed environment. Agents handling financial data, healthcare information, or anything compliance-sensitive need routing rules that send a case to a human whenever confidence drops below threshold or an error exceeds a defined risk level. That escalation path is part of the architecture itself, not a policy bolted on afterward.

None of this holds up if the infrastructure underneath it isn't sound. An agent with perfectly designed conditional logic but an execution environment that isn't isolated, encrypted, and auditable can't satisfy what enterprise buyers actually need to see. Running each customer's agent in its own persistent, encrypted sandbox is the infrastructure prerequisite that makes conditional logic auditable at scale, because it keeps agent sessions from contaminating each other and gives operators a clean, per-customer audit trail to point to.

Choosing the right pattern: a decision framework for the four cases

The choice between these four patterns isn't a matter of taste or sophistication. It follows directly from the structure of the decision the agent is facing at that particular step, and picking the wrong one carries predictable, specific costs: wasted inference spend, decisions that can't be reproduced, or loops that never terminate.

The first question to ask at any decision point is whether the routing condition can be expressed as a rule, a field value, a regex match, a threshold. And if the task requires judging the quality of an output and deciding whether to accept it, revise it, or escalate it, that's a reflection loop, built with a hard iteration cap and a full log of the evaluation criterion and score at every pass.

The rule that sits above all four cases is simple: default to deterministic routing at every decision point where it applies, and reach for the more complex patterns only where they're genuinely required. Complexity that isn't carrying real weight in the decision is just a latency, cost, and governance penalty dressed up as sophistication.

Most production agent jobs end up composing two or more of these patterns, because the decision framework applies separately at each decision point inside a job, not once for the whole job as a unit. An agent job that reliably completes is the one where every decision point got matched to the pattern it actually needed, nothing more and nothing less.