00:00:00:00 - 00:00:29:06
Hi I'm Jibran Ijaz, In this video we will talk about the latest changes to the views AI agent. Since our last catch up, we have moved the AI agent module to its own dedicated page. We have add a ton of new features. One of them is the Views AI agent development assistant submodule. You can enable this module using a drush command on your local website.
00:00:29:08 - 00:00:59:01
Since our last catchup, we have received a lot of feedback from the community. And one of that, was that the prompts are very, complicated and has a lot of Drupal related jargon in them. So how can we make them simpler? So we have worked on it. We have created a documentation site. With all the prompt examples as well.
00:00:59:01 - 00:01:28:13
And we have simplified it. With the prompts a lot. Here is a step by step by step guide to all the, functionalities you can, use, with this agent. And at the end of the page, there is a very comprehensive, complete prompt as well. Later in the video will go into the detail, of it functionalities you can perform using this agent.
00:01:28:15 - 00:02:03:25
So with this, let's get started. With the demo of the views agent development assistant. After enabling the module, you will get this nice button on the toolbar. This is a gene toolbar. And once you click that, you'll get to see the, development assistant. Next up will use a sample prompt, which is in a very simple, plain English with the, with no Drupal jargon at all.
00:02:03:27 - 00:02:33:28
Create Views page to list the latest articles showing the title body tags and image field. As you can see, it is, calling all the sub agents available to itself. To figure out the content, status structure, of the website, see the data model details and how to use the views tool. Here it has come back with the confirmation step.
00:02:34:00 - 00:03:07:03
And you can verify the plan here. So create a new contact list named, latest articles show only publish article content. Add the fields title, body tags and images. Image. Sort the title. So it has figured out all these things by itself. So let's with this, let's go ahead. And now it will call the tool directly create the page.
00:03:07:06 - 00:03:35:13
And now it has come back. With the follow prompt. That latest article which has been created. There is the link to the page, the page and the view add screen as well. So let's go to the view edit screen. Here we can see that it has chosen the format. As well as set up a title body tags and image field.
00:03:35:15 - 00:04:01:08
It has also set up the proper filter criteria. And the later settings. If we go to the page display. We can see the URL and permissions are properly set up as well. So now look at the let's look at the output of the view. If you look at the output there are some labels coming through.
00:04:01:10 - 00:04:27:28
There's a whole bunch of formatting issues with the body field. The whole body field is coming through. And we have tags and images coming through as well. So let's give it a follow up prompt. To remove the labels. So for this prompt, I have instructed, that, you know, that, just keep the tag labels and remove, other labels.
00:04:28:00 - 00:04:31:15
Trim the body field to just show the summary.
00:04:34:26 - 00:05:07:11
So again, it has come back with a plan, and we can see that it has figured out that only on the label for title, body and image fields. Also, keep the label of tags. Trim the body as well. So we can just say, please go ahead. And now it has made all those changes. So let's go here and update the preview and see.
00:05:10:16 - 00:05:41:07
As you can see that it has, changed the title and the body as well as, updated the images as well. So yeah. That's how you can create and update the views, using the new, views development assistant chatbot. Also, there are step by step instructions to create the views, adding, how to add displays, how to add different fields, filters or sorting criterias.
00:05:41:10 - 00:06:11:07
How to configure displays, how to expose filters. You can even create admin views. You can create field and attachment displays as well. And as I mentioned before, there are complete example for to do everything in one prompt as well. We have written and tested all these prompts, to make sure, they are all working as well.
00:06:11:10 - 00:06:34:01
So please have a look. Let us know. If you run into any bugs, or you want us to, add new features. One thing which is on the roadmap is to make sure it works with canvas AI module as well. So that is the next, on the agenda. Thank you.
The original post introduced an AI agent that could create and update Drupal views from natural language, without ever opening the Views UI. It worked, and it demonstrated something genuinely difficult: translating loose human instructions into the sprawling key-value structure of a views config entity, safely, with core's config schema validating every write.
It also asked quite a lot of the person writing the prompt. Since then, the agent has moved into a dedicated project, AI Agents Views, and has shipped a series of beta releases. The most recent one is the substantial one: 27 issues resolved, a large batch of bug fixes, a documentation site, and a development assistant chatbot that turns view building into a conversation.
The prompt problem
Community feedback after the first release was consistent. The prompts were complicated and full of Drupal jargon. Here is what creating a view used to look like:
Create an entity type node listing view with the default display, title field with label Title, sort in descending order by created date, filter by published status 1, and filter by type article.
That prompt requires the author to already know about entity types, default displays, handler labels and published status as an integer value. That is, it requires them to know Views well enough to build it by hand.
Here is the equivalent today:
Create a view of published articles, sorted newest first, showing just the title.
The fully explicit form still works, and is documented for anyone who wants to specify everything up front. But the agent now does the technical translation itself, which was always the point. Simplifying that translation layer was the main focus of the release, alongside a new documentation site with a categorised library of example prompts for both the agent and the chatbot, each run against a live site rather than written from imagination.
The development assistant
The bigger addition is a submodule, the Views Agent development assistant, which puts a chatbot in the admin toolbar so views can be built through conversation rather than through drush.
It is deliberately not available from the Extend page. It ships hidden and is enabled from the command line instead:
drush en views_agent_dev_assistantThere is a reason for that, and it is worth understanding rather than working around. The assistant needs the Gin theme, the Gin toolbar and the chatbot module, none of which the Views Agent itself has any business depending on. Keeping it as a separate module means people who only want the agent's tools are not forced to install a theme and a chat interface. Hiding it from the Extend page avoids a specific failure mode: that page runs every module's requirements check before installing anything and silently drops modules that fail, along with anything depending on them. Since the assistant's own requirements check degrades gracefully rather than blocking, steering people to drush means the actual behaviour matches what they are told.
The strong recommendation is to keep this on development environments only. It is a build tool for site builders, not something to run on a production site.
What it looks like in practice
The video walkthrough at the top of the documentation site shows the whole loop. It is worth watching, because the flow is more conversational than a written summary suggests.
The starting prompt is deliberately unremarkable:
Create a views page to list the latest articles, showing the title, body, tags and image fields.
No machine names, no mention of displays, no filter values. The assistant calls its sub-agents to work out the site's data structure, then comes back with a plan and a confirmation step: a new listing named Latest Articles, restricted to published articles, with the title, body, tags and image fields, sorted appropriately. Everything in that plan was inferred, not specified. Approving it creates the view, and the reply includes links to both the page and the view edit screen.
Opening the edit screen shows a properly formed view: format, fields, filter criteria, pager settings, and on the page display a URL and access permissions already configured.
Then comes the part that makes it feel like a tool rather than a demo. The first result is not perfect. Field labels are showing, the full body is rendering where a summary belongs. So the next prompt is a correction in exactly the language a site builder would use:
Remove the labels for the fields but keep the tag label. Trim the body field to show only the summary.
The assistant produces another plan, correctly working out that this means removing the label from the title, body and image fields while leaving the tag label alone, and applies the changes. The preview updates. That iterate-and-refine loop, rather than one perfect prompt, is how the tool is actually meant to be used.
An orchestrator, not just a views agent
The assistant is more than a chat wrapper around the Views Agent. It is an orchestrator that delegates to whichever agents the request needs, including content type, field and taxonomy agents alongside the views one.
That matters for a request like creating a content type with a field and a view listing it, all in one sentence. One confirmation covers the lot, and the sub-agents run in a working order rather than in parallel against stale state, so the view genuinely references the field that was created moments earlier in the same turn. For a request that only needs one agent, only that agent is called.
The documentation records how it behaves in the awkward cases too. Ambiguous requests get a stated interpretation inside the plan rather than an open question, so the way to correct a wrong guess is to say so at the confirmation step. Read-only questions like asking what displays a view has are answered directly with no confirmation, because nothing is being written.
Safety and the hardening pass
The agent still refuses to delete a view. It now gives back the direct Views UI delete link so the site builder can do it themselves, which is a better answer than a flat refusal. It also cannot change an existing view's base table, and the honest note in the documentation is that this refusal is less clean than the delete one: the request simply never gets delegated, so it can look like the agent is stuck when it is actually declining by design.
Most of the release is unglamorous correctness work, and the list is a good tour of everything that is hard about programmatically editing views. Handler option keys that the plugin never declared are now rejected rather than written. Exposed filters no longer save without an identifier. Updates aimed at a non-default display no longer land silently in the wrong place. Overriding one option in a grouped pair now warns that its sibling has been un-defaulted. Attachment displays save with an actual target rather than an empty value. Removing a handler that another handler still depends on is refused with a reason, and that reason turns out to be actionable enough that the model resolves it by removing the dependent handler first and then retrying.
That last one is the difference between a rejection and a dead end, and it is a good illustration of what building agent tools actually involves: the error message is part of the interface.
Tips and tricks
Start plain, then correct. The quick-start prompt plus a follow-up correction is faster and more reliable than trying to specify everything perfectly in one go.
Name displays by machine name. Once a display exists it is page_1 or block_1, not "the page display". The agent reports the ID it assigned when it creates one, and will list them if asked.
Ask what exists before changing it. Read-only questions cost nothing, skip the confirmation step, and prevent a change landing on the wrong display.
Expect more than one confirmation round on anything destructive. The documented delete example took three before the request was delegated and properly refused. Two or three turns deep is normal, not stuck.
Use the prompt library. Both prompt pages on the documentation site are organised by task, covering displays, fields, filters and sorts, display settings, exposed filters, admin views, feed displays, attachment displays and handler management, with a complete one-prompt example at the end of each.
What is next
Canvas AI integration is next on the agenda. Beyond that, the project is in beta so we are looking for bug reports and feature requests, try it on a development site and filing what breaks is the most useful contribution available right now.
Conclusion
The first version of this agent proved that views could be built from natural language. This release is about making that practical: prompts a site builder can write without knowing the Views data API, a chatbot that turns building into a conversation with a review step before anything is written, an orchestrator that pulls in other agents when a request needs them, and a long list of fixes for the specific ways that programmatic views editing goes wrong. The Views UI is not going anywhere, but for a lot of everyday listing work, describing what you want and correcting the result is now a genuinely faster path.
