AI Is a Catalyst, Not a Cure for Optimization

Most teams I have worked with arrive at the same moment. The model is integrated, the demo looks impressive, and then production data arrives and nothing behaves the way it should. The AI-driven optimization they expected turns out to need three other things they had not built yet. I have been in that moment myself, more than once. What changed my approach was accepting that the model is not the product. It is one part of a compound system, and the other parts matter just as much.

The silver bullet assumption costs you weeks

The assumption goes like this: swap in a model, point it at the problem, watch it optimize. It is a reasonable assumption if you have only seen AI in demos. In production, it falls apart fast. The model has no memory of your domain unless you give it one. It cannot verify its own outputs unless you write the verification layer. It will drift off-task unless you constrain it with deterministic code around it.

The industry shifted on this between 2025 and 2026. The term that stuck was compound AI systems, meaning the model is one node in a pipeline that also includes structured databases, external APIs, rule-based validators, and orchestration logic. That framing is useful because it tells you where to spend your engineering time. Most of it is not on the model itself.

What I actually built instead of plugging in a model

When I built Fursa, a visa route eligibility tool, the AI component was responsible for interpreting unstructured policy language and mapping it to structured eligibility criteria. That sounds like an AI problem. It is also a data modeling problem, a rules engine problem, and a user trust problem.

The model alone would hallucinate edge cases. It would confidently produce eligibility verdicts for document combinations it had never seen. So I wrapped it. A deterministic validator checked every output against a known matrix of visa categories before anything reached the user. The AI did the interpretation work it was actually good at. The surrounding code enforced correctness.

That pattern, model plus validator plus structured data layer, is what I now treat as the baseline for any AI-driven optimization problem.

The three components that make optimization actually work

After building across fintech, public sector, and SaaS contexts, the compound system that holds up in production tends to have the same three layers.

Structured context. The model needs to know things it cannot infer from the prompt. Domain rules, user history, business constraints. This has to be engineered. It does not come from the model provider.

Deterministic guardrails. Any output that touches money, compliance, or user-facing decisions needs a rule-based check before it ships. On OptimalTax, an automated tax return platform I built for a public sector client, the AI handled classification of income types and deduction categories. Every calculation was then verified against the statutory rules in a separate layer. That separation is why the platform reached 99% tax calculation accuracy. The model was not responsible for the accuracy. The architecture was.

Feedback loops. The model needs to get better over time, and that does not happen automatically. You have to log the cases where it was wrong, categorize them, and decide whether the fix is a prompt change, a data change, or a rules change. Most teams skip this. They ship the model and move on. Six months later the outputs have drifted and no one knows why.

Where engineering effort actually goes

If you map out the work on a real AI product, the model integration is usually ten to twenty percent of the total effort. The rest is:

• —Data pipelines that feed the model clean, structured context
• —Output validation logic that catches errors before users see them
• —Monitoring and logging that makes drift visible
• —Fallback paths for when the model is wrong or unavailable
• —UX that communicates uncertainty honestly

On Job Hunter, a daily job board and outreach engine, the AI layer matched candidates to roles and drafted outreach messages. The harder engineering work was the crawler that kept the job data fresh across 185+ career pages, the deduplication logic, and the scheduling system that made sure outputs arrived at the right time for each user. The model was maybe fifteen percent of the codebase. The infrastructure around it was the product.

The constraint that makes this discipline stick

The reason most teams do not build compound systems from the start is speed. An MVP that is just a model and a UI ships in days. Adding validators, structured context layers, and feedback pipelines adds weeks. That trade-off is real and sometimes the right call.

But the teams I have seen skip the infrastructure pay for it in a specific way. They end up rebuilding the system six months later under pressure, with a user base that has already lost trust in the outputs. That rebuild costs more than the original infrastructure would have.

The discipline I try to apply is this: decide early which outputs are load-bearing. If the output drives a financial decision, a compliance action, or a user commitment, it gets the full compound treatment. If it is a suggestion the user can ignore, a lighter approach is fine. Not every AI output needs the same architecture. But you have to make that call deliberately, not by accident.

The practical starting point for your next AI feature

Before you integrate a model, write down the three things that would make this output wrong in a way that matters. Then build the layer that catches each of those failure modes before the output reaches the user. That exercise usually takes an afternoon. It will tell you more about your actual engineering requirements than any model evaluation will.

If you are building something where AI-driven optimization is central to the product, I am happy to look at the architecture with you. The full picture of what that kind of engagement looks like is on the engineering page, or you can reach out directly and describe what you are working on.