And then, roughly one commit after we increased the harnessing regarding our architectural layers, an agent took a fat slab of domain business logic and dropped it straight into our application wiring layer. While it was there, it reached past the domain and grabbed the persistence layer directly. The exact two things our RFC said, in bold letters, must never happen.

The agent had read the RFC. It could quote the RFC. It just didn’t obey the RFC.

That’s the moment we stopped writing better prompts and started writing better laws. Okay, we did not stop writing better prompts, we still do that. But if we really care about things, we now make it a law.

Non deterministic harnesses are pleas, deterministic ones are laws

The problem with non-deterministic guardrails like skills, prompt engineering, style guides, or LLM-as-judge is a shared one: each one is a probability, not a deterministic guarantee.

For a deeper dive into the differences between deterministic and non-deterministic and a look into what inspired us, check out my former colleague Birgitta Böckeler’s post on martinfowler.com or her chat with Chris Ford on the topic. But let’s start with a simplified example and get into it:

Say your markdown guideline is respected 95% of the time. On its own that sounds good. Now the agent makes forty decisions in one task where the guideline applies, and it becomes:

P(all respected) = 0.95^40 ≈ 13%

I want to give a disclaimer in the form of a quote of my colleague Matthias from his article Why non-deterministic ai agents are the ultimate doom for enterprises here:

Some may say that a good agentic system can correct its own errors, making the steps not truly independent. Others (rightly so) will tell you this is an oversimplification, and I cannot simply apply multiplicative laws of probabilities to an agentic system like a math punk. While that’s true, it just means the math gets more complicated; the fundamental problem of decaying reliability for long tasks remains. And while, indeed, work is done to make models “less stochastic” in their output, ie via Feedback Loops, grounding, planning, task decomposition, the problem is both foundational and multilayered, and it’s not solved now, nor will it ever be fully solved.

None of this means the guideline was badly written, nor that writing it was wasted effort. It’s what we were told to do: You noticed agents need guidance, and you gave it to them in the clearest form the LLM vendor tooling offered. The problem isn’t the idea or quality, it’s the medium. Anything an agent interprets will inherit the probabilistic nature, so even an excellent guideline enters the compliance product above as a factor below one. And stacking more probabilistic layers on top, for example a judge agent that itself works 90% of the time reviewing output that’s 95% compliant, can’t push that product back to one. The math is working against any non deterministic harness, no matter how well it’s written.

Additionally the harnesses shipped with the LLMs, as well as our own guidelines, constantly change. This means that at times your agent based harnessing will yield wildly different results, or stop working all together. This is akin to traditional dependency management where you need to keep up with new contracts. However with dependency management you have a) a control over the timing and b) a deterministic impact.

Even worse is that the more rules you have the less important each individual rule becomes to the agent. This is known as the “Lost in the middle problem”. (see Lost in the Middle: How Language Models Use Long Contexts) So the more time you invest into your non deterministic harness rules, the less important each one might become. This might be non problematic for small isolated tasks that only need a few of your rules, but if you want agents to implement complex features across your whole stack, this becomes a very real risk.

A deterministic check inverts this completely. A test that fails the build when a rule is broken is respected 100% of the time. On the 1st run and on the 10,000th. It doesn’t get tired, doesn’t get creative, and doesn’t decide that this particular case is surely an exception.

The agent doesn’t need to want or remember to follow the rule. It just needs to be physically unable to progress without following it.

Why Rust turned out to be an agent harness for us

At INXM we use Rust for most of our services. And we didn’t pick Rust to be fashionable. We picked it because, viewed through this lens, a strict compiler is a deterministic harness. One somebody else already spent years building.

In Rust:

• There is no implicit null. If a value can be absent, it’s an Option<T>, and the compiler forces the agent to handle both cases. No agent can “forget” a null check, because forgetting is a compile error.

• Errors are values. Result<T, E> means error handling isn’t a best practice the agent might skip under pressure; unhandled results are loud, visible, and linted.

• The compiler talks to agents like a good colleague. Rust’s error messages don’t just say what broke, they usually say how to fix it. That’s not a human luxury anymore. It’s a feedback loop. The agent proposes, the compiler rejects with a precise explanation, the agent corrects. Deterministically. Every time.

• Clippy nudges toward idiom. Instead of a markdown file saying “please prefer iterators over index loops,” a lint says it — and can fail the build if we mean it. Better yet the “Clippy” tool can usually adjust the code itself, which we added as a step before committing anything to our agents’ workflows.

In interpreted and / or weakly typed languages every one of these would have been a paragraph in our guidelines. As paragraphs, they’d each be a 0.xx factor in the compliance product above. As compiler rules, they’re 1.0.
Of course you can get similar or even higher levels of support from the tooling in other languages as well. Examples here could be Haskell or Kotlin, where most of our developers made good experiences with their strict modeling capabilities. The general rule of thumb and the main takeaway from this paragraph should be:

The more rules your compiler can statically check with high confidence, the better of a baseline harness it provides

When the language isn’t strict enough, extend it

But languages don’t ship with your architecture rules. No compiler knows that your app wiring layer may construct repositories and clients but must never contain business logic. No borrow checker knows that nothing may enter your domain layer without authorization. And that is the point. A language is general purpose, whilst your architecture rules should fit for your domain and your environment.

So we wrote the rules we cared about and were missing as code. Here at two (very simplified) examples:

Architectural layers

We built a small crate of architecture fitness tests. Deterministic checks that parse the codebase’s AST and fail the build when a structural rule is violated. Simplified, the wiring-layer rule looks like this:

#[test]
fn app_layer_only_wires() {
    let violations = analyze_crate("app")
        .functions()
        .filter(|f| {
            !f.is_constructor_call_of(&["Repository", "Client"])
                && !f.is_domain_type_construction()
        })
        .collect::<Vec<_>>();

    assert!(
        violations.is_empty(),
        "app layer must only wire dependencies and build domain types:\n{violations:#?}"
    );
}

The app layer may build repositories and clients in approved wiring files. It may construct domain types and hand them over. Anything else, like an actual call of functionality from the persistence crate, and the build goes red with a message pointing at the exact offending line.

We have similar tests demanding our domain layer does not know any of the other crates besides importing the wrapper types for authorization (see next paragraph), and all the other rules we care about in this repository.

Authorization

Our rule that any domain function needs to run in an authorized context got the same treatment, but one level deeper: we encoded it into the type system itself. Domain entry points don’t accept raw requests; they demand proof:

pub fn approve_order(
    auth: Authorized<ApproveOrderRequest>,   // can only be obtained via the auth crate
) -> Result<Approval, DomainError> {
    // ...
}

There is no way to construct an Authorized<ApproveOrderRequest> except by going through our authorization crate. An agent that tries to shortcut it doesn’t produce a subtle security bug that a judge-agent might catch on a good day. It produces code that does not compile.
Our RFCs stopped only being documents and became deterministic tests.

What actually changed

After the fitness tests landed, the agents didn’t just get caught more often. They violated the rules less.

In hindsight it makes sense. An agent in a tight loop with a deterministic harness converges fast. It writes the shortcut once, the build screams with a precise error, it learns what this codebase’s physics are. The red build is a far better teacher than the markdown file ever was, because it’s incapable of being ignored.

The practical effect: we now hand agents significantly more complex tasks with a straight face. Not because the agents got smarter, but because the blast radius of their creativity got smaller. The architecture can’t drift, the domain can’t be entered without authorization, and null can’t sneak in, no matter how the model is feeling today.

Okay that last sentence was a bit of an overstatement. We still review the code our agents spit out. And they still make mistakes we did not anticipate. But now we do what good development practices taught us to do when we encounter a bug: We write tests that prevent a regression. And it makes our experience a little better every time.

The takeaway

If there’s one thing to take away from this post, it is this:

Every rule you actually care about should be a failing build, not a paragraph.

Keep the markdown as agents and humans both benefit from context and intent. But treat textual guidelines as what they are: suggestions with a compliance probability strictly below one. The moment a rule matters, like architecture boundaries, authorization, or error handling, promote it. Into a type. Into a lint. Into a fitness test that parses your AST and says no.

Non-deterministic workers are here to stay. The trick isn’t making them promise to behave.

It’s building a world where misbehaving doesn’t compile.

As an example: in procurement the unit of work is not “one agent completing one task for Bob”. It is thousands of small, repeatable decisions and actions executed with audit trails. Agents, and Agent Swarms, can’t keep up with that. So what does?

Why Current Agent Metaphors Fail

Most implementations of Agents today rely on hierarchies (manager agents overseeing worker agents) or swarms pursuing one goal at a time. These metaphors break when we scale up. Error rates compound: each supervisory layer adds mistakes and false positives. Or worse, they create a massive token overhead for supervision and correction. Creating a negative ROI. You’d be better off hiring more interns.

The fundamental problem is treating agents as the core primitive is the wrong way to scale.

We do not need to “organize twenty agents”. Maybe a bakery can make a lot of profit with that. But we need to run 300,000+ reliable transactions. Stochastic parrots won’t scale for that.

The Right Primitive: Deterministic Transactions

The fundamental primitive must be audited, deterministic transactions. Reliable, compiled steps with clear inputs/outputs. We call this Compiled AI.

Agents need to switch roles as the scale increases. They translate user intent, route exceptions, and serve as human-interface glue.

What we want isn’t a roman legion of LLMs (a popular metaphor for organizing agents into groups), what we want is something like a steering wheel. A basic human interaction, that translates into a lot of reliable machine actions.

The Computer Science Solution: Orchestration as the Operating System

Computer science solved this decades ago through orchestration. The best metaphor for this is an operating system.

In a traditional Operating System like windows or iOS the following happens:

• Users interact with apps.

• Apps request actions from the OS.

• The OS schedules, validates, and executes millions of low-level operations reliably.

We are building the same thing for enterprise work: an Enterprise Operating System, we call it a Process Execution Engine.

• Top layer: Human users give high-level intent.

• Middle layer: The orchestrator schedules, validates, secures,and executes millions of low-level operations reliably.

• Bottom layer: Deterministic, auditable transactions (Compiled AI).

Unlike agent hierarchies, this contains errors in typed, inspectable, reversible transactions instead of letting stochastic agents supervise each other, and praying it will work next time.

How It Works

1. User expresses high-level intent.

2. Orchestrator maps it to sequences of deterministic transactions (which we call Plans).

3. System executes at massive scale with built-in controls.

4. Only true exceptions and decisions surface to the human.

If you’re “AI-pilled” you might start asking why there isn’t another AI above this? But there is no need for an “orchestrator of orchestrators”, at the highest level the problem becomes human alignment on priorities and tradeoffs.

That’s your company strategy, and needs to remain in the hands of humans.

Why Orchestration is a better metaphor

Thinking about AI this way scales cleanly to enterprise volumes. Want to to 100 tasks? Fine. How about 30 000 000? Yeah, no problem.

This maintains the enterprise governance we’ve spent decades creating in IT. It shares the same observability, and audibility you’d expect from any modern software.

It keep humans focused on the strategy and judgment, where it matters. And not on maintaining the stability of AI agents.

The future of work

We think orchestration can transform work. Every action a human wants to do becomes a reusable transaction. Tasks and processes are discovered and mapped as a side effect to people doing their normal work. And no one is left behind in “searching for documents hell” again.

The future is not autonomous agent armies. It is an Enterprise Operating System, a Process Execution Engine, that turns reliable transactions into a orchestrator of work at scale. We already know how to build this in computer science. Now we are applying it to organizations.

That is how we think AI will reshape enterprise work.

Subscribe now

You delegate the meeting notes, the follow-up, the invoice, the ticket nobody wants to touch because the description says “quick fix” and therefore definitely contains a distributed systems problem. You delegate the spreadsheet, the vendor email, the meeting where everyone already knows what will be said but the calendar required a sacrifice anyway. That is normal. Annoying, often, but normal.

So when people say that we should “delegate work to AI agents”, the sentence sounds harmless enough. Almost boring. It has the shape of a productivity sentence. It belongs on a slide next to a soft gradient and a diagram where three boxes point at another box, which is how you know civilisation has produced value.

But I do not think we are only delegating work. I think we are delegating write access and pretending it is the same thing.

That is the bit I keep getting stuck on. In the last posts I wrote about statistical approximation and Compiled-AI, I mostly circled around the question of where probabilistic systems belong. LLMs are useful. Obviously. Painfully useful, sometimes. But they are useful in a very particular way: they are good at turning messy context into plausible structure. And plausible structure is not nothing. It is often exactly what you need before something becomes software, policy, documentation, tests, mappings, migrations, or whatever ugly intermediate artifact the work requires. The trouble starts when that plausible structure stops being something we can inspect, argue about, test, and throw away, and starts touching state instead. The model is not suddenly worse there, it’s just that the mistake now has somewhere to go where it really hurts. The problem is not only approximation. It is approximation with write access.

That sentence feels close to the thing I mean.

A model saying something wrong in a chat window is one problem. A model rewriting the thing everyone will later treat as the document is another. The first one is output. The second one is state. The first one can be ignored, copied, deleted, mocked, or sent to Slack with the usual “lol”, because apparently that is how adults communicate now. The second one lives somewhere, and things that live somewhere have consequences.

I came across a recent paper called LLMs Corrupt Your Documents When You Delegate, which is a very good title because it contains almost no optimism. I appreciate that level of honesty. The paper looks at long document workflows where models are asked to keep working on an artifact over time. Not answer one question, not produce one summary, not do the little benchmark dance where everyone pretends the test set was discovered in the wild by innocent hikers. Work on it. Modify it. Continue it. Preserve some things, change other things, and keep the document coherent across time. Basically the kind of thing people mean when they say “agent”, just without the reassuring animation.

The result is not surprising in the abstract, but still ugly in the concrete: the documents degrade. Not always dramatically, which would almost be easier. It is not always the machine driving into a wall while shouting that it has successfully reached the destination. It is more like the document becomes slightly less itself. A clause moves or disappears. A definition shifts. A table survives visually but not semantically. A distractor file sneaks into the main artifact. The tone remains fine, which is very rude, because tone is the cheapest part to preserve while meaning quietly leaves through the side door.

That is the uncomfortable version of failure. The work still looks like work, so now you need to inspect it like evidence. This is something very similar to what I wrote on my private blog already: This [is one of the more dangerous properties of these systems: they fail in complete sentences.](https://matthias-kainer.de/blog/posts/llm-meet-ml-pipeline/)

And this is where I think the agent story becomes strange. We already understand this problem in normal software. A suggested patch is not the same as a merged patch. A migration plan is not the same as a migration that ran. A draft email is not the same as an email sent to 40 customers and one person who will reply-all with “thanks”. We know this. We have built entire ceremonies around this. Branches, reviews, tests, diffs, staging environments, preview environments, feature flags, canary releases, dry runs, migrations, rollbacks, audit logs, access controls, approval flows, schema checks, type checks, linting, CI pipelines, deployment gates, monitoring, alerts, traces, backups, restore drills, runbooks, incident reviews, postmortems, ownership maps, change requests, dependency locks, version pins, checksums, immutable artifacts, reproducible builds, golden files, contract tests, snapshot tests, integration tests, smoke tests, load tests, permissions, rate limits, idempotency keys, transaction boundaries, validation rules, invariants, and the small prayer every engineer performs before pressing enter in production. Yeah, I’m a nerd, I love long lists, deal with it. Half of software engineering is just inventing increasingly elaborate ways to say: maybe don’t mutate the important thing directly.

Then AI agents arrive and the industry starts acting as if write access is a UX detail.

It is not. Same button, different animal. If an assistant writes a bad summary of a contract, the contract is still there. Annoying, but recoverable. If an agent updates the contract and silently changes a term, the model’s mistake may now be part of the artifact. It is no longer next to the work. It is in the work. And once it is in the work, future work can build on it, which is how small mistakes become durable without ever needing to become loud.

This is also where “human in the loop” often does not calm me down as much as it is supposed to. Which human? Seeing what? Before or after the mutation? With a diff? With invariants checked? With the original preserved? With enough context to notice that the model kept the style and damaged the meaning? A human approving a clear proposed change is one thing. A human skimming a polished artifact after a probabilistic system has already rewritten it is something else. That is not supervision. That is archaeology with a nicer interface.

We spend quite a bit of time on this at INXM, and the more time we spend on it, the less I believe in the comforting version of “just put a human in the loop”. The hard part is not adding a little approval box somewhere and pretending responsibility has now been routed through a mammal. The hard part is showing the person what will actually happen before the plan runs for the first time. What state will change. What might break. What assumptions the system is making. What the decision means, not in the abstract, but in terms of the artifact; the workflow, the customer, the invoice, or whatever piece of reality the agent is about to touch.

And then you have to do all of that without punishing the user for reading it. You cannot throw a wall of generated text at them and call it transparency. You also cannot hide the important parts because the UI looked cleaner in Figma. Somewhere between those two failures is the thing you actually need: enough context to make a decision, shaped in a way that a tired human can still understand before clicking the button. So if there is a human in the loop, the loop has to mean something, and it should be scarce so it becomes important to care. And it has to show impact, not vibes. It has to preserve the relevant context, not summarize it into corporate soup. It has to make the boundary visible: before this point, the workflow is proposing; after this point, state changes. Otherwise we have not built supervision. We have built a button that lets everyone feel briefly responsible before the system does whatever it was going to do anyway. None of this is something were my old pals Claude, ChatGPT or Gemini had been particularily convincing to me neither in user flow, nor in actual execution.

I am not saying agents are useless. That would be too easy and also wrong (which is a very efficient combination if you want a career in commenting on technology on LinkedIn, but this is a serious blog post). Agents are useful already, and they will become more useful. For isolated, reversible, low-risk work, go ahead. Let the model explore, draft, sort, prepare, triage, rename, format, summarize, all of that. There is plenty of real work hiding in the annoying edges of work, and if a machine wants to spend its short statistical life making those edges less annoying, I am not going to stand in its way.

But once the model crosses into durable state, I want the system to become boring very quickly.

This is where I keep coming back to Compiled-AI. Not as a grand theory, and not because every workflow should suddenly pretend to be a compiler. More as a shape I trust. Use the model where the input is messy. Let it turn ambiguity into candidate structure. Let it propose the mapping, the rule, the edit, the migration, the classification, the test, the plan. Then stop. Put the thing on the table. Diff it. Version it. Review it. Test it. Run something boring after that. The model can be clever before the boundary. After the boundary, clever is not the feature I want. I want repeatable. I want inspectable. I want something I can blame without it producing an apology in bullet points, starting with “You are right!”

Maybe that is the actual line. AI before the boundary can be weird and useful. AI after the boundary needs a leash, a log, and ideally fewer vibes.

There is also a second reason why this matters, and it is less about one corrupted document and more about how work actually accumulates. Organisations do not usually fail because one artifact is wrong in a beautiful, isolated way. They fail because the wrong artifact becomes input. Someone copies it into the next thing. Someone references the shifted definition. Someone trusts the summary because it looks more finished than the source. Someone builds the migration from the plan. Someone approves the customer email because the tone is good, and tone is apparently enough to pass as competence if the font is clean. That is where approximation with write access becomes unpleasant. It does not just produce mistakes, it’s worse - It produces material for future mistakes.

This is also why I do not think benchmark success, by itself, tells us enough. A system that succeeds once on a clean task has succeeded once on a clean task. Congratulations to the system, and also to the clean task for being so clean. But real workflows are not clean. The input changes slightly, the wording changes, the API returns partial data, a tool times out, a file has a misleading name, a user says “the thing from last quarter”, and suddenly the question is not whether the model can produce a plausible next step. The question is whether the operational end state is still correct.

For agents, the end state is the product. Not the explanation, not the trace, not the confident summary, not the little checklist of what it claims to have done. The state. Did the right thing change? Did the wrong thing remain untouched? Can we prove it? Can we replay it? Can we roll it back? Can we see the difference between the intended change and the actual change?

That is a much less glamorous conversation than “autonomous AI workers”, but glamour has a disappointing incident record.

Delegation sounds like productivity. In systems, it is permission. It is deciding what gets to mutate the world, or at least the small local piece of the world currently represented by a document, database row, ticket, pull request, workflow state, CRM record, invoice, or customer email. That does not mean we should never delegate to AI. It means the word “delegate” is doing too much deodorant work. Say what it REALLY is: the model gets write access. It gets to mutate state. Its approximation may become part of the artifact other people rely on, and once that is the case, the useful conversation changes. It is no longer enough to ask whether the model can do the task. We have to ask what it is allowed to touch, which changes are only proposed, which changes become real, what can be rolled back, what remains the source of truth, and where exactly approximation ends and state begins.

I do not think these questions make AI less useful. I think they are the questions that make it useful without becoming another mess future teams have to excavate. Use the model where ambiguity is the input, where the work is still fluid enough that a plausible structure is valuable. Let it help form the mapping, the edit, the rule, the migration, the classification, the test, the plan. But do not confuse that with execution. And when possible, compile the model’s fuzzy understanding into something dull enough to run without improvisation. That does not make the system perfect. Nothing does. But it puts the uncertainty somewhere visible, before it has quietly entered the artifact and started pretending it was always there.

That is probably my whole discomfort with delegation. It sounds like handing off work, but in AI systems it often means handing over the pen. And the pen is not floating in a chat window. It is attached to production.

The confusion is this: because a system performs well on tasks that look intelligent to us, we start treating the performance as evidence for intelligence itself. That sounds reasonable at first, because humans are also mostly judged by their behaviour. If somebody solves a difficult maths problem, writes a competent essay, passes an exam, or explains a concept well enough that even your uncle stops pretending he understood it already, we usually infer some form of intelligence from that. Like people assumed me to be intelligent after I wrote that piece about explaining an LLM to a 12 year old or your dad. But the paper’s point is that this inference becomes dangerous when we forget that similar output does not imply similar mechanism. A human and a model can both produce the same correct answer, but the process that led there can be very different, and when we move from impressive demonstrations to systems that are supposed to operate in the real world, the mechanism matters more than the screenshot.

This is especially important because the AGI discussion has become a wonderful place to hide sloppy engineering thinking behind large words. If a model passes a benchmark, someone calls it generalisation. If it solves a task from a domain it was not explicitly trained for, someone calls it reasoning. If it produces a convincing answer, someone calls it understanding. And if enough people do that often enough, we eventually end up in a place where “it worked in the demo” becomes the empirical foundation for a claim about general intelligence. Which is quite a leap, and not the fun kind. More the kind where the bridge was generated by a model and nobody checked the load-bearing parts.

The authors push back against exactly that move. Their argument is not that current systems are useless, nor that the progress is fake, nor that benchmark performance does not matter. It clearly does matter. If a model becomes better at coding, translation, summarisation, mathematical problem solving, planning, or tool use, then something meaningful has improved. The problem starts when we take performance on a collection of tasks and treat it as sufficient evidence that the system has the kind of robust, adaptive, reliable intelligence we historically meant when we used the term AGI. That is not a small definitional quibble. That is the difference between observing that a system can do many useful things and deciding that the system can be trusted as a general actor in open-ended environments.

And this is where the paper connects very directly to the enterprise AI problem. In enterprise systems, nobody should care whether the model’s output looks intelligent in isolation. That is not the bar. The bar is whether the system can be operated. Can I explain what happened? Can I reproduce it? Can I test it before it goes live? Can I prevent it from taking actions outside its authority? Can I detect when it has failed? Can I repair the process without turning every incident into a séance where five developers stare at a prompt and try to infer what the model was thinking? Those are the questions that determine whether AI becomes useful infrastructure or a very expensive way to produce new incident categories.

The uncomfortable truth is that statistical approximation is a fantastic interface to messy reality and a terrible runtime contract for critical work. LLMs are very good at dealing with the parts of work that classical software has always hated: ambiguity, incomplete language, weird phrasing, inconsistent descriptions, half-structured documents, human intent that arrives wrapped in three layers of organisational folklore, and all the little cases where a regular expression looks at the input and quietly gives up on life. That is a real breakthrough. It is not marketing. It is genuinely useful that a model can read a messy description, infer structure, propose categories, explain trade-offs, translate between business language and technical language, and help a human get from “this is roughly what I need” to something that can be specified.

But none of that means the model should own the execution of the work forever. Quite the opposite. If the paper is right that we should not confuse statistical approximation with general intelligence, then we definitely should not confuse statistical approximation with governance. A model can produce the next plausible token, the next plausible step, the next plausible tool call, the next plausible explanation. Sometimes that plausible continuation is correct. Often enough it is extremely useful. But plausibility is not the same thing as truth, and it is absolutely not the same thing as accountability. Enterprises are not built on plausible continuations. They are built on processes, approvals, constraints, logs, retries, audit trails, access rights, boring controls, and all the other things that make software less magical and therefore actually usable.

This is the part that the agent hype keeps trying to skip. The story usually goes like this: instead of building workflows, we give an autonomous agent access to tools, tell it what outcome we want, and then it figures out the rest. Which sounds beautiful, until you remember that “the rest” is where most of the work lives. The rest is the ERP returning a value that is technically valid and semantically nonsense. The rest is the customer using a term that only makes sense inside their department because that department has developed its own private language over the last decade. The rest is a policy document contradicting another policy document, a missing field being optional in the schema but mandatory in reality, an approval limit changing because someone restructured procurement, or a supplier invoice that looks normal until you notice that the legal entity changed halfway through the process. Real systems are not made of happy paths. They are made of exceptions that survived long enough to become business rules.

Now, one can of course argue that a sufficiently capable agent can handle those cases. It can inspect the error, reason about the context, try a different path, ask another model, reflect on its own answer, call a tool, update its plan, and continue. Some of that is true, and some of it is genuinely useful. But it does not remove the architectural problem. It mostly moves it into a darker room. If the agent repairs itself silently while operating your business, then the system may become more impressive and less governable at the same time, which is not what I would call progress unless your definition of progress is “we now have incidents that write their own postmortems”. The ability to recover from uncertainty is not the same as the right to improvise around controls.

This is why I keep coming back to Compiled AI. Not because the word itself is magical, although it is nice when a term finally appears for something you have been trying to explain for a while. The useful idea is that the LLM should be involved where probability is helpful: during understanding, design, generation, specification, validation, and repair. It should help translate intent into a Plan. It should help identify missing information. It should help propose steps, map messy human language into structure, generate executable artifacts, and explain what will happen. But once the work is understood, the execution should become explicit. The Plan should be inspectable, testable, versioned, approved, monitored, and repairable. In other words, the probabilistic system helps build the machine, but the machine does not have to remain probabilistic at every transaction.

That distinction sounds small, but it changes the failure mode completely. In a runtime-agent system, every execution is a new interpretation. The model reads the context, decides what matters, selects tools, chooses arguments, evaluates responses, and continues. Every run is a little performance, and performances can differ. In a compiled execution model, the interpretation happens before deployment. The resulting Plan is not a vague intention floating inside a prompt. It is a governed artifact. It can be reviewed. It can be tested against known cases. It can be logged. It can fail at a specific step for a specific reason. And when it fails, the model does not need to reinvent the whole process like a confused oracle with admin permissions. It can look at the failed step, the actual error, the tool response, the surrounding context, and the allowed boundaries for repair.

This is also where the paper’s critique of AGI claims becomes practical. If task performance is not enough to establish general intelligence, then task performance is also not enough to justify operational autonomy. A benchmark can tell us that a system often produces the right answer for a certain class of inputs. It cannot tell us that the system is safe to put in charge of a business process that has legal, financial, reputational, or operational consequences. A Turing-test-style interaction can tell us that a system can sound human enough under certain conditions. It cannot tell us that the system understands organisational accountability, or that it will stop at the right boundary, or that it knows when the correct answer is not to continue.

The annoying thing is that this should not be controversial. We already know this from software. We do not deploy systems into production because they once produced a nice output in a meeting. We test them, we constrain them, we monitor them, we define ownership, and then reality still finds a way to make us feel humble. Somehow, when AI enters the conversation, people become willing to forget decades of operational discipline because the demo can explain itself in a pleasant tone. That is not engineering. That is being seduced by autocomplete with better manners.

And yes, humans are also unreliable. Humans forget, misunderstand, hallucinate, overfit to their own experience, approve things because the meeting starts in three minutes, and generally behave like biological distributed systems with caffeine dependencies. But organisations do not deal with human unreliability by pretending it does not exist. They wrap humans in process. Four-eyes principles, approval limits, audit trails, training, policies, escalation paths, segregation of duties, incident reviews. None of that makes humans perfect. It makes the work governable. It creates a structure in which mistakes have a place to surface and a path to be corrected. If we are serious about using AI in enterprises, the same principle applies. The goal is not to pretend that the model has become a perfect worker. The goal is to design a system in which the model’s usefulness is amplified and its failure modes are contained.

That is why “statistical approximation is not general intelligence” is not an anti-AI argument. It is a pro-architecture argument. It says: use the thing for what it is good at, but do not confuse the interface with the runtime. Use it to read the messy world, but do not let it silently rewrite the rules of the business while doing so. Use it to generate Plans, but make those Plans concrete. Use it to repair failures, but make repair an explicit governed action. Use it to accelerate the creation of workflows, but do not confuse faster workflow creation with permission to run uncontrolled workflows.

There is a very boring sentence hidden underneath all of this, and boring sentences are usually where enterprise value lives: AI systems need boundaries. Not because they are weak, but because they are useful enough to become dangerous without them. A weak tool does not need much governance because nobody gives it important work. A powerful tool absolutely does. The more capable LLMs become, the more important it becomes to separate semantic understanding from operational authority. Otherwise we will keep building systems that look intelligent in the parts humans can easily observe and fail in the parts organisations actually depend on.

So no, I do not think the most interesting question is whether current models are AGI. Maybe they are, under some definition. Maybe they are not, under a better one. Maybe the word has been stretched so far that it now mostly tells you which conference panel someone wants to be invited to. What matters for enterprise AI is much simpler and much harder to fake: can the system finish the work correctly, repeatedly, observably, and with enough evidence that someone can trust the result later?

That is the bar. Not fluency. Not benchmarks. Not the feeling that the system “kind of gets it”. The bar is operability. Statistical approximation can help us get there, but only if we stop asking it to be the whole machine. Probabilistic where the world is messy. Deterministic where the business needs repeatability. Adaptive where the Plan needs improvement. Governed where the change has consequences.

That is not as exciting as declaring AGI. Good. Excitement is not a control mechanism.

Large Language Models are an amazing technology. Our feeds are full of impressive demoes of what we can do with them. Chatbots were amazing when they arrived a couple of years ago. But the value for businesses didn’t really materialize. It turns out hallucinations make them unreliable.

The Claude Code and Claw-like agents were shockingly futuristic at first. But just like the chatbots, the demo did not deliver. It turned out they require so much maintenance, and so many tokens, that the ROI is still low.

The biggest business impact I’ve seen is in software development. Why? Because code can be tested. Unlike the wall of slop you saw on LinkedIn this morning, your team is shipping working code to production. Generating code has become so valuable that some companies are bragging about developers burning through tokens to equal their salary. Code generation is already useful, but expensive.

Compiled AI resolves all of this, making AI into a real business case. Hallucinations are kept out of production use cases, maintenance is low and simple enough for the average user to handle, and the cost structure is much better. The term Compiled AI was coined in this paper released in April (together with some very interesting benchmarks). But at INXM we’ve been hard at work on this for over a year.

At it’s core Compiled AI means you use LLMs to generate deterministic, enterprise-ready, code. You then run the code to achieve your outcome. This gives you the flexibility of natural language from AI models, but the testability of deterministic code.

It’s also a lot cheaper.

This is crucial step forward since a business in practice is a handful of reliable processes. If we had to rely on the 98% probability of LLMs, most of us wouldn’t be in business. The risk profile this probability creates would make delivery sporadic even in small businesses. In enterprise where processes are more complex it would be unusable.

Each step in a business process multiplies this possible error rate from an LLM, until eventually it hits the ceiling of 100%. This is partly why so many AI pilots fail.

We knew this when we started INXM, but we didn’t have a term to describe the solution, until now. Compiled AI does not have these problems.

Our Process Execution Engine, called the Orchestrator, uses Compiled AI to do work more reliably than chatbots or agents, but it’s also more reliably than legacy automation systems. Using the strengths of AI to make Compiled AI processes much less fragile to changes.

Compiled AI also uses a lot less tokens than basic LLM based approaches. How much depends on the use case, in the paper that coined the term they created a benchmark that showed a 90% reduction. This is a remarkable cost reduction. Especially in Europe where we are severely constrained by data center build out. We believe that using 90% less tokens resolves the token bottle neck in Europe, keeping your data secure.

Every Business runs on reliable processes. We need reliable and auditable transactions through all our systems of record. Probabilistic tools don’t provide this, Compiled Ai does.

The larger the organization, the more flexibility their processes require. Our Compiled AI lets humans make key decisions and adapt to new context, which means we don’t need to rely on IT to maintain fragile automations.

We believe Compiled AI changes the business case completely. AI is now enterprise ready.

The paper is called Compiled AI: Deterministic Code Generation for LLM-Based Workflow Automation, and the core idea is refreshingly simple: use the LLM during a compilation phase to generate executable artifacts, validate those artifacts, and then execute the workflow deterministically without asking the model again at transaction time. The authors define compiled AI through three properties: one-time LLM invocation, zero-token deterministic execution, and mandatory multi-stage validation before deployment.

Or, in less academic language: let the probabilistic thing help you build the machine, but do not make the probabilistic thing be the machine.

That is pretty much the sentence I wish we had one year ago.

I wrote before that non-deterministic AI agents are a terrible foundation for enterprise workflows. Not because AI is useless. It is not. But because enterprises are not built on “probably”. They are built on approvals, audit trails, retries, access control, accountability, compliance boundaries, and the very unglamorous ability to explain why something happened after it already happened and everybody suddenly cares about the answer. If each step in a workflow has a probability of being correct, those probabilities do not magically become enterprise-grade because the demo had nice animations. They multiply. 0.99^10 is already uncomfortable. 0.99^100 is not a business process, it is a risk register with a prompt attached to it. (blog.inxm.ai)

And yes, before someone writes the obvious comment: good agentic systems can self-correct, plan, reflect, use tools, run feedback loops, ask another model, and do all the other things we now pack into YAML files until they begin to look like distributed systems designed by a very enthusiastic intern. Some of that is useful. Some of it is necessary. But it does not remove the architectural question. Are you asking an LLM to interpret the work at runtime, step after step, transaction after transaction? Or are you using AI to turn intent into something explicit, validated, and executable, and then running that thing like software?

That distinction is the whole point. And I’m happy to say that INXM has been building the first Compiled AI Process Execution Engine for enterprises. For work too critical to improvise. At the center of that is Orchestrator. Orchestrator is a Process Execution Engine. It uses Compiled AI to turn user intent into executable Plans: governed workflows that complete repeatable, auditable, very small transactions across existing systems. Generated, validated, and deployed once; then run reliably across your existing tools.

That sounds less magical than “autonomous agents will automate your entire business”. Good. Magic is not what you want near your billing reconciliation, quality deviation handling, procurement approvals, regulatory checks, engineering validation, or anything else where “the model felt confident” is not a satisfying incident report.

The paper makes the same trade-off explicit. Compiled AI trades runtime flexibility for predictability, auditability, cost efficiency, and reduced security exposure. It is aimed at well-specified, high-volume, compliance-sensitive workflows where the work needs intelligence to design, but not intelligence to execute again and again. The authors also show why this matters economically: in their function-calling benchmark, compiled AI had a one-time generation cost, zero execution tokens, broke even against direct runtime inference after roughly 17 transactions, and reduced token consumption by 57x at 1,000 transactions.

The cost numbers are nice, of course, but the determinism is nicer. Because cost can be optimized later. Determinism is an architectural decision. If your workflow is interpreted by an LLM every time it runs, then every run is a new little performance. The prompt is read, the context is considered, the tool selection is made, the answer is generated, and everyone hopes the model does not discover a creative interpretation of “approve invoice”. With compiled execution, the clever part happens before deployment. The resulting Plan can be inspected, tested, versioned, approved, rolled back, and explained. Not perfectly, because software is still software and therefore a machine for converting assumptions into tickets, but at least it fails in the way software fails: visibly, locally, and with something concrete to fix.

This is the part I think is still underappreciated.

The paper says deterministic execution yields observability, and that when accuracy degrades you can pinpoint which code segment underperformed and trigger targeted regeneration. It describes compiled AI not as a one-shot process, but as an evolutionary system: deterministic execution with adaptive improvement. (arXiv)

That sentence is very important, because “compile once” alone is not enough. If all you do is generate a giant block of code from a vague specification and then declare victory, you have not solved enterprise AI. You have created a new place for bugs to hide. The real question is how you operate the compiled artifact. What happens when the Plan fails? What happens when a tool schema changed? What happens when the ERP returns a weird response because of course it does? What happens when the human intent was underspecified, or a compliance check requires an additional approval, or the system reaches a branch that looked theoretical during design and very real at 4:17pm on a Friday?

And here is where I will allow myself a little bit of German: we have about one year Vorsprung in this. We did not just arrive at “LLM generates workflow, workflow runs”. That is the easy sentence. We spent the year dealing with the uncomfortable runtime reality around it. In INXM, Plans are not one giant agentic blob that either succeeds or explodes into a tragic stack trace. They are made of small executable steps. Each step has a job. Each step has inputs. Each step has expected outputs. Each step can fail in a way that the system can actually understand. That changes the failure mode completely. When a Plan fails, the LLM does not have to stare at the entire enterprise process like a confused oracle and invent a new strategy from scratch. It sees the exact step that failed, the actual error, the tool response, the surrounding context, and the boundaries of what it is allowed to change. It can then propose a repair to the Plan instead of improvising around the error at runtime. And if the repair changes the governed workflow, the system can come back to the user in the way enterprise systems should come back to users:

“Your Plan failed, but we can repair it. I prepared the following changes. Are you fine with this?”

This sounds like a small UX detail, but it is the difference between an agent silently correcting itself while operating your business on one end, or requiring a 20-person developer team on call on the other, and a governed execution engine that can say: here is where the Plan failed, here is the proposed change, here is why, here is what will happen if you approve it. The user is not asked to debug a vague AI failure. The user is asked to approve a concrete repair to a concrete Plan. That is how AI becomes operable. And reduces cost, because you get predictability without the operating costs of keeping those predictable workflows alive.

Now the paper also has a limitations section, and I like that, because without limitations every architecture becomes a religion. Compiled AI assumes good specifications. Not every workflow can be reduced to deterministic code. Some tasks need runtime semantic understanding. Generation can fail. Generated code quality depends on the model. Broader evaluation is still needed. All true.

But that is also why “Compiled AI” alone is not enough. The specification problem is not solved by telling business users to write perfect YAML. That is just moving the pain from code into a slightly different file format, which is not progress, it is mostly typography. The better approach is to let people describe intent in the language they already use, then turn that intent into an explicit Plan that can be reviewed, validated, deployed, operated, and repaired. Natural language is a perfectly good creation interface, given enough guidance. But it is really really not a good runtime contract.

This is where Orchestrator matters. It turns enterprise intent into executable Plans: governed workflows that complete repeatable, auditable transactions across existing systems. The LLM helps build and improve the Plan. The Process Execution Engine runs it. And when reality disagrees with the Plan, the system does not quietly improvise. It stops at the failed step, prepares a repair, and brings the decision back into governance.

Now, Compiled AI does not mean “no LLMs at runtime ever”. The paper itself highlights this as well. Some tasks are too semantic, too noisy, or too dependent on ambiguous input to be solved with pure deterministic extraction. Their document intelligence example uses a Code Factory variant, where focused LLM calls are wrapped inside compiled code artifacts. That is the right middle ground: bounded invocation, schemas, validation, fallback logic, and deterministic control flow around the probabilistic part. The LLM can help extract meaning from a messy clinical note or invoice, but it should not own the whole process like a tiny drunk process manager. But critical enterprise work is different. The goal is not to maximize how autonomous the AI feels. The goal is to finish the work correctly, repeatedly, and with enough evidence that someone can trust the result later.

That is why I am genuinely happy about this paper. Not in the “excited to announce” way where every minor API wrapper somehow changes the future of humanity. I mean happy in the engineering sense. Someone put a clean name and scientific framing around the thing we have been building toward: AI should compile enterprise intent into governed execution, not improvise business operations forever. And yes, I also like that we have a year Vorsprung in the ugly part. The part where Plans fail. The part where tools return bad data. The part where generated artifacts need tests. The part where users need to approve repairs. The part where auditability, permissions, replayability, and deterministic execution are not slideware, but product requirements.

INXM. AI that finishes the work.

He is the orchestration layer.

And I say this with deep respect for him. He is brilliant at what he does. But a company should never depend on one person to hold everything together. That is a fragile setup. Everybody in that room knew it. Nobody said it out loud until I did.

So let me say it here: what this manufacturer needs, what most manufacturers need, is a technical orchestration layer. A system that does what this one person does. Every day. Every shift. Without getting sick, without going on holiday, without retiring.

The real number behind the chaos

How many applications does the average enterprise actually run? Depends who you ask. Okta’s 2025 data, based on real login activity, says 101. Zylo, tracking SaaS subscriptions, says 275. MuleSoft lands at 897, though they sell integration software, so take that number with some healthy skepticism.

For a manufacturing plant, the number that matters is usually somewhere between twelve and thirty. ERP, MES, SCADA, PLM, QMS, CMMS, WMS, CRM, ITSM, BI tools. Plus whatever the last digital transformation project left behind that nobody dares to turn off.

Most of these systems work perfectly fine on their own.

But they were never built to work with each other. MuleSoft found that only 29% of enterprise applications are actually integrated. The rest? Manual handoffs. People copying numbers from one screen into another. Decisions based on whoever last saved something to a shared drive.

A Harvard Business Review study tracked workers across three Fortune 500 companies. They toggle between applications 1,200 times per day. That burns almost four hours a week just reorienting after each switch. Roughly 9% of their working time, gone. And that is office workers. On a factory floor, where a wrong number in the wrong system means a missed shipment or a failed audit, the cost goes far beyond time. It hits trust. It hits customers. It hits the bottom line.

Where the hours actually disappear

I keep asking the same question when I talk to operations people: what happens when your ERP says one thing and your MES says another?

The answer is always the same. Someone walks over to someone else. They open two systems side by side. They compare. They make a judgment call. They move on. Nobody logs this. Nobody tracks the twenty minutes it took. It is just how things work.

Multiply that by every shift. Every handoff. Every order confirmation that requires cross-referencing two sources of truth that were never designed to agree with each other.

That is the orchestration gap. Your systems work. They just work alone.

The AI that industry actually needs (and the one it keeps buying instead)

Here is where I have to be honest about something that most people in this industry will find uncomfortable.

The instinct right now is to throw “AI” at everything. And I understand why. The marketing is loud. The demos are impressive. The pressure from the board is real.

But let me share what the data actually says.

MIT’s NANDA initiative studied hundreds of enterprise AI deployments. Only about 5% of integrated GenAI pilots achieved measurable impact on the P&L. Five percent. RAND’s research on AI project failure puts broader rates above 80%. The reasons come up again and again: misaligned expectations, wrong tool for the job and infrastructure gaps.

In manufacturing, I believe the numbers are worse. Because manufacturing does not need surprise. Manufacturing needs repeatability.

Think about it this way. Would you put a system that gives a different answer to the same question every time you ask it in charge of your quality process? Your supply chain reconciliation? Your audit documentation?

I would hope the answer is a clear no.

The distinction that matters here is simple. Probabilistic AI generates plausible outputs that vary each time. It is built to be creative. Deterministic execution gives you the same output for the same input. Always. Full audit trail. Zero hallucination. Zero creative reinterpretation of your production schedule.

For a factory, that second one is everything.

Connect what you have. Stop replacing what already works.

The pattern I see at almost every manufacturer we work with goes like this: someone proposes a platform migration. Rip out the old system. Drop in a new one. Twelve months minimum. Eight figures. The promise is consolidation.

The reality? You end up with a shiny new system that still fails to talk to the three old ones you could never switch off because somebody built a critical process on top of them years ago.

I have seen this story play out a dozen times. It always ends the same way.

The better path is orchestration. Instead of replacing systems, you connect them. An orchestration layer sits above your existing platforms and coordinates what they already do well. Your ERP stays. Your MES stays. Your SCADA stays. The orchestration layer makes them work together. Deterministically. Auditably. Automatically.

This idea is simple in principle. What changed is that it is now feasible at the speed and reliability that manufacturing actually requires. But only if you build it on deterministic AI. The kind that does the same thing right, every single time.

Why this conversation belongs in Europe

I am writing this ahead of Hannover Messe 2026 and there is a reason this topic hits harder here than in San Francisco.

Europe’s regulatory environment with GDPR, the AI Act and data sovereignty requirements is often framed as a burden. And sometimes, honestly, it is.

But for industrial AI, it is the competitive advantage.

Data sovereignty means your orchestration layer will never silently route production data through a US hyperscaler. Good. Audit requirements mean every automated decision must be traceable. Good. Quality standards mean you can only ship something that works reliably. Good.

These constraints force you to build things that are actually solid. European industry has been doing this for decades. Precision engineering. Process discipline. Quality systems that hold up under pressure. The orchestration layer is the same philosophy applied to software. Software that reads between the tools. Just like that one guy on the floor does, but at scale, around the clock, across every system.

The companies that figure this out now will have more than a productivity advantage. They will have a compounding one. Because once your systems are coordinated, once the gaps are closed, every improvement you make to any single system benefits the whole operation.

The question nobody is asking at Hannover Messe

Every booth will demo AI this year. Every panel will discuss AI. Everyone will hear the word until it loses all meaning.

But here is the question I would actually like someone to answer honestly:

How many manual handoffs happen in your operations every single day?

It is the boring question. The unsexy one. But when you actually sit down and count, it explains exactly where your time and money are going.

That is the conversation I want to have in April.

Because at INXM, we are already building the answer.

Now let me show you what this looks like when it is real.

Imagine you are a buyer at a large enterprise. You wake up on a Tuesday morning. Coffee in hand. You have 180 suppliers under your responsibility. Contracts, quality scores, delivery performance, risk profiles, incoming goods receipts and open issues. All of it spread across SAP, your supplier portal, your quality management system, your email inbox and probably three or four Excel files that only you understand.

You have no idea that three of your suppliers are running out of contract today.

But INXM does.

INXM runs through all 180 suppliers. Every single day. It collects the data about their situation, their problems and their challenges. It pulls incoming goods receipts. It checks the contracts. It reviews quality scores, delivery reliability, the full performance picture and every risk signal in the system.

INXM knows that yesterday, three contracts were about to expire. It has already prepared everything you need for the call this morning. The supplier performance summary. The open quality issues. The delivery track record. The full negotiation preparation tailored to each supplier sitting ready for you.

And it has aligned everything in SAP. Checked. Prepared. Ready for you to review and go.

This is what orchestration looks like when it actually works. In a fast moving market, with processes and systems of record that no single human can manage alone anymore. INXM does that work. Quietly. Reliably. Every morning before you finish your coffee.

inxm.ai

There’s a particular kind of CompanyGPT/MCP Server problem that IT teams face, and we don’t discuss much in tech blogs. You’ve integrated some important system with an MCP server. Maybe it’s a weather service, maybe it’s your internal HR system, maybe it’s a customer database. The MCP is working beautifully in the terminal, and your enterprise tools are fully integrated. Finally, people can do things that were difficult or impossible with the UI of the software. But now someone asks: “Can we build a UI for this so that people can do X?”

You’re like “Why don’t they just use the MCP directly?”, but the answer is broad: terminal usage is both restricted to few people and anyways intimidating for most people, so no claude code; because prompt paralysis is real in Chat Interfaces; because they simply don’t know how. They want a simple interface where they can click buttons, see data displayed in tables or charts, and interact without needing to understand the underlying tools.

So you bring this to your CompanyGPT Team, they tell you they’ll add this to their backlog, and then this is where things usually stall.

They’d need to set up authentication, test it, and deploy it. After that people will still not using it because they freeze in front of the empty prompt, see prompt paralysis above. So first talks are around deploying a web app. That’s weeks of work. For something that might only be used by a handful of people internally? Wasn’t that supposed to be easier with MCP and LLMs by now?

Hopefully with v0.4.4 of Enterprise MCP Bridge, it is. Instead of waiting for developers, the person managing your IT infrastructure, and even everybody having access to the MCP, can build the interface themselves, directly from the MCP tools you already have. In plain language. No code required.

We already added the first bits of this in an earlier version - but now you can use it yourself, without building an extra user interface to generate user interfaces. And we give you a “Deploy To Render” button so you can easily try it out on a free service instance on Render.

This isn’t about replacing developers. It’s about extending the capabilities of your teams so they can solve problems that would never have had dedicated engineering resources in the first place. It’s about moving from “we have a tool” to “we have a tool that people can make work for themselves”.

How AI-Generated UIs Actually Work

The technical approach matters here, because the difference between “toys” and “useful tools” comes down to architecture.

Most code generation is optimised for a single attempt. You describe what you want, the AI generates something, and you hope it works. If it doesn’t, you try again. This is unreliable at scale, especially for anything that needs to integrate with real systems.

The Enterprise MCP Bridge uses a different approach. When you describe a UI, the system doesn’t just generate code and send it to you. It generates code, runs it immediately against actual tests, catches problems, and fixes them. Then it shows you the result.

The generation happens in two phases. Phase 1 generates the service layer: the logic that talks to your MCP tools, orchestrates their responses, and turns raw tool output into usable data. This is the hard part. Phase 2 generates the presentation layer: the HTML and JavaScript that displays the data to a user.

We separate these because they live in different problem domains. The service layer needs to be correct above all else. The presentation layer can iterate. And by running tests after phase 1, we catch fundamental problems before we even try to build a UI.

Here’s what actually happens when you ask for a weather dashboard, for example. The system queries your MCP servers and discovers the available tools. It figures out that a weather tool exists. It calls that tool with sample data, gets back a real response, and now it knows exactly what the tool outputs look like. It then generates a JavaScript service class that knows how to call this tool and extract the temperature value from whatever structure the tool returns. It generates tests that verify this works. It runs the tests. If they fail, it sees the actual error expected 0 to be greater than 0 and adjusts the dummy data generation to use real values. Then it re-runs the tests. Only once tests pass does it move to generating the UI that will display this data.

At each step, the AI has concrete feedback about what works and what doesn’t. It’s not guessing. It’s not making assumptions. It’s looking at actual test failures and fixing them.

UI Generation for People - The User Experience

When you navigate to /app/_generated/start, you’re at the generation interface. You give your UI a name and describe what you want. The system queries your MCP servers, discovers tools, and generates everything. While it’s running, you see status updates as each phase completes.

Once generation is complete, you’re dropped into the conversational editor. This is where the back-and-forth happens. The preview is live on the right side. On the left, you have a text input where you can describe changes. “Add a filter for department.” “Make the font bigger.” “Change the color to blue.” Each change goes to the AI, which regenerates the affected code, runs tests again, and updates the preview within seconds.

The interesting thing is that this approach isn’t limited to just create your usual business value creating stuff. Let’s say you’re not a fan of microsoft teams, and always wanted it to be slack. You can just ask the system to generate a slack interface for your m365 mcp tools for Teams.

You’re not locked into one interface. You can build multiple UIs for the same tool, even targeting different platforms, and they all use the same underlying service logic. Your coordinator can see employee data in a web dashboard. Your Slack users can query it from Teams. Your executives can see a different view optimized for their needs. All for the cost of describing what you want a few times, and the tokens that are needed to make your idea come true.

Why This Matters in Enterprise Settings

I want to step back and explain why this matters beyond just “cool technology.”

In most organizations, there’s a massive backlog of small tools that nobody gets around to building properly. Your HR coordinators want a better way to look up employee information. Your accounting team wants a dashboard to see budget spend. Your ops team wants a way to check system status. These are all important problems, but they’re not big enough to justify hiring developers or pushing them through a formal project process.

So they don’t get built. Instead, people use spreadsheets, or they call the developers on Slack, or they log into the main system (which is expensive in terms of licensing and slow because it’s not optimized for this particular task).

With conversational UI generation, these problems become solvable by the people who understand them best. The manager who owns the system isn’t a professional developer, but they can describe what they need and iterate until it’s right. They can deploy it themselves. They can modify it when requirements change. There’s no queue. There’s no waiting for developer bandwidth.

The enterprise angle here is about empowerment more than automation. You’re giving teams the ability to build simple interfaces without waiting for someone else.

The security angle matters too. Your IT team handles IAM once, in a central place. Users never see tokens. Credentials never leak into the browser, or obscure devices. It’s managed the way enterprises should manage it: centrally, with audit trails, with proper access controls.

Right now, most enterprise tool integrations happen through expensive consultants or your own development team. Conversational UI generation makes it possible for smaller organizations, or smaller problems within larger organizations, to be solved without that overhead.

How Conversation Works

The core insight behind this is treating UI generation as a conversation rather than a single request-response cycle. Traditional code generation feels like calling a function: you pass in parameters, you get back code, and you hope it’s right. Conversational generation feels more like working with a collaborator who remembers what you’ve asked for, what you’ve changed, and what problems you’ve hit.

When you first describe your UI, the system generates something. It might not be perfect. You look at it and describe a change. The system now knows both your original intent and your first change. It regenerates just the parts that need to change, leaving the rest alone. This continues as long as you want to iterate.

What makes this work is maintaining state. The system tracks your conversation history: every request you’ve made, every change. It tracks the current code in all four layers: the service code that calls your MCP tools, the component structure that holds state, the tests that verify behavior, and the dummy data used for development. It tracks what changed in each generation step. It tracks test results so it knows what’s working and what isn’t. When it needs to make a change, it has all this context, so the changes are usually small and targeted instead of wholesale rewrites.

This is actually more like how software professions do work, when you think about it. You build something, you look at it, you adjust it based on feedback. You don’t hand a specification to someone and get back perfect code on the first attempt. Yet that’s what we ask of code generation systems most of the time.

What This Isn’t

I want to be clear about the boundaries of what we’ve built.

This isn’t a replacement for professional design. Generated UIs are functional and reasonably attractive, but if you need pixel-perfect design or complex interactions that differentiate your product, you’ll want a designer. Generated UIs are for internal tools, dashboards, administrative interfaces: the kinds of applications where people care about function, not form.

It’s not magic. If your tools are poorly documented or have inconsistent behavior, the generated code will inherit those problems. The system generates code based on what it understands about your tools. Understanding is bounded by what the tool tells us.

You still need to think about your problem. The system helps you build a solution quickly, but it doesn’t figure out what you should build. You need to know that you want an employee directory, and roughly what should be in it. You can have the system build it for you, but the vision has to come from you.

It’s not production-ready for every use case. Internal dashboards? Absolutely. Administrative interfaces? Yes. Tools for your team? Perfect. User-facing consumer applications where design is a competitive advantage? These aren’t good fits.

What it is good for: the 80% of applications that don’t need custom design. The tools that are requested but never get built because they’re not big enough to justify a formal project. The simple interfaces that would take a developer days to build but take a conversation with a non-technical person five minutes to describe. Rapidly prototyping new ideas without committing engineering resources. Building multiple interface variants for the same tool.

What Else Changed Since v0.4.2

The work since the last release has been substantial. We built the conversational UI generation system from the ground up, but we also made several infrastructure improvements that matter for enterprise deployments.

One of them is authentication. In a typical enterprise, you don’t want every individual user to set up OAuth2 credentials for every tool they might need to use. That’s fast one it gets to onboarding, but a bit slow when you want to revoke all tokens quickly after a security incident. The Enterprise MCP Bridge always was about support this centrally. So now, after plenty of internal testing, we could release direct MCP exposure through Server-Sent Events, with token switching handled by the bridge itself.

What this means in practice is that your IT team sets up the OAuth2 once, in your IAM system. Then when an end user accesses a generated UI, the bridge automatically handles credentials on their behalf. It takes the token from the IAM system, asks the IAM System for the correct token for the system and exchanges them. The user never sees tokens. They never have to configure anything. They just have to be logged in with your IAM, and have a link only connection to the source system to use the UI. Your IT team manages security centrally, which is how it should work in enterprise environments. As IT Team, you get your inventory of active connections, logs who access what, when, trace movement across systems and you can revoke access immediately if needed.

We also improved how the system handles tool calls. When a tool fails: timeout, authentication error, malformed response: the system now attempts recovery strategies before giving up. It also classifies errors properly, so when something goes wrong during generation, we can tell you whether it’s a problem with the tool, a problem with the data, or something else entirely.

The documentation was completely reworked. We used to have scattered markdown files. Now there’s a proper documentation site with tutorials, reference material, and architecture explanations. The architecture documentation includes ASCII diagrams of how MCP, OAuth, sessions, and workflows fit together, because diagramming tools are often overkill for explaining how systems actually work.

We also improved agentic workflows so they can run in the background. Previously, workflows that called multiple tools in sequence had to wait for everything to complete before returning to the user. Now longer-running workflows can execute asynchronously while you continue working. The bridge streams updates back to you as steps complete. This is particularly useful for workflows that call external APIs with latency, or tools that do batch processing.

We added proper MCP elicitation support. This implements the client-side protocol from the MCP specification for requesting feedback from the user. We started before this was part of MCP, so we had our own flavor based on some discussions that happened on a mailing list. Now it’s standardized and integrated into session setup. When you create a UI, the system automatically elicits available options and waits for the user.

What Comes Next

The architecture we’ve built is modular. Each piece: the generation pipeline, the session management, the authentication handling, the MCP integration: is separate and extensible. Future releases could add a lot of things.

Multi-step forms would let users build complex data entry workflows, not just dashboards and display interfaces. Real-time collaboration would let multiple people edit the same UI simultaneously and see each other’s changes. A component marketplace would let you build collections of reusable pieces: a date picker, a file upload, a multi-select list: that you can inject into generation. Mobile generation would let you describe an interface once and get iOS and Android apps automatically. Custom design systems would let you plug in your company’s brand colors and typography so generated UIs automatically look like yours.

But these are all downstream. v0.4.4 is about solidifying the core pattern and proving it works. Describe what you want, iterate through conversation, deploy what you’ve built. Everything else builds from there.

Getting Started

If you want to try this, but haven’t gotten around to deploying it yet, we added a Deploy to Render.io Button in the README (or just click here, but the readme gives you info about the environment variables you’ll be asked for) that will set up a free Render instance for you with a Weather MCP server, that you can use this with your OpenAI API Key to explore the UI generation experience without needing to set up your own MCP server.

After you deployed it, navigate to https://$YOUR_URL/app/_generated/start. Give your UI a name, describe what you want to build, and watch as the system generates working code, tests it, and shows you a preview. From there, you can iterate by describing changes you’d like to make.

If you connect it to an actual MCP server with real tools, the system uses real data in testing and generation. If you don’t have a real MCP yet, there’s a mock mode where it generates dummy tools to work with while you learn the system.

Full documentation is at https://inxm-ai.github.io/enterprise-mcp-bridge, including deployment guides for production environments, reference material for the API, and more detailed examples.

Wrapping Up

There’s something interesting about building technology that extends what non-developers can do. The traditional model in enterprise software is that technical people build software, and everyone else uses it. But technical constraints are often arbitrary. Your HR coordinator probably understands your HR process better than any developer ever will. Your IT manager understands your infrastructure better than anyone else. If you give them the right tools, they can solve problems faster and better than waiting for developer bandwidth.

That’s what this release is really about. Conversational UI generation is the headline feature, but the underlying idea is bigger: empowering IT teams and domain experts to build simple tools without waiting for developers. Making it possible to turn an MCP: which is itself just declarative tool descriptions: into working, tested, user-facing applications through conversation.

Building, for me, means creating something predictable in a well-defined way. This system does that. You describe your intent. The system generates code. It tests the code immediately. It shows you the results. You iterate. Everything is traceable and understandable.

One last thing: it’s refreshing to build something that makes things simpler instead of more complex. There’s no new framework to learn. No special build process. No configuration files to maintain. You take an MCP server that you already built, and you get a working web application out the other end. Plain JavaScript, plain HTML, CSS that follows conventions you already know. If something doesn’t work the way you want, you can open the generated code and modify it directly. It’s not some opaque abstraction. It’s code you can read and understand.

Enterprise MCP Bridge v0.4.4 and v.4.5 is available now. Find it at https://github.com/inxm-ai/enterprise-mcp-bridge. The documentation includes tutorials, reference material, and deployment guides for getting this running in production environments.

Want to learn more? Contact us at hello@inxm.ai! Looking forward to hear from you

We keep being told how much everybody loves the bridge’s no-code UI generation, but the truth is that most real-world operators don’t need just a single screen, they need a guided, repeatable sequence of steps that respects approvals, reroutes when something changes, and keeps everyone in sync. Workflows brings that capability to the next release: it is the missing layer between a set of tools, a generated UI and a polished process.

To tell the story, let’s use something every accountant recognizes - Let’s say we have something like a good old NetSuite running, with their AI connector service that exposes a set of tools. A single operator should be able to review open quotes, check whether the matching invoices exist, verify cash actually hit the bank, and then approve both documents, all without leaving the bridge. Workflows takes that intent and turns it into a reusable runbook.

Scene 1: Describe the mission

You start with a root_intent, think of it as the mission statement. For accounting it’s “Close out open quotes and invoices with cash confirmation.” The bridge reads the workflow JSON, loads the MCP tool schemas, and lets the routing agent orchestrate the sequence. Here’s a condensed definition that lives next to your generated UI:

{
  "flow_id": "accounting-close",
  "root_intent": "Finalize quotes and invoices once cash clears",
  "agents": [
    {
      "name": "gather.open_docs",
      "description": "List all open quotes and invoices for the selected organisation.",
      "tools": [
        "list-organisation-details",
        "list-quotes",
        "list-invoices",
        "list-items"
      ],
      "returns": ["quotes", "invoices"]
    },
    {
      "name": "reconcile.cash",
      "description": "Match invoices to incoming bank transactions.",
      "tools": [
        "list-bank-transactions",
        "list-payments",
        "list-trial-balance"
      ],
      "context": ["gather.open_docs.quotes", "gather.open_docs.invoices"]
    },
    {
      "name": "sanity.checks",
      "description": "Verify compliance inputs such as tax rates and payroll exposure.",
      "tools": [
        "list-tax-rates",
        "list-accounts",
        "list-payroll-employees",
        "list-credit-notes"
      ],
      "when": "need tax insight"
    },
    {
      "name": "approve.documents",
      "description": "Show the user the quotes and invoices and the generated approval screen snippet, and ask to approve quotes and invoices.",
      "tools": [],
      "context": ["reconcile.cash.matches"],
      "reroute": [
        { "on": "missing_payment", "to": "reconcile.cash" }
      ]
    }
  ]
}

And then, all that’s left is to kick off the flow with a simple API call that includes the use_workflow parameter and the start_with agent to set the context:

curl -X POST <http://localhost:8000/tgi/v1/chat/completions> \\
  -H "Authorization: Bearer $TOKEN" \\
  -H "Content-Type: application/json" \\
  -H "Accept: text/event-stream" \\
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Close the open quotes for ACME Ltd"}],
    "use_workflow": "accounting-close",
    "start_with": {
      "args": {"organisation_id": "acme-ltd"},
      "agent": "gather.open_docs"
    }
  }'

Scene 2: The agents take the stage

1. gather.open_docs calls list-organisation-details, list-quotes, and list-invoices. While it streams over SSE you literally watch the open quotes appear in the UI your team already generated.

2. reconcile.cash compares each invoice against list-bank-transactions and list-payments. If it can’t find a match it emits <reroute>missing_payment</reroute> and the routing agent loops the operator back with the right context instead of guessing.

3. sanity.checks pulls list-tax-rates, list-credit-notes, list-accounts, and list-payroll-employees only when the routing agent judges the context needs extra scrutiny, for example when invoices include payroll or cross-border tax items.

4. approve.documents calls approve-quote and approve-invoice for every reconciled pair. If a stakeholder wants to pause, the agent adds <user_feedback_needed> and the workflow waits for a human confirmation before running the approvals again with the same workflow_execution_id.

Each agent only sees the context it needs. You can mask sensitive data, thread audit metadata, or have an agent run “headless” by setting context: false. Everything that matters, reroute reasons, human feedback, structured returns like <return name="reconcile.cash.matches">[...]</return>, is stored so you can replay the exact path later.

Scene 3: The happy ending

In enterprises the obstacle is never a lack of APIs. It’s the handoffs between them. Workflows shows up where the bridge already proved itself: you use the same accounting MCP server, OAuth boundaries, design prompts, and SSE channels, but now the bridge owns the sequence too. Your accounting lead describes the process in plain English, the bridge renders both the UI and the workflow, and the ops team gets an auditable, repeatable automation without scheduling a build sprint.

You can find the latest release on our github page inxm-ai/enterprise-mcp-bridge!

The fine print: limitations and what comes next

These workflows are powered by lightweight JSON definitions and LLM prompts, and that comes with trade-offs:

• Syntax is explicit: you still define agents, when clauses, reroutes, and argument mappings in JSON. It’s far friendlier than writing code, but it isn’t a drag-and-drop canvas.

• Interruptions pause the flow but don’t insert retries or circuit breakers automatically. If an agent hangs or returns bad data, you either rerun or craft a reroute path; there’s no built-in “retry three times” primitive.

• Long-running workflows rely on persisted event logs; there’s no distributed queue, SLA enforcement, or programmable backoff policies.

• Error handling is human-readable but it’s not the deterministic state machine you might expect from your BPM suite.

• This is very heavy on LLM judgment calls. In a real deployment, would you really trust an AI to decide when tax compliance checks are needed? Probably not without guardrails.

• This is only for single MCP servers. You can’t orchestrate across multiple systems of record in one flow.

If you need an automation you can trust with regulated processes, want contract-level guarantees, or prefer creating a plan without learning json, that’s exactly what our core INXM platform delivers.

The bridge workflows are meant to be the on-ramp: you prototype intent with natural language, close the loop with single MCP tools, and when it’s time to industrialize the flow, combine multiple MCP servers with integrated scalable runtime, you graduate to INXM’s production-grade workflow engine, no rewriting required, just a handoff to the platform that was built for predictable orchestration from day one.

Because as Kamil said: Enterprise AI does not fail because of missing intelligence. It fails because it lacks enterprise grade cognitive orchestration.

In large machine and plant engineering organizations, work rarely slows down because information is missing.
It slows down because work has to be done repeatedly, by hand, across domains.

Once the data is available, the real effort begins:

• Someone has to take the technical inputs and fill the approval documents.

• Update the control plan.

• Prepare or adjust compliance and waiver documentation.

• Generate test reports.

• Store them correctly across multiple systems.

• Notify the relevant stakeholders about what changed.

• Trigger the next set of approvals.

• Prepare and update the SteerCo slides.

• And finally, inform the customer.

None of these tasks is exceptional.
All of them are necessary.
And all of them happen every single day.

The problem is not that this work is complex.
The problem is that it is repetitive, administrative, and distributed across people who are involved in many projects at the same time.

Approvers are not waiting for work to arrive. They are already overloaded.
So execution waits.

Projects wait for approvals.
Approvals wait for documents.
Documents wait because someone must manually carry information from one system to another and repeat the same steps again and again.

From the outside, this looks like slow delivery.
From the inside, it is unowned execution.

This is the part of enterprise work that most AI initiatives never touch.
Not because it is intellectually hard, but because it requires orchestration.

Decisions still stall. Execution still fractures across systems. Risk and compliance have become harder, not easier, to control. This is rarely a model problem. It is almost always a structural problem.

At INXM, we built the company around a clear conviction:

Enterprise AI does not fail because of missing intelligence. It fails because it lacks enterprise grade cognitive orchestration.

The Enterprise AI Paradox

Most enterprises now treat AI as unavoidable. Dedicated budgets are common. AI initiatives span sales, operations, engineering, quality, finance, and IT. In many organizations, dozens of pilots run in parallel.

Yet only a small fraction ever reaches enterprise-wide impact.

The reason is straightforward. AI is still being deployed through an application-centric lens. Each use case is optimized locally. Each team introduces its own tools. Coordination, validation, and risk management remain manual.

AI improves individual tasks.

It neither accelerates the organization nor brings the work of the table.

Without orchestration, AI simply increases the speed at which fragmentation occurs.

Why “Agent-First” Approaches Break at Scale

As pilot fatigue grows, many organizations turn to autonomous agents as the next step. The promise is compelling: let AI systems execute tasks independently, collaborate across domains, and remove humans from the loop.

In practice, this approach often collapses under its own weight.

Agent-first architectures introduce systemic issues:

• No shared control over execution paths

• Limited visibility into how decisions are made

• Inconsistent enforcement of policies and constraints

• Growing human supervision instead of less

Rather than eliminating manual work, employees become responsible for monitoring and correcting AI behavior. They turn into “human middleware” between systems that still do not truly work together.

Agents are powerful.

Without orchestration, they amplify complexity instead of reducing it.

The Shift to Enterprise AI Orchestration

What enterprises actually need is not more agents or smarter copilots. They need a governing operational layer.

This is Enterprise AI Orchestration.

Enterprise AI Orchestration is a controlled execution layer that coordinates AI, systems, and humans across the organization. It sits above existing enterprise platforms and ensures that AI-driven actions happen in the right order, under the right constraints, and with full traceability.

Its role is not to replace existing systems, but to bind them together into coherent execution.

Enterprise AI Orchestration:

• Owns end-to-end decision flows

• Enforces governance by design

• Makes execution auditable and reproducible

• Allows AI to act only within defined boundaries

This is the architectural layer missing from most AI strategies today.

Why INXM Exists

INXM was built explicitly as an Enterprise AI Orchestration platform.

Not as another application.

Not as a chatbot.

But as an operational layer that turns AI from an advisory tool into an execution capability.

At the core of INXM is a planning and execution model where every meaningful business activity is treated as a plan. Plans define how work flows across systems, agents, and humans. They are small, reusable, and executable.

A plan can:

• Call enterprise systems through governed integrations

• Invoke AI models where reasoning is required

• Route approvals and wait for human decisions

• Handle dependencies, exceptions, and retries

• Produce a complete, traceable execution record

Plans can reference other plans. They can be reused across departments. Over time, they become the organization’s executable operating knowledge.

This is orchestration as infrastructure.

How Orchestration Changes Enterprise Work

With INXM, AI no longer operates at the level of isolated tasks. It operates at the level of decisions and outcomes.

A customer request becomes a coordinated execution that checks feasibility, compliance, and capacity across systems before a commitment is made.

A quality deviation becomes a structured lifecycle that links specifications, historical cases, root cause analysis, corrective actions, and regulatory documentation into one controlled flow.

The key difference is not just speed.

It is reliability at scale.

Work no longer depends on individuals remembering how to navigate complex processes. The logic of execution is embedded into orchestrated plans.

Why This Is a Board-Level Decision

Boards do not govern AI tools.

They govern risk, resilience, and long-term competitiveness.

Enterprise AI Orchestration directly affects all three.

Without orchestration:

• AI usage fragments into shadow systems

• Compliance becomes reactive

• Execution risk increases as autonomy grows

• Knowledge leaves with people

With INXM as an orchestration layer:

• AI execution is policy-bound and auditable

• Decisions are reproducible rather than probabilistic

• Risk is managed structurally, not manually

• AI becomes a dependable operational asset

This is why orchestration cannot be delegated as a purely technical concern. It shapes how the organization operates.

The Strategic Choice Ahead

Enterprise AI is moving from experimentation to obligation.

The organizations that win the next decade will not be those with the most models or agents. They will be the ones that establish Enterprise AI Orchestration as a core capability.

INXM was built for exactly this transition.

The question for leadership is no longer whether to use AI, but whether the organization is architected to let AI run work safely, consistently, and at scale.

“We deployed AI, but our organization isn’t getting any faster.”

It is a striking observation, considering the vast sums poured into copilots, assistants, generative search, and productivity tools. Yet the disappointment is not a failure of technology. It is the consequence of a fundamental misunderstanding of the type of work organizations actually need to automate.

Most companies today rely on two classes of AI systems. They are often blended together in conversation, but they operate on entirely different levels:

• One class improves the experience of work.

• The other changes the logic of work itself.

Confusing the two leads directly to stalled transformation efforts.

The first class: copilots, intelligent add-ons, AI search functions acts like vitamins.
- They are useful.
- They make daily tasks more comfortable.
- They reduce the friction of finding information, generating content, or summarizing meetings.
- They deliver answers, insights, and clarity.
- They reduce cognitive load.

But vitamins, no matter how effective, do not treat acute operational pain.
They do not change bottlenecks, workflows, or throughput.
They enrich knowledge.
They do not create significant movement.

And that is the crucial point.

Because what executives across industries actually seek has very little to do with “better information.”

When you speak with COOs, plant managers, heads of engineering, or sales leaders, the pattern is unmistakable.
- They do not want another tool; they have enough so far.
- They do not want another dashboard filled with insights.

What they want – though it is rarely phrased so directly – “is a system that takes work off the table”, not one that merely assists in doing it.
They want a system that works.
Not a system that helps them work better.

This is why the label “assistant” is misleading. Assistants answer questions, summarize content, and explain data. They are valuable but they do not alter the flow of operations. The number of handovers remains unchanged. The same tickets circulate. The same approvals clog the pipeline. The same Excel files travel across inboxes.

An assistant improves awareness.
It does not improve execution.

The turning point comes when organizations recognize that what they lack is not a new interface, but an entity that can operate their existing systems on their behalf.

That realization marks the entry point into a fundamentally different category:

Orchestration.

🚫Orchestration is not a chat window
🚫It is not a sidebar feature
🚫It is not an Add-on “AI inside a product”

Orchestration is

• ✅an Operational Layer

• ✅that converts information into actions,

• ✅and actions into completed work.

It is the context in which INXM operates.

INXM does not build another copilot or add-on. We provide a Cognitive Orchestration Layer that works inside a complex enterprise environment with the same standards of security, governance and auditability that define mission-critical operations. By connecting directly to your systems PLM, MES, QMS, ERP, engineering assets, regulatory rules and capacity data, all under the customer’s control, INXM enables AI to participate in the actual execution flow rather than observing it from the outside. It gives enterprises the mechanism for turning AI-generated recommendations into structured action across their core systems.

Where a copilot produces text, INXM. Orchestrator produces PLANs:

• structured, executable sequences of steps

• that run deterministically across your systems
  (ERP, PLM, QMS, CRM, ticketing)1

In this model, tasks are decomposed into atomic steps – each one linked to data, conditions, dependencies, and system interactions. These steps form a plan that is reproducible, auditable, and capable of spanning multiple systems end-to-end. The machine executes what it can autonomously and hands off to humans only where judgment, risk assessment, or accountability require it. This distinction is not theoretical. In daily operations, it is transformative.

• A customer request is not merely summarized and drafted into a reply. It is classified, checked against product data, validated against available capacity, simulated against material constraints, converted into multiple delivery scenarios, and prepared as a ready-to-approve offer.

• A production deviation is not merely explained. It is contextualized with specifications, logs, and historical cases; evaluated for risk; converted into a structured QMS entry; mapped to CAPA actions; distributed to the right systems; and followed through to effectiveness verification.

Through orchestration, operational work becomes a distributed system of PLANs:

• one plan extracts and analyzes incoming requests

• another checks capacity and material availability

• another creates deviations

• another executes and tracks CAPA steps

• another generates an offer

• another routes follow-up actions when thresholds are breached

• another triggers new plans based on completed steps

• …more 100x

No individual plan is revolutionary.
But collectively, they absorb a significant share of the operational load.
This is where organizations finally start to feel faster.

The real surprise for many executives is that they have not “implemented enterprise grade AI” – they have implemented another tools – copilots, assistants and add-ons. Helpful, impressive, often delightful assistants. But not systems that carry operational weight.

This explains why productivity remains flat despite AI expansions.
The problem is not model quality.
It is architectural.

Organizations that invest heavily in speech interfaces, copilots, and summarization tools without investing in orchestration will consistently find themselves better informed but not more capable. The bottleneck is not knowledge – it is coordination.

The strategic shift ahead is therefore not about better models, but about building an operational layer that can execute the work those models recommend. Copilots remain useful and should continue to be deployed. But they do not replace the need for a structural system that moves processes forward across the enterprise stack.

In this new frame, the difference between both classes condenses into a single sentence:

Copilot: 💡 “Here is the information you need.”

Orchestrator: ✅ “Here is the completed result. I’ve created and saved the related documents in PLM, started the Engineering Change Request, informed each project team domain about their specific impacts and updated the daily tomorrow including the project dashboard.” 

This is why orchestration is not just another AI category. It is emerging as the missing infrastructure that turns fragmented enterprise systems into a coherent operational engine – one capable of lifting work out of email threads, meetings, and manual handoffs, and into structured, machine-driven execution.

Companies that continue to invest exclusively in assistants will remain in a world of Vitamineffekte: helpful, pleasant, but ultimately superficial.
Companies that invest in orchestration will begin to shrink their operational workload in a way that no copilot, no matter how advanced, can deliver.

When executives today say, “We have AI, but we are not faster,” the solution is rarely another feature or another generative tool.
It is almost always the absence of orchestration – the layer where AI stops advising and starts working.

And that is the step that finally turns digital ambition into operational reality.

About INXM

Every large industrial enterprise runs its mission critical programs on a dense landscape of PLM systems, MES platforms, QMS environments, engineering documents, regulatory rules and capacity data. These systems keep the organization running, yet they rarely work together in a way that enables fast decisions or consistent execution. INXM is built to change that.

INXM provides a cognitive orchestration layer that operates inside your infrastructure and augments your workforce. It does not replace people. It works as an extension of them. When INXM triggers a workflow or sends a message into Teams or Jira, it acts in the name of the authenticated user and only within the permissions that user already has. INXM sees only what the user sees and performs only the actions the user approved. This preserves enterprise governance while unlocking a new speed of execution.

The Enterprise MCP Bridge, one of our essential parts of INXM. Orchestrator the controlled gateway through which AI can interact with your systems. The bridge turns arbitrary MCP servers into secure, observable, enterprise grade interfaces. It adds capabilities many systems do not provide on their own such as filtering, OAuth, routing, traceability and clear auditability. INXM never exposes internal systems externally. The bridge ensures that retrievals, tool calls and actions stay inside your network and remain bound to your authentication and access policies. This is how INXM integrates with complex landscapes without requiring architectural change.

This architecture also introduces self healing for mission critical workflows. INXM plans run through a managed execution layer with retry logic, failure tracking, dependency checks and success trees. Transient problems such as expired tokens, timeouts or schema mismatches can often be detected and resolved within the platform. IT teams no longer need external support after every update to fix brittle integrations or broken connectors.

INXM fits directly into existing IT operating models. It can run on premises or in a private cloud. It uses your authentication provider. It respects your RBAC setup. It connects through the network boundaries you define. It works with your preferred LLM setup or with hosted open source models provided through the TGI Manager. This gives enterprises full data sovereignty and full control of the AI execution environment.

With this foundation in place, organizations can orchestrate work where speed, precision and compliance matter most. Examples include engineering evaluations, quality deviation handling, regulatory checks, technical compatibility validation, corrective actions and cross functional coordination.

INXM gives enterprises a way to let AI operate across their landscape without redesigning architecture or compromising governance. It connects every part of a mission critical workflow into something reliable, auditable and repeatable.

INXM provides the cognitive orchestration foundation. Your teams provide the expertise. Together, execution across mission critical programs becomes faster, more resilient and enterprise aligned.

Recent months have been full of conversations about AI, transformation, and the uncomfortable question of why companies invest millions in new technology but experience almost no real change. In many organizations, the topic now simmers quietly under the surface. “AI” exists, expectations are high, use cases appear endless, yet daily life looks nearly unchanged. The same meetings, the same bottlenecks, the same manual coordination loops. Leadership voices: “We deployed AI, but the organization is not getting any faster.”

This gap has a root cause that is easy to overlook. It has little to do with algorithms, models, or tools. It has everything to do with culture, power structures, and the actual logic of work. AI forces companies to reveal how work truly flows. Not how it is described on paper, but how it actually happens. Informal, distributed, fragmented, political, friction-filled. This is where a critical realization emerges: Adoption is not a software problem. Adoption is a cultural phenomenon.

The Copilot Trap: Why Assistance and CompanyGPT Isn’t Transformation

Most companies begin their AI journey with a copilot. A tool that writes text, summarizes emails, explains information, performs minor analyses. It feels modern, elegant, productivity-enhancing. The first weeks are often impressive. People test limits, enjoy quick wins, and celebrate having a smarter assistant for daily work. But the curve flattens quickly. Usage stagnates, teams drift back into old patterns, enthusiasm fades, adoption stalls. A false conclusion emerges: AI does not work in daily life.

The truth is simpler. A copilot changes supports tasks but not the dynamics of work. It sits at the edge of the system, not in the center of your workflows. It provides answers, but coordinates nothing. It supports you creating ideas and insights, providing you recommendations in best case, but does not shape flow. It is helpful, but it does not transform a process. Transformation is created by coordination, not assistance. This is the blind spot in most initiatives.

The Pivot to Cognitive Orchestration: Relieving the System

Once AI moves beyond preparing decisions and begins coordinating the steps that follow, the organization reaches a natural next stage. Responsibilities become clearer, process chains become more predictable, and automated handovers link departments in a way that reduces friction rather than creating it. What previously required dozens of small manual actions can now flow with structure and reliability. This is not a loss of control. It is an opportunity for teams to focus on decisions instead of pushing work through the system.

Many companies discover at this point that their speed limits were never caused by missing technology. They were the result of processes designed for another era, where every step required verification and every handover triggered another alignment. Cognitive Orchestration does not break these structures. It relieves them. A copilot helps individuals work faster. An orchestrator helps the whole organization work cleaner, with fewer stops and more confidence in the flow of work.

From “Help Me” to “Move the Work Forward”: Making Adoption Stick

Copilots deliver quick wins and reduce personal workload, but they do not change how tasks travel across the enterprise. Work still moves manually from person to person. Faster, yes. But not more scalable. That is why early excitement often levels off: the underlying system has not evolved.

With cognitive orchestration, that changes. Pockets of efficiency connect. What used to be parallel efforts becomes a single coherent process. Teams no longer rely on workarounds or shadow workflows. Leaders no longer see only insights; they see momentum. The organization feels the difference between “AI helps me” and “AI moves the work forward.”

This is the natural next step after copilots. Not disruptive. Not threatening. Simply the progression from individual productivity to organizational performance, the point where AI becomes part of how the business runs rather than something that sits on the side.

The Turning Point: When AI Starts Acting

Transformation begins when AI triggers actions, synchronizes data, connects departments, and orchestrates workflows. When AI becomes part of the operational rhythm. When it does not describe work but performs it.

Consider a few examples:

• A single late-delivery signal launches an orchestrated multi-agent chain.

• One deviation triggers twelve interconnected plans.

• A customer request activates more than fifteen plans in parallel and brings them together into one result.

more… (mail me to discuss more)

This is the shift. Work flows as structured execution, not recommendations. AI is not asked; AI acts. The system performs steps autonomously and calls humans only for exceptions. The organization begins to relieve itself instead of simply informing itself.

The Innovation Ceiling: The Danger of Stopping Early

The biggest mistake today is declaring victory after deploying a copilot. Statements like “we now have AI” or “we introduced a copilot” create a false sense of progress. It is like buying a car and only using the seats. A company builds its own innovation ceiling. A polished facade with an unchanged core.

The cost is high. Missed velocity gains. Missed quality improvements. Missed cross-functional synergy. And most importantly, an organization that believes it has transformed while nothing fundamental has changed.

Don’t Just Optimize the Old World. Build a New One

Where this leads is a new operational reality.

Companies using AI for assistance make people faster. Companies using AI for orchestration make work faster. This is the difference between optimization and transformation.

The operating model changes fundamentally. Fewer handovers. Fewer dependencies. Fewer wait times. Fewer searches. Fewer manual routing steps. In parallel, more clarity. More consistency. More visibility into risks, bottlenecks, and decisions.

A production logic emerges that no longer depends on manual steering. Teams shift from gatekeeping to supervising. Decisions become traceable. Processes become auditable. Quality rises through structure, not oversight.

This is where the next evolution of work begins. The game changer. The next thing companies are searching for.

The Final Picture: Optimization vs. Reinvention. Transformation is a path.

The future belongs to organizations that treat AI not as an assistant but as an operational coordination layer, not as a gadget but as process intelligence.

The true shift begins with a simple realization: typing faster does not make the enterprise faster. Workflows must change. This separates organizations that merely adapt from those that reinvent themselves. Those who settle for assistance will build a slightly improved version of their old world. Those who embrace orchestration will build the next generation of industrial operations and shape the decade ahead.

About INXM

Every large industrial enterprise runs its mission-critical programs on a complex landscape of PLM systems, MES platforms, QMS environments, engineering documents, regulatory rules and capacity data. These systems keep the company running, but they rarely work together in a way that enables fast decisions or consistent execution. INXM is built to change that.

INXM provides an cognitive orchestration layer that connects directly with systems and people, to your authentication system, infrastructure, network and model setup. This allows AI to operate inside your environment with the same security and compliance expectations that already govern your mission-critical operations.

At the center of the platform is the Enterprise MCP Bridge, which makes your systems accessible to AI in a structured and controlled way. It supports filtering, OAuth, and routing so the cognitive orchestration layer can retrieve requirements, specifications, guidelines, regulatory inputs, capacity data, historical deviations, or ticket information without exposing systems externally. All integrations remain under your ownership.

Because INXM runs inside your infrastructure, it fits directly into existing IT operating models. It can run on-prem or cloud, connect to systems and people and respect the authentication and access policies already in place. It can use your preferred LLM setup or hosted open-source models where appropriate.

This architecture makes it possible to orchestrate work where speed, precision and compliance matter most. Companies can use INXM to support engineering evaluations, quality deviation handling, regulatory checks, technical compatibility validation, corrective actions, and cross-functional coordination.

INXM gives enterprises a way to let AI operate across their landscape without changing the underlying architecture. It ensures every part of a mission-critical workflow is connected, secured, and repeatable across the organization.

INXM provides the cognitive orchestration foundation. Your teams provide the expertise.

Together, execution across mission-critical programs becomes faster, more reliable, and fully aligned with enterprise governance.

I think what you want is your agent to go away and do really good work for you, and then come back with its work product to let you review, steer it, decide everything. But you can’t be overwhelmed, because it’s gonna do so many more things than you have time to look at, and if you’re always looking at it, you know, it can be slower than if you just did it yourself. And so it actually strikes me as an interface problem.

— on A Cheeky Pint Dario had this to say about the future of AI

The software we currently use is based on the idea of direct manipulation. It’s easy to describe as “you move a file into a folder by dragging the file into the folder”. Software wasn’t always like this. In fact a lot of developers today still use command line interfaces where you input commands and get an output. CLIs are more like indirect manipulation. But what does this have to do with AI? This interaction model needs to change, because AI breaks the assumptions direct manipulation rely on.

AI models are unpredictable, they are non-deterministic, and much slower than traditional code, which makes it impossible to use them for direct manipulation. We can use them for indirect manipulation (photo from photoshop), for example using Photoshops new magic eraser tool you can select the thing you want to remove from a photo and ask AI to do it. But you can’t just drag the thing out of the image. AI is fundamentally unpredictable, which makes it unsuitable for direct manipulation.

If direct manipulation doesn’t work, how should we work with AI? Here’s another clue from Dario’s quote, he talks about an example where you have several AI Agents doing work for you. And your job is to guide them, to help them understand when they’re doing something right and when they’re getting it wrong.

The more Agents you have working for you, the better! But the more Agents you have doing work for you, the easier it is to get overwhelmed.

At INXM we’re currently experimenting with ways of solving this, and no doubt we will find even better ways of working with AI over time. But we’ve already made meaningful improvements by building our platform to be asynchronous first. You don’t sit there watching AI writing a wall of text. When it needs your input, it will come to you.

You ask INXM to do something and the platform creates a plan to reach that goal. It tells you about it, and you give feedback. This process can happen once or ten times until you’re ready to let the plan be executed.

While INXM is doing work for you the same feedback loop continues happening, if something doesn’t go according to plan the platform will ask you for feedback or next steps before it continues working.

When INXM is done working for you, it again comes back to ask for your input.

The key here is that we treat all work as fundamentally asynchronous. The platform does work for you, and then asks for input. Whether that’s while it’s figuring out a plan to do something complicated, or checking your CRM notifications, or collecting feedback from the department heads. The specific task doesn’t matter. You simply ask it to do work, and you can trust that it will come back to you with whatever the result is. This workflow is a shift from direct manipulation to guided orchestration, the interaction model AI actually requires.

This doesn’t stop you from checking on long running work however, everything is transparent in INXM, there’s no magic black box where some agent can run amok. If you wonder why we’re still waiting on the sales report, you can just open the task and see what we’re waiting for. Steve didn’t answer? Ask INXM to reach out again.

Summary

We were happy to learn Anthropic aligns with us on what the future of work looks like. But we suspect most of the world is starting to have the same realisations we’ve been working on for the last year.

Come with us as we reinvent how we do work.

• The old way lives inside systems that only talk to people. Every delay depends on someone catching what a system cannot see. Every correction arrives late because it relies on attention.

• The new way connects systems to each other but overwhelms people with more information than any team can absorb. Speed rises. Control falls. Teams swim in signals, not clarity.

• The emerging way introduces something different. An Orchestration Layer that understands intent, guides actions across the entire landscape, and protects the organization from the tiny cracks that quietly grow into strategic problems. It is not a replacement for systems or for people. It is a missing layer that finally understands both.

Remaining in the first two ways means slow reactions and fragmented responsibility. Decisions are shaped by what happens to be noticed. Moving into the third means the system carries the complexity. People regain clarity. The enterprise stops losing ground in moments that should never have been surprising.

The idea of a layer that serves both systems and people

Inside almost every large organization, I see a new structure is taking shape. It does not erase what exists. It elevates it. A layer that reads how work should flow, understands the rules beneath it, and acts through every system involved.

It bridges the point where tools stop being helpful and people start becoming tired. It listens. It interprets. It moves work forward without waiting for someone to piece the picture together by hand.

In this era, progress no longer depends on a person spotting a single change at the perfect moment. The layer stands between the scattered machinery of the enterprise and the people who guide it. It translates intention into action and complexity into clarity.

How the layer behaves

This layer behaves in a way no traditional workflow engine ever could.

• It speaks machine language and human language.

• It interprets, reasons, sequences, and acts.

• It connects signals to consequences across the entire landscape.

What once required messages, meetings, and manual recalculation now unfolds as one coordinated response. A shift in capacity triggers adjustments in procurement. A risk in supply ripples through scheduling. People step in only when their judgment is needed.

Picture a change in demand. In the old pattern someone edits spreadsheets, informs production, contacts suppliers, and chases confirmations. With the new layer the actions move orchestrated from system to system and people. The organization behaves like a single body instead of a set of separate departments.

How is it different from a chatbot?
A chatbot answers questions. An Orchestration Layer does something categorically different: it interprets signals across systems, resolves contradictions, sequences actions, and moves work between humans and machines. It doesn’t wait to be asked it works continuously, like an operational nervous system. No rule-based workflow engine can do this, because the complexity changes frequently.

What an enterprise Orchestration Layer actually means
An Orchestration Layer sits above all your systems and people. It listens to signals from systems and people. It interprets what’s happening, and orchestrates specialized agents to take safe, auditable actions keeping the employees in the loop. Instead of every team navigating dozens of tools, the Orchestration Layer becomes the single coordination point, understanding the full picture and ensuring every workflow runs the way the business intends.

Example to make the idea concrete
Imagine a late supplier delivery. A chatbot would merely tell you the expected delay. An Orchestration Layer automatically checks inventory buffers, recalculates the production plan, evaluates customer impact, triggers supplier escalation if needed, and asks a human only for the final approval. One instruction in natural language triggers a full chain of safe, traceable actions.

Why enterprises that adopt this layer pull ahead

Organizations that adopt this layer gain a structural advantage. They reduce the hidden workload that employees once carried. They narrow the space between understanding and action. They avoid tiny operational issues that often escalate into strategic cost.

The complexity moves into the system that can handle it. The clarity returns to the people who deserve it.

The INXM Orchestrator platform is built to deliver this layer. It provides a reliable foundation where systems and people operate together with speed, consistency, and control.

We don’t believe that free text is the future of interfaces. Instead, we think the future lies in systems that can generate constrained, guided interfaces from natural language descriptions. This gives users the best of both worlds: the flexibility to express their needs in their own words, and the structure to ensure valid, efficient interactions.

For the teams and operators who just want to get work done, the Bridge now does the heavy lifting: you describe the screen you need in plain language, it understands the tools and data your company already trusts, according to their access rights, and it responds with a polished, guided interface ready to use. No fiddling with prompts, no waiting on a developer, just the right buttons, filters, and guardrails appearing where you need them.

The Enterprise MCP Bridge now generates complete web applications from natural language prompts. No build step, no frontend framework, no separate repository. The bridge takes in your prompt, reads your MCP tool schemas, generates an interactive UI, and serves it scoped to user or group identity.

Let’s have a look

Generating a User Interface for an time-off mcp server with a short prompt

What is this about and why do you need that over everything else that exists in the world

This is what happens when the systems you already rely on finally meet an interface that speaks their language. You can literally tell the bridge, “generate me a nice interface to our ERP to hand in my purchase request” and in a few seconds you have a guided workflow that respects the same rules your ERP team guards so carefully. The bridge reads the MCP schemas your ERP provides, inspects your current processes, surfaces the right controls, and gives you a safe, branded UI that plugs straight into production.

Instead of filing a ticket and waiting weeks for a bespoke dashboard, you describe the job in plain English. The bridge keeps every permission, audit requirement, and design token intact. Your operators get a purpose-built screen, your security team gets the audit trail, and your product teams get to move on. It’s the fastest path from “I wish I had a button for this” to an interface that exists, behaves, and persists like any other first-party app.

Tech Deepdive - How it works

When you POST a prompt to /_generated/{scope}, the bridge:

1. Extracts your OAuth identity and validates scope (user or group)

2. Queries the MCP server for available tools and their input/output schemas

3. Constructs a generation request with tool definitions and your design system prompt

4. Streams structured JSON over SSE as the LLM generates HTML and metadata

5. Writes the result to disk as a versioned artifact with full history

The generated HTML uses pfusch - a minimal progressive enhancement library that runs in the browser with zero build tools. State is mutable. DOM updates are direct. Event listeners are declarative. The model produces working HTML first, then enhances it with reactive components.

A single request:

curl -X POST “<http://localhost:8000/_generated/group=eng>” \
  -H “Content-Type: application/json” \
  -d ‘{
    “id”: “absence-dashboard”,
    “name”: “Absence Dashboard”,
    “prompt”: “Show employee absence data with filters for date range and type”,
    “tools”: [”list_absence_types”, “get_absences”]
  }’

When complete, the dashboard is available at /_generated/group=eng/absence-dashboard/Absence Dashboard?as=page.

If the result is not satisfactory, you can POST what you want changed to the same URL again:

curl -X POST “<http://localhost:8000/_generated/group=eng/absence-dashboard>” \
  -H “Content-Type: application/json” \
  -d ‘{
    “prompt”: “Add a bar chart showing absences by type”
  }’

The bridge will review the past changes, apply the new prompt, and generate an updated UI.

And each update appends to the history array. As we add more features you will be able to diff prompts, compare outputs, and roll back to previous versions. The metadata tracks who changed what and when, giving you a full audit trail.

Scoping and access control

Generated UIs inherit authentication from the facade. User-scoped apps (user=alice) are writable only by that user. Group-scoped apps (group=eng) are writable by any group member. All fetch calls from generated UIs include the user’s OAuth token, so MCP tools enforce the same access control as programmatic API usage.

The bridge stores each UI as a JSON record:

• metadata: scope, creator, timestamps, full generation history

• current.html.page: Complete HTML document

• current.html.snippet: Embeddable fragment

You can retrieve the raw JSON (?as=card), render the full page (?as=page), or embed the snippet (?as=snippet).

Tool schema awareness

The LLM receives tool definitions with both input and output schemas. When generating fetch calls, it knows:

• The exact endpoint: {{MCP_BASE_PATH}}/tools/{tool_name}

• The POST body structure (input schema)

• The response envelope (MCP protocol: { content, isError, structuredContent })

• The data structure inside structuredContent (output schema)

This eliminates guesswork. The model doesn’t hallucinate field names or invent API contracts. It reads the schema and generates correct fetch logic. This also means that this works best with defined input/output schemas rather than freeform text.

Design system integration

LLMs are already great working with MCP tools - thanks to the Enterprise MCP Bridge they can now leverage that knowledge to build interfaces that interact with those tools as they would, as they are available in their most native web form (REST), making it easy to integrate it into any website.

Many people and companies have shown UIs created by AI, but few have tackled design system integration. More often, each generated UI is a one-off that looks different from the rest of the product, and from itself if regenerated later.

This is not what you need in an enterprise setting. The bridge solves this by integrating with your existing design system.

To help it understand your design system, you can define a system-defined prompt named design-system and the bridge injects it into every generation request. The model applies your typography, spacing, color tokens, and component patterns automatically. Update the prompt, regenerate the UI, and the new design is applied without touching code. You can directly embed the snippets into your existing applications, as long as you follow this rule: Because pfusch components use shadow DOM, you must mark shared styles with data-pfusch

<link rel=”stylesheet” href=”/design.css” data-pfusch>
<style data-pfusch>
  .card { border: 1px solid var(--gray-200); }
</style>

This allows Pfusch to automatically link the relevant parts into the shadow dom, styling components as you would expect it.

The bridge’s generation prompt documents this requirement, and the model includes it, so for pages this is automatic.

Why this changes the calculus

Traditional frontend development for enterprise tools costs months and requires dedicated teams. This system collapses that timeline to minutes. Product teams describe requirements in prose. The bridge generates working interfaces that call real APIs, enforce real permissions, and apply real design systems.

If the tool schema changes, regenerate the UI. If the design system evolves, regenerate the UI. If a new feature is needed, send a new prompt. The cost of iteration drops from sprint cycles to seconds.

For compliance-heavy organizations: one LLM gateway, one authentication boundary, one audit trail. Generated UIs are artifacts you can version, review, and deploy through your existing infrastructure. We have open sourced the Enterprise MCP Bridge to make it easy to more companies to move in this direction. The Enterprise MCP Bridge, however is only a small step. Our platform is an integrated solution that allows you to Vibe Code, not just a single UI, but your entire enteprise.

View the release on GitHub

It’s because your organization has evolved into something far more complex than anyone designed, a network of systems, data and dependencies that no single dashboard can explain anymore.

The limits of “Digital Transformation”

The past two decades were about connecting what used to be disconnected. We replaced paper with systems, linked those systems through APIs and automated repetitive work. That journey was necessary. It made companies faster, more transparent and more data-driven. But in reality, this progress never happened all at once. Digital transformation unfolded situationally whenever there was budget, leadership momentum or a local need to improve. A new plant manager modernized quality KPIs reporting. A procurement team introduced a supplier tool. Engineering built a local database to track changes. Finance added an integration to share master data overnight. Piece by piece, every initiative made sense. Together, they created a landscape of mixed maturity levels, some workflows still on paper, others managed through PDFs, some running in standalone applications, others loosely connected through APIs and a few already synchronized across platforms. It’s progress, but it’s fragmented progress.

Every domain evolved on its own timeline and now, coordination across those timelines has become the real challenge.

The real inflection point

Most organizations have reached a new ceiling. Processes seems connected but are not. Automation exists but it’s static and brittle. Data flows but intent doesn’t. So leaders find themselves in a strange in-between the company is “digitally mature” on paper, yet operationally tangled in a thousand small dependencies. That’s why the next decade won’t be about more fragmented digitalization initiatives. It will be about building and re-think the way enterprises have worked for decades – one that allows enterprises to unfold unlimited value creation.

A different kind of infrastructure

This new foundation is not another app or integration.
It’s an Enterprise Intelligence Spine, a living layer that connects its multiple plans with systems, agents, artificial intelligence and enterprise domains into one coordinated whole. It learns how people and systems work together and orchestrates them toward a shared goal. Production KPIs, supplier schedules, quality alerts, engineering changes, invoices, delivery notes, project plans – all of them can flow through this intelligence spine of each domain and their plans, adapting in real time as conditions change. This is not automation in the old sense, static rules or scripted workflows. It’s adaptive coordination, where intelligence is built into the fabric of operations. Over time, the enterprise begins to steer itself – not by removing people, but by freeing them from the endless work of manual coordination, so they can focus on what only humans can do: innovation, judgment and responding to the unexpected.

From transformation to intelligence

This is the quiet shift already underway from digital transformation to enterprise intelligence. In this model, leadership changes meaning.

Executives don’t manage every data flow or process directly, they define intent, set policies and ensure the system learns from outcomes. Control gives way to comprehension.

Instead of asking, “What went wrong?” leaders can ask, “What did we learn from this and how will the enterprise respond next time?” That is the beginning of true enterprise intelligence with real impact.

The quiet disruption

No one announces this change with a press release. It doesn’t look dramatic from the outside. But inside the company, the impact is profound. Enterprises with an intelligence spine make decisions faster, recover from disruptions sooner and operate with a coherence that traditional systems can’t achieve. They stop managing data and start directing intent. They stop chasing efficiency and start enabling adaptability. That’s how the next decade will be won – not through the next add on subscription in a legacy system, but through a foundation that allows the enterprise to run itself intelligently.

The over-next step

Eventually, this (r)evolution reaches its natural maturity plans in production, logistics, and purchasing begin to operate under their own intelligence, guided by clear policies and human oversight. When disruptions occur, the system already knows how to respond because it learned from the last one, it learned how people solved the unexpected. That’s not a vision of less human work. It’s a vision of more human focus. The real frontier isn’t flow automation, it’s the over-next step, the enterprise intelligence embedded in how the enterprise operates, so that people can spend less time coordinating and more time leading.

The over-next step is not doing digital better, but building a company that learns to run itself safely, transparently and intelligently.
That’s how you win the next decade.

I still see people fall for this, especially each time new models are released.

AI is such an impressive technology it’s easy to start believing that it can think. It can hold a conversation better than I can, it knows more than my college professor. Maybe it actually is intelligent?

But behind the scenes, it’s just technology. Ordinary technology, just very impressive.

“Any sufficiently advanced technology is indistinguishable from magic” — Arthur C. Clarke

There is no meaning-making happening in an LLM. It’s a static mathematical model (static as in it does not change) that predicts what you want to hear, based only on language.

By choosing a specific word or inflection you can make the model behave in any way you want. That’s the magic part, not in a defined number of ways, but in Any way.

You can make it become a raving lunatic, or give you completely incorrect math, or even dangerous medical recommendations.

The companies training these amazing models claim they are in a race to create an Artificial General Intelligence. A super intelligent model that can learn new things. A super human intelligence. Or at least that’s the story they’re selling to us. Because there is zero evidence of this.

How smart is a model that cannot change? No LLM can. This isn’t a small thing, we need totally different models for them to be able to learn. How smart is a model that can be persuaded to agree on bad math?

It’s not smart. Not at all. But it is phenomenal at language. It’s so good, in fact, that we start believing it knows all sorts of things. So good we start believing its magic.

To make useful tools we need to make them understandable first. A calculator or a pair of scissors has a specific function. We understand what function that is, so we can use them effectively, even if we couldn’t explain exactly how a calculator calculates.

At INXM, one of our goals is to make our Orchestrator understandable. While the user can chat with the platform, we’re not trying to pretend it’s magic. It isn’t, it’s just an interface that fully understands your language and what you mean.

INXM Orchestrator can perform the same tasks you can, using the same software and tools. The difference is it does it 24/7, it doesn’t forget, and if something unforeseen happens, it asks you what to do.

It’s not magic. It’s just smart code. But when it asks you what to do next, it feels almost magical.

It can seem like AI is flooding us with slop. But this isn’t a new problem, just an old problem at a higher velocity.

Text as a medium

Text is a magical medium. It lets us send information forwards in time. It can communicate complicated ideas. And it’s very information dense. The right words can communicate an entire world in a paragraph.

Compared to spoke language, reading and writing has a much higher rate of signal to noise.

But text is also demanding. Writing takes a lot of effort. There is even some evidence that rendering fuzzy thoughts into the right words is the active form of thinking. This makes text less great for moments when you need a lot of actions.

Thinking: super fast but fuzzy
Speaking: fast but vague
Writing: slow but specific

This tells us something about how to design better tools for work.

Thought experiment: designing better tools

Imagine if your car was self driving but you would have to manually text it where to go: “Right, Left, Left, Right”. That keyboard would be pounded to bits.

What about voice? Less information dense and takes less effort. Better in the car too. But you’d still get very tired of saying “Right, Left” quite soon.

The better way is to shape the context of information around what the user is trying to do. In a car they always have a destination, so a natural language UI can simply parse that, and then use a routing service to understand where to go. Close to zero effort for the user, they can verify on a map that the car got it right or wrong, no need to read a long text.

“Context is the interface The best agents don’t stay in isolated chat dialogues. They move into surfaces we already trust. “I feel like a browser … because you can do an infinite number of things on a browser and we’re all using browsers.”
— Liam Matteson, Browserbase

This is how we thinking about the future of work.

What is the context our user is in? She’s between meetings, in her email, chatting in teams, or in a face to face conversation. She’s trying to reference data, or complete some process, in her companies software suite.

Anything from “create a new deal flow pipeline in our CRM”, and “look up the material costs of regional projects”, to “Did procurement respond about this request from last week I don’t remember?”

Each request can be made simply through natural language, or through a specific User Interface depending on the users context.

Coming back to our car analogy: INXM Orchestrator understands enough about the landscape she’s in to realise which systems are needed to perform this journey.

Orchestrator then presents that specific UI, in this case a map, to the user so she know where she’s going. And can even add extra stops along the way if they need.

When she accepts, Orchestrator fires off this journey plan as a series of tasks in the systems and programs she normally uses. The map shows her the current progress. And if anything changes Orchestrator will ping her to let her know.

The future of Ai, and of software, is not about reading and writing more text. It was always going to be about showing you information more intelligently. Making it easier for the human user to take the right actions at the right time.

For INXM this means we spend an absurd amount of time testing what information is right for which actions. What is the “map” for something as complicated as “material costs of regional projects”?

This future of work wont be perfected any time soon, but we’re excited about the steps we have already taken. And we cant wait to see you put more work on cruise control.

Today, I’m proud to officially announce our founding team on this journey: Matthias Kainer, Jesper Bylund, and Kamil Klüber and me, Alexander Oelling. Together, we’re building INXM—a future‑of‑work platform shaped by people who’ve shipped rockets, air taxis, industrial automation, and AI‑native products.

Four Perspectives on Building Digital-Physical Systems That Actually Work

Most digital transformation projects fail because they optimize for technology instead of outcomes. Here’s what happens when you combine deep technical expertise, human-centered design, industrial operations, and enterprise scaling—all in one room.

Matthias has spent 25+ years turning organizational chaos into working systems. From early Microsoft code to orchestrating mission-control dashboards at Isar Aerospace and Volocopter, he’s specialized in the hard stuff: replacing legacy COBOL fleet applications with cloud-native microservices, building launch orchestration systems, and doing it in a way that transforms team dynamics rather than just technology stacks. The results speak for themselves: greater than 90% team engagement scores, not through perks but through systems that match how people actually work. He’s published on organizational change, AI, and DevOps, and spoken at DevOpsCon and XP Days. His core insight: technical architecture and organizational design are the same problem viewed from different angles.

Jesper leads AI design at n8n and has spent his career making powerful systems feel intuitive. His portfolio spans flight control software, clinical data platforms, social platforms, video games, and B2B SaaS—domains where complexity is inherent and comprehensibility is critical. His current focus: designing for human-AI collaboration where the AI’s reasoning is legible rather than opaque. In regulated industries and high-stakes workflows, this isn’t about making AI look simple—it’s about making it comprehensible. Users need to understand not just what the system recommends, but why, so they can build trust and maintain control.

Kamil started in metal construction and welding, learning production from the ground up. He’s run projects across the complete value chain—from first customer contact through series production—and helped design automotive production machines that now generate millions in revenue. His experience spans SMEs and global players like HELLA, BASF, and Siemens, where he specialized in end-to-end digitalization and SaaS sales. At INXM, he brings operational depth and commercial focus to revenue, partnerships, and industrial-grade solutions. His advantage: he knows what works on factory floors, not just in presentations.

Alex has 20+ years delivering digital strategies, cloud environments, enterprise applications, cyber security, and IoT across regulated industries. As former Chief Digital Officer at Isar Aerospace and Volocopter, and founder/board member at Sensorberg, he’s built the organizational infrastructure that makes digital transformation actually scale. He helped create VoloIQ for urban air mobility and built internal IT teams, budgets, and processes under aerospace standards—where you need simultaneous speed and rigor, agile development and formal verification, rapid iteration and certification-grade traceability.

What we’re building (and how we’ll do it)

We’re focused on the hard, boring, valuable work: connecting people, process, and data into workflows that actually run the business. Our principles:

• AI‑native from day one — copilots that explain, not obscure.

• Graph over glue — a shared data model instead of brittle point‑to‑point scripts.

• Consumer‑grade UX — built for shift leads, controllers, and analysts, not just developers.

• Compliance‑by‑construction — traceability, role‑based access, and audit trails as first‑class citizens.

Why now

Work has outgrown yesterday’s ticket queues and spreadsheet choreography. AI is powerful, but without an operational memory and clear governance, it’s noise. We’ve lived this gap in aerospace, mobility, AI tooling, and manufacturing. INXM is our answer: a platform that turns fragmented tools and tribal knowledge into reliable, explainable AI driven workflows.

Enterprise MCP Bridge: From Local Tools to Global Minds

With versions v0.2.0 and v0.2.1, the Enterprise MCP Bridge grows up. What started as a REST-Facade for your beloved MCPs, has been turning into something more over the past few releases: a distributed platform for intelligent coordination. These easily created mcp-agents can now reach across remote MCP servers with integrated token management, plan their work through todo-driven reasoning, and start to look less like scripts and more like collaborators. And you can still use it as before - just like we do internally at INXM, a thing we have been way to secretive about, but worry not, we will share much more soon!

Remote MCP Repositories: The End of Local Isolation

Let’s start with the big one: remote MCP server support.

You can now connect remote MCP servers and let agents discover and use them as if they were local. A model in one data center can now tap a service hosted halfway across the world, without custom integration work - and all with the previously built-in authentication/token management and the observability features you would love to have in your other platforms.

This shift isn’t just technical - it’s architectural. It hints at a future where agents don’t belong to a single environment but roam across trusted MCP networks. The bridge now acts as the federation layer between silos, enforcing authentication, caching intelligently, and doing all the boring-but-crucial bits that make distributed intelligence actually work. And you can manage all the connections centrally through your own IT, filtering the available tools and auditing everything that happened.

Todo-Based Planning: When Agents Learn to Think in Lists

The second new capability - todo-based planning - might look humble on the surface. But this one changes how agents reason.

Agents can now plan through structured todo lists. Not the static kind you forget in your notebook, but dynamic, self-adjusting task graphs. The bridge understands todos as actionable, contextual units: things that can be decomposed, tracked, and completed. It’s a foundational step toward autonomous planning, one that you might have seen in other products already.

In practice, this means your agent no longer just executes instructions - it organizes its own work. It can decide what to do first, what depends on what, and what’s blocked. More importantly, you can see it happen. Each todo is a window into the agent’s reasoning. Planning through todos might sound trivial, but anyone who’s worked with multi-step agents knows how brittle improvisation can be. This change introduces a more consistent, inspectable framework for goal-driven workflows - turning lists into logic.

Note that this will happen only if you don’t provide a single, predetermined tool call. If you do provide a tool the agent must call, the agent will execute it directly without generating a todo list.

The Rest of the Iceberg

The releases also bring a wave of polish and refinement:

• Caching and lifecycle management have been overhauled. Connections now keep state predictably across sessions, cutting latency and drift.

• Observability got a boost. Logs are cleaner, and debugging multi-agent interactions finally feels like you’re not spelunking through chaos.

• SDK ergonomics have improved across the board, especially for developers embedding the bridge in locally hosted environments or Claude.

• Configuration is simpler, less fragile, and (hopefully) clearer documented.

These improvements reflect our commitment to quality. With each update, the bridge transforms from a developer tool into robust, production-grade infrastructure you can depend on.

A Bridge That Thinks Beyond Itself

There’s a pattern here - one that’s easy to miss if you only look at the changelog. Every iteration of the Enterprise MCP Bridge pushes toward the same goal: reducing friction between intelligence and systems.

Remote MCPs let agents explore beyond local boundaries. Todo-based planning lets them reason about what to do once they’re there. Combined, they mark the moment where the bridge stops just connecting endpoints and starts connecting intent.

It’s not just a framework anymore. It’s a hint at what happens when you give structure to autonomy - and let distributed systems think together.

Feel free to dig dive deeper into the details and commits here:

• v0.2.0 Release Notes

• v0.2.1 Release Notes

Or check out the new remote MCP example that directly demonstrates these new capabilities by connecting to the remote Github MCP Server!