← Writing

What Breaks When You Actually Try to Build This

A lot of ideas in AI look straightforward until you try to build them. The failures aren't model failures. They're system failures, and they show up in specific, concrete ways.


A lot of ideas in AI look straightforward until you try to build them.

Systems that carry context. Multi-step workflows. Something that stays with a decision as it evolves.

At a high level, it all makes sense.

In practice, things break in ways that are not obvious at the start.

The first thing that breaks is context

It is easy to say a system should remember.

It is much harder to decide what that actually means.

What should persist across steps? What should be updated? What should be ignored?

If you keep too little, the system resets and loses continuity.

If you keep too much, the system becomes inconsistent. Old assumptions leak into new decisions. Outdated context gets treated as current.

The system doesn't fail loudly.

It drifts.

The second thing that breaks is consistency

Even when the model behaves well in isolation, it does not behave identically across steps.

Small differences accumulate.

A slightly different interpretation of the same input. A tool result that changes the framing. A shift in how the system weighs one constraint over another.

Over multiple steps, these differences compound.

What starts as a coherent plan becomes harder to reason about.

Tool use helps, but introduces new failure modes

Connecting models to real data and services is necessary.

Static answers are not enough.

But once you introduce tools, the system is no longer just generating outputs. It is making decisions about which tool to call, when to call it, and how to interpret the result.

Tools don't behave like models.

They fail. They return incomplete data. They change behavior over time.

Now the system has to handle not just uncertainty in language, but uncertainty in the underlying systems it depends on.

State is not a single thing

One of the more subtle issues is that state is not one layer.

There is user preference: what someone generally cares about. There is session context: what is true right now. There is decision state: what has already been chosen.

Treating these as the same creates problems.

If everything is merged, the system loses clarity. If everything is separated, the system loses continuity.

Getting this balance right is not obvious, and it affects every part of the system.

The system doesn't know what matters

Models can process a lot of information.

They are less reliable at knowing what should be prioritized.

In real decisions, not all constraints are equal. Some are hard limits. Some are preferences. Some only matter in specific situations.

If the system treats everything the same, it produces outputs that look reasonable but don't actually reflect the decision.

You need structure around what matters.

Not just more data.

Evaluation becomes unclear very quickly

It is not obvious what correct looks like.

If a plan changes halfway through, was the original wrong? If a user overrides a suggestion, is that a failure or expected behavior? If the outcome is good but the path was inefficient, how do you measure that?

Simple metrics stop being useful.

You have to evaluate the system across time, not just at a single step.

The temptation to over-correct

Once these issues show up, the instinct is to add control.

More rules. More constraints. More explicit logic.

Sometimes that helps.

Often it creates a different problem. The system becomes rigid again. You end up rebuilding the same brittle pipelines you were trying to move away from.

What this looks like in practice

In Voyami, these problems show up in very concrete ways.

A user starts planning a trip with a rough idea. They refine it over time. Dates change. Preferences evolve. New constraints appear.

If the system doesn't manage context correctly, it either forgets what mattered earlier, or holds on to things that are no longer relevant.

Both lead to a poor experience.

If tool interactions are not handled carefully, you get outdated availability, conflicting options, recommendations that don't reflect the latest state.

None of these are model failures.

They are system failures.

What this changes

Building systems like this is less about making the model smarter.

And more about deciding what the system should remember, what it should recompute, what it should trust, and what it should verify.

Those decisions shape the behavior far more than model choice.

Why this matters

From the outside, it is easy to assume that once models are capable enough, the rest is straightforward.

In practice, the opposite is true.

The more capable the model, the more surface area the system has. More flexibility. More edge cases. More ways for things to go wrong subtly.

The challenge is not just to make the system work.

It is to make it hold together over time.

That is where most of the real work is.