The Model Is One Component, Not the Product

Every AI product I have shipped required the same mental shift: stop treating the model as the thing and start treating it as a step. The model generates. The workflow decides. That boundary is where most AI products either hold together or fall apart, and getting it right is the actual engineering problem in building AI products that work in production.

The model is a generator, not a decision-maker

A language model is good at producing plausible text quickly. It is not good at knowing when it is wrong. That asymmetry matters more than any benchmark score. When I built Fursa, the visa route eligibility engine, the model had to reason across immigration rules for four destination countries. The rules are specific, they change, and a wrong answer has real consequences for a real person. Letting the model answer directly was never an option. The model produced a structured candidate answer. A verification layer checked that answer against the source rules. Only a passing result reached the user. The model was one component. The workflow was the product.

This is the shift the industry has been making through 2025 and into 2026. Single-prompt RAG pipelines are giving way to multi-agent architectures, frameworks like LangGraph and LlamaIndex Workflows, stateful graphs where each node has a defined responsibility. The model does not own the outcome. The graph does.

Structured outputs are a contract, not a convenience

Native structured outputs changed how I think about model integration. When a model returns a typed object rather than a prose string, the downstream code can treat it like any other function call. You validate it, route on its fields, pass it to the next step. The model becomes composable.

I used this pattern in Job Hunter, the daily job board and outreach engine. The system crawls over 185 career pages, extracts job records, and then personalises outreach. Each extraction step returns a structured object. If a field is missing or malformed, the pipeline flags it before it reaches the personalisation stage. The model never touches the outreach copy until the job record is clean. That sequencing is not clever. It is just engineering discipline applied to a probabilistic component.

The practical rule I follow: any model output that feeds another automated step must be typed and validated. Prose output is for the human at the end of the chain, not for the machine in the middle of it.

Human approval is not a workaround, it is an architectural gate

There is a pattern I keep returning to, which I wrote about in the custody chain notes: every consequential action in an agentic workflow should pass through a human approval gate before it executes. This is not about distrust of the model. It is about accountability. When a system acts on behalf of a user, that user needs a moment to confirm the action is what they intended.

ProPost AI generates 365 draft posts per user per year. The model produces the drafts. The user reviews and approves each one before it publishes. That gate is not a friction point. It is the product. Users trust the output more because they touched it. The approval step also generates signal: which drafts get accepted, which get edited, which get discarded. That signal feeds the next iteration.

In fintech the stakes are higher and the gates are more formal. The financial services platform I built handles transaction flows where a misrouted instruction is a compliance event, not just a bug. Every automated decision in that system has an audit trail. The model-assisted steps are logged with their inputs, outputs, and the human action that followed. That log is not optional. It is what makes the system auditable, and auditability is what makes it deployable in a regulated context.

Verification is not post-processing, it is a first-class step

Most teams I have seen treat verification as something you bolt on after the model is working. That is the wrong order. Verification should be designed before the model is integrated, because the model's role depends on what can be checked.

The question to ask first is: what does a correct output look like, and can I test for it programmatically? If the answer is yes, you can gate on it. If the answer is no, you need a human in the loop or you need to rethink the task. Some tasks are not suitable for full automation at any quality level. Recognising that early saves a lot of rework.

For OptimalTax, the automated tax return system, correctness was measurable. Tax calculations either match the rules or they do not. The system reached 99% calculation accuracy because the verification layer ran every output against the statutory rules before surfacing a result. The model accelerated extraction and interpretation. The rules engine confirmed the answer. Neither component alone would have been sufficient.

Composability over monoliths

A monolithic prompt that tries to do everything, retrieve context, reason about it, format the answer, and apply business rules, is fragile. Change the retrieval and the reasoning breaks. Change the formatting and the rules break. Decomposing the workflow into discrete steps with typed interfaces between them makes each step testable and replaceable independently.

This is standard software engineering. The fact that one of the components is a language model does not change the principle. A model node in a graph should have a single responsibility, a defined input schema, and a defined output schema. If it has more than one responsibility, split it.

I apply this across every AI product I build. The graphs get more complex as the product matures, but the individual nodes stay narrow. A narrow node is easy to monitor, easy to swap for a better model when one becomes available, and easy to explain to a non-technical stakeholder who needs to understand why the system made a decision.

Where to go from here

These principles did not come from reading about AI. They came from shipping systems where a wrong answer had a cost: a rejected visa application, a misfiled tax return, a compliance breach. The constraint was the teacher.

If you are building an AI product and the workflow feels fragile, the problem is usually architectural. The model is probably doing too much. If you want to see how these patterns play out across different sectors and constraints, the full case study record is at /work. If you want to talk through the architecture of something you are building, start a conversation with Kadon.