AI in your CMS sounds simple: you switch it on and your editorial team works faster. In practice, there's a step in between. We go all in on AI, both in our own work and in what we build for our clients, and that's exactly why we run into the things that separate "it sort of works" from "it really works."
Over the past few months we ran into three issues with Umbraco AI, and each one affected an editorial team's daily work: two bugs and a missed opportunity. In every case the answer wasn't in the settings but a layer deeper. And in every case we took our findings back to Umbraco, so the benefit isn't ours alone.
Where we're heading is concrete. With the help of AI, editors should be able to write, set up and publish content in the CMS without detouring through separate tools or adding an extra review round. That goal applies to our own editorial team and just as much to our clients' teams.
From a briefing or an existing document to a published page, all in one environment. We ran into these three issues on exactly that path. Each one got in the way at the moment speed mattered most.
AI isn't a side project for us. We use it every day ourselves, in our development work, in our marketing and in the way we create content. And we build AI applications for our clients, from smart search to editorial support in the backoffice. If you'd like to see more examples, you'll find eight in our overview of smart AI applications in Umbraco.
That means we don't just deliver, we're users ourselves. When something doesn't work, we notice right away, which is why we don't wait for someone else to fix it.
Umbraco AI is still young. Some things don't work the way you'd expect, and some useful features are still missing. You can wait and see. Or you can figure out what's going on and take it back to the makers. As an Umbraco Gold Partner, we build on Umbraco as a platform for our clients, and "it doesn't work" isn't an answer we can sell.
It started with an editor asking the AI for a blog post. The first paragraphs looked good. Then, mid-sentence, it just stopped. No error message, no warning. The text simply ended.
Annoying, and at first glance illogical, because the maximum length in the settings was set generously. Still, it happened every single time. In a situation like that, users quickly start to doubt themselves: am I doing something wrong, or can the AI just not do this?
It turned out to be neither. The setting in the backoffice wasn't being passed on to the AI, so the system fell back on a much lower default value. You filled in a value correctly, and it was ignored. Since the fix, editors can generate complete texts again, without topping them off by hand or retrying.
Shortly after, the same editor ran into something else. She wanted to have blog posts drafted from a Word document. A perfectly normal wish: you have a report or a briefing lying around and want to turn it into content. The upload worked, and then the chat kept loading forever.
That hang had already been fixed in a release we had just pulled in. But once that release was running, the real problem surfaced: on a follow-up question, the AI could no longer see the document.
It's the kind of bug that's easy to miss. The first question worked fine, so you assume everything is OK. Only when you kept asking questions, which is where the AI becomes most useful, did the file drop out. The cause turned out to be a single line of code. Using documents as a source works as intended again, follow-up questions included.
Not everything we found was a malfunction. Sometimes it's a missed opportunity. With every request to the AI, the same standing context was sent along: your writing style, the company context, the available instructions. That part never changes between two requests. Yet it was processed from scratch every time and billed at the full rate.
There's a fix for this, prompt caching, which reuses that fixed part at a fraction of the price. The question was whether Umbraco AI already supported it. Rather than assume, we checked the source code. It didn't, and that was a concrete, demonstrable gap.
So we wrote up a well-founded feature request: what it is, why it pays off and where it plugs in. In the discussion that followed, the design was refined together with the package maintainer into something you can configure per profile, with statistics so you can also see whether it's working.
The numbers after enabling it, compared to the seven days before:
Uncached input: −97.6%. Nearly everything that used to be billed at the full rate now comes from the cache.
Cache read ratio: 96.5%, more than triple what it was. Most of the cost is now billed at roughly a tenth of the normal price.
A structural cost item, brought down to a fraction. And as a bonus, the AI starts answering faster, which you notice right away as a user.
That cost saving is no small detail. Many organizations start AI small, watch the costs climb as soon as it catches on, and then start cutting back at the very moment it begins to deliver value. This saving takes that brake off. And because it lands in the package itself, it applies to everyone who uses it, not just our own projects.
With the two bugs, the gain is somewhere else: trust. A tool you can't count on to finish what it starts will end up on the shelf sooner or later. That's how AI projects stall, not because of the technology but because users give up. If you want to know how to prevent that, read how AI can strengthen a team instead of running off to the side.
What these three stories have in common is that the answer was never in the settings, and that it always started with checking instead of assuming. That's what a partner should bring to the table: not just switching a tool on and forwarding the manual, but finding out why something doesn't do what it promises. We have the advantage of being able to look into the source code. For you that would be a hassle; for us it's just the job.
Because we use AI seriously ourselves, we run into the rough edges before our clients do. What we fix for ourselves ends up in what we build for you. That's how an ecosystem works when you're part of it rather than just a user.
Yes, with the caveat that it's still young. The basics work well and you can use it for daily production work. At the same time, it has rough edges, such as settings that don't always come through or features that are still missing. With a partner who can look into the source code and report findings back to Umbraco, you can use Umbraco AI in production safely, without those rough edges affecting your work.
A partner figures out why something doesn't do what it promises, instead of just forwarding the manual. For us, the answer was never in the settings but a layer deeper in the code. Because we use AI seriously ourselves, we run into those rough edges before our clients do, and what we fix ends up in what we build for them.
We build AI applications that work in day-to-day practice, and we fix whatever isn't right along the way. We'd love to explore what's possible with you.