Smarter Umbraco Workflows: Headless Publishing, Automation and AI

Our September Umbraco Newcastle Meetup was a great example of that.

We were joined by two Umbraco MVPs, Callum Whyte and Matthew Wise, for talks that explored very different areas of development but shared a similar theme: how can we remove unnecessary work from the development process?

Callum explored how Umbraco Automate can be extended to create smarter headless publishing workflows, while Matthew took us further into the world of AI orchestration and automation, demonstrating how development tasks can move from a Jira ticket towards a reviewable pull request with significantly less developer intervention.

Here are some of my key takeaways from both sessions.

Callum Whyte, Umbraco & Microsoft MVP, started with an interesting question:

What if Umbraco could be the engine that publishes content to just about anything? Headless architectures give us huge flexibility around how and where we deliver content, but they also introduce an important architectural consideration: what actually happens when somebody publishes something?

A common approach with static-generated websites is to trigger another complete website build whenever content changes. It works, but as the size and complexity of a digital estate grows, it isn't necessarily the most efficient approach.

Callum demonstrated how Umbraco Automate can provide a much more flexible layer between content changes and whatever needs to happen next.

Automation is useful. Augmentation is where the value is.

Those questions carried through the MVP Summit, the keynote sessions, the roundtables and the conversations in between.

One of my biggest takeaways from the week is that Umbraco feels like it’s in a really sweet spot.

The product is mature. The roadmap is ambitious. The CMS remains at the centre, but the wider ecosystem around it is becoming much more powerful, with Cloud, Compose, Engage, Automate, AI tooling, improved search, stronger deployment approaches, and a growing focus on scalable digital experience platforms.

The Codegarden keynote brought that together clearly, with Umbraco describing the platform as one that “developers love and business trust”, supported by upcoming CMS features, Cloud improvements, AI capability, and the launch of Umbraco Automate. For us at Shout, that direction really matters.

We’re often helping clients manage complex digital estates, modernise legacy platforms, integrate multiple systems, improve editorial workflows, and plan for long-term maintainability. What stood out this year was how closely Umbraco’s roadmap aligns with the real-world challenges we’re already solving.

Moving beyond "publish equals rebuild"

One of the most interesting parts of Callum's demonstration was a queue-based approach to publishing. Rather than rebuilding the website every time an editor makes a change, content events can be added to a queue. Custom Automate triggers can then determine when that queue should be processed.

That could mean:

• Waiting until the queue reaches a particular number of items

• Processing changes after a defined period

• Responding to a specific content event

• Combining multiple conditions before triggering the next action

Once those conditions are met, another Automate action can process the queue and trigger a GitHub Actions workflow to rebuild and deploy the static site.

The important part isn't necessarily GitHub Actions itself. It's that the publishing process becomes event-driven and configurable rather than tightly coupled to a piece of bespoke application code.

As Callum put it during the session, you're no longer having to write all the code that runs the process. You're writing the things you actually want the process to do.

Extending Automate with custom triggers and actions

Callum took us into the code behind the implementation to show that extending Automate doesn't require huge amounts of custom development.

A custom trigger essentially needs to answer a question:

Can this workflow run yet? In the queue example, the trigger checks whether the number of queued items has reached the configured threshold. A time-based trigger can instead check how long it has been since the queue was last processed. If the condition returns true, Automate moves onto the next step. Actions follow a similar pattern.

An action might:

• Add content to a publishing queue

• Process queued content

• Call an external API

• Trigger a GitHub Actions workflow

• Send a push notification

• Update data in another system

Connections can also be configured centrally, allowing credentials and configuration such as GitHub organisation and repository details to be reused rather than hard-coded into individual actions. That combination of triggers, actions and reusable connections starts to make Automate feel less like a CMS feature and more like an orchestration layer that happens to understand Umbraco.

Logic Apps, but with Umbraco awareness

This was probably the comparison that made the potential particularly clear.

At Shout, we've used technologies such as Azure Logic Apps for a long time to orchestrate integrations and workflows. The challenge is providing those external services with enough context. Historically that can mean serialising content to JSON, putting messages onto queues, storing information somewhere Logic Apps can retrieve it, or exposing APIs so an external workflow can communicate back with the application.

Automate changes that relationship because the workflow already lives within the Umbraco environment. It has awareness of the CMS, its events and its content. That opens up some interesting possibilities beyond headless publishing. Callum shared examples including commerce processing, updating related database information and sending push notifications through Azure messaging services following a CMS change.

There are also approval steps available, allowing a workflow to pause until a particular user or group has manually approved it. For developers familiar with deployment pipelines and workflow tools, the model feels very familiar but it is directly connected to what's happening inside Umbraco.

Headless isn't automatically the answer

One thing I particularly liked about Callum's session was that it wasn't a sales pitch for headless architecture.

During the discussion afterwards, he was open about the additional complexity headless can introduce. The demonstration site used Astro to create a fully static website with excellent performance, while still supporting dynamic experiences through techniques including Astro Islands and generated content collections. But achieving dynamic behaviour within an otherwise static architecture can require additional engineering. Authentication is another obvious example.

Once a headless solution needs authenticated or highly dynamic functionality, APIs and additional architectural components quickly start appearing. The takeaway wasn't that every Umbraco website should become headless. It was much more useful: If you are building headless, think carefully about your publishing strategy. Don't automatically rebuild everything whenever something changes. Understand the events that matter, the conditions under which publishing should happen and whether tools such as Automate can remove bespoke orchestration code.

Callum was also clear that some parts of the Automate experience still need refinement, particularly around the UI.

But the underlying model of low-code workflows combined with developer-extensible triggers and actions has a lot of potential.

From AI assistance to AI orchestration

Matthew Wise, Umbraco MVP, then took us into another area that's moving incredibly quickly: agentic software development.

Most developers have now experienced some form of AI-assisted development. You ask an agent to make a change. It writes some code. You review it. Something breaks. You give it more context. It tries again. That can certainly make an individual developer faster.

But Matthew raised an interesting problem.

What happens when you have multiple agents working across multiple features and projects? Eventually, you become the bottleneck. You're still sitting in the middle, providing instructions, approving actions, checking outputs and keeping the context of multiple pieces of work in your head.

Matthew's goal was to remove himself and eventually the developer from more of that middle process. Or, put more ambitiously: Ticket to pull request while you sleep.

AI needs structure before it needs autonomy

Before getting into the automation itself, Matthew made an important point about the foundations required for agents to work effectively.

The strongest projects for AI-assisted development tend to already have good engineering practices.

That means having:

• Well-defined and repeatable development patterns

• Clear conventions around how code should be written

• Mature testing where possible

• Structured instructions and contextual documentation

• Automated linting and validation

• Controlled access to tools and external systems

Matthew described using hierarchical instruction files at project, folder and feature level so agents can discover the context they need without loading information about an entire application for every small change.

The principle is straightforward. The more predictable your project is, the easier it becomes for an agent to work within it. AI doesn't remove the need for engineering discipline. If anything, it makes that discipline more important.

From Jira ticket to working code

Matthew then demonstrated a proof of concept built around Jira, Claude and Azure DevOps. The workflow starts somewhere deliberately familiar: a Jira ticket. Someone selects the ticket and triggers an automation. From there, a webhook starts a Claude routine running inside a configured environment.

The agent can then:

Removing the developer from the middle

Matthew described four goals behind the experiment:

• Remove work from his own plate

• Remove work from his own machine

• Remove himself from the middle of the process

• Make the approach usable by the wider team

That final point is particularly important. If agentic development remains something that only works when an experienced developer carefully operates an AI tool on their laptop, its impact is limited.

The bigger opportunity is creating controlled environments and repeatable workflows where other people can initiate appropriate tasks safely. A designer could prototype a UI change. A project manager could trigger initial investigation of a client request.

An agent could triage a ticket, identify missing information and suggest the questions that need answering before it reaches the development team.

Developers then spend more time on the work where their expertise actually adds value.

There are still plenty of challenges

Again, this wasn't presented as a finished solution.

Matthew highlighted several areas still needing work. Testing is one. The current proof of concept relies heavily on visual testing and screenshot comparison. More comprehensive unit and code-based testing would allow the agent to validate more of its own work before handing it back. Environment management is another.

There are currently scripts and configuration required to install and prepare everything the agent needs, alongside credentials that Matthew openly acknowledged he wants to remove from the process. Moving towards MCP connectors and self-hosted environments could provide much stronger control over authentication, infrastructure and security boundaries.

There's also the behaviour of the agents themselves. Sometimes they refuse tasks that would be straightforward when working locally, which means the instructions and prompts around the process still need refinement. This is experimentation, not magic.

And that's exactly why seeing a working example was so valuable.

What happens when AI doesn't need to be instant?

Matthew finished with another interesting consideration.

We tend to assume AI needs to respond immediately. But does it? If a designer triggers a piece of work that they aren't going to review until tomorrow, does it matter whether the agent takes ten minutes or half a day? If an automated process is triaging incoming requests overnight, does it need the fastest and most expensive model available? Potentially not.

That opens the door to considering slower open-weight models running within controlled environments for certain workloads.

For organisations thinking about AI at scale, that balance between speed, cost, security and task complexity is going to become increasingly important.

Two talks, one underlying theme

On the surface, Callum and Matthew's sessions were very different.

One was about publishing content from Umbraco.

The other was about using AI agents to deliver software.

But there was a common thread running through both.

Developers shouldn't have to manually orchestrate every step of a repeatable process.

With Automate, the question becomes: When this happens in Umbraco, what should happen next?

With agentic development, it becomes: When this ticket is ready, how much of the journey towards a reviewable solution can happen without somebody manually driving every step?

Both require strong foundations. Clear conditions. Predictable patterns. Good observability. Appropriate security. Testing. And, importantly, knowing where human judgement still needs to remain.

Final thoughts

What I enjoyed most about both talks was their practicality.

Neither suggested that headless architecture, automation or AI automatically makes software development better. Instead, both demonstrated real implementations, the compromises involved and the areas that still need work.

For me, that's where the most interesting conversations around Umbraco are happening at the moment. The CMS continues to evolve, but so does the ecosystem around it. We're moving towards workflows where content can trigger increasingly sophisticated processes and where AI agents can take on more of the repetitive work between an idea and its implementation.

The role of the developer doesn't disappear. It shifts towards designing the architecture, constraints, patterns and guardrails that allow those processes to work reliably.

A massive thank you to Callum Whyte and Matthew Wise for travelling to Newcastle, sharing what they've been experimenting with and being open about what worked and what didn't.

And thank you to everyone who came along, asked questions, shared experiences and helped make another Umbraco Newcastle Meetup a great evening.

That's what these meetups are about, sharing practical knowledge, learning from each other and giving people a friendly place to explore where Umbraco development is heading next.

See you at the next one.