Agents need good tools too | WCUS 2026

At WordCamp US 2026, our Chief Marketing Officer, Aviral Mittal, argued that content teams get more freedom when you give them tighter guardrails, and that those same guardrails are what make it safe to let an AI agent build pages on your site. He demoed the editorial experience rtCamp is building for itself, starting with the small ways pattern-led editing still lets design drift in.

The fix runs on a few primitives: patterns named for what they present, swaps limited to the variants a section allows, and limits an editor cannot quietly break. Aviral then pointed Claude at a Google Doc and had it build the page, and it stayed inside those same limits even when asked to exceed them. His point: the more work AI does, the more precisely you have to define the primitives.

Watch the full talk to see the editor and the agent working against one set of rules, and why publishing still ends with a human in WordPress.

Watch the talk here

Agents Need Good Tools Too: Designing an Editorial Experience for Humans and AI Alike

Agents_need_good_tools_too

Read the full transcript

Show transcript

Hello everyone. My boss is sitting right in front of me here, front and center, so I’m not feeling any pressure at all, as you can imagine.

Hello, my name is Aviral, and I work as the CMO at rtCamp. As the first users of many of the solutions we build, I want to present today an editorial experience that we are building for ourselves. The editorial experience decides how much freedom a content or marketing team has when it publishes. You can build it in many ways. The best way starts with two questions: who will use it and for what purpose? In the agency world, the answer to these questions separates a successful implementation from a weak one.

By the end of this talk, I’m going to argue that to be able to give more freedom, you need to create thoughtful guardrails to first prevent human teams from creating design drift, and then we will show how those same guardrails can apply to AI agents so that you can allow them to publish on your website.

To begin with, we will start at what is today considered the right way to build editorial experiences in WordPress. The ecosystem seems to agree that to prevent design drift or brand drift, a good editorial experience should be led by patterns and not by blocks. An author drops the correct pattern onto a page and then edits the content. The author does not build a layout, the author does not resize a block, the author does not choose a font.

With that in mind, let’s look at what the average editorial experience looks like today. This is when we are all following the best practice of using patterns instead of blocks. We will begin with creating a page for one of our services and see how it goes. So we have a blank page. We drop a pattern for the hero section. There is some placeholder content, you change the content, change the images, link the CTAs, and that is it. We have just completed building the hero section of our page. And from here, we can simply drop the next pattern, edit content, and so on. All good so far.

But from here, what could go wrong? Especially when we talk about enterprise implementations. Let me walk you through what typically goes wrong. So we already have added the hero section. Now I want to talk about the key features of our migration service. So I go into the pattern library again and try to figure out which pattern is right for this section. I look at boxes, I look at cards, which card to choose exactly. I go back to boxes and choose one of the patterns based on a hunch and drop it on the page. However, in a few weeks you will realize that key features was represented by a completely different pattern on another page on the same website. Since the pattern names are not mapped to the kind of content that they are supposed to present, we are leaving a design decision to content teams, and inconsistency is inevitable.

Nonetheless, we have now dropped this pattern and we will continue to use it. However, I realize that I don’t want a paragraph after the main section heading. Generally, we leave it to the content teams to delete the paragraph as needed. But as we can see in the video, the content team might just delete the text in the paragraph without really deleting the paragraph block. And here in the screenshot, we can see on the right how the spacing below the heading is supposed to look if the paragraph block was actually deleted. There is a clear difference in spacing, and these are the small things that content teams will always miss because they don’t publish content with Figma files in front of them. They simply use what is there without having to think about layout decisions. And therefore, it is our responsibility to design for the real users.

And if you have thought about this already, you will probably try to create different pattern variations for each of the possibilities, where the heading is with para, without para, with CTA, without CTA, with para and CTA, and so on. But that leads to another problem, which is that you now have too many pattern variations just to ensure that your content team has no way to break the design. Does that work? You take a guess.

So we thought about this a lot and wondered how this should be done. First of all, to solve the naming problem, what we saw across the projects was that most web pages on a website generally have only a few types of information presented in varying order across the website. So we realized that instead of categorizing and naming things as cards, boxes, etc., we can actually categorize and name patterns for their real usage.

For example, your patterns can be categorized and named as CTA sections, downloadables, key features, project phases, resources, stats, or whatever is relevant to your business. This approach does not just ensure that editors and content teams know exactly which pattern to pick for the type of section they want to present, but even the variations are more intentional. When you already know the kind of information you want to present, the variations are easier to figure out. On the front end, it is also good for your users to become familiar with your design system. They see a pattern and quickly know what kind of information they should expect, even before reading through it.

So talking of variations, in previous slides, we highlighted how inconsistencies can arise when you leave it to the editors and content teams to make direct changes to patterns. Now, I don’t want to mean that they should not have any freedom to make any changes. In fact, quite the opposite. The point is: how do we allow them to make changes while being intentional about design? What if we could provide only the relevant options so that even by mistake, content teams cannot make a wrong decision?

So we thought about this a lot and found out some basic truths. A general pattern is a combination of two things, a header and a body. As an editor, you either want to have a different variation of the header or a different variation of the body. And if you can find a way to select variants for both of these independently, we can give editors and content teams much more freedom to choose the right kind of layout without ever breaking the design.

Let’s see how we built it.

So we dropped the key features pattern with icon cards. When you are on any area within a pattern, you first want to clearly know where you are and where you want to make changes. We added this arrow button to take you to the parent section of wherever you are. So let us say I click on this arrow and I reach the parent section, which is the card in this case. Similarly, if I click again, it will take me to the entire grid. And when I’m on the grid, you’re now seeing a swap icon.

If I click on this swap icon, I see the variations available to me for this grid. And here I’m seeing only the card grids which are allowed to represent key features. And now I’ll just swap with the other type of key features grid. And now my content team has more freedom to change the pattern without going off the design. Similarly, I can go into the header and change the entire heading section and swap it with a different kind of header. In this case, with a CTA and a para. If you notice, this also solves the problem of overloading your content teams with too many patterns for minor variations. Something that we spoke about a few slides back.

Now, another issue that editors often face is the freedom to add or remove the number of cards or the amount of content they can add to each card. In any layout, unless you are writing a plain text doc, there are constraints. When the website is being designed initially, even when it is in Figma, it intentionally or unintentionally assumes constraints. However, at the level of each content area, how do you enforce these constraints while having the freedom to adjust as the site grows? In this example implementation here, we have six cards, and without breaking the design, we want to add or subtract more cards.

Let us first see how an average implementation adds more cards. You go in the left sidebar, choose one of the cards, and duplicate it. And then you will see one more card appear. However, what if this section was designed for a maximum of six cards only? How do we enforce a minimum and maximum number of cards in this section?

Similarly, if you had way more content in any card, generally the size of all cards in that row changes. The cards in the next row have different sizes, and suddenly the design feels off. How do you really enforce the minimum and maximum length of content in each card without changing the size of the card itself? We built a system for that.

We have already seen how swap works. Similarly, if you go to the card grid, you will see the grid icon, which shows you a slider. The slider already has the minimum and maximum clearly defined. All you need to do is slide to add or subtract the number of cards in the grid. With this, you have a pattern which never breaks design and makes you fully aware of the constraints as an editor or as part of the content team.

Similarly, even the content limits are well defined for each of the items within the pattern. So if I edit the heading and make it more than four words and make the paragraph longer than 30 words, it will take it, but here is where the guardrails come into play. We have an entire publishing checklist added to the right sidebar. Before you can publish, the right sidebar will show you everything that is incorrect or does not meet the guardrails on the page. If you are just an author, you will not be able to publish the page unless you meet the guidelines. This is of course flexible depending on what a team needs, but you get the point.

Let’s also quickly see how we are defining these limits. We are not defining these in code and you don’t need an engineer. You simply go into the plugin settings and you can set up guidelines for each of the elements in a pattern. Right now, we go at the card level and for the header we are selecting a maximum word count of four. You can even set if the field is allowed to be empty, or you can also set the limits by characters. And then for para, we are selecting a maximum word count of 30.

The idea is the different blocks can have their own set of constraints based on their composition. So for the grid, we are selecting the minimum and maximum number of cards that can appear. Here the minimum is three and maximum is six. You can also set whether the grid is swappable, and if yes, with which other grid is it swappable.

Coming back to the editorial guidelines, by the way, there is more to the editorial guidelines than you might think. The editorial guidelines will not only show the content limits, but they will also flag things like page title, meta description, heading hierarchy, etcetera. It also shows if any part of any pattern on the page is not meeting the guidelines or needs a look. And hence, once again, we are setting guardrails for content and editorial teams while giving them freedom to make mistakes so that they can always remain on brand and get the technical SEO right.

So we’ll do a quick recap of what we have established so far. We spoke about naming the pattern semantically or based on the type of content they present. We have seen how you can swap parts of a pattern with relevant alternatives. We have also seen how you can increase or decrease the number of cards in a pattern within a minimum and maximum range. We have seen how you can define the content guardrails for each part of the pattern. And we have also seen how you can set the guardrails at page level as well, to not just have consistent design but also consistently followed accessibility and SEO practices.

So what about AI? You must now be wondering: this talk was about creating the right tooling for AI. So what happened to it? At the same time, many of you might have also understood how the system we have spoken about so far is also just the right system for AI. So we connected the website with Claude and asked it to build a page by providing all the content within a Google Doc. It is expected to make sense of the content, choose the right patterns, fill content, and make sure it follows all the guidelines, just like a human would. Most importantly, it should reliably be able to do it to make it into production. Let us see how it performs.

First, we provide Claude with a Google Doc. After reading the Google Doc, Claude thinks a little, as it always does. And it tells us a broad plan of the patterns it will use to cover various sections of the page. Seems alright. I largely approve it and ask it to go ahead. Claude uses the hero pattern and fetches content from the doc. And as you see, we have a preview that we can look at. Looking fine to me.

Next, Claude takes a logo strip. This one doesn’t need much of my time. Then Claude uses the case study carousel and it already chooses the case studies relevant to the service. However, even within Claude, if I want to change the case studies being shown, I can simply choose the case study I want here. And again, I can do it from within Claude. I insert the pattern and let us see how it looks in the preview. Looks pretty good, right? So why is it important to be able to do these actions within Claude? Because you don’t want to be switching between Claude and WordPress every few seconds.

Now Claude adds the key feature section. It shows me the cards with text only. So I want to swap with icon cards. That too, I could do from within Claude. So I swap with the icon cards grid and see the preview in Claude. Then I ask Claude to also swap the heading and I choose another variation of the heading. Let’s see how the preview on the actual page looks like. Looking good to me. As we can sense, Claude is already following all the guidelines that we defined for the humans to follow.

Now let us get into the why us section. Here, the minimum limit of cards is three and maximum is eight. However, let me show you what happens when I ask Claude to add nine cards. As we can see, Claude understands the limit based on what is defined and does not go beyond it. So I agree and ask it to stick to six cards. And here we see a preview. We insert it to see a preview on the actual page, and as expected, there are no more than six cards. And that happens because the same limits that are governing humans can also govern agentic actions.

We can also add testimonials, all within Claude by selecting the available options. And similarly, we can add the rest of the sections to complete this page. So we add the FAQ, then we add the CTA. And then we’ll see how it looks in preview. The entire page is on brand and does not go off the design anywhere. And let us see if it passes all checks. And you bet it does.

So AI has the world’s knowledge that makes it very powerful, but that also makes it prone to going off the rails and doing its own thing. And that is where the system needs to be architected in a manner that it is able to specify all the primitives and guardrails clearly. And those can then be used by humans as well as agents without confusion.

One learning from this implementation is that amidst all the talk of AI doing the work, if we have to create really production-worthy implementations, we have to be more intentional, more detail-oriented than ever. The quality bar is much higher. Second, there are always scenarios, at least until now, in which humans still need to go into a system. And therefore, it is better to architect solutions that are usable by both humans and agents.

For example, in the AI page building experience we just showed, only a draft is getting created in the WordPress backend. Actual publishing still has to happen in WordPress. Thank you.

Watch the talk here

Read the full transcript

On this page

WordCamp US, News & Events

Credits

Abhijit Prabhudan

Author

Abhijit Prabhudan

Author

Works on content systems, publishing workflows, and knowledge management. Diverse experience spans editorial, marketing, ecommerce, and IT support. He operates across open source platforms, hand…

Babita Manna

Editor

Babita Manna

Editor

Babita is a writer and an editor on the marketing team at rtCamp. She has been part of the open source ecosystem for some time now and has grown fond of the ideas and communities that make it what …

Contributions and Updates: Aviral Aviral Mittal Chief Marketing Officer

Related articles

Comments

Leave a Reply Cancel reply

Name*

Email*

Comment*

Submit

Δ