Mak Sò

Posted on Nov 23

Don Quixote Of Orchestration: Building For Problems No One Sees Yet

#programming #ai #opensource #resources

I think I have a strange "talent" that is both a gift and a curse. I tend to see certain problems very early. I see the cracks long before they become visible to everyone else. With AI this has always been about one thing: the need to orchestrate cognition instead of trying to babysit a single model with clever prompts and brittle guardrails.

While most of the field is still obsessed with "the right system prompt" and endless tweaks around one big LLM, I have spent months building something very different: OrKa, a modular cognition layer that makes AI reasoning observable, traceable, and deterministic enough to be trusted. It routes. It scores. It logs every decision. It treats reasoning as a graph, not as a black box.

And this is where the frustration starts.

A small group of people see it and tell me: keep going, this is important for the field, not just for a single app.

The rest look at me like I am Don Quixote fighting windmills.

They do not say it with bad intentions. From their point of view, I am overengineering. I am solving "future problems". I am worrying about stability, traceability, and deterministic routing in a world that is still happy to ship yet another wrapper around an LLM and call it innovation.

I understand them. I also know they are wrong. And holding both of these truths at the same time is exactly what hurts.

Two types of feedback

Over the last months, working on OrKa has generated two very different types of reactions.

1. The "this matters for the field" people

These are usually builders. They may not use my stack directly, but when they see the ideas, something clicks.

They say things like:

"This is how AI infra will have to look once people get serious about safety and traceability."
"You are basically building the cognitive runtime that everyone will need in a few years."
"The fact that you can replay the entire reasoning trace is not a feature, it is a requirement."

They understand that once AI leaves the toy phase and enters regulated environments, ad hoc prompts are not going to survive. You cannot sell "trust me, it works" to a hospital, a bank, or a court. You need to show how the system decided what it decided.

You need:

Structured orchestration instead of spaghetti prompts.
Deterministic routing instead of hidden internal magic.
Memory with decay and scope instead of infinite context stuffing.
Logs that can be audited, replayed, and reasoned about by humans.

These people are a minority, but they keep me sane. They do not think I am crazy. They think I am early.

2. The "Don Quixote" people

The second group also gives honest feedback. They see what I am doing. They are not stupid. They simply live in a different time horizon.

For them, the problem is not:

"How do we guarantee that a reasoning chain is reproducible?" It is:
"How do we get something that somewhat works in production this month?"

From that perspective, my work looks like a distraction.

Why build a router agent with thresholds and confidence distributions when you can just add another if into the code and ship? Why define a full YAML cognition graph when you can throw yet another prompt on top of the pile and move on? Why build a memory model with decay when you can just increase the max tokens?

From their point of view, I am the guy who insists on drawing a full map of the territory while everyone else is still happy following a GPS that sometimes teleports them into a lake. If you are trying to hit quarterly goals, the lake is a "future problem".

This is where the emotional friction really shows up.

The emotional cost of seeing problems early

People talk about technical debt in code. They rarely talk about cognitive debt in teams.

When you see orchestration issues early, you also see the debt building up:

every custom prompt written for a single client
every undocumented "magic" behavior inside a model
every one-off hack that no one remembers six months later
every missing log that makes a failure impossible to reproduce

You see it compounding. You know that at some point it will collapse. And you know that when it collapses, someone will say "we should have done this properly from the start".

You want to prevent that moment.

But preventing a future problem has no visible reward. If the disaster never happens, nobody sees the fire that you silently avoided. You just look like the paranoid one who was "too negative" or "too theoretical".

And this is what makes it painful.

I am not frustrated because I am not understood technically. I am frustrated because the incentive structure of the current AI bubble rewards speed and spectacle over depth and stability.

As long as the market pays for shiny demos and not for traceable cognition, you will always look like Don Quixote if you spend your nights building an orchestration engine.

Why I still keep going

I could stop. It would free a lot of mental space. I could join the game of fast features and short lived hacks. I could accept the idea that "this is just how things are done" and enjoy a simpler life.

But then I look at what is actually happening.

Models hallucinate and nobody can explain why.
Outputs change from one day to another because a provider updated something upstream.
Teams re-implement the same pattern twenty times because there is no shared cognitive layer.
Regulated industries look at all this and simply cannot trust it.

And I cannot unsee it.

I cannot accept a future where AI systems make high impact decisions and no one can replay the chain of reasoning that led to them. I cannot accept that all the intelligence is trapped inside an opaque black box that we "talk to" but never truly understand.

So I keep going, knowing that:

I am building for a market that is not fully here yet.
The majority will keep thinking I am exaggerating.
A tiny fraction will quietly see the same horizon and nod.

Honestly, that fraction is enough for me.

Orchestration is not a buzzword

Right now "orchestration" is often used as a fancy name for "we glued some tools and prompts with a framework".

That is not what I mean.

For me, orchestration is:

A graph of agents and service nodes, not a linear chain of calls.
Routing decisions that are explicit, inspectable, and driven by confidence, thresholds, and memory.
A memory model that treats forgetting as a feature, not a bug.
A log of every step, with timestamps, inputs, outputs, and metrics.
The ability to replay any execution and understand where everything came from.

This is what I am trying to encode in OrKa. It is not a wrapper. It is not a prompt factory. It is a cognitive execution layer that sits between your models and your products, making reasoning something you can reason about.

That is why it feels "too early". Because most people are still convinced that the real magic is just "a better prompt".

Living with the Don Quixote label

So how do I live with this tension without burning out completely?

A few rules I try to follow:

Keep one foot in the present.

I still ship pragmatic things. I still write simple code. Not everything must be a research project. The key is to have a bridge between today's needs and tomorrow's structure.
Turn frustration into artifacts.

Every time I get frustrated, I try to turn it into something that exists: a benchmark, a repo, a trace visualizer, a blog post, a talk. Code and data are harder to argue with than opinions.
Listen carefully, but not literally.

When people say "you are overthinking this", I translate it to "I do not feel the pain you are describing yet". That is valid. It does not mean the pain is imaginary. It means our timelines differ.
Stay honest about your motives.

If I was doing this only for external validation, I would have stopped a long time ago. I do it because the question "how do we make AI reasoning explainable and deterministic" does not let me sleep. That is enough of a reason.
Accept that the gap will never fully close.

If you are wired to see certain classes of problems early, the gap will always be there. The field will move, you will move, and the distance will shrink a bit, but it will never be zero. The goal is not to be perfectly aligned with the mainstream. The goal is to be useful when the mainstream finally hits the wall you saw years before.

For anyone else who feels like this

Maybe you are also building something that feels "too early". Maybe your colleagues roll their eyes when you bring up long term stability. Maybe you also feel like you are speaking from a different timeline.

Here is the only thing I can say with certainty: if you see the problem clearly, it is better that you exist.

The world already has enough people who are happy to ignore the cracks. The ones who cannot unsee them are the ones who eventually create the tools that everyone will later call "obvious".

Until then, enjoy your windmills. Sharpen your lance. Log your traces. Someone has to map this territory for real.

And if one day the rest of the field wakes up and says "of course we need orchestration and traceability, this is basic", I will happily accept my fate:
I was just building basic things a bit too early.