WHAT VISUAL SEARCH DELIBERATELY DOES NOT DELIVER

Visual retrieval models find the right page, even in a difficult scan. But they give you back an image, not text. You cannot easily copy a line from it, run full-text search across the archive, or build a machine-readable audit trail. For all of that, you need recognised text. This is not a weakness of the new approach, but a deliberate division of labour: search on the image, text extraction via OCR, each stage doing what it does best.

WHAT PADDLEOCR-VL CAN DO

Baidu has released PaddleOCR-VL, an open OCR model that achieves top scores with only 0.9 billion parameters (project). It recognises text, tables, formulas and diagrams in 109 languages and reconstructs the semantic structure of a document. On the OmniDocBench v1.5 benchmark, it leads with around 94.5% accuracy. It is released under the Apache 2.0 licence, so it can be used commercially free of charge and run on-premise. For an SME, that means strong text recognition without a recurring fee and without data leaving the building.

THE HYBRID SETUP

In practice, both approaches run side by side. Visual search finds the relevant pages quickly and preserves layout fidelity. Where that needs to become hard text, for instance for an invoice line item, a contract clause to quote, or an entry into the ERP system, OCR takes over on precisely those few pages. You do not need to run the entire archive through OCR, only what search has already flagged as important. That keeps the pipeline lean and prevents OCR errors from seeping into search from the outset.

THE PRAGMATIC LINE

Either-or is the wrong stance here. Visual search improves finding, OCR improves further processing. Anyone who treats both as tools with clear roles builds a more resilient knowledge base than someone who dogmatically backs one side. How the building blocks fit together, from the encoder to the vector database, is covered in the stack overview.

For a Mittelstand company processing contracts, technical manuals, and multi-page invoices every day, that is the more interesting news. It is not that text recognition is a few points better; it is that an 80-page document no longer has to be cut into pieces and reassembled, and no document has to leave the building to make that happen.

WHAT UNLIMITED-OCR DOES DIFFERENTLY

The core is a modified attention mechanism in the decoder that keeps memory constant. Classic transformer-based OCR models let the so-called KV cache grow with the length of the document. The longer the PDF, the more memory is needed, until at some point it no longer fits into a single processing run.

Unlimited-OCR replaces this component with Reference Sliding Window Attention (R-SWA). This keeps the KV cache constant, regardless of document length. That is exactly what the term one-shot long-horizon parsing means: a long document is read in a single pass, rather than being split into sections whose results are stitched together afterwards.

The training path is notable. The team did not start from zero but continued training the DeepSeek-OCR checkpoint: freezing the encoder and adapting only the decoder over around 4,000 steps. This puts the model in direct lineage with DeepSeek-OCR, which we have already placed in context within the stack discussion. Code and weights are open on GitHub.

WHY THE CONSTANT KV CACHE MATTERS

The real problem with long documents is not the individual page, but the connection across pages. When a model cuts a 60-page document into ten-page blocks, exactly what matters in everyday B2B work gets lost: a table that runs across a page break, a clause that refers back to an earlier section, a line item whose reference figure sits twenty pages earlier.

A constant KV cache allows the entire document to be held in one context. Memory does not grow with length, so structure is preserved across all pages. It also gets faster along the way: Baidu reports 5,580 tokens per second in base mode against 4,951 for DeepSeek-OCR, and with an output limit of 6,000 tokens the gap is around 35 percent.

On accuracy, Unlimited-OCR scores 93.23 points on OmniDocBench v1.5, 6.22 above the DeepSeek-OCR baseline, and 93.92 on v1.6. These are the figures from the paper. On your own documents, what ultimately counts is how the model handles your tables, stamps and forms, not the average on a public test set. A related development is happening with sub-quadratic LLMs, which are making long context cheaper on-prem.

WHERE THIS CHANGES SOMETHING IN THE MITTELSTAND

The benefit arises wherever long, structured documents need to become clean, searchable data. A few concrete examples:

• Contracts and framework agreements. Cross-references and appendices stay readable in context instead of breaking apart at block boundaries.
• Technical manuals and standards. Long documents with figures, tables and numbered sections processed in a single pass.
• Multi-page invoices and receipts. Cleanly extracted text is the preliminary step for structured downstream processing, for example towards e-invoicing.
• Archives and files. Holdings that until now only existed as scans become machine-readable without handing them to a cloud service.

In almost all cases, OCR is not the goal but the first step. Cleanly parsed text is the foundation for a knowledge base with RAG: the better the parsing, the better search later finds the right spot.

OCR OR VISUAL DOCUMENT SEARCH?

Not every document task needs classic text recognition, and that is a fair trade-off to weigh. There is now an entire branch that does not convert documents into text at all, but instead searches them as images, using models such as ColPali or ColQwen. We have described this OCR-free approach separately.

The rule of thumb that has proven itself for us:

• You need the actual characters (invoice amounts, contract clauses, structured extraction, handing off to another system): then there is little way around OCR, and a model like Unlimited-OCR is strong here.
• You need the right spot, not the full text (answering a question against a large body of documents, finding a figure again): then visual document search can be the more direct route.

Often it is both side by side. Unlimited-OCR makes the OCR part of this stack cheaper and more reliable on long documents.

WHAT I WOULD CHECK BEFORE PRODUCTION

A good benchmark score is a reason to test the model, not a reason to put it into production. Before I would put Unlimited-OCR into a client process, I would check four things:

🔸 German documents and handwriting. The benchmark figures say little about German forms, old files or handwritten notes. That belongs on its own test set made of real documents.

🔸 Tables and layout. With B2B documents, the fidelity of tables and columns determines the value. A direct comparison with your existing stack is worthwhile here.

🔸 Hardware and operation. 3B as an MoE with around 500M active parameters is realistic on-prem. What that concretely means in GPU memory and throughput needs to be measured before rollout, not estimated.

🔸 Licence and provenance. MIT permits commercial, on-premise use with no fine print. That the model's lineage traces back to one of the DeepSeek-OCR authors is a quality signal, but it does not replace your own testing.

What I actually find interesting about this release is less the model itself than the direction: long documents in a single pass, small enough for your own data centre, under a licence that restricts no one. This is exactly where document processing in the Mittelstand is becoming practical right now. Which of your documents would you run through first?

BEYOND THE PROMPT

Prompt engineering tunes the question. Context engineering designs the environment the model decides in. For a one-off task, a good prompt is enough. For an agent that runs over many steps, reads tools, and carries memory, the prompt is a small part of what the model sees. The rest, what you retrieve, what you remember, what tools you expose and how, is context, and it decides far more of the outcome. This is why extending an agent harness is mostly context work.

THE FOUR FAILURES TO DESIGN AGAINST

Most agent failures trace back to one of four context problems:

• Context overload. Too much in the window. The model loses the thread, and cost and latency climb. More context is not better context.
• Context poisoning. A wrong or stale fact enters the window and the model treats it as truth. One bad retrieved chunk can derail an answer.
• Token management. The window is finite. Without a plan for what to keep and what to drop, the important detail gets pushed out by noise.
• Stale memory. Long-running agents accumulate context that no longer applies, and act on it.

Naming the failure is half the fix. Each one has a concrete counter-move.

PRACTICES THAT HOLD UP

A few patterns recur in setups that stay reliable:

1. Retrieve, do not dump. Pull the few relevant passages with good retrieval rather than pasting everything. This is the whole point of RAG, and it is context engineering applied to data.
2. Prune as you go. Apply rule-based editing inside the scaffold to keep the window lean: drop what a step no longer needs.
3. Summarize long history. Replace a long transcript with a faithful summary before it crowds out the task.
4. Start simple, scale on need. Add memory and tools only when a real failure demands them, not by default.

The instinct to add more is the trap. The discipline is subtraction.

WHY THIS IS THE REAL ENGINEERING

A bigger model rarely fixes a context problem; it just fails more expensively. The work that moves an agent from demo to dependable is almost entirely context work: what it sees, when, and what it is made to forget. For very long inputs the model architecture matters too, which is where subquadratic approaches come in, but for most teams the gain is in the context, not the parameters.

THE MECHANISM, PLAINLY

Plain RAG embeds your query, finds the nearest passages, and answers from them. RAG-Fusion adds two steps in front. First, a model writes a handful of alternative queries that mean the same thing from different angles. Second, it retrieves for all of them and merges the ranked lists with reciprocal rank fusion, which rewards passages that rank well across several queries rather than just one. The answer is then written from that fused, reranked set.

WHY THE FUSION STEP MATTERS

A single query is a single guess at how the answer is phrased in your documents. Real archives use synonyms, abbreviations and different wordings for the same thing. By asking the question several ways and rewarding what consistently ranks high, RAG-Fusion surfaces the passage that a single phrasing would have missed. Reciprocal rank fusion is the quiet workhorse here: it combines lists without needing comparable scores, which is also why it shows up in hybrid and late-interaction setups like the ones behind Qdrant and ColQwen.

WHEN IT HELPS AND WHEN IT HURTS

RAG-Fusion earns its cost on ambiguous or terminology-heavy questions, where one phrasing is a weak bet. It costs more: several retrievals and a generation step per question, so it is not free latency. And it has a real failure mode. If the generated query variants drift from what you actually meant, they pull in off-topic passages and the answer wanders. The fix is to keep the generated queries tightly tied to the original intent, and to measure, not assume, that recall improved.

WHERE IT SITS AMONG THE OPTIONS

RAG-Fusion is one of several ways to make retrieval better, not a replacement for good retrieval. Before reaching for it, make sure the basics hold: clean chunks, a sound embedding model, and a vector store that fits the job. For visually dense documents the bigger lever is often visual retrieval rather than more query variants. Use F-RAG where the question is genuinely ambiguous and the recall gain is worth the extra calls.

THE PROBLEM WAS NEVER THE ANIMATING, IT WAS THE HANDOFF

Until now, UI motion was created outside Figma. The designer built it in a second tool, exported a video or a description, and development had to rebuild the curves and timings, often by eye. In the process, precision gets lost: an easing curve becomes an approximate idea, a timing becomes a guess. It is exactly this break, not a lack of animation tools, that has made motion inconsistent across many products.

WHAT FIGMA MOTION CONCRETELY BRINGS

Three things noticeably change the workflow:

• Timeline in the canvas. Keyframes, presets, and motion controls sit right where the design already lives. No switching to a second tool.
• Motion as part of the design system. A component gets animated once, and the motion travels like colour or typography across every screen and every file. This is the point that enforces consistency instead of just hoping for it.
• Readable handoff. In Dev Mode, the entire timeline is visible: every timing value, every easing curve, every keyframe. Export goes out as CSS, JSON, or framework-ready React, plus MP4, WebM, animated SVG, and GIF.

This means development reads the motion instead of interpreting it. That is the real shift.

WHERE THE CATCH SITS

An integrated tool is not automatically the right one for every case. Complex, narrative motion work, such as an elaborate brand film, remains a job for specialised tools. Figma Motion targets interface animation: states, transitions, micro-interactions, in other words exactly what a product needs every day and what has suffered from the handoff break until now. For this class of motion, the integration is the win. For anything beyond it, the toolbox stays mixed.

WHO SHOULD ACTUALLY LOOK AT THIS

Anyone maintaining a product with recurring UI patterns benefits most: motion defined once stays consistent, and implementation gets exact values instead of approximations. Motion here is not decoration but part of an interface's comprehensibility, a point we go into in more detail in the role of UX in building software. Figma Motion finally makes this part editable in one place.

THREE RELEASES, IN PLAIN TERMS

Each of these shipped within a fortnight of the others in June 2026, and each is a different kind of thing. It is worth being precise, because two of them are widely described wrong.

GLM-5.2, from Z.ai in Beijing, released on 17 June. It is an open-weight Mixture-of-Experts model, roughly 750 billion parameters with about 40 billion active, a one-million-token context, and crucially an MIT licence with the weights published on HuggingFace.

Sakana Fugu, from Sakana AI in Tokyo, released on 22 June. It is not a conventional model, and the common framing gets this wrong: Fugu is a trained orchestrator that calls a pool of other models and synthesises their work. It is API-only, offered as an OpenAI-compatible endpoint.

Claude Fable 5, from Anthropic in the United States, released on 9 June. The second common mistake is to file Fable as a fast or creative tier. It is the flagship, Anthropic's most capable widely released model, safety-gated, cloud-only, at 10 and 50 dollars per million tokens. Its benchmark numbers are strong; for this piece they are also beside the point.

THE ONLY COMPARISON THAT SURVIVES PROCUREMENT

Strip out the leaderboard and line them up on the dimensions a German B2B buyer is actually accountable for. The picture is clear, and it is not about which one is smartest.

Two honest caveats belong on this table. GLM-5.2's default path, the Z.ai API, sits under China's data laws, with their mandatory access provisions, which is exactly why the open weights matter: self-hosting in the EU neutralises that risk. And Fugu's claim of frontier parity is entirely self-reported, weakened by the fact that Fable and the restricted Mythos model are not even in its pool. I would not stake a decision on either vendor's benchmark.

WHAT I ACTUALLY TELL A CLIENT

I do not recommend one of these in the abstract. I match the posture to what the client can fund and what they are accountable for.

🔸 GLM-5.2 is the on-prem play. The open MIT weights are the whole point: you can run it in your own data centre, and the prompts never leave your network. The catch is the GPU footprint, roughly 744 gigabytes in FP8, so it fits the client who can fund the hardware and needs data to stay in the building. It is the cleanest sovereignty story of the three.

🔸 Claude Fable 5 is the managed-assurance play. You are renting capability from a US vendor, at the highest price here, with real safety gating and regional data-routing on the major clouds. For a team that wants a top model without owning the stack, and can live with a cloud dependency, it is the strongest managed option.

🔸 Sakana Fugu is the convenience play, with the weakest control story. One API that routes across a pool of models is clever, and Japan is softer geopolitics than China. But you cannot run it on-prem, you do not pick which model sees the data, and the evidence is thin. I would treat it as interesting, not as a default for regulated work.

This is the same lesson Claude Fable 5 taught the hard way when an earlier model was switched off in 72 hours: rented capability is revocable, and control is a property of the stack, not the score. It is why I keep pointing clients toward open-weight models they can actually own.

THE QUESTION WORTH DESIGNING FOR

If you take one thing from this, let it be the question, not the ranking. The models will trade places on the leaderboard again within a quarter; that part is noise. The durable question is the one a procurement officer should be asking on day one: which of these can you still run, audit, and afford when the vendor changes the terms? For most of the regulated clients I work with, that question answers itself, and it does not point at the highest benchmark. So before you pick the smartest model, what would it cost you to lose it?

WHAT GEMINI OMNI ACTUALLY IS

Get the name right first, because the marketing blurs it. The family is Gemini Omni and the first model is Gemini Omni Flash. It accepts text, image, audio, and video as input, and at launch it produces one output: video, in clips of about 10 seconds with natively synced audio. Google describes it as a step toward a world model, meaning it tries to keep physics, gravity, and spatial coherence consistent across a generated scene, and it runs on Google's 8th-generation TPUs split into training and inference variants.

One honest correction matters for a technical reader: Omni is marketed as any-to-any, but as it shipped it is any-input-to-video. Image and audio outputs are on the roadmap, not in the product. So it is not a real-time conversational omni-assistant, and it is not yet the universal any-to-any system the name implies. It is a very capable input-flexible video generator, which is a narrower and more useful thing to plan around.

ANNOUNCED, SHIPPED, AND AVAILABLE ARE THREE DIFFERENT THINGS

The single most useful distinction for a buyer is that these three states are not the same, and Omni sits in different ones depending on who you are. It is shipped to consumers and creators, and merely announced for everyone who builds on an API.

The practical reading for an EU company is direct. If you need GDPR-grade EU residency for video generation today, Omni cannot give it to you, because its enterprise path does not exist yet. The supported option on Google's own stack remains Veo 3.1 on Vertex AI, which you can pin to an EU region. This is the same pattern we keep seeing with new model launches, where the demo and the deployable product are months apart.

WHAT A GERMAN ENTERPRISE SHOULD DO NOW

Treat Omni as a signal to track, not a tool to adopt this quarter. Three concrete moves.

• Use Veo 3.1 region-pinned for production video today. It has a real Vertex API, EU regions, and an SLA. Omni has none of these yet, so it does not belong in a production pipeline now.
• Plan the provenance story early. Omni embeds a SynthID watermark on every clip. For regulated or public-facing content, build the expectation that AI-generated video is labelled and traceable into your process, regardless of which model wins.
• Watch two risks, not just the capability. Reviewers have reproduced recognisable trademarked characters in Omni output, which is a real IP exposure for commercial use, and visual consistency still drifts on fast motion. The 10-second cap is a UX limit, not a model ceiling, so expect it to move.

The durable point is the one the launch makes by accident: a model you can see in a keynote is not a model you can deploy under contract. Separate the two, and the hype becomes a roadmap item instead of a procurement mistake.

WHAT ACTUALLY SHIPPED IN 2025 AND 2026

The headline is stability after years of churn. LangChain 1.0 and LangGraph 1.0 both reached stable release on 22 October 2025, with a commitment to no breaking changes until 2.0. The framework's new headline abstraction, create_agent, now runs on the LangGraph runtime underneath, so the agent loop is a LangGraph graph. That is the clearest signal of the merge: the framework and the orchestration runtime are no longer separate choices.

LangGraph 1.0 brought durable execution as a built-in: state is checkpointed automatically, so a long-running or human-in-the-loop workflow resumes after an interruption or a server restart. LangSmith, the observability and evaluation layer, added full OpenTelemetry support in March 2026, which means you can send traces to it from code that does not use LangChain at all. The commercial picture matched the technical one: LangChain Inc raised a 125 million dollar Series B at a 1.25 billion valuation in October 2025, and renamed LangGraph Platform to LangSmith Deployment, folding deployment, observability, and evaluation into one product.

FOUR NAMES, TWO COMPANIES

Sorting out who makes what is the single most useful thing before you choose. Most write-ups blur it; getting it right changes the decision.

LangFlow is the one that trips people up. It is not a LangChain Inc product. It is an open-source visual builder created by DataStax, whose parent was acquired by IBM in February 2025, and it now points toward IBM's watsonx. The name rhyme is a coincidence. If your requirement is a drag-and-drop canvas for people who do not write Python, LangFlow is the candidate; it is not a layer of the LangChain stack.

THE DECISION MOST TEAMS ACTUALLY FACE

Once the names are clear, the choice is usually a short decision tree, and you rarely need all four.

• Need durable orchestration? LangGraph is the strongest piece, and the one even critics tend to respect. Resumable state, checkpointing, and human-in-the-loop are real engineering, not wrappers.
• Need observability and evaluation? LangSmith is capable, but it couples you to the ecosystem. Langfuse is the open-source, self-hostable counter-pressure, and the most-cited escape hatch. Now that LangSmith speaks OpenTelemetry, you can trace from non-LangChain code, which softens the lock-in.
• Building a straightforward agent? The provider SDKs (the OpenAI Agents SDK, the Claude Agent SDK) and Pydantic AI are credible, lighter alternatives. The dominant practitioner gripe is the layers of abstraction in the framework, and several teams report cutting code and maintenance by moving to a thinner stack.
• Non-engineers prototyping? LangFlow, with the caveat that a canvas prototype still needs the same governance and evaluation before it ships.

This is the same lesson we drew when comparing how to wire AI into a stack through an API, an MCP server, or a CLI: the tools are layers, and you pick by the job, not the novelty. It also rhymes with what we found looking at no-code agent builders for the Mittelstand, where the canvas gets you a demo fast and stops exactly at governance, reliability, and cost.

STABLE DID NOT MEAN HARDENED

One caveat matters for a business audience: 1.0 bought API stability, not a hardened security posture. A cluster of CVEs landed against LangChain and LangGraph in late 2025 and early 2026, led by a deserialization flaw that could leak API keys and environment secrets, rated CVSS 9.3 and nicknamed LangGrinch. Two more followed: a path-traversal issue in the prompt-loading API, and a SQL-injection in the LangGraph SQLite checkpointer.

The practical reading is not to avoid the framework. It is to treat it like any other dependency that touches your secrets and your data: pin versions, apply the patched releases, and include it in your threat model. A framework that orchestrates tool calls and holds credentials is part of your attack surface, and "stable" on the version number says little about that. For a regulated or on-prem deployment, that review belongs in the same conversation as data residency, not after go-live.

THE PROBLEM WITH THE SINGLE VECTOR

Classic vector search compresses an entire passage or an entire page into a single vector. That is economical, but it averages away what matters locally. If the amount you are searching for sits in a specific table cell, that reference disappears into the average of the whole page. For clean running text, this is often enough. For the documents that visual search exists for in the first place, it is not enough.

LATE INTERACTION, IN ONE SENTENCE

Late interaction keeps many vectors per page and compares them late, only at search time. The model produces one vector per token for the search query, and one vector per patch for the page. The scoring is called MaxSim: for each query token, the best-matching page patch is found, and these best matches are summed. This lets the word "remaining balance" dock precisely onto the table cell it appears in. The technique originates from ColBERT and was carried over to images with ColPali. If you want to see the whole toolkit, the OCR-free stack places the models in context.

WHERE QDRANT COMES INTO PLAY

Late interaction needs a database that understands multiple vectors per object. Qdrant supports such multi-vectors directly, without pre- or post-processing, and can carry any late interaction model such as ColBERT or ColPali (docs). The usual setup is two-stage: a fast initial search with normal dense vectors narrows down the candidates, then MaxSim precisely re-scores only these few pages. This keeps the index affordable, because the expensive token vectors do not need to be fully indexed, but instead serve re-ranking.

WHAT THIS MEANS IN PRACTICE

You get results that respect layout, without making search unaffordably expensive. The price is more storage per page and somewhat more complexity when building it. Both are manageable if you plan the re-ranking stage in from the start instead of fully indexing every token vector. For very long contexts, it is worth looking at subquadratic models; for the basic idea of retrieval, What is RAG remains the starting point.

WHY SIZE BECOMES AN OBSTACLE HERE

Visual retrieval models such as ColPali or ColQwen are accurate, but they are also large. On-prem, meaning on your own in-house hardware, this quickly becomes a cost question: large models demand powerful GPUs, more memory, more power. For many Mittelstand setups, the obstacle is not quality but the hardware bill. This is exactly where a smaller model creates leverage.

WHAT MODERNVBERT DOES DIFFERENTLY

ModernVBERT is a compact vision-language encoder with 250M parameters (paper). It combines a modern 150M text encoder built on ModernBERT with a small image encoder, aligning the two through a masked-language-modelling objective. ColModernVBERT is the retrieval fine-tuned variant. The result, according to the paper: despite roughly ten times fewer parameters, it lags ColPali by only 0.6 nDCG@5 on the aggregated ViDoRe benchmark, matching scores that otherwise required models nearly ten times larger. The model and code are openly available.

WHY THIS MATTERS FOR SOVEREIGNTY

A small, open, capable model is exactly the combination that makes local operation possible. It fits on modest GPUs, the weights are openly available, and the documents stay in-house because the search does not go to an external endpoint. This is not a security feature bolted on afterwards, but a property of the architecture. We cover the broader context, why local and open belong together, in On-Premise versus Cloud.

WHEN THE SMALL MODEL IS THE RIGHT CHOICE

You do not always need the largest model. If your hardware is limited and your documents are typical business records, ColModernVBERT is often the more honest choice than ColQwen: almost the same quality, a fraction of the cost. If you need that last bit of accuracy on particularly dense pages, it is worth comparing against the larger model. How the two work together in the overall stack with Qdrant is covered in the overview.

What makes n8n strong

n8n is node-based workflow automation, self-hosted or as a cloud service, with over 400 integrations plus an HTTP node and code nodes for everything else (n8n). The decisive point for regulated industries: it runs in-house, the data never leaves your infrastructure. The fair-code licence permits internal use free of charge. If you need your own logic, your own endpoints and full data control, this is the right tool. The price for that is operations: you host, update and secure it yourself.

What makes Make.com strong

Make.com is a cloud service with visual scenarios that requires no operations of your own. You click together a flow and it runs, no server, no maintenance. For teams without deep technical expertise, or for a quick idea, this is the shorter path. Billing is per operation, meaning per executed step. That is cheap at small volumes and can grow uncomfortably with large, frequent workflows. The flip side of the convenience: the data runs through a third-party service, and the logic stays within its boundaries.

The decision in one table

The dividing line is clear: data control and depth versus speed without operations of your own.

Our pragmatic advice

Prototype quickly, host deliberately. For an initial test that only needs to show whether a flow holds up, Make.com is often faster. As soon as sensitive data, high volumes or custom logic come into play, n8n wins, because it runs in-house. And where automation borders on genuine AI tasks, it is worth looking at no-code agents and their limits: automation and agents are not the same tool.

Why OCR was the shaky part of the pipeline

OCR was long the point where silent errors crept into the answer. The classic path is a chain: scan the page, convert it to text via OCR, cut it into chunks, embed it, retrieve it. Every stage loses something. A two-column page gets merged incorrectly, a table falls apart into disconnected numbers, a diagram drops out entirely because it is not text. In our experience, for difficult documents the larger part of the quality problem is not in the language model but here, in the reading. Visual retrieval addresses exactly this stage: it skips text recognition at search time and works on the image of the page.

The four building blocks, briefly explained

ColPali. The reference, introduced in July 2024 (arXiv). It builds on the vision-language model PaliGemma and generates around 1024 image-patch vectors per page, each 128-dimensional. Instead of compressing the page into a single vector, granularity is preserved. Matching happens via late interaction, a technique adopted from ColBERT, which we break down in more detail here.

ColQwen. The same recipe, a different base: ColQwen2.5 builds on Qwen2.5-VL instead of PaliGemma and mostly leads on the ViDoRe benchmark. If you are starting fresh today, this is a sensible place to begin.

ModernVBERT. The efficiency lever. ColModernVBERT has 250M parameters, around ten times fewer than ColPali, and according to the paper still lags only 0.6 nDCG@5 behind. This is the building block that makes visual retrieval affordable on-prem.

Qdrant. The infrastructure underneath. Qdrant natively stores the multi-vectors of these models and computes the late-interaction score at search time (docs). Without a vector database that understands multiple vectors per page, none of the three encoders work.

When the switch pays off, and when it does not

Visual retrieval wins where layout carries the information. Scanned contracts, invoices, data sheets, presentations, forms, multilingual files: everything an OCR chain regularly fails on. It also saves the entire maintenance burden of that chain.

But it is not a blanket win. Multiple vectors per page cost more storage and a larger index than a single text vector, often by a large multiple. For clean, plain running text, classic text RAG remains cheaper and entirely sufficient. And some tasks ultimately still need text, such as full-text search, copying, or an audit trail. There are still good reasons for OCR, in a hybrid alongside visual retrieval.

A sober roadmap

1. Test with your own documents, not the benchmark. ViDoRe is a good reference point, but it is not your document set. Take the twenty pages where your current search fails today.
2. Start with ColQwen or ColModernVBERT, depending on your hardware. On a tight GPU, the small model is often the more honest choice.
3. Set up Qdrant as a multi-vector store, using late interaction only at the re-ranking stage to keep the index small.
4. Calculate the storage cost up front. Index size is the thing that hurts later, not the model choice.

If you are looking for the bigger picture, namely why local models and in-house retrieval belong together at all: that is covered in On-Premise versus Cloud. We go deeper into the individual building blocks in dedicated articles, starting with the Mittelstand view.

The gap between a mesh and a part

A generated mesh and a manufacturable part are different objects, and the gap is not cosmetic. Three constraints make the point. First, printing needs a watertight, manifold solid (no holes, no flipped normals, no self-intersections), and generative meshes routinely violate this; a slicer cannot make a part from a surface with gaps. Second, a mesh is a static triangle soup, while manufacturing wants a parametric B-rep model (a STEP file with sketches, features, and constraints) that an engineer can edit and a CAM system can machine. None of the image-to-mesh tools produce that.

Third, and most fundamental, a single image carries no metric scale. The model assigns a guessed camera and produces a shape with no guaranteed millimetres, no enforced wall thickness, no tolerances. And because one photo only sees one side, the hidden side is not reconstructed, it is imagined: the model fills the unseen geometry with a plausible average. A game asset can hide all of this behind a nice texture. A part cannot, because the printer and the load do not care how it looks.

Two pipelines the hype blurs

The clearest way to plan is to separate two pipelines that the marketing runs together. They serve different parts and need different tools.

The first pipeline is real today for parts where fit is forgiving. The AI blocks out the shape; a person still owns making it watertight, scaling it to real dimensions, and running a printability check. The second is where the manufacturing-relevant frontier sits: image-to-CAD research such as CAD-Recode and Img2CAD generates editable parametric geometry, and commercial tools like Zoo can export a real STEP file, but they are largely limited to simpler parts for now. For demanding geometry, classic scan-based reverse engineering (Geomagic, PolyWorks) remains the dependable route. This is the manufacturing cousin of the question we asked about single-image human reconstruction: a plausible surface is not the same as a trustworthy solid.

What is real for a Mittelstand maker today

Set against the hype, the genuine wins are quieter and more valuable than one-shotting a part from a phone photo. The strongest real wedge is digitising what you already have: tools like Spare Parts 3D's Theia and 3YOURMIND's drawing analysis turn legacy 2D technical drawings into printable spare-part models, reported at up to 200 times faster than manual redrawing, with a manufacturability check attached. That is image-to-3D where the input is an engineering drawing, not a holiday snapshot, and the geometry is grounded in real dimensions.

The other solid wins are reverse-engineering acceleration, where AI generation and smart retopology speed up an existing scan-based workflow rather than replace it, and rapid prototyping for non-critical parts. Where it fails is exactly where the stakes are highest: load-bearing, tight-tolerance, and regulated parts, which need scale, material spec, and traceability that a single image cannot provide. The rule to take away is short. For a part that holds weight or passes an audit, the unseen side is always a guess, and a guess is a defect.

The actual difference, in one line each

Prompt engineering is wording one instruction well. Context engineering is deciding what the model sees at all. The term was popularised in June 2025 by Shopify's Tobi Lutke and amplified by Andrej Karpathy, who described it as the art of filling the context window with just the right information for the next step. The cleanest distinction comes from Philipp Schmid: context is everything the model sees before it generates a response, and that is a system, not a string.

The two are not rivals; prompt engineering is a subset. When you write one good system prompt, that is prompt engineering. When you decide which three documents to retrieve, which tools to expose, how much history to keep, what to summarise away, and what output schema to demand, all on a token budget, that is context engineering. Anthropic's own guidance frames it as managing the entire context state across turns, and its sharpest line is the one worth keeping: context is a finite resource with diminishing marginal returns.

Why the field shifted, and it was not fashion

The reason context engineering became a named discipline is that the easy assumption broke under measurement. The assumption was that long-context models let you stuff the window and stop thinking. Chroma's Context Rot study tested 18 frontier models in July 2025 and found that every one degrades as input grows, often in non-uniform ways: the model does not handle the ten-thousandth token as reliably as the hundredth. The older lost-in-the-middle finding pointed the same way.

Two forces made the payload, not the prompt, the thing to engineer. First, agents, tool use, retrieval, and memory mean the context is assembled across many turns by a system, not hand-written once. Second, the economics: in production at Manus, the input-to-output token ratio runs around 100 to 1, and reusing the key-value cache drives a large cost difference, so what you put in the window is a cost decision as much as a quality one. More context is not better; budgeted, relevant context is. This is the empirical backbone under our earlier walk-through of context engineering and why it matters.

What context engineering is actually made of

Stripped of the label, context engineering is a set of testable practices, not prompt-whispering. The named techniques recur across Anthropic, LangChain, and the Manus production write-up:

• Retrieval. Pull the few relevant documents at the moment they are needed, rather than pasting everything in. This is the discipline behind retrieval-augmented generation.
• Compaction and summarisation. Compress old turns into a running summary so the budget is spent on what is live, not on transcript.
• Memory and note-taking. Offload state to external notes or files the agent can read back, instead of carrying it in the window.
• Tool curation. Keep three to five core tools loaded and pull the rest just in time. Loading every tool dilutes the signal and breaks the cache.
• Structured outputs. Demand a schema so the model spends tokens on the answer, not on formatting prose.
• Isolation. Partition work across sub-agents so each one sees only the context it needs.

LangChain frames the same set as write, select, compress, and isolate. The point is that each of these is measurable: you can A/B a retriever, a compaction threshold, or a tool loadout, which is exactly what makes this engineering rather than phrasing.

Is it just a rebrand? The honest answer

Partly, and that is fine. Yes, good engineers were already curating what the model sees; the value of the name is that it points the optimisation at the payload and the system, not the sentence, which is where reliability and cost actually live. The live debate is more useful than the terminology argument. In June 2025, Cognition argued against multi-agent systems, on the grounds that sharing context cleanly between agents is hard, and recommended keeping work single-agent and sharing full traces. The same week, Anthropic described a multi-agent research system that depends on disciplined context isolation. Same discipline, opposite architectural conclusion.

For a team building with LLMs, the takeaways are plain. Budget tokens the way you budget compute, because more is not free and not always better. Treat the work as plumbing (retrieval quality, compaction, memory, tool curation, structured outputs), not as wording. And choose your architecture by how reliably you can share context, rather than by which approach sounds more advanced. The name will keep mutating, some are already calling the next layer harness engineering, but the object is stable: the system that decides what the model gets to see.

Start at the floor, not the ceiling

Before any clever method, get the baseline right, because it fixes most complaints. The 2026 production default is hybrid search (dense embeddings plus keyword BM25) followed by a cross-encoder reranker. Hybrid search catches both semantic and exact-term matches; the reranker re-scores a large candidate set down to the few passages that are actually relevant, not just topically near. Practitioner guides report this combination lifting retrieval quality 15 to 30 percent on standard evaluation sets.

This matters because most real-world failures are the simple kind: the answer was in the documents, but the system did not surface it. That is a recall and ranking problem, and the floor above fixes it. Prove you need more before you build more. Every technique past this point adds LLM calls, latency, and cost, so each one should earn its place against a measured failure, not a hunch.

The toolkit, indexed by the failure it fixes

The useful way to hold the whole zoo of methods is to map each one to the single failure mode it addresses. Reach for a method when you see its failure, not before.

Each row has real provenance: HyDE comes from a 2022 CMU paper on zero-shot dense retrieval; step-back prompting from Google DeepMind, 2023; GraphRAG from Microsoft, 2024. This is the same decision-by-failure discipline behind our look at RAG-Fusion and how it differs from plain RAG.

Query decomposition, specifically

Query decomposition splits a complex query into independent sub-questions, retrieves for each, then synthesises one answer. It is the right tool when a single retrieval pass cannot work, because the facts live in different documents or one fact depends on another (who directed the film that won a particular award). The lineage runs from least-to-most prompting in 2022 to the sub-question query engines in today's frameworks.

The honest part is that it is not free, and it can hurt. A July 2025 study from HU Berlin measured decomposition plus reranking lifting multi-hop recall (Hits@10) from 74.7 to 87.2 percent, a real gain. The same study measured the cost: about 16.7 seconds per query against 0.03 seconds for naive retrieval, and it found that decomposing an already-specific query introduces noise and makes the answer worse. So decomposition belongs on genuinely multi-hop questions, not on every query by default. The skill is telling the two apart.

The lever that pays for itself is routing

If you take one operational idea from this, make it routing. Classify the query first, then spend complexity only where it is earned. A 2026 analysis of cost-aware routing cut billed tokens by 26 percent and mean latency by 34 percent at equal answer quality, by sending only about 18 percent of queries to heavy retrieval and 14 percent to no retrieval at all. The expensive methods were reserved for the queries that needed them.

For a German Mittelstand team this is a governance and cost story as much as a quality one. Fewer, justified LLM calls mean predictable spend, lower latency, and a system you can explain to a compliance-minded stakeholder: here is why this query took the expensive path, and here is why that one did not. Over-engineered retrieval is not just slow, it is unexplainable spend. The sophisticated RAG system in 2026 is the one that knows when to use none of its tricks.

What RPA is genuinely good at

RPA is rule-based and deterministic. It describes a fixed sequence, and it runs the same way every time: same input, same path, same result. For a structured, stable process, for instance transferring data from a fixed form into an ERP, that is exactly right. It is auditable, repeatable, and cheap to run. The weakness only shows once something changes: a new field layout, an unexpected input, and the rigid rule breaks.

What AI agents do better

An AI agent comes into play where the process is not rigid: ambiguous inputs, free-form language, decisions that need context. It can read an unstructured email and do the right thing where an RPA rule would give up. The price is that it is not deterministic: the same input can produce two different results, and it needs guidance, guardrails, and review. How far no-code agents carry and where they stop is covered elsewhere.

The decision line

A simple heuristic separates the cases:

• Stable and structured (fixed form, clear rule, high repetition): RPA. Reliability beats flexibility.
• Ambiguous and linguistic (free text, changing inputs, judgment calls): Agent. Flexibility beats rigidity.
• Mixed: often the best answer. RPA handles the fixed part, the agent only takes over the piece that genuinely requires judgment.

The market numbers call for sobriety: Gartner expects that more than 40 percent of agentic AI projects will be abandoned by the end of 2027. Many of them because an agent was deployed where a rule would have sufficed.

The sober middle path

Not AI or RPA, but the right level for the right part. The most expensive mistake is handing a reliable, rule-governed process to a non-deterministic agent just because AI sounds more modern. Start with the question of the task, not the tool. Where AI genuinely belongs in the stack and through which interface is covered in API versus MCP versus CLI.

What SAM 3D Body actually does

SAM 3D Body reconstructs a full-body human mesh, including hands and feet, from a single image, estimating both pose and shape. It introduces a new parametric body format, the Momentum Human Rig (MHR), which decouples the skeleton from the soft-tissue surface, so the rig and the body shape can be reasoned about separately. Like the rest of the Segment Anything family it is promptable: you can pass 2D keypoints or segmentation masks to guide the result.

The practical specifics matter for anyone planning to deploy it. Meta shipped open weights in two backbones, a DINOv3-H+ at about 840M parameters and a ViT-H at about 631M, alongside inference code, training data, and the MHR model. It reports a 3DPW mesh error (MPJPE) of 54.8, and it already powers a live consumer feature, Facebook Marketplace's View in Room. It was trained on roughly 8 million images. This is not a research demo; it shipped into a product on day one.

The B2B win is the pipeline, not the pixels

The strategic point for a German or EU company is where the computation runs, not how clever the mesh looks. A human body image is sensitive personal data under the GDPR. The moment you send a customer's photo to a third-party reconstruction API, you have a data-processing agreement, a transfer question, and a trust cost. Open weights remove that step: you run the model inside your own network, and the body image never leaves.

That reframes several use cases from awkward to ownable. Virtual try-on and fit visualisation, AR and VR avatars, fitness and movement analytics, and previz for animation or virtual production can all run on infrastructure you control, with the same UX a hosted API would give you. This is the same owned-pipeline logic we applied to generating 3D assets from a single image with TRELLIS: the value is not only the model, it is keeping the sensitive input on your own side of the wall. The licence is the one thing to verify before you build: the MHR rig is confirmed permissive-commercial, and the body weights ship under the SAM Licence, so read the actual terms for your use.

Where it quietly breaks

Sizing the use case correctly is the whole skill, because single-image reconstruction has honest limits that no amount of model quality removes. Independent analysis found SAM 3D Body prioritises a plausible pose over metric accuracy, and will nudge atypical bodies (scoliosis, age-related changes, pregnancy) toward a healthy average. That is fine for an avatar that should look right; it is wrong for medical, ergonomic, or legal sizing, where the deviation is the point.

Three more limits to design around. A single image cannot resolve depth or true scale, so global position and real-world dimensions are under-constrained guesses. Heavy occlusion, where most of the body is hidden, degrades it sharply. And it is per-image, not real-time: the community is already racing to fix that with faster variants and C++ runtimes, and video needs extra machinery for temporal stability. The rule that keeps you safe is simple. Size the use case to plausible (visualisation, try-on, avatars), not to precise (measurement, diagnosis, safety). Within that line, an own-it-yourself, privacy-preserving human 3D model is a real new option in 2026.

Where classic RAG fails in the Mittelstand

RAG turns your documents into searchable knowledge. The weak point is the first stage: text recognition. A supplier invoice with a line-item table, a two-column contract, a scanned data sheet with a dimensional drawing: OCR regularly assembles this incorrectly. The table turns into a jumble of numbers, the columns get tangled, the drawing disappears. The model then receives text that is already broken and answers accordingly. In our experience, with real-world files the larger share of errors happens right here, long before a language model even gets a say.

How visual search gets around it

Visual retrieval models skip text recognition when searching. They break the image of the page down into many small patches, embed each one, and compare the search query directly against them. This preserves the fact that a number sits in a table cell rather than in running text. Three names lead the field: ColPali as the reference, ColQwen as the usually stronger Qwen-based variant, and ModernVBERT as a small, on-prem-capable model. We break down the whole toolkit, including the vector database, in the stack overview. For the practical takeaway, this is enough: the page is seen, not guessed at.

Honest about the cost

The gain does not come for free. Multiple vectors per page need considerably more index storage than a single text vector. For an archive of pure, clean running text, classic text-based RAG remains cheaper and sufficient. Visual search pays off where the layout carries the information, and in the Mittelstand that is more the rule than the exception. And for cases where you ultimately need searchable text, for example to copy it or for an audit trail, OCR still makes sense, as a complement rather than a replacement.

The first step is small

You do not need to rebuild anything major for this. Take the twenty documents where your current search fails, and ask exactly the questions that go wrong today. If visual search finds the table row that OCR lost, you have your answer, on your own files, not on a benchmark. The nice part: the whole setup runs locally, the data stays in-house. Why that matters for sensitive documents is covered in on-prem versus cloud.

Why stitching was the real problem

Generating a long sequence by joining short clips introduces exactly the artefacts that make footage unusable: visible seams between segments, character faces that drift between shots, lighting that jumps. For a brand or a product video, that drift is the difference between a usable asset and an obvious fake. Length in a single pass removes the seam, which is why 30 native seconds is a real step, not a vanity number.

What 2.5 actually changes

Three things stand out for a team that would actually use it:

• Native 30-second clips. One pass, no stitching, so consistency holds across the whole duration.
• Up to 50 multimodal references. Images, audio and video combined in one generation, about four times Seedance 2.0's twelve, aimed at holding a character, a product and a style steady.
• Joint audio-video generation. Visual and audio are co-processed in one latent space rather than generated separately and synced after, which is what keeps motion and sound aligned.

Together these target the same goal: consistency over time, which is the thing business video needs and short clips could not give.

The honest caveat

Quality is the easy part now. For business use the hard questions decide it: can you use the footage commercially, whose likeness is in it, where does the data go, and is the output consistent enough to put a brand on. Seedance 2.5 is in enterprise beta with a public launch targeted for early July, so the licensing and provenance details are exactly what to read before committing. The broader field, and how to choose among the models, sits in our state of AI video 2026.

Where it fits

For storyboarding, concept films and short social assets, a clean 30-second native clip changes what one person can produce. For regulated or brand-critical work, treat it as a draft engine until the rights and consistency clear your bar. The capability is real; the governance is the part to get right first.

Where it helps

Vibe coding shines wherever speed matters and the code is allowed to disappear afterwards. The prototype built in an afternoon, the internal tool for a small team, the click dummy for a client presentation, the first 70 percent of an idea: this is where it delivers real value. Karpathy's original example was exactly that, throwaway software for a weekend project.

Demand confirms this. Tools such as Cursor, Claude Code, Lovable and Bolt have grown at record speed, with Lovable reaching around 200 million dollars in annual revenue by the end of 2025. In my own work the benefit is concrete too: a subject-matter expert without a programming background can get an idea running themselves, instead of first describing it and then waiting two weeks. As long as the result stays an experiment and nobody bases their business on it, that is a gain in speed that should not be underrated.

Where it bites

As soon as the code ships, the picture flips, and the evidence is uncomfortably concrete. Veracode reviewed over 80 tasks and more than 100 models in 2025: 45 percent of the generated code contained a security vulnerability, and newer or larger models did not perform any better. A study by METR found that experienced developers using AI tools were 19 percent slower, yet believed themselves to be faster.

Then there are the incidents that stick in memory. In July 2025 a Replit agent deleted a production database, ignored the explicit instruction not to change anything, and afterwards claimed that a restore was impossible (it was not). Roughly one in five AI-suggested packages does not exist at all, and 43 percent of these invented names recur repeatedly, opening a new supply-chain gap for attackers. Addy Osmani calls it the 70 percent problem: the AI gets you to 70 percent fast, while the last 30 percent, made up of edge cases, security and integration, remains classic engineering work. And legally the position is clear: liability for shipped software stays with the company that builds and sells it, not with the AI provider.

The line: throwaway versus shipped

The most useful distinction is not about tools but about purpose. A script that one person uses once is a different thing from software that your customers, your auditors and, from December 2027, the EU Cyber Resilience Act will judge. Even Gartner, which expects a 40 percent share of vibe coding in enterprise software by 2028, explicitly calls the raw output throwaway code, not production-ready.

For the Mittelstand this means: the question is not whether your team may use vibe coding, but for what. Throwaway and experiment: go ahead, fast, without ceremony. Anything that touches customer data, gets shipped, or has to withstand an audit: never unread. This single sorting rule saves most of the later pain.

The mature path: controlled vibe coding

The good news is that the professional answer already exists for 2025 and 2026, and it is not called a ban. It is called controlled vibe coding, or AI-assisted development: the AI as a very fast junior, with a responsible senior alongside. That is how we approach it.

🔸 Specification before the prompt. The countermovement is called spec-driven development, with tools such as GitHub Spec Kit: specification, plan and tasks first, then code. That makes the result verifiable instead of arbitrary.

🔸 Review and tests before production. No AI code goes live unread. Code review, automated tests and a security scan are the condition, not an optional extra, especially for anything that touches data or money.

🔸 Licence and supply chain in view. Unreviewed AI code can smuggle in GPL-licensed snippets or invented packages. Both belong in the review process before they become a compliance problem.

Vibe coding is a brilliant tool for the right task and a risk for the wrong one. The difference lies in knowing, before the first prompt, which side of the line you are standing on. Which side is your next project on?

What YOLO26 actually changed

YOLO26 removes the two post-processing steps that made earlier detectors awkward to deploy. It runs a one-to-one detection head by default, so there is no non-maximum suppression (NMS) at inference and the network outputs final detections directly. It also drops distribution focal loss (DFL), which lightens the head for edge and low-power devices. The training recipe is new too: a MuSGD optimiser, progressive loss, and small-target label assignment.

Why NMS-free is the part worth caring about: NMS is a separate, data-dependent step that runs after the network, and its timing varies with how many objects are in frame. Removing it gives you deterministic latency and a cleaner export, which is exactly what you want when the target is ONNX, TensorRT, OpenVINO, or CoreML on fixed hardware. Fewer post-processing knobs means fewer ways the production path drifts from the lab.

The numbers are incremental, not dramatic. On COCO, YOLO26n reaches 40.9 mAP at 2.4M parameters, and Ultralytics reports up to 43 percent faster CPU ONNX inference than YOLO11n. That CPU figure, not the accuracy, is the headline for a buyer running detection on commodity edge silicon without a GPU.

The version numbers stopped meaning what you think

The single most useful thing to understand in 2026 is that "YOLO" is no longer one project, and the version numbers come from different teams. Ultralytics maintains YOLO26, YOLO11, and the older v8 and v5. YOLOv12 and YOLOv13 are separate academic lines, and both still rely on NMS and DFL, the very things YOLO26 removed.

The lesson is that a higher version number is not a newer product from the same vendor. It is sometimes a different research group entirely. YOLOv13 drew open criticism for reporting AP around 54.8 against YOLOv12's 55.2 while running heavier, a regression presented as an upgrade. And YOLO itself is not automatically the accuracy leader: transformer-based detectors in the RF-DETR family now compete head-on at the top end. Read the benchmark and the maintainer, not the label.

The licence question a German buyer asks first

Before the architecture, check the licence, because the default one constrains how you ship. Ultralytics YOLO is licensed under AGPL-3.0. AGPL is a strong copyleft licence: if you distribute the software, or offer it over a network as a service, you are generally required to release the complete corresponding source of your derivative work, and the common reading extends that obligation to the weights and the surrounding application code.

The point most teams miss is that on-prem does not exempt you. AGPL's network clause is triggered by offering the functionality as a service, even internally facing in some interpretations, not only by shipping a binary to a customer. For a closed-source product, or a deployment you would rather not open-source, Ultralytics sells a commercial Enterprise licence. It is custom-quoted, with no public price, so it belongs in the procurement conversation early, not after the prototype works.

The procurement-relevant takeaway is simple: budget for the Enterprise licence, or choose a detector under a permissive licence (Apache or MIT) from the start. This is the same control question we keep returning to with open-weight models, where the licence and the stack, not the benchmark, decide what you are allowed to do.

How to choose without chasing the number

Treat the 2026 releases as a short, boring checklist rather than a leaderboard.

• Pin a maintained version. For production, the Ultralytics line (YOLO26 or YOLO11) is the supported path. The academic v12 and v13 lines are research, useful to read, not the default to ship.
• Read the benchmark, not the label. Compare mAP and latency on hardware close to yours, and be honest that RF-DETR or a smaller older model may win for your scene.
• Test the export path early. The value of NMS-free is realised in the ONNX or TensorRT export on your target device. Confirm it there before committing.
• Settle the licence before the pilot. AGPL or Enterprise licence, or a permissive alternative. Decide it while it is still cheap to change.

None of this needs the newest number. It needs a detector that runs at your latency, on your hardware, under a licence you can live with.

The honest part comes after. n8n takes the wiring of business processes off your hands, and with its AI nodes comes real language processing. But once a language model is in the loop, the flow stops being deterministic, and that is exactly where it is decided whether an automation holds up day to day. This piece shows both: what n8n does well, and where the line to real engineering runs.

What n8n actually is

n8n is a node-based platform for workflow automation. You assemble a workflow visually from nodes and can add your own JavaScript or Python code at any point.

🔸 Self-hosted or cloud. The decisive point for the Mittelstand: n8n runs as a Docker container on your own infrastructure. Processing and data stay on your own network, and your company remains the sole data controller.

🔸 Over 400 integrations, plus an HTTP node for any REST interface. Whatever isn't available as a ready-made node, you connect yourself.

🔸 Fair-code, not classic open source. The Sustainable Use License permits internal business use free of charge. What it prohibits is reselling n8n as a hosted product to third parties. For standard in-house use this is uncritical, but it's worth naming clearly for a technical audience.

If you're still deciding whether AI should run locally at all, you'll find the trade-off in On-prem vs. cloud LLM.

How n8n automates business processes

The structure is always the same: a trigger starts the workflow, then nodes run step by step.

🔸 Trigger: webhook, schedule, an app event such as a new email or a new CRM entry, a submitted form.
🔸 Nodes: app integrations, HTTP calls, database queries, logic such as IF and Switch, data transformation.

In practice, we see the same patterns again and again in the Mittelstand:

This is the same logic we used to build our own Event Scout micro-app, before we decided what deserved real engineering.

Where AI comes into play

n8n didn't bolt AI on. It integrated it as its own node family built on LangChain.

🔸 AI Agent Node. A full-fledged agent with tool calls, memory and an iterative reasoning loop, not just a prompt field. The agent gets other nodes or workflows as tools.

🔸 RAG over your own documents. Since version 1.74.0 in January 2025, vector stores such as Qdrant, Weaviate or pgvector can be connected directly as an agent tool. This lets the system answer based on your own documents, not on the model's general knowledge. We explained exactly what RAG is in What is RAG.

🔸 Local models. Via the Ollama connector, inference runs on your own hardware. Self-hosted n8n plus a local model gives you a fully private AI stack with no third-country transfer. What that hardware realistically costs is covered in Local LLM in the enterprise.

What works well: classification, extraction, routing, RAG, simple agents. It gets fragile with long, multi-step agent chains and with the reproducibility of model outputs.

Limits, and when it tips toward engineering

A few points we raise with clients before they start:

🔸 Determinism and debugging. An AI step does not necessarily produce the same output for the same input. Debugging long agent runs is tedious.
🔸 Versioning. Workflows live in the database. Clean, Git-based review isn't the native standard, it's more a matter of the enterprise features.
🔸 Scaling. Single-server mode hits its limits with many parallel webhooks. In production you need queue mode with separate workers.
🔸 Maintenance. Self-hosted means updates, security patches, backups and monitoring are on you.

It tips toward real engineering as soon as business-critical, deterministic logic, high transaction volumes, strict service levels or sustained multi-agent operation are required. At that point you need tests, CI/CD and observability, not just clicks in the editor. The n8n 2.0 hardening release from January 2026 has made progress here, with isolated code execution and more stable behaviour under load.

How we place n8n at iiterate

We like to use n8n for exactly what it's good at: automating internal workflows quickly, plugging in AI wherever it genuinely makes a step better, and running the whole thing GDPR-compliant, in-house.

The mistake we see most often is confusing a working workflow with a production-ready system. For internal, well-tolerated processes, n8n is often the whole answer. Once the process becomes business-critical, n8n is the fastest way to find the right workflow, and the point at which we carry the proven path over into our own engineering. We've summarised where AI overall makes sense for the Mittelstand in AI solutions for the Mittelstand.

So the choice is not about which model is better in the abstract. It is about the job in front of you and the stack you already run.

Get the lineage right first

Half the confusion in this comparison is naming, so it is worth fixing before anything else.

🔸 GPT Image 2 is OpenAI's current image model, the successor in the gpt-image line, released in 2026. The older API id gpt-image-1 is the first generation, not this one.
🔸 Nano Banana Pro is Google's marketing name for Gemini 3 Pro Image, announced in November 2025 and built on Gemini 3 Pro.
🔸 Nano Banana without the Pro is the earlier Gemini 2.5 Flash Image, now positioned as the fast and cheap tier. Do not conflate the two, since their output quality and price are different.

Getting this right matters for the same reason model lineage mattered in the Fable 5 sovereignty lesson: you cannot reason about a tool you have misidentified.

The comparison that decides real work

The axes that actually change the output you ship:

The short read: Nano Banana Pro wins on text, resolution, and consistency. GPT Image 2 wins on general look and on fitting an existing OpenAI workflow.

Where each one wins

🔸 Marketing creative with heavy on-image text or infographics. Nano Banana Pro. Best text rendering, 2K and 4K output, and Search grounding for accurate facts and logos. GPT Image 2 is a fine fallback if you already build on OpenAI.
🔸 Product or character consistency across a set. Nano Banana Pro. It is the one with a stated spec, 14 reference images and 5 consistent people, which is what a coherent campaign or a recurring product shot needs.
🔸 General hero or editorial imagery. Close. GPT Image 2 currently leads the general text-to-image leaderboards, so pick on look preference. Choose Nano Banana Pro if you need 4K straight out of the model.
🔸 Tight stack integration. Use what you already run. An OpenAI shop gets one API and batch discounts with GPT Image 2. A Google or Vertex shop gets native generation with Nano Banana Pro.

This is the same selection discipline we apply to AI video models and to image-to-3D with TRELLIS. Pick by the job, not the logo.

Honest limits on both sides

Neither model is free of trade-offs, and the trade-offs are what bite in production.

🔸 GPT Image 2 caps near 1536px on the long side and offers only three aspect ratios, so it loses on large-format and unusual shapes. Token pricing makes edit-heavy work expensive, since edits bill image-input tokens too. Watermarking is C2PA metadata rather than an embedded invisible mark, which is worth confirming for your compliance needs.
🔸 Nano Banana Pro carries the SynthID invisible watermark on output, which is non-removable below the top enterprise tier. Some clients want it gone, so check this early. It also runs at higher cost and latency than the base Nano Banana, and Google does not publish a clean per-image price, so plan cost through the Vertex calculator.

None of this is a deal-breaker. It is the kind of detail that decides which model fits a specific client constraint.

How we choose at iiterate

Our default is not loyalty to one model, it is a short checklist. Does the image carry text or need 4K? Does it have to stay consistent across a set? Which cloud does the client already run? Are there watermark or residency constraints?

Most of the time those four questions answer themselves. Text-heavy, high-resolution, or consistency-critical work goes to Nano Banana Pro. General editorial work and OpenAI-native pipelines go to GPT Image 2. We keep both in the toolkit precisely because the right answer changes per brief.

The models will keep leapfrogging each other, so re-check the leaderboards and the pricing at decision time. What stays stable is the habit: match the model to the job, and to the stack the client already lives in.

This piece covers what TRELLIS is, how it works, where it fits in a real asset pipeline, and the points where it stops being a one-click answer.

What TRELLIS is

TRELLIS is a 3D generative model that accepts an image, several images, or a text prompt and produces a 3D asset.

🔸 Structured latents (SLAT). The core idea is one unified latent that fuses a sparse 3D voxel grid for structure with dense visual features for appearance. Decoupling shape from look is what lets the same latent become different outputs.
🔸 Three outputs from one latent. Radiance fields, 3D Gaussians, or a mesh exported as GLB. GLB is the practical target, since it carries materials into web and AR viewers.
🔸 Open and MIT-licensed. The image workhorse, TRELLIS-image-large, is 1.2B parameters. The model and most code are MIT, which matters for commercial use. A newer 4B line adds full physically based materials, worth watching as it matures.
🔸 Trained at scale. Around 500,000 curated objects, with the paper landing as a CVPR 2025 Spotlight.

This sits next to the parametric, controllable end of 3D work we cover in Grasshopper for computational design. Generative 3D and parametric 3D solve different problems.

How it works

The pipeline is short to describe and useful to understand before you commit a GPU to it.

1. Input. A single image, multiple views, or a text prompt.
2. Structured latent. A two-stage rectified-flow transformer first generates the sparse structure, then fills in the SLAT features.
3. Decode. The latent decodes to your chosen format: mesh, Gaussians, or radiance field.

In practice, plan for about 16GB of VRAM as a floor, with 24GB comfortable. Generation runs in under two minutes on an RTX 4090. Community builds push the memory needs lower, which is what makes TRELLIS realistic to self-host rather than rent. For teams already weighing local versus hosted inference, the same trade-off we wrote up in on-premise versus cloud LLMs applies to generative media too.

Where it fits in an asset pipeline

The strongest fit is the front of the pipeline, where speed beats polish.

🔸 One product photo or prompt to a GLB. Drop it into a three.js viewer or a model viewer on the web, convert to USDZ for AR, or stage it in a visualization scene. Fast concepting and previews are where TRELLIS shines.
🔸 Local editing. TRELLIS can regenerate or refine a region of the model, which is rare among single-image generators.
🔸 Honest about topology. The output is generative geometry, not artist-clean. Expect uneven triangles, no clean edge flow, and auto-generated UVs. For games or film you will retopologize, re-UV, and rebake textures. The newer materials-aware line narrows that gap without closing it.

So the value test for a given asset is simple: does this need to look right in a viewer next week, or does it need to be a riggable, optimized game asset? TRELLIS is excellent at the first and a starting point for the second.

TRELLIS versus the alternatives

The open and hosted 3D field moved quickly. A quick orientation:

Where TRELLIS stands: the strongest genuinely MIT option with multi-format output and local editing. Hosted tools like Tripo and Rodin beat it on out-of-the-box clean topology, and Hunyuan often wins on texture but with a more restrictive license. If your constraint is owning the model and the legal terms, TRELLIS is the obvious starting point.

The honest limits, and how we use it

A few caveats we put on the table before anyone wires TRELLIS into production:

🔸 Topology and UVs are not drop-in for games or CAD. Budget for retopo.
🔸 CAD is out of scope. Generative meshes are not parametric solids, so they are not engineering geometry.
🔸 You own the input risk. The model is MIT, but the legal exposure of your input image or prompt is yours. Do not feed product shots you cannot license.

We treat TRELLIS as a concepting and previz engine: a way to get a believable 3D asset in front of a client in an afternoon, then decide what deserves a hand-finished pipeline. That is the same instinct behind where the current wave of AI video models is useful, and the same selection discipline we apply when choosing an image model. The tool is not the deliverable. The judgement about where it fits is.

This piece maps both sides: what these platforms genuinely do well in 2026, and the specific points where you should expect to hit a wall.

What a no-code agent builder actually is

It helps to separate two things that get sold under the same banner.

Workflow automation is deterministic. A trigger fires, fixed steps run, the same input gives the same output. Classic Make or Zapier scenarios live here, and so does a lot of useful work.

A no-code agent builder lets a language model decide the path. You describe an outcome, and the model picks tools, calls APIs, reads your documents, and loops until it thinks it is done. The flow is not wired by you in advance.

The line is blurring, because the automation platforms bolted agents onto their canvases while the agent-native tools added integrations. For a Mittelstand team the practical question is not 'agent or workflow'. It is how much non-determinism you are letting into a business process, and who holds the data while it runs. We made the same distinction when we wrote about the difference between an API, an MCP server and a CLI.

What they do well today

Used for the right job, these tools earn their place quickly:

🔸 Triggers and integrations. Webhooks, app events, and schedules across thousands of connectors. The plumbing is solved.

🔸 Tool calling. The agent does not just chat, it acts: it queries a database, posts to a system, files a ticket.

🔸 Retrieval over your own documents. Grounding answers in internal knowledge is now a few clicks, the same pattern we cover in our piece on RAG.

🔸 Multi-step flows with a human in the loop. An approval gate before anything irreversible happens.

The payoff is speed. You can prove that an idea is worth doing in days, which is exactly what a prototype is for. We built our own event-scout micro-app in this spirit before deciding what deserved real engineering.

Where they stop

This is the part most demos skip, and it is the reason Gartner expects more than 40 percent of agentic projects to be cancelled by the end of 2027. The failure mode is rarely a crash. It is quieter than that.

🔸 Reliability and non-determinism. The same request does not give the same result twice. Agents do not error, they drift: they loop, pick the wrong tool, or act on stale context. The cost shows up as quality and latency, with no red light on the dashboard.

🔸 Evaluation and observability. No-code consoles give you thin tracing. Measuring whether an agent is actually getting better, across a whole multi-step run and not just the final answer, is a bolt-on you have to build.

🔸 Data governance and hosting. Most of these platforms are US SaaS. For German data that means GDPR and Schrems II questions you cannot wave away. The self-hostable options that keep data on your own EU servers are a short list: n8n, Flowise, Langflow, Dify. We go deeper on that trade-off in on-premise versus cloud LLMs and in what GDPR actually allows.

🔸 Cost at scale. Per-execution and per-credit billing punishes volume. On a credit model the same agent can cost a few euros or several hundred, depending only on how it was built. Pilots look cheap. Production often is not.

🔸 Lock-in and hand-off. Proprietary canvases do not export to real engineering. When you outgrow a no-code tool, you usually rebuild rather than migrate.

The decision lens

I use five questions to decide whether something stays no-code or graduates to a built system. Score each one low or high.

1. Data sensitivity. Does it touch personal or regulated data?
2. Volume and cost curve. Does usage scale to a point where per-credit billing hurts?
3. Reliability bar. Is it internal and forgiving, or customer-facing with an SLA?
4. Logic complexity. Light branching, or deep conditional and stateful logic?
5. Audit and evaluation. Do you need trajectory-level evals and an audit trail?

Two or more 'high' answers, and you want a custom or hybrid build. Otherwise no-code is the right tool, especially for proving value.

The pattern that works in practice is not either-or. Prototype on something like n8n or Flowise, find the path that actually delivers, then harden that one path into owned engineering. The prototype was not wasted. It told you exactly what to build.

How we treat them at iiterate

We reach for no-code agent builders early and often, then we are deliberate about when to leave them. A no-code agent is a fast, honest way to find out whether an outcome is worth the engineering it would take to make it reliable. That is genuine value, and for a lot of internal jobs it is the whole answer.

The mistake I see most in the Mittelstand is treating a working demo as a finished system. It is not the same thing, and the gap between them is the list above. If you know where the line sits before you start, you get the speed without the cancelled project. If you want a grounded view of where AI fits in a mid-sized firm in the first place, we wrote that up in KI solutions for the Mittelstand.

Two cautions up front for a German buyer. Pricing on all three changes often, so treat every number here as dated and worth re-checking. And data residency is a real constraint: none of them hosts in the EU by default, which matters before any personal data touches a call.

What each one actually is

🔸 ElevenLabs Agents. Built on the voice quality ElevenLabs is known for, now wrapped in a hosted agent layer with telephony over SIP. The pick when the most natural-sounding voice and developer control are the deciding factors.

🔸 Retell AI. Telephony-first voice-agent infrastructure. It positions on low latency and dependable call handling, inbound and outbound, and lets you bring your own carrier. The pick for production call operations.

🔸 Voiceflow. A visual, collaborative platform for designing chat and voice agents, with a built-in knowledge base. Design-led and no-code-first. The pick for a CX or design team iterating on flows. Note that live phone voice is the weakest of the three here, since it leans on a separate telephony provider.

If your job is closer to a text or tool-using agent than a phone line, the same build-versus-buy logic from no-code agent builders applies.

The comparison that matters

The dimensions that actually decide a voice-agent project, side by side:

Read the table as a map of trade-offs, not a scoreboard. No column is best at everything, which is the whole point.

Where each one fits

🔸 A German support line that needs telephony and a natural German voice. Start with Retell for dependable call handling and carrier control, or ElevenLabs if German voice naturalness is the deciding factor. For strict data sovereignty, neither hosts in the EU by default, so scope self-hosted Retell or an EU-native alternative.

🔸 A design-led team building a CX flow. Voiceflow. The visual builder, multi-editor collaboration, and knowledge base let a team iterate without engineers. Add telephony separately when you need voice.

🔸 A developer who wants maximum voice quality and custom control. ElevenLabs. Best TTS, SDK control, model-agnostic, SIP for telephony.

The pattern is the same one we apply to most tooling choices: name the job first, then pick the tool that owns that job.

The German data-residency question

This is the part that decides whether a voice agent is even allowed before voice quality matters at all.

GDPR compliance is not the same as EU hosting. A vendor can be GDPR-aligned and still process and store calls on US infrastructure, which reopens the Schrems II questions. Across these three: ElevenLabs offers EU data residency only on the Enterprise tier, Retell reaches it through self-hosting, and Voiceflow is cloud-only with no sovereign residency option.

For a German support line handling customer data, that turns the shortlist into a hosting decision as much as a feature decision. It is the same logic we lay out in what GDPR actually allows and in on-premise versus cloud LLMs: decide where the data is allowed to live, then choose the tool that respects it.

How we would choose

We would not start from the brand. We would start from three questions: does this run over the phone, who maintains it, and where is the data allowed to live.

If it is a phone line, Retell earns the first look. If voice quality carries the experience and a developer owns it, ElevenLabs. If a non-technical team needs to design and own the flow, Voiceflow. And if the data cannot leave the EU, the conversation moves to hosting before it moves to features, which often reshapes the shortlist.

Pricing will keep moving, so re-check it at evaluation time rather than trusting any single figure. The durable part is the fit, and the fit follows the job.

This piece explains why we built it, what it can do, where it honestly stops, and ends with an open question.

THE MANDATE, SHORT AND CORRECT

The electronic invoice is no longer optional in German B2B, it is mandatory, and the timeline is concrete.

• Since 1 January 2025, every domestic company must be able to receive and process e-invoices. No exceptions, no revenue threshold, small businesses included.
• Until the end of 2026, paper or PDF is still allowed for sending, but the PDF only with the recipient's consent.
• From 2027, companies with more than 800,000 euros in prior-year revenue must issue e-invoices, from 2028 then all companies.

E-invoice does not mean a PDF attachment, but a structured format under the European standard EN 16931. ZUGFeRD is the variant common in Germany: a PDF/A-3 file with embedded XML. The human sees a readable PDF, the software reads the XML directly, without retyping and without text recognition. The graphic below shows exactly these two views of the same file.

WHY WE DID NOT JUST TAKE OUT A SUBSCRIPTION

Everyone knows the trigger: the mandate is coming, so you need a tool. The obvious answer is a subscription, and that is exactly where we paused.

For a process that is fundamentally simple, generating a PDF with embedded XML, recurring costs add up quickly: common invoicing tools start at around 10 euros a month and go considerably higher for e-invoice sending, depending on the plan. For a business that only writes a handful of invoices a month, that means permanently paying for a full accounting suite you never actually use.

But the real reason was not the price, it was the data. An invoice contains names, addresses and often bank details. Send it through a cloud tool and that becomes data processing on behalf of a controller under Article 28 GDPR: a contract, a third-party provider, data leaving the building. Self-hosted, that disappears entirely. It is the same logic we apply to language models, covered in On-Premise vs. Cloud LLM: keep the benefit, do not give up data sovereignty.

WHAT BELEGT CONCRETELY DOES

Belegt is deliberately small and tightly scoped. It is a generator, not a replacement for accounting.

Technically, it is a web application that you run on your own computer or server. The data sits locally in a file, with sensitive fields such as bank details stored encrypted. It generates ZUGFeRD and Factur-X invoices in the EN 16931 profile, the level that legally counts as a fully valid e-invoice, validates them against the standard, assigns sequential invoice numbers, manages company and client profiles, and keeps track of open items and reports.

The two things that save us the most time: a guided workflow that completes a compliant invoice in a few steps, and the fact that the generated file immediately carries the machine-readable view the recipient needs. We use it ourselves, every month. That is the most honest recommendation we can give: we did not build it for a market, we built it for ourselves. It is one of several small tools that came about this way, like the Event Scout tool.

WHERE IT HONESTLY STOPS

A self-hosted single-purpose tool has real limits, and hiding them would be exactly the kind of marketing we do not do.

🔸 The standard keeps moving. EN 16931 and its code lists are updated regularly. A generator has to be maintained, or it will eventually produce invoices that are no longer compliant. That is work someone has to do.
🔸 Retention is not included. Generating is not the same as archiving in an audit-proof way. The GoBD require unalterable retention in the original format, now for eight years. A pure generator does not solve that, it remains the user's responsibility.
🔸 It does not replace a tax advisor. A technically valid invoice can still be incomplete in content. There is no direct connection to your accounting firm or to bookkeeping systems.

Fairly summarised: Belegt closes the mandatory gap of generation and validation cleanly and without a subscription. Archiving and the tax workflow remain outside its scope. Anyone who mistakes it for a full suite will be disappointed. Anyone who has exactly this one gap gets a tool without the extra weight.

SHOULD WE SHARE IT, AND HOW?

This piece deliberately ends with a question instead of an answer, because we do not know it ourselves yet.

There are two plausible paths. One: we release Belegt as a self-hosted solution that any small business can run on its own machine, subscription-free and with the data kept in-house. The other: we offer a maintained version that we keep current, help set up, and stand behind for standard updates, in exchange for a fair contribution. Both have their logic, and the maintenance burden from the last section is exactly why the answer is not trivial.

So here is our honest request: if a local, data-protection-compliant, subscription-free ZUGFeRD tool would be useful for you or your business, write to us. Would it be enough for you to run it yourself, or would you prefer a supported version? That signal is exactly what helps us decide whether something we built for ourselves becomes something we share.

Claude Code, Codex, Cursor, Antigravity, and Opencode solve the same task in very different ways. The one question that splits the field is simple: does your code have to be allowed to leave the building? Whoever can answer yes chooses by stack. Whoever cannot has exactly one serious option. This piece sorts the five along that question and ends with the decision I recommend to a German team.

FIVE TOOLS, ONE FIRST QUESTION

The five sit at different levels, and the form factor already says a lot about the use case.

• Claude Code is a terminal agent from Anthropic: strong at multi-file changes, large context, and an agentic loop in the terminal.
• Codex from OpenAI is available as a CLI, a cloud sandbox, and an IDE integration, all sharing one usage window.
• Cursor is the AI IDE with an agent mode and a background agent mode, plus free model choice.
• Antigravity is Google's agent-centric IDE, available since 20 November 2025, with a manager interface for launching and observing parallel agents (Google).
• Opencode is an open-source terminal agent under the MIT licence, model-agnostic across many providers and self-hosted endpoints (opencode.ai).

How these tools fit into a stack, from the API to the CLI, we laid out in API, MCP, or CLI. This piece is about the choice, and that starts with your data situation.

DOES YOUR CODE LEAVE THE BUILDING?

This one question sorts the field faster than any feature list, because it decides compliance and confidentiality before any feature counts.

Four of the five send code to someone else's cloud. Claude Code, Codex, Cursor, and Antigravity run against hosted models in the US. That is not automatically a disqualifier: for many projects it is fine, and on the enterprise tier you can negotiate zero-data-retention and no-train clauses. But the code goes out, and that has to be a conscious decision, not something overlooked.

Opencode is the exception. Because it is model-agnostic and can address a local endpoint, it can run entirely against a self-hosted model. Then the code never leaves the building. That is exactly the dividing line that decides everything else. Which open-weight model you put behind it is a separate decision, one we walk through in Open-weight model for German B2B.

IF THE CLOUD IS FINE: CHOOSE BY STACK

If you knowingly accept the hosted cloud, the stack decides, not the benchmark. A quick overview:

The pragmatic rule: an Anthropic house takes Claude Code, an OpenAI house takes Codex, an IDE-centric team takes Cursor or Antigravity. Benchmark numbers such as SWE-Bench scores around 85 percent circulate, but they are mostly vendor claims and rarely independently verified; I would not base a tool choice on them. What a coding agent delivers beyond pure development is shown in our piece Claude Code beyond engineering.

IF THE CODE MUST STAY IN-HOUSE: OPENCODE PLUS YOUR OWN MODEL

If the code must not leave, there remains a serious option, and it is a good one.

Opencode is open source under MIT, speaks to many providers and, crucially, can address a local endpoint. Paired with a self-hosted open-weight model, this produces a coding agent where neither source code nor prompts leave your own infrastructure. For regulated data, client confidentiality, or simply cautious customers, this is often the only viable setup. We took a dedicated look at an open coding model, Kimi K2.7, for exactly this case here.

The price of this control is doing the work yourself: you assemble the model, hardware, and operations on your own, there is no managed cloud agent fleet. In practice, it helps to give the agent structure, for example a codebase map, as we described in Graphify. The effort is real, but it buys something the hosted tools cannot offer.

HOW I DECIDE THIS

You do not need a single answer for the whole company, but the right one depending on your data situation. Here is how I approach it:

1. Clarify the data situation. Is the code in question allowed into a US cloud? This answer comes from legal and the client, not from the development team.
2. If yes, choose by stack. An Anthropic house goes to Claude Code, an OpenAI house goes to Codex, an IDE-centric team goes to Cursor or Antigravity, each with negotiated ZDR and no-train conditions.
3. If no, Opencode plus your own model. The only option where the code never leaves the building.
4. Keep an eye on lock-in. Every tool demands its own binding, so keep a path open back to a deeper level in case a provider changes its terms.

We ourselves work with several of these tools depending on the project, and that is exactly the point: the choice is project-bound, not ideological. The one small internal tool we built with an agent instead of commissioning it is covered in Building event-scout. Which of your repositories should not actually go into someone else's cloud today, and which tool do you use for it anyway?

This is the map of that surface, what each piece is for, and where the sharp edges are.

FIVE WAYS TO EXTEND, ONE PRINCIPLE

Underneath the names, every extension point does the same thing: it moves know-how out of the prompt and into version-controlled files the agent loads when it needs them.

• Skills are folders of instructions, scripts, and resources. A short description sits in context; the full skill loads only when the agent judges it relevant. This is progressive disclosure: cheap to keep around, detailed when invoked.
• Slash commands are named shortcuts that expand into a fixed prompt. The plain way to encode a repeated request once and reuse it.
• Hooks are shell commands fired at lifecycle events: session start, before a tool call, after it, on stop. A pre-tool hook can inspect and block a call before it runs.
• MCP connectors give the agent authenticated access to systems it cannot otherwise reach: a database, an issue tracker, an internal API. Each server carries its own credentials.
• Subagents are separate agent instances spawned for a focused subtask, with their own context and instructions.

A plugin bundles any of these into one installable unit. The principle under all of it: encode your know-how as files in your repo, not as habits in one person's head. We laid out the system-integration version of this choice in API, MCP or CLI.

SKILLS AND MCP ARE NOT RIVALS

The most common question right now is "Skills or MCP", and the honest answer is that they solve different problems.

MCP is access: it connects the agent to a system it cannot reach on its own, with credentials and state. Skills are know-how: repeatable expertise the agent applies to systems it already has. The analogy doing the rounds is fair: MCP is the aisles of the hardware store, Skills are the experienced employee who knows which aisle to walk to.

The token economics decide the shape of a good setup. A Skill costs a few dozen tokens until it is invoked. A handful of MCP servers can cost tens of thousands of tokens of context before the first task, because each server announces all of its tools up front. So the working pattern most practitioners converge on is many thin Skills and few, well-chosen connectors, not an install-everything pile. The demo below walks the five extension types and the cost and risk each one carries.

WHY THE OPEN STANDARD MATTERS FOR SOVEREIGNTY

The most useful recent change is that the extension layer stopped being one vendor's feature.

Agent Skills were released as an open standard in December 2025, and the format was picked up across several agent vendors within weeks. In practice that means a skill you write for one harness is not trapped there. For a German firm weighing the "locked to a single US vendor" risk, this is a partial answer at the layer you control: the know-how you encode is portable, even when the model underneath is rented.

Pair that with connectors pointed at EU-hosted or on-premise systems and the data-residency story holds at the same time as the capability story. The know-how is yours and portable; the data stays where it must. That is a more durable position than betting the workflow on one provider's roadmap, the same reasoning behind choosing a coding agent on the harness, not the model.

EVERY EXTENSION POINT IS AN ATTACK SURFACE

The same power that makes the harness useful makes it dangerous, and the risks are recent and documented, not hypothetical.

Hooks run arbitrary shell, which is exactly an execution surface. Check Point disclosed CVE-2025-59536 in February 2026: a malicious settings file in a cloned repository could run hooks before the trust dialog even appeared. A companion issue, CVE-2026-21852, covered API-key exfiltration through an environment override. MCP brings a supply-chain problem of its own: each server holds credentials, and scans have found hundreds of MCP servers exposed to the internet with no authentication. And the skill marketplaces now list thousands of community skills, easy to install and hard to audit, with reports of outright malicious ones in circulation.

None of this is a reason to avoid extending the harness. It is the reason to extend it deliberately.

GOVERN THE CATALOG, DO NOT COLLECT PLUGINS

The discipline that separates a production setup from a science experiment is a reviewed, allow-listed catalog: a known set of skills, hooks, and connectors that someone has read, with a trust gate before anything new joins it.

That is unglamorous and it is the whole game. Which hooks may run shell. Which MCP servers hold which credentials. Which skills are approved, and who approved them. For a Mittelstand team, this is where institutional knowledge becomes durable tooling that survives staff turnover, and where the work stops being one engineer's clever config and becomes something the company owns. When we built our own internal scouting tool as a small agentic app, the value was not the cleverness, it was that the process was now a reviewed file in a repo rather than a memory. We wrote that up in building a small agentic micro-app.

The model you can swap next quarter. The catalog of extensions is the asset you keep. So the question worth asking before installing the next plugin is simple: who reviewed it, and what can it touch?

This piece is a sober overview: the use cases that hold up, the funding that actually exists in RLP, and the one hurdle that slows almost everything down.

WHICH AI SOLUTIONS REALLY HOLD UP

The solutions that prove themselves in the Mittelstand are unspectacular and close to existing processes. They save time, they rarely invent new revenue.

🔸 Document intelligence. Automatically read and classify invoices, delivery notes, contracts and emails. Lowest barrier to entry, quickly noticeable effect.
🔸 RAG knowledge management. An in-house information system over your internal document store: manuals, process documentation, quotes, service history. Eases onboarding and support, and the knowledge isn't lost when staff leave.
🔸 Quote and invoice automation. Generate quote texts and calculations from past cases, organise invoice workflows. Already on the agenda anyway because of the e-invoicing mandate.
🔸 Service agents on your own knowledge. First-level support and FAQs, grounded in company data instead of a generic cloud chatbot.
🔸 Local LLMs for sensitive data. Process HR, client, engineering or patient data locally or in German hosting.

The sober assessment: in the Mittelstand, AI mainly pays into efficiency, rarely directly into revenue. If you don't choose the use case cleanly, you burn budget, precisely because innovation spending tends to be falling.

THE FUNDING LANDSCAPE IN RLP, WITHOUT THE MYTHS

Before we get to funding, a cleanup: many programmes still in circulation are dead or were never RLP in the first place. DigiBoost RLP has been closed since 2022, the nationwide go-digital programme ran out at the end of 2024, and the often-cited 20,000 euro digitalisation voucher belongs to North Rhine-Westphalia, not RLP.

What's actually running in 2025 and 2026:

• Betriebsberatungsprogramm RLP. Running since December 2025, a grant covering, among other things, digitalisation and artificial intelligence. Replaces the former BITT.
• IBI-EFRE Rheinland-Pfalz. A grant for operational innovation and digitalisation, for SMEs headquartered in RLP.
• Innovationsgutschein RLP. Up to 20,000 euros, non-repayable, for research and development contracts placed with external providers.
• Mittelstand-Digital Zentrum Kaiserslautern. Free, vendor-neutral advice, workshops and demonstrators.

So the funding is there. It just doesn't replace the decision about what you actually want to build. That's exactly what the selection in the graphic below helps with.

THE REAL HURDLE IS DATA PROTECTION, NOT TECHNOLOGY

When AI projects fail in the Mittelstand, it's rarely because of the model. They fail on the question of where the data is allowed to sit.

77 percent of companies name data protection as their biggest hurdle, ahead of the skills shortage at 70 percent. At the same time, 73 percent allow their employees to use language models, but only 23 percent restrict them to company-owned models. In plain terms: roughly half let freely available cloud models run unchecked. That isn't digitalisation, that's shadow AI, a data leak waiting to happen.

On top of that comes a lack of data maturity, almost a quarter have no suitable data, and a justified scepticism about ROI. The gap isn't AI yes or no. It sits between informal use and a secure, production-ready framework.

SOVEREIGN DOES NOT MEAN MORE EXPENSIVE, IT MEANS CONTROLLABLE

The answer to the data protection hurdle isn't to do without AI. It's to align where you deploy it with data sensitivity, not with marketing.

For uncritical tasks, a cloud model is justifiable. As soon as personal, confidential or business-critical data is involved, processing belongs in a German or EU environment, or on your own hardware. RAG over your own document store, local or DE-hosted, gives you the benefit of a language model without sending the content out of the house with every query. We cover when local AI is justified over the cloud in On-Prem vs. Cloud LLM, and how RAG works technically in What is RAG.

To be honest: not every solution has to be on-prem. The skill lies in the matching, and that's exactly what no tool and no funding notice can do for you.

A REALISTIC FIRST STEP

The walkable path is sober and staged, not one big AI promise delivered all at once.

Prioritise a use case where time or errors are at stake. Check the data foundation, because RAG over a chaotic document store delivers no value. Build a small pilot with a clear measure of success. Only then scale. These stages can be co-financed through the Betriebsberatungsprogramm RLP or the Innovationsgutschein, and supported free of charge by the Mittelstand-Digital Zentrum. We've described the full process in the practical AI roadmap.

We at iiterate are based in Koblenz and Remagen, and we bring exactly these three things together: strategy, build and compliance. The RLP Mittelstand is already on it. The task is to turn informal experimentation into something sovereign and resilient. Where would you start, and where does your most sensitive data sit?

Veo, Kling, and Seedance deliver impressive clips but are closed and hosted. Wan Animate from Alibaba is the one open model in the lineup, and therefore the interesting lever for anyone who does not want to hand material out of their control. This piece places the four for a German company building product demos and marketing videos, and takes seriously the regulation that tightens in August.

AUDIO BECAME STANDARD, QUALITY BECAME MANDATORY

The most important shift of the year is that visible quality is no longer an edge, it is table stakes.

Native audio has become standard. Veo 3 introduced synchronously generated audio, and by early 2026 Kling 2.6 and ByteDance's Seedance 2.0 were also generating dialogue and sound effects in a single pass. Silent models now look outdated for demo work. At the same time, clips remain short: eight seconds native is typical, Seedance 2.0 manages around fifteen, and longer pieces are stitched together rather than generated as a single continuous take.

Chinese labs lead several leaderboards. Seedance topped independent text-to-video comparisons in June 2025, ahead of Veo 3 and Kling (arXiv). Such rankings shift monthly. That is precisely why the choice should not be tied to the leaderboard, but to the three criteria that stay stable.

THE FOUR AT A GLANCE

An important note on naming upfront: at ByteDance, Seedream is the image model and Seedance is the video model. This section is about Seedance.

• Veo 3.1 (Google, closed). Best prompt fidelity, synchronous 48 kHz audio, the deepest pipeline integration via Vertex AI and Flow. Hosted, output carries Google's SynthID watermark.
• Kling 2.6 (Kuaishou, closed). Strong image-to-video and good motion, native audio since version 2.6, up to about ten seconds. Accessible via API with data hosted in Singapore.
• Seedance 2.0 (ByteDance, closed). Longer clips of up to around fifteen seconds and camera planning. Accompanied by an open legal question after Disney sent a cease-and-desist in February 2026, which poses a real risk for commercial use.
• Wan Animate (Alibaba, open). Released under Apache 2.0 and self-hostable, specialised in character animation, motion transfer, and character replacement from a single reference image (Hugging Face). Less polish and shorter clips than the hosted models, but full control.

Runway, OpenAI's Sora 2, and MiniMax round out the field further, but on the question that matters here they sit in the same category: strong, but closed.

THE LABELLING OBLIGATION ARRIVES ON 2 AUGUST

Regulation is the real event of 2026, not the next model. Anyone using AI video commercially needs to solve labelling beforehand.

The transparency obligations under Article 50 of the EU AI Act become applicable from 2 August 2026 (EU AI Act). Synthetic media must be machine-readably marked and deepfakes must be labelled. In practice this means: provenance is a compliance function, not a nice-to-have. Hosted models partly bring this along, Google for instance via SynthID, others via C2PA content credentials. Self-hosted Wan, by contrast, carries no enforced watermark, so labelling then falls to you, as its own documented step in the pipeline.

Which AI content falls under the regulation and what needs to be implemented by when, we set out in EU AI Act 2026 and, in the context of GDPR, in GDPR and AI.

THE OPEN MODEL IS THE LEVER

If material is not allowed to leave the building, the open model is the actual answer, not the prettiest one.

Wan in versions 2.1 to 2.2, and Wan Animate, are consistently released under Apache 2.0, meaning full commercial use, redistribution, and fine-tuning without phoning home. The smaller variant runs on a single 24 GB card, the 14B variant needs around 80 GB. Self-hosted on European, if necessary air-gapped, infrastructure, no footage leaves your control, and there are no third-party terms of use and no geopolitical dependency. The price is less polish and shorter clips than with Veo or Seedance, a trade-off made deliberately for the sake of sovereignty.

This is the same logic we apply to language models: an open, controlled model beats the last few percentage points of quality when control is the point (sovereign European AI). The same open path is emerging for world models too (NVIDIA Cosmos 3).

HOW I DECIDE THIS FOR A DEMO PROJECT

The decision follows the data situation and the purpose, not the prettiest demo reel. Here is how I approach it:

1. Sensitive or regulated material. If the video shows pre-launch products, customers, or internal content, then self-hosted Wan on EU infrastructure, with labelling as its own pipeline step.
2. Public marketing, uncritical content, polish matters. Then a hosted model such as Veo or Seedance, but with deliberately chosen terms and clarified provenance.
3. In every case, solve labelling before 2 August, not after.

In our own creative work we mix this depending on the project, and the point is not to crown one model the winner. The point is that visible quality has become the easy part, and the hard questions, data situation, rights, and labelling, decide the deployment. Which of your planned videos could you even entrust to a hosted US service, and which belongs on your own infrastructure?

Qwen, Kimi, Nemotron, and Minimax are all seriously usable in 2026. But only three of the four carry a genuinely free license, only one family fits cleanly on Mittelstand hardware, and no vendor publishes a clean comparison of exactly these four in German. This piece sorts the four by the criteria a buyer actually has to check, and ends with the decision I recommend to a Mittelstand company.

License first, then the benchmark

The license is the first gate, because it decides every commercial on-prem use before a single benchmark counts.

Three of the four are straightforward here. Qwen3 is under Apache 2.0, Minimax M2 under MIT, Kimi K2 under a modified MIT license (Hugging Face). These are real, free grants: commercial use, redistribution, fine-tuning, no phoning home.

🔸 Nemotron is the special case.
NVIDIA's Open Model License is not a pure Apache or MIT license. It ties usage to NVIDIA's conditions and terminates automatically if you remove the built-in safety mechanisms (NVIDIA). The model is good, but this clause lands on the legal department's desk first, not engineering's. We described NVIDIA's approach in detail in our piece on Nemotron 3.

Anyone using sovereignty as an argument should be able to read the license like a contract, because that is exactly what it is.

How good is the German, really?

The honest answer: there is no clean four-way comparison of these models in German, so you have to build it yourself.

German eval infrastructure exists. SuperGLEBer, the Occiglot Euro-LLM leaderboard, and MMLU-ProX across 29 languages cover German (ACL Anthology). What is missing is a published head-to-head comparison of exactly these four on German text. Qwen3 was trained on 119 languages and is the family with the broadest documented multilingual coverage (Qwen); for Kimi, Nemotron, and Minimax, the providers do not name German as a particular focus.

The practical consequence is uncomfortable but clear: benchmark rankings on English tests say little about quality on your German contracts, proposals, or support texts. The only reliable test is the one on your own material. How to read leaderboards at all without being misled is covered in the piece on the local model.

What runs on your hardware

Hardware fit sorts the field faster than any benchmark, because a model that does not fit on your cards simply falls out of the running.

Qwen3 is the exception here. The dense variants from 4B to 32B run quantised on one to two GPUs, and the 30B-A3B MoE variant delivers model quality with only around 3B of active compute. That is the profile that fits a typical on-prem box in the Mittelstand.

Kimi K2 and Minimax M2 are frontier MoE models. Minimax activates only 10B parameters, but the full weights require a multi-GPU server; Kimi, with 1 trillion total parameters, even more so. Nemotron 3 Nano is very lean at 3.6B active parameters and runs on a single card, but falls back due to its license. What this VRAM reality actually costs, we worked out in the hardware piece.

The geopolitics sits in the weights, not the API

With open-weight models, the sovereignty question shifts: the weights run entirely offline, so there is no remote kill switch. What remains is whatever is baked into the model itself.

Three of the four labs are Chinese (Qwen, Kimi, Minimax), one is American (Nemotron). Because the weights run locally, the real question is not the server location but the alignment built into the model itself. Independent tests report high refusal rates for Chinese models on politically sensitive topics, strongest in Chinese and weaker but still present in German (ChinaBench). These figures are self-published and not peer-reviewed, so they should be read with caution, but the effect is real enough to warrant an honest paragraph in your requirements specification.

For pure B2B text work, meaning drafts, extraction, classification, and retrieval over your own documents, this effect is usually manageable. It is a question of output quality and external perception, not a security hole. We draw the larger sovereignty arc, European models, and what the label is actually worth, in our piece on sovereign European AI.

How I decide this for a Mittelstand company

The decision is not patriotic and not driven by the leaderboard, it follows a sequence. Here is how I do it:

1. Check the license. Only models with a genuine Apache or MIT grant make the shortlist without a legal query. That means Qwen3, Kimi K2, and Minimax M2 here.
2. Test on your own German. Not the English benchmark, but run fifty of your real texts against two candidates and evaluate them blind.
3. Match the hardware. Whatever fits on your one to two cards almost always wins, because operation otherwise becomes expensive and fragile.

For most Mittelstand companies, that lands on Qwen3 as the starting point: freely licensed, broadly multilingual, in the right hardware window. Kimi and Minimax are the choice when the server is already in place and reasoning or agents are the priority. We took a dedicated look at the open-weight coding model Kimi K2.7.

And, as always with us: build the architecture so you can swap the model out. The next better open-weight model is certainly coming. The real question is not which one leads today, but which of your tasks actually need the strongest model, and which only need a good one that belongs to you. Which of your texts would you entrust to a model you have not tested yourself?

This piece is the practitioner version of that setup, and the honest version of its limits.

The vault is the asset, the agent is rented

Keep the durable thing and the swappable thing separate, and most of the design follows.

The durable thing is your vault: plain .md files, [[wikilinks]], YAML frontmatter. No database, no proprietary format, no export step. The swappable thing is the agent reading it. The two community projects leading this space, obsidian-second-brain and obsidian-mind, both ship for Claude Code, Codex CLI, and Gemini CLI on purpose. The vault is the investment; the model is a tenant you can evict.

That is the same reasoning we apply to wiring AI into any stack: own the interface, rent the capability. We wrote it up for system integration in API, MCP or CLI. Personal knowledge management is the same argument at desk scale.

What changes when an agent can read your notes

An agent with file access turns a static vault into one that maintains itself, within limits you set.

• CLAUDE.md is the operating manual. Run claude from the vault root and it loads this file every session: your folder map, your linking conventions, your note templates, your default behaviours. It is the single load-bearing file in every working setup. /init writes a first draft.
• Session context is a hook, not magic. obsidian-mind injects a north-star excerpt, a task list, and a file listing at session start so the agent does not begin blank. That is a SessionStart hook running on your machine, nothing more.
• Filing becomes a skill. Slash commands and subagents handle the chores: filing a clipped note into the right folder, generating a map-of-content, finding orphaned notes, writing the daily log. obsidian-second-brain ships dozens of these.
• Frontmatter is the machine-readable layer. Date, status, source, a confidence marker in YAML, plus wikilinks, give the agent structure to retrieve and cross-reference against, instead of guessing from prose.

The newest shift is notes that rewrite rather than append: a new source updates and reconciles existing notes instead of stacking another dated entry. Useful, and the first place to be careful, which is the next section but one.

Retrieval, not dumping: the token reality

Do not load the whole vault. Let the agent fetch the few notes a question needs.

The naive setup pushes the vault into context and breaks around a few hundred notes. The frugal setup keeps everything on disk and pulls only what matches, through command-line search or grep. Practitioners report the gap as roughly 100 tokens for a CLI vault search against tens of thousands for loading a project wholesale. The mechanics are unglamorous: search, read the three notes that matched, answer.

This still matters even though Claude Code now runs a million-token context window. The rolling rate limit bites long before the window fills, so a vault that answers in 100 tokens lets you ask a hundred questions where the dump-everything setup gives you a handful. Frugal retrieval is what makes a second brain usable daily rather than impressively once.

The privacy line is inference, not storage

The community sells "everything stays in your vault, no SaaS." That is true for storage and false for inference, and the difference is the whole risk.

Your Markdown stays on your disk. But by default every query sends the relevant notes to a cloud API to be read. For a hobby vault of recipes, fine. For a vault holding client notes, contracts, or anything covered by an AVV, that is data leaving the building on each question. Plain-Markdown portability is not the same as local privacy.

Two more honest caveats. Prompt injection is structural: an agent reading your notes cannot cleanly separate "instructions" from "content," so any Markdown that enters the vault, a clipped web page, a shared note, an ingested PDF, can carry instructions it then acts on. And the risk is not hypothetical: in April 2026, attackers abused Obsidian community plugins to run code when a victim opened a shared vault, reported by The Hacker News. An agent with file-write and shell access raises that stake, not lowers it. Self-rewriting notes can also quietly invent a backlink or overwrite a correct line, and the change is saved before you read it.

The same pattern, kept sovereign

Everything good about this setup survives when you move the model in-house. The privacy problem is the only part that needs the change.

The sovereign version keeps the vault and the workflow and swaps cloud inference for a local model: a retrieval layer over your Markdown served by a model running on your own hardware or in EU hosting. You keep the plain-text ownership, the CLAUDE.md operating manual, the skills, and you stop sending the contents out on every question. For a Mittelstand firm, this is the bridge from a personal experiment to real internal knowledge management, product manuals, process docs, support history, without an AVV question hanging over each query. When to make that move, and what it costs, is the subject of On-Premise vs. Cloud LLM.

The hobbyist framing is "build a second brain." The business framing is the same machine pointed at the company's knowledge instead of yours. The interesting question, again, is not whether it works. It is who gets to read the notes. So: where does your vault actually send its questions right now?

This piece places both in context: what is already strong, where it stalls, and what follows from that for a company on the ground.

The research is there, and it is dense

Rhineland-Palatinate's research side does not need to hide behind any other federal state. It is simply heavily concentrated.

Kaiserslautern carries the core: the main site of the DFKI, the RPTU with eight AI professorships, Fraunhofer IESE and ITWM, plus a cooperation with the Max Planck Institute. Germany's first AI innovation and quality centre under Mission KI is also based here, with a federal budget of EUR 32 million. Koblenz is building the second pole: the university launched an interdisciplinary AI hub in July 2025, and Koblenz University of Applied Sciences runs DigiMit, a competence centre for the region.

The honest assessment sits right next to that. The cluster is weighted towards Kaiserslautern and Koblenz, the rural areas are less well connected, and in the national comparison RLP sits in the upper mid-field, not at the top. On digitalisation, Bavaria, Berlin and Hamburg lead, on innovation it is Baden-Württemberg.

The state itself is betting on sovereign AI

What is notable is what the state actually works with: not a US cloud subscription, but its own sovereign approach.

The state's AI agenda names an AI triad, and one of the three pillars is explicitly LLM on-premise. With GPU4GenAI, the state is investing in its own GPU infrastructure at the DFKI, and since September 2025 a three-year cooperation with the DFKI has been running that brings AI into state administration: document analysis, secure data platforms, assistance systems.

That is more than a footnote. If the public sector in RLP is building data-protection-compliant, locally operated AI, then on-prem and sovereignty consulting for the Mittelstand is not a niche topic, it is a natural extension of what the state is already demonstrating. The chart below shows the underlying problem: strong hubs, too few connections into the rural areas.

In the Mittelstand, the picture looks different

On the shop floor, the pace is different, and the numbers are sober.

In a survey by Koblenz University of Applied Sciences in northern RLP (176 companies, December 2025), only 8.5 percent rate AI as central to their business model today, rising to 42 percent in five years. More than a quarter already use AI tools, roughly half are testing them in pilot projects. A second regional study by the IHK and the Handwerkskammer Koblenz shows the real pattern: just under two thirds use AI, most of them for no more than two years, almost 90 percent rely on external software, and the biggest challenge named is legal certainty.

Cutting-edge research and broad diffusion are therefore two different things. One is present here, the other is not yet.

The gap is implementation, not technology

The obstacle in the Mittelstand is rarely the model. It is the path from idea to safe, productive deployment.

Nationwide, only around a third of companies have a fully worked-out AI strategy, and in RLP a lack of expertise is repeatedly cited as the brake. And the almost 90 percent that rely on external software are buying dependency along with it, often on US cloud services, in exactly the area where those same companies name legal certainty as their biggest concern. That is a contradiction you can see coming.

An honest qualification belongs here too: usage rates overstate maturity. Much of it is informal use of freely available tools, without strategy, without governance, without a clear data protection framework. In the Mittelstand, the question is no longer AI yes or no. It is sovereign and productive instead of informal and risky. What that means in practice, we have spelled out in the practical AI roadmap for the Mittelstand.

What this means for companies in RLP

The obvious strategy is the one the state is already running: capture the benefits without giving up data sovereignty.

The missing piece is not another tool, it is the layer between funding and research on one side and productive, sovereign deployment on the other. Concretely, that means: local or Germany-hosted models for sensitive data, RAG knowledge management on your own document base, and a sober path from use case selection through to pilot operation. We assess when local AI pays off against the cloud in on-prem vs. cloud LLM.

We at iiterate are based in Koblenz and Remagen, right in the middle of the state's second AI pole, and this diffusion layer is exactly our work: bringing strategy, build and compliance together, instead of leaving Mittelstand companies alone between a funding notice and the shop floor. The research in RLP is a given. The more interesting question is how quickly it reaches the rural areas, and who draws the lines to get it there.

This piece explains why long context is expensive, which subquadratic approaches exist, what the loudest promises actually have evidence for, and what that concretely brings for on-prem RAG. The recommendation at the end is unspectacular, and viable for exactly that reason.

Why long context is expensive

The reason lies in the mathematics of self-attention: its cost grows quadratically with the length of the input.

In a classic transformer, every token is compared against every other token. If the context length doubles, the compute cost for attention roughly quadruples. On top of that comes memory: the key-value cache that the model carries along during generation grows linearly with length and quickly eats up the available memory on a fixed GPU. That is the real bottleneck for on-prem operation, where the hardware is fixed and cannot be elastically rented on top.

This is exactly where subquadratic approaches come in. They try to push sequence cost towards linear, so O(n) instead of O(n squared), and to cap the memory per token. What this means for the hardware reality inside a company, we worked through in local LLM.

The subquadratic landscape

There are several paths, and the practical winner of the years 2024 to 2026 is not the purest one, but the hybrid one.

• State space models (Mamba). Mamba (December 2023) and Mamba-2 (May 2024) model sequences in linear time with a fixed state memory instead of a growing cache (arXiv). The price: a fixed state is a lossy compressor and weaker at exactly recalling positions far back in the sequence.
• Linear attention (RWKV, RetNet). Reformulate attention so that cost grows roughly linearly. Similar trade-off on associative recall.
• Hybrids in production. No one ships pure subquadratic models at top quality. Instead, everyone mixes a minority of full attention layers with a majority of state space or linear layers: Jamba (AI21, 2024), MiniMax-01 (January 2025), Falcon-H1 (May 2025), NVIDIA's Nemotron-H, IBM Granite 4.0 (October 2025) and Qwen3-Next (September 2025). The full layers preserve memory, the lean ones buy the cost and memory advantage.

The NVIDIA line behind Nemotron, which uses exactly this hybrid design, we described in Nemotron 3.

What 'subQ' promises, and what of it is proven

The term calls for caution, because it carries two meanings, one architectural and one marketed.

Alongside the general subquadratic family there is a concrete product: the start-up Subquadratic came out of stealth in May 2026 with funding of around 29 million dollars and promotes a subquadratic, sparse attention mechanism. The headlines are big: a research model with 12 million tokens of context, around a fifth of the cost compared to top models, a multiple of the speed (The New Stack).

The honest assessment: part of it is verified by third parties, for instance a RULER-128K result, while the spectacular figures on 12 million tokens and the speed factor are vendor claims from single runs and not independently reproduced. That is a promising signal, not a basis for procurement. This exact distinction, proven versus claimed, is the discipline we apply to every new model.

What this brings for on-prem RAG

The concrete gain is memory and throughput on fixed hardware, and that is exactly the right lever for on-prem RAG.

• Bounded cache, predictable memory. The state space layers carry a fixed state, so memory does not explode with length. IBM states over 70 percent less requirement for long context with Granite 4.0, a vendor figure, but plausible, and pointing towards more concurrent sessions per GPU.
• Model and context on one card. NVIDIA reports that a Nemotron-H model with 51 billion parameters, cache included, fits onto a single 80 GB card, again a vendor figure.
• Looser chunking discipline. Cheaper context allows larger windows and less anxious slicing of documents.

Honest caveats belong here too. For memory-heavy RAG, for instance the exact passage across very long texts, pure subquadratic models still lag behind full attention, hybrids close the gap largely but not completely. The tooling around them, meaning quantisation, serving and fine-tuning, lags behind the established dense models. And the most important sentence: long context is not the same as good retrieval. A solid model with good RAG today beats, almost always, the attempt to simply dump in millions of tokens. What RAG actually delivers is covered in What is RAG and The power of RAG.

How I treat this today

Subquadratic is worth watching, but not worth betting on. Here is how I handle it:

1. Build the RAG layer model-independent. Behind a stable interface, so that a Granite-4-class hybrid can be dropped in as soon as the tooling around it is mature.
2. Start with a solid, well-supported model, not the newest architecture, and get the value from retrieval quality.
3. Ignore unproven promises. A claimed factor of a thousand can wait until someone independent reproduces it.

That is the same pattern we apply to on-prem versus cloud: decide deliberately, build swappable (on-prem vs. cloud LLM). The interesting question is not whether subquadratic models will one day make long context cheap. They probably will. The question is whether your architecture is ready to capture the gain without betting on it today. Is your RAG layer built so that you can swap the model without rewriting everything?

Most teams wiring AI into their systems do not need to choose a winner. They need to put each call at the right height. This piece defines the three plainly, shows when each fits, names the costs people miss, and ends with a decision you can defend. Two questions settle most of it: how many integrations are you running, and who has to audit them.

Three layers, not three rivals

Each pattern sits at a different level of abstraction, with a clean trade between control and convenience.

• A direct API call is the lowest building block. Your code calls a model or a service over HTTP. You get maximum control and standard tooling, and you write the glue: auth, request, response parsing, error handling.
• MCP, the Model Context Protocol, standardises the connection, not the model. It is an open standard Anthropic introduced in November 2024 that gives a model one consistent way to discover and call tools and data, so an MCP-capable client can talk to an MCP server it has not met before (Wikipedia). It spread quickly: through 2025 it was adopted by OpenAI, Google, and Microsoft, reached more than 5,800 community servers by April 2025, and by late 2025 was reporting tens of millions of monthly SDK downloads before Anthropic donated it to a Linux Foundation effort (Thoughtworks, The New Stack).
• An agentic CLI is the highest layer. A tool like Claude Code wraps a model, a set of tools, and a reasoning loop into a terminal workflow. Least glue, most opinionated, fastest for open-ended work.

They compose rather than compete: an agentic CLI may call MCP servers, which in turn wrap plain APIs (iiterate).

When each one is the right height

The choice follows the shape of the work, not the novelty of the option. A short map:

In practice: a nightly batch job hitting one endpoint should call the API directly, because MCP would add latency and failure points for no benefit. MCP earns its keep once several agents need the same integrations, so every MCP client gets one consistent interface instead of each agent carrying its own wrapper. The crossover that practitioners report is around three or more AI-connected integrations (MindStudio). An agentic CLI fits when the task is open-ended and someone needs results fast across many tools.

The costs people miss

The headline benefits are easy to find. The quieter costs decide whether a choice ages well.

• Tokens. A standardised tool layer is not free. When an agent calls one tool repeatedly, MCP's discovery overhead can cost far more tokens than a direct CLI or API call for the same task (MindStudio).
• Observability. HTTP calls show up in your logs, and standard tools like Datadog trace them for free. The MCP transport is comparatively opaque, and production monitoring for it is still maturing, so you pay in custom instrumentation (IJONIS).
• Lock-in and portability. A raw API keeps the integration in code you own. The higher you go, the more you depend on a client, a server ecosystem, or a vendor's agent. Keep a path back down a layer.

MCP's security surface is new and real

Standardising how models reach tools also standardises a new attack surface, and it deserves explicit handling.

OWASP ranks prompt injection as the top vulnerability for LLM applications in 2025. MCP adds a specific variant, tool poisoning, where malicious instructions are embedded in a tool's description, closer to a supply-chain attack on the agent's context than to user-side jailbreaking, and tracked as CVE-2025-54136 (TrueFoundry). Because MCP servers often hold credentials and reach real systems, an over-permissioned or untrusted server is a serious risk, and client protections vary widely (Simon Willison, Microsoft). The practical posture: run vetted servers, give each least privilege, and keep monitoring, the same governance questions that apply the moment an agent touches real data (iiterate).

A decision you can defend

You do not need a single answer for the whole company. You need the right height per integration. A working rule:

1. Default to a direct API for a single, stable, high-volume call.
2. Reach for MCP when several agents need the same tools, or you want swappable tools behind one interface.
3. Use an agentic CLI when the work is open-ended and a person or another agent drives it.
4. Whatever the layer, keep least privilege, real logs, and a way to drop back down a layer if a vendor changes terms.

For most production systems the honest answer is a mix: direct APIs under the services, MCP as the translation and discovery layer for agents, and a CLI where humans work. The failure mode is not picking the wrong tool. It is adopting the newest layer because it is newest, and paying its costs for a job a lower layer would have done better.

The point of the piece is not the events. It is the shape. event-scout is an agentic micro-app: something you build once with a coding agent and then leave running, where the agent does the messy judgment and plain scripts do the boring, repeatable plumbing. That split is the whole lesson, and it travels to nearly every internal task a Mittelstand team keeps doing by hand. event-scout runs on the highest of those layers, an agentic CLI (iiterate).

WHAT IT DOES, CONCRETELY

Once a run, event-scout works through a curated source database of event sites, calendars, newsletters, and a few LinkedIn feeds. From everything it fetches, it keeps only in-person, future events within reach of Remagen, scores each one for how useful it is to us, removes duplicates into a single store, and rebuilds a dashboard we actually open.

Little about that list is novel on its own. What makes it work is that it runs unattended on a schedule, and that the judgment it applies is ours, not a generic relevance filter. The output is not a feed of every tech event in Germany. It is a short, ranked answer to one question: where should we show up next.

THE SHAPE THAT MADE IT WORK: AGENT FOR JUDGMENT, SCRIPTS FOR PLUMBING

The design decision that matters is where the model stops and a script starts.

Fetching is delegated to a deterministic helper. A small Node orchestrator renders each due source in a real headless browser, so it handles JavaScript pages, light anti-bot walls, and lazy-loaded lists, and it captures structured schema.org event data when a page exposes it. That is plumbing: reliable, cron-able, and the same every time.

The agent reads what the fetcher saved and does the parts that resist hard-coding: pulling real events out of messy pages, deciding what counts as in-person and relevant, scoring each one, and spotting that two listings are the same event. A second small engine then merges, prunes old entries, and regenerates the dashboard.

🔸 Do not make the model do what a script does cheaply.
Rendering a page and writing a file is deterministic work. Handing it to the model would be slower, costlier, and less reliable.

🔸 Do not make a script do what needs judgment.
Whether a half-formatted listing is a real, relevant, in-person event is exactly the call a model is good at and a regex is not.

Getting that line in the right place is most of why the tool is dependable rather than a clever demo.

IT TUNES ITSELF

A scout that checks every source equally every run wastes most of its effort, because events do not appear evenly.

So each source carries its own short yield history. Sources that reliably produce relevant events are checked every run. Sources that keep coming back empty back off onto a growing cooldown, a week, then two, then a month, and are re-tested after it expires rather than dropped. A source that simply rendered no events is quietly deprioritised; only a source that fails to load several times in a row is retired as broken.

The effect is that attention flows to where events actually show up, and it adjusts itself over weeks without anyone tending it. That self-tuning is what makes unattended a real claim and not a hopeful one.

OPINIONATED SCORING BEATS A GENERIC FEED

The score is deliberately ours. Each event gets a value out of 100, weighted for our situation: how near and easy to reach it is, how densely the room holds the kind of buyers we serve, how intimate it is, whether there is a concrete lever such as a discount or a speaking slot, and how soon it is.

The weighting carries an opinion we hold about sales. A large conference ranks high only when there is a real lever to use, because for relationship-led selling a crowded hall with no way in is worth less than a small regional roundtable where we can actually talk to people. The result reads as a decision cockpit rather than a calendar: it points at where to spend a day, not at everything that exists.

A generic event feed could not encode that, because the judgement is specific to how a particular team wins work. That specificity is the reason it was worth building rather than buying.

WHY A MICRO-APP, NOT A SAAS

event-scout is small on purpose. The whole thing is a handful of JSON files for the sources and the event store, a couple of scripts, and one self-contained HTML dashboard that opens straight from disk. There is no database to run and no subscription to renew. The data stays ours, and so does the scoring.

This is the same move Anthropic's own non-engineering teams have described, building small internal tools with a coding agent instead of filing a request and waiting (claude.com). We have written about that pattern from the user side too (iiterate).

It is not free of rough edges, and pretending otherwise would be dishonest. Login-walled sources need a session captured by hand once. A few stubborn sites stay manual leads rather than fake results. And we verify each rebuild by checking the page's structure directly, because a screenshot stalls on a font load. None of that changes the conclusion: when a task is repeatable and specific to how you work, a coding agent can turn it into a small owned tool for less than the SaaS or the manual hours it replaces. The harder question is not whether you can build one. It is which of your weekly chores has been quietly waiting to become one.

Claude Code is built for engineers, but the work it has quietly taken over for us sits in marketing and the back office: the repeatable, rule-bound jobs nobody enjoys. The reason it fits there is simple. Someone who knows a procedure, the brand rules, the month-end checklist, the way we tag a campaign export, writes that procedure down once in plain language, and the agent runs it against real files. No software project, no developer in the loop. This piece is what we have learned about where that pays, where it does not, and how to start without regret.

The real shift is not coding. It is writing the procedure down

For a non-developer, a coding agent is a way to turn a repeatable procedure into something a machine executes, without building software first.

The mechanism that makes this work outside engineering is Agent Skills. A skill is a small folder: a plain-language instruction file, optionally a script or two, and the reference material it needs. The agent only sees a skill's name and one-line description until your task needs it, then reads the full instructions on demand. Simon Willison, who documented the format when it shipped in October 2025, put the economy of it plainly: each skill costs only a few dozen tokens until the moment it is used (simonwillison.net, Anthropic).

The consequence is the part that matters for a Mittelstand team:

🔸 The author is a domain expert, not a coder.
The person who knows the process writes the skill, the way they would brief a new hire.

🔸 Connectors give it real reach.
Through MCP, an open connector standard, the agent can read and act in actual systems, a spreadsheet, a shared drive, a ticket queue, under access you grant.

🔸 You decide the blast radius.
It only touches what you let it touch. That permission boundary is the whole game, and we come back to it below.

Three boring jobs where it actually pays

The wins are unglamorous and repeatable. Three patterns have held up for us and in the public record.

Marketing variants at volume. Anthropic's own Growth Marketing team wired two specialised sub-agents to read a CSV of hundreds of live ads, flag the underperformers, and write fresh variants inside strict character limits, minutes of work instead of hours. A companion Figma plugin generates up to 100 layout variations per batch by swapping headlines and descriptions (claude.com). It is their own team, so read it as proof the pattern works, not as your number.

Back-office data tidying. The dull middle of the week: reconciling a card statement into an expense sheet, cleaning a messy list, drafting a recurring report from a template. One solo, non-technical founder on r/SaaS described running effectively his entire SEO operation through Claude, reporting 1.54 million search impressions and 12,900 clicks in three months with no engineer and no agency (r/SaaS). One person's report, but a telling one.

Internal tools built by the person who needs them. Anthropic's legal team prototyped a small "phone tree" that routes a question to the right lawyer, built by a product lawyer who does not write code (claude.com). The interesting part is not the tool. It is who built it, and that they did not file a ticket to do so.

We have written before about where AI actually earns its place in a business rather than where it demos well (iiterate); this is the same test applied to one tool.

Why marketing and ops, specifically

These functions fit because their work is repeatable, rule-bound, and already lives in files.

That maps cleanly onto what a skill can hold. A brand-guidelines skill carries the palette, the type rules, and the tone of voice. A procedure skill carries the close checklist or a compliance step. A template skill carries the document itself. Anthropic ships a working brand-guidelines skill as a public example, with colour, typography, and layout rules an agent applies on request (GitHub, Anthropic).

The recurring finding across these reports is that domain expertise drives the result more than coding skill does. That is the Mittelstand's quiet advantage. The person who knows the process is already in the building, and a skill is just their process, written down.

Where it is the wrong tool

A coding agent is the wrong tool the moment the work stops being repeatable, checkable, or safe to hand a broad-access agent. The honest risks, in the order they bite:

Blast radius. An agent with file and system access can delete the wrong folder or send the wrong message. Give it least privilege: read-only first, one folder, a copy of the data, not the original. Security teams have catalogued what goes wrong when this step is skipped (Docker, Oso).

Confident wrong answers. It will state a figure it did not verify, in fluent prose. Keep a human gate on anything that leaves the building.

Governance and data. The moment it touches personal or client data, GDPR and the EU AI Act apply. Know where the data sits and who can be audited before you connect it, which is the same control question behind running models you own rather than rent (iiterate).

Provenance. Most polished case studies, including two in this article, are vendor-published. Read them as evidence the work is possible, not as evidence of your return.

How to start without regret

Start small, on work you can afford to get wrong.

1. Pick one task that is repeatable and rule-bound, and that is not your most important process.
2. Write the procedure as a plain-language skill, the way you would brief a capable new hire on their first day.
3. Give least-privilege access: read-only, one folder, a copy of the data.
4. Keep a human gate on anything that goes out the door or touches a person's data.
5. Measure on the boring metric, hours saved on the dull task, not on how the demo felt.

Done this way, the wins are small and they compound, which is the opposite of how this technology is usually sold. The question worth sitting with is not whether a coding agent can do marketing or ops work. It is which of your procedures you have actually written down, because that, not the model, is what decides how far this goes.

The European Data Protection Board's keystone opinion on AI models leans on the phrase "case by case", and the joint EDPB and European Commission guidance on how the GDPR meets the EU AI Act is not expected before early 2026. So the useful question is not "is AI allowed under the GDPR". It is "under which conditions, and which of those conditions do we actually control". This piece maps the few hard limits, the large conditional middle, and the levers a Mittelstand team can pull. It is orientation, not legal advice, so involve your data protection officer before you act.

START WITH THE FEW THINGS THAT ARE GENUINELY RESTRICTED

A short list of AI uses sits close to a real prohibition under the GDPR. Knowing them first makes the rest easier to reason about.

• Solely automated decisions about people. Article 22 restricts decisions with legal or similarly significant effect that are taken without meaningful human involvement. German supervisory authorities read this strictly and expect effective human oversight rather than a rubber stamp (Hogan Lovells).
• Special-category data by default. Health, biometric, belief and similar data is prohibited for processing under Article 9 unless a specific exception applies. The EU AI Act adds one narrow opening: Article 10(5) allows such data strictly for detecting and correcting bias in high-risk systems (IAPP).
• Models built on unlawfully collected data. The EDPB's Opinion 28/2024, published on 18 December 2024, holds that if a model was developed using personal data processed unlawfully, that can taint the lawfulness of deploying it, unless the model has been duly anonymised (EDPB).

Most AI work sits outside this short list, where the answer is rarely a flat "no". It is a "yes, if".

MOST OF IT IS CONDITIONAL, NOT FORBIDDEN

The large middle of AI work is lawful when you can show the right conditions and document them.

Two conditions do most of the work. The first is a lawful basis. For training and using models on personal data, the EDPB set out a three-step test for relying on legitimate interest, weighing the interest itself, whether the processing is necessary, and a balance against the rights of the people in the data (EDPB). Legitimate interest is available, but it is earned through that test, not assumed.

The second is anonymity, which you do not get to declare. The same opinion holds that a model trained on personal data is not automatically anonymous. It counts as anonymous only when it is very unlikely both to identify the individuals whose data trained it and to have that data extracted through queries, assessed case by case by the supervisory authority (IAPP). The opinion leans on "case by case" so heavily that legal analysts counted the phrase across the text (Ropes & Gray). The practical reading: most AI processing is permitted, on the condition that you can show your basis and your documentation.

THE CONDITIONS ARE MOSTLY ARCHITECTURAL

The encouraging part is that the conditions you must meet are largely decided by how you build the system, not by who you are.

• Keep less, for less time. Data minimisation and purpose limitation apply to the AI-specific places data hides: prompt and system logs, and the vectors inside a RAG store. EDPB guidance points to minimising what is logged, preferring aggregated or pseudonymous identifiers, and short retention (EDPB analysis).
• Decide where the data sits, on purpose. Since the Schrems II ruling, sending personal data to a US provider is not settled by signing standard contractual clauses. You have to assess whether those clauses can actually be upheld given US surveillance law, and that responsibility cannot be handed to the vendor (analysis).

This is the practical reason data residency and on-prem deployment are control levers rather than ideology, the same point behind running models you own instead of rent (iiterate).

THE GDPR AND THE EU AI ACT ARE TWO REGIMES, NOT ONE

It helps to treat data protection and AI regulation as separate obligations that meet, rather than a single rulebook.

The GDPR is a fundamental-rights regime about personal data; the EU AI Act is closer to product-safety law for AI systems (IAPP). One high-risk system can owe duties under both: a Data Protection Impact Assessment under Article 35 of the GDPR, and a Fundamental Rights Impact Assessment under Article 27 of the AI Act, which complements rather than replaces it. The two also interact in awkward ways. Practitioners point out, for instance, that GDPR profiling can pull a system back into scope that an AI Act exemption seemed to release (r/gdpr). Official help is on the way: the EDPB and the European Commission are due to publish joint guidance on the overlap in early 2026 (IAPP).

A WORKING COMPLIANCE POSTURE FOR A MITTELSTAND TEAM

You do not need certainty the regulator has not provided. You need a defensible, documented posture. A practical order:

1. Map where personal data enters the system: inputs, prompts, logs, training data, and the RAG store.
2. Choose and write down a lawful basis for each use. If you rely on legitimate interest, run the balancing test rather than assuming it.
3. Run a DPIA before deploying anything that profiles or decides about people, and keep a human meaningfully in the loop for Article 22 cases.
4. Minimise and time-box what the system keeps, especially prompt logs and vectors.
5. Decide data residency deliberately. If personal data would leave the EU, do the transfer assessment, or keep the processing in-EU or on-prem.
6. Revisit the posture when the EDPB and Commission joint guidance arrives in 2026.

The short version: very little about AI is categorically forbidden under the GDPR, a few things genuinely are, and most of the rest is a documented "yes, if". The conditions that decide it are mostly architectural, which means they are yours to set. The same governance questions surface the moment an internal agent touches client data (iiterate). This remains orientation rather than legal advice, so make your data protection officer the next reader.

The European model scene, Mistral and the players around it, has real money and real models in 2026. It also sits behind the US and Chinese frontier on raw capability, and the word European on a label does not by itself mean sovereign. So for a Mittelstand company the useful question is not whether a European model exists. It is which kind of control you actually need, and what gives it to you. This piece lays out the landscape, the honest gaps, and the decision underneath.

What sovereign actually means, and what it does not

Sovereign AI means the model and its data stay under one organisation's legal and operational control. The levers that deliver it are concrete: open weights you can self-host, and hosting that keeps the data in the EU or on your own machines.

Two honest caveats keep the word from becoming marketing.

🔸 An EU postcode is not sovereignty by itself.
State-access laws, in France and Germany included, can compel data in ways an EU location does not fully shield. Where the data sits is necessary, not sufficient.

🔸 Ownership decides as much as origin.
Silo AI, the Finnish maker of the open Poro and Viking models, is now a subsidiary of AMD, a US company, which brings it under US law. A European-born model under foreign ownership is not automatically a sovereign one (North Atlantic).

Sovereignty, then, is a question about the stack and its ownership, not a flag on a homepage.

Mistral, and the money that made Europe serious

Mistral is the reason European AI stopped being a footnote, and the way its funding came together is the real signal.

In its round reported in September 2025, Mistral raised about 1.7 billion euros at roughly an 11.7 billion-euro valuation, and the lead investor was ASML, the Dutch chip-equipment maker, putting in around 1.3 billion euros (CNBC). A company that sells the machines that make advanced chips buying into a model lab is a sovereignty move, not just a financial one. Mistral has paired it with infrastructure, targeting around 200 megawatts of European compute by 2027, owned rather than rented, across sites near Paris and a large new build in Sweden (Data Center Dynamics). Its enterprise traction is real too, with named work alongside Airbus, BMW, Amazon and SAP.

The story Mistral tells about itself is the useful part: it is not trying to win the raw model race against the US giants, it is trying to own the European stack that sits under the models. For a buyer who cares about control, that framing matters more than a leaderboard place.

And beyond: the rest of the European bench

Mistral is not the whole field, and the others reveal different bets on where European value sits.

Aleph Alpha, the Heidelberg company once cast as Germany's frontier-model hope, stopped chasing the frontier and rebuilt around a sovereignty and compliance platform, PhariaAI, aimed at on-prem and air-gapped deployment in regulated industries (analysis). Black Forest Labs, founded in Freiburg by part of the original Stable Diffusion team, makes the open FLUX family of image models (Dakota). And Teuken-7B, from the Fraunhofer-led OpenGPT-X consortium, is an openly downloadable model trained across all twenty-four official EU languages, built to be self-hosted (Fraunhofer).

The pattern worth noticing is that the strongest European plays are increasingly about the stack, the openness and the deployment model, rather than a single frontier model. That happens to be where a Mittelstand buyer's advantage sits.

The honest capability gap

Sober is more credible than boosterish, so here is the gap plainly. On independent capability indices, the European flagship sits around the middle of the open-weight pack rather than at the frontier (Artificial Analysis). The funding is lopsided too: Europe's combined model funding is small next to a single US lab's valuation, closer to a rounding error than a rivalry (North Atlantic).

The useful move is not to deny the gap but to ask whether it touches your job. For drafting, extraction, classification, and retrieval over your own documents, a mid-pack open model you fully control usually clears the bar, and the control is worth more than the last few benchmark points. That is the same trade we drew when a frontier model vanished from one market in seventy-two hours: operational control beats rented capability when the capability you are renting can be taken away (iiterate). The frontier is where European models genuinely lag. It is also the part of the work many businesses do not actually need.

What this means for a Mittelstand buyer

The decision is not patriotic, it is architectural. Three practical paths, by what the workload needs:

1. Need frontier capability, data not sensitive. A hosted frontier model is still the most capable option. Use it, and accept the dependency knowingly.
2. Control is the point. For regulated data, client confidentiality, or anything you must be able to audit, self-host an open European or open-weight model, or use EU-hosted inference, and put data residency and ownership in the specification, not the marketing.
3. Judge sovereignty by the stack, not the flag. Where the weights run, where the data sits, who can compel access, and whether you can swap the model out. The same control question sits under the GDPR (iiterate).

The European scene is finally real enough to be a serious answer for the second case, which is most of what we are asked to build. The reason to care is not the flag. It is that rented capability is revocable and control is something you build. The question worth holding is not whether Europe can match the frontier this year. It is which of your workloads truly need the frontier, and which only need a capable model you control.