Every automation we build at Otimiz follows one rule I will not bend, even when skipping it would be faster: the AI extracts and drafts, and deterministic logic (a Switch node, a Code node, a plain if-statement) makes the actual decision. AI is genuinely excellent at reading a messy PDF or a screenshot and pulling structured information out of it. It is a bad choice for deciding what happens to that information next. This isn't a theoretical position. It's the rule behind every client system described below, and it's the line that keeps an AI-touching automation auditable instead of a black box.
Key takeaways
- AI extracts and drafts. Deterministic logic (Switch nodes, Code nodes, plain conditionals) routes and decides.
- The reason is auditability: you can point at the exact line of logic that made a routing decision, replay it, and know it will do the same thing next time.
- AI earns its place reading inconsistent formats and drafting first-pass text, scores or summaries for a person or a rule to act on.
- In every client system described here, the AI's output feeds a rule, a threshold or a human review gate. It never fires the action itself.
The rule, stated plainly
Let the model extract. Let logic decide. That's the entire rule, and the reason it's short is that it has to survive contact with a deadline. The moment you're under pressure to ship, "just let the AI figure out the routing too" is the tempting shortcut, and it's the one that turns an automation into something nobody can explain six months later.
Concretely, in every workflow we build: a language model reads something unstructured (a document, an email, a form response) and turns it into structured fields, a score, or a draft of text. What happens with that output, which folder it lands in, whether it gets approved or held for review, which team gets notified, is decided by conventional logic sitting downstream of the model. A Switch node checking a threshold. A Code node applying a rule you could write on a whiteboard. Not a second prompt asking the model to "decide what to do with this."
Why this matters: auditability, cost, and failure modes
Auditability. When a routing decision is made by a Switch node comparing a number to a threshold, you can point at the exact condition that fired and know it will fire the same way on the same input tomorrow. When a routing decision is made by asking a model what should happen, you get a plausible answer that might differ on a rerun, and there is no line of code to point at when a client asks why a record went somewhere unexpected. For anything touching money, compliance or a client relationship, that difference is not academic.
Cost. Every extra round-trip to a language model costs money and adds latency. If your logic can be expressed as a comparison or a lookup, running it through a model is paying for a slower, less predictable version of an if-statement.
Failure modes. A model that misreads a number fails silently and confidently: it doesn't raise an exception, it produces a wrong answer that looks exactly like a right one. Deterministic logic fails loudly, the way software is supposed to. When the extraction step is wrong, you want the outcome to be "this record got flagged for review," not "this record got approved because the model was confident about the wrong number."
AI is brilliant at reading a messy document and pulling out a name and a figure. It's a terrible choice for deciding where that record goes next. Let the model extract. Let plain logic decide.
Where AI genuinely earns its place
None of this is an argument against using AI. It's an argument for using it where it's the best tool, which is reading things that don't have a fixed structure.
- Reading inconsistent formats. One vendor reporting pipeline we built ingests performance data arriving as Excel workbooks, CSV exports, PDF screenshots and even ZIP folders of billboard photos, from around 20 vendors who never agreed on a layout. Gemini Vision reads the images and screenshots, and extraction turns each vendor's layout into one common structured shape.
- Scoring against known criteria. In a recruitment pipeline we built, each incoming CV is parsed and scored against the role's must-have criteria by a model. That handles about 70% of first-pass screening before a recruiter opens a file, and cut average time from application to shortlist from five days to about 24 hours.
- Drafting text that a person or a rule will act on. For a media agency with dashboards for more than 26 clients, a model drafts the performance commentary per client and per dashboard section. The output is stored as structured data, not published directly, and the dashboard looks up the right narrative for whatever date range a viewer selects.
In every one of those, the model's job stops at an extraction, a score or a draft. What happens next, whether a vendor record is merged or quarantined, whether a candidate lands on a shortlist, which stored narrative a dashboard shows, is decided by rules and lookups after the model, not by the model itself.
How the split holds up under real conditions
The vendor pipeline is the clearest example because it has an explicit safety valve on the rule side. After the model extracts a file's fields, deterministic logic de-duplicates, matches campaign names against a canonical list, and validates the record. The pipeline also scores its own confidence, and anything below a threshold is routed to a quarantine path for a person to check rather than merged into the warehouse other reports are built on. The rule decides what counts as uncertain enough to check. The model never gets to wave a record through on its own say-so.
The recruitment pipeline follows the same shape at a smaller scale: a model reads and scores, the routing that turns a scored CV into a shortlist entry is deterministic, and a recruiter still makes the hiring judgment on the shortlist the system hands them. The model compresses the reading time. It never makes the call.
How to design the split in your own system
If you're deciding where to draw this line, three questions do most of the work:
- Is the output judged against a rule, or is it a judgment call? "Is this figure above the reorder threshold" is a rule. "Is this the right candidate to hire" is a judgment call. Rules stay deterministic. Judgment calls go to a person, informed by whatever the model extracted or drafted.
- Can you write the routing logic on a whiteboard? If yes, write it as a Switch node or a Code step, not a second AI call. Reaching for a model to do a conditional's job is slower, costs more, and is harder to debug.
- What happens if the model is confidently wrong? If the answer is "a low-confidence record gets flagged instead of published," you designed it correctly. If the answer is "nobody would notice," that's the gap to close, usually with a confidence threshold and a quarantine path like the one above.
This is also the architecture question underneath most of what people mean by "AI agent development": not whether a model can technically make a decision, but whether the system is designed so a wrong extraction fails safely instead of invisibly. It's the conversation our AI agents and chatbots service exists to have, and the same principle is behind keeping a person in the loop, covered in full in how to design a human-in-the-loop automation.
