About this talk
This talk by Scott Falconer focuses on the emerging importance of agent experience within the Drupal ecosystem. He shares his insights on how to make Drupal more understandable and governable for both human and AI agents. By using personal anecdotes, he illustrates the challenges of maintaining clarity and structure when multiple actors are involved with a site. Falconer emphasizes the significance of building effective action surfaces, governance frameworks, and providing context for agents, which enables them to operate effectively without causing chaos. He advocates for adopting existing APIs and best practices while exploring the concept of 'bring your own agent' and highlights the role of examples in improving AI interactions with Drupal. Overall, the session aims to equip developers and site maintainers with practical strategies to enhance the experience of agents working within the Drupal environment.
Full transcript
Thank you for being here today. I'm Scott Falconer. So, some background on myself, I lead applied AI and agent success at Acquia. Been working with about Drupal for about 20 years, and I'm also on the Drupal AI initiative leadership team. So, as we go through today, I'm happy for this to be a discussion. You don't need to wait till the end for questions, so raise your hand,
yell, get my attention somehow. Um but what I want to start with is the claim I'm going to spend the next 45 minutes talking about is that I feel agent experience is becoming one of the most important architectural conversations in Drupal. And it's not because humans matter less in the ecosystem. It's because ambiguity gets more expensive when there are machines involved. So, this session is going to
be about how we make Drupal understandable, operable, and governable for any actor. So, when I say agent, I often mean a human, an agent, or a hybrid mix of the both, because you may not always know who you're dealing with in the system. So, I want to start with a story that, if you were in the AI summit yesterday, I told. Um and I want to repeat
it here, but there's a slightly different angle this time. I have a Drupal site that I've worked on for about a decade now. So, it's a personal site. Started right when Drupal 8 came out. Uh it's one of those sites that can go months or years without me touching it, and then I'll do a burst of work. But it is a real site that is up, has
a production, people use it, and I don't want it to go down. I'm always happy to tell people to follow best practices, but I can't admit that I have on this site, because it has just been me working on it. And that's been fine, right? Now, one of the things I never really buttoned up was making it so my production matched my development and test environments, as
well as my local environments. And my config system was a mess. There was no semblance of coherence between any of it. But it worked because it was mostly just me. I knew the weird parts, I knew what to do, I knew where the shortcuts were. But then when I started adding agents to the site, suddenly it wasn't just me anymore. I had a team working with me.
So I ran an experiment. I asked an agent to make my local, dev, and test match production. And that's the only guidance I gave it, and I let it go. And it got there. I wasn't really happy about how it did it, but it made it happen. But it did a lot of work, and it reminded me of, you know, asking my kids to make a cake.
Um they would get the ingredients in the oven, and the oven would be on, but I wouldn't really be happy with the end result. And that's very much what it felt like. That experience led me to a lot of this thinking of how do we allow agents to work effectively within Drupal? So if you were in the talk yesterday, a lot of it was about the guardrails
we could set up so you can let an agent loose without it causing too much damage. This is the other side of the conversation about the things we can do in Drupal to make it easier for agents to operate at scale. this is about building the rails and how we can accelerate what these agents do It's essentially providing the tools and infos agents need to navigate Drupal
effectively. So we'll talk about this in the context of what agent experience is. Really is guidance, validation, and the direction that the agents can use. And again, a lot of this that we'll talk about today is not new. These are existing APIs, permissions, and workflows. One of the things you'll see with Drupal is the reason it is so good with AI and agents is because we've solved
a lot of these problems over the last 20 years. You know, one of the examples I like to go back to is the problem set we have with agents working on the site is the same as we had when we started doing user-generated content. You have untrusted, unknown entities doing things on your site. You want to balance a bit of what they can do while having the
guardrails in there to make sure too much chaos doesn't happen. And that can range all the way from things like an unknown person that can come in and sign up on the site to, you know, more common things where you may have a editorial team that can write content, but you don't want to have them have the ability to publish content until it um is in a
good state. one of the definitions we'll use is this concept of agent experience. And this isn't replacing user experience or developer experience. Again, it's rolling all of those plus the agents into one. So, a lot of times you'll hear me use the term principal or actor on this. And in part because we may not know who the principal interacting with us. It may be an AI-based agent.
It may be a human. A lot of cases it can be a combination of the both. And you're probably already seeing this in action on some of your sites. So, one of the things you'll see me say in this presentation a few times is this isn't new. And if you were in the session yesterday, don't overthink it. As soon as AI com- comes into the conversation, I
find that people really overcomplicate what the conversation needs to be. Yes, there are new tools. There's There's new scale. There's a whole bunch of questions that we don't yet have answers to. But at the end of the day, the fundamentals are still the same. So, you still need instructions, predictable paths, and safe boundaries. So, one of the examples I tend to use for how to think of
AI agents is think of it as having an alien coworker. It has read everything it's ever gotten its hands on. It is incredibly fast at what it does, and it has never lived a day in our world. So, you can't assume that the common sense is going to be there in what's done. But at the end, the technology is new, the operating principles are not. I see
where a lot of AI conversations, and I'll see this in the Drupal issue queue, or as people are talking about products or projects and things they want to do, it focuses on which agent should we use, which model should we use, which assistant should we use. And I think the better starting point is what is the action surface your platform or product exposes. Because the future isn't
going to be just one agent that everybody uses. It's hybrid teams. It's humans working with IDE assistants, with local agents, with continuous integration systems, automation, and external tools. And the platform that wins is going to be the one that can make sure all of those actors in the system can work safely and predictably. So again, don't start by building the agent, build the action surface that the
agents interact with. And you'll see, you know, API first coming back. This is, you know, 10 years ago or more, that was the big exciting thing in Drupal. Let's be API first. And it was a really good decision at that time, and it's a really good decision for us now. And what's nice is it scales very well. It's very similar conceptually to the headless conversations we've had
over the years. And again, as I'll say over and over, this isn't new. A lot of the same considerations and conversations are there. the pivot I want you to use when you think about this is when you're building either your own project or working on a Drupal contrib or other issue, worry less about a specific agent. That would be like designing for a specific person. Design in
general for a class of actors in the system who will want to accomplish a goal. And part of that is because the future that I see coming here is really going to be a concept of bring your own agent. So, there's a lot of conversations about agents and assistants that we can put into systems. But even within places like Acquia, we see a huge portion of our
traffic to our docs and our systems is done by agents. And that's probably many of you without realizing that you're doing it. So, when you go into Gemini or chat GPT chat GPT or Claude and you ask it a question about how can I do this in Acquia Cloud? How can I deploy my site? How can I do this in Drupal? It is most likely likely referencing
and looking at those things. So, that's why we see a dramatic increase in traffic there. So, it's already happening and it's going to continue to happen. As organizations get bigger and accelerate and get more comfortable with AI, they're going to be bringing their own agents to the table just like they bring partners or internal employees. Sorry. Next slide here. So, one of the neat examples about this
is with the right info and context, when you have an agent using your system, you can have it tell you what's wrong with the system and then fix it. That's not a luxury we often have with generally users or customers. We get bug reports that are somewhat problematic. They tell us there's an issue, they're not well-written, and we usually can't go tell the customer, "Could you just
do a pull request and fix this for us?" But when you're working with an agent, it really is possible. So, one of the things that I like to do is just ask an agent to do something. Now, that's predicated on you having a site that you can let an unknown actor loose on it. That means don't let an agent loose with a super user permission unless you're
in kind of a controlled environment. But set up a Drupal site, give it roles, give it permissions like you would an untrusted user, and ask it to do something. Eventually, the agent will get blocked. This is where they tend to go wild sometimes because they try to accomplish the goal. You'll see this where you let an agent go and you say, "Build me a page with this
component." And you look at it and it's created 500 lines of JSON and put it into a block and themed it. And you say, "Why did you do that?" And it will say, "I didn't have access to create a view." Well, you step back and you say, "Okay, if we could give you access to create a view, what could you do?" in an ideal system, it tells
the agent why it is blocked. A really common one we'll see in Drupal is something like, "This field is required." And as agents improve, they get better at working with that stuff. They won't try to work around it necessarily. They are getting better at understanding, "I need to stop." or asking for access. So, when you ask it why it got blocked, you can then also ask it,
"Could you write me a user story on that? Could you write me acceptance criteria on that? Could you actually try to fix this issue? A lot of times that's handing off to another agent, but it's a really nice area as we are building this substrate in the APIs that Drupal uses to not only identify these issues that are big blockers, but to get those fixed rather quickly.
So, I want to show this in practice a bit today. If you were in the DriesNote today, you saw the Lovable to Drupal demo. And we used some of these techniques to get that built. one background before we dig into this. One of the questions I get from a lot of people is what kind of prompt did you use? What do you use? I write the worst
prompts in the world. It really doesn't matter. What matters is the context you give it. So, this is the one that led to the initial Lovable site. Now, the important thing is, you know, with all my misspelling, lack of direction, and punctuation, the file attached at the top is a call that we had between Dries and the rest of the team that was thinking through what we
should have done with this site. And the context for this was we had built out a initial demo site, and we were all kind of underwhelmed with it. What could look better? So, we got on a call, and we talked it through. So, I went in, and I think this one was ChatGPT right here, and I said, "Here's the conversation we had. Look through it. Write me
a prompt that I can paste into Lovable." And this prompt This is probably the top tenth of it. It is incredibly long that ChatGPT wrote. A very, very well-detailed prompt about what was needing to be done. I gave it a little bit of feedback of things like, you know, "Okay, we want this to look bright, big, and unlike a Drupal snow website, it needs to be able
to show well on a large projector screen. So, from that prompt, we threw it into Lovable. It built the site, and this one may be a little hard to see, but this is the entirety of the prompt that I used to actually build the Drupal site. I said, "Here's this site on Lovable. Here's what I've exported in this GitHub repo. Build it, and then I think I
added in make sure editors can use it well." So, there's a little bit going on in the background here where the more we've kind of built these things, and we'll talk about some of the techniques you can use for this. I've been building out skills and agent files, things that kind of guide the agents to work in a kind of best practice thing. I'll show what that
means, but it's really the same as if you have somebody that's gone from starting as a brand new developer to all the tips and tricks they learn over the So, by the time we had built this final version of the Lovable site, I think it was probably the fifth round that we had And so, as we went through it, I was asking the agent, "Why did you
do this thing this way?" I think the first time we built it without a lot of guidance, it had just kind of done everything in the theme. It built the whole site in the theme. So, we said, "Please don't do that." Right? The same thing that you would tell, you know, It wasn't any worse than some of the sites customers have probably brought you over the years.
It got the job done, but it wasn't necessarily done in the right way. So, again, this is still the simplest framework I found for talking about agent experience in And it really is three surfaces. So, the first one is the action surface. And that is what an actor can actually do. So, if you think about that in the context of Drupal, somebody can visit your site, they
can log in or not, they can view some content, they have permissions to do something, they generally can access things through an API. it's a consideration. So, those of you who have, you know, explored JSON API in Drupal have probably run into the situation of why is that data visible when you can't see it on the site? And you find out, oh, it was only hidden visually,
that is still there. Those kind of things will absolutely happen. The next surface is the governance And you know, before Drupal, I had never really heard the term governance in context of technology, but it has been very important for the last decade or more, and it will become even more important about what makes action safe, traceable, and reversible. Because again, as the way Drupal is used may
remain somewhat the same, the scale of it is going to change. When you have an agent that can come in and change every single piece of content on your site. And we did this with building the lovable demo. If we had built a demo, built out the site, and then gotten feedback that said, well, this doesn't look great on a projector, we would have said, there's Drupal
cons in a month, there's not time for this. But you can ask the agent to go solve that. Walk away, go for a run, drink a cup of coffee, and it has it done. So, the scale of action is something we've never run into before. But if the action service is weak, the agent improvises badly. So, you'll you'll see this, and it's a good test you can
run. Take a Drupal site and have it hosted up somewhere, and create a user account for an agent, and just give it access to JSON API, allow it to change things, or even allow it to use a browser and change things. And watch how it tries to get things done, because it can't fake its way around where Drupal tells it no. If a field is required, and
it doesn't have data for that field, there's really nothing it can do besides put something in. Whereas if you have this Drupal site on your local environment and the agents there, you're very likely going to say, "Oh, I added this field." Or I changed that configuration. Or I turned off that test because it kept failing. So, it really is about governance and the action service that they
have. And then, the really important one is the context surface. And this is where agents guess. And this is also real important, because the context surface is where we are most important as humans with our expertise in the system, right? And you know, one of the things I always want you to think about with this is it's very easy to assume that agents can do anything, right?
And it's very easy for us to underestimate things that feel easy for humans, but are really hard. But fortunately for us, there's there are areas where there's not crossover. There are areas where agents can do things at scale that is unimaginable to what a human can do. And there are things that agents will immediately fall on their face. One of the examples I like to use on
that one is an agent can build a really great dashboard for you. It's probably never going to tell you you don't need that dashboard or that doesn't make sense. So, it will help you build really, really bad ideas at scale. And your expertise needs to be in there to help that not happen. Sorry, next slide here. I may need to restart my browser. Give me 1 second
here. Let's see what happens when I switch to this one now. >> Here we go. Okay, and so as we've talked about before, the good news is that Drupal is actually very well positioned for what's coming. We're already thinking in terms of structured content and permissions and revisions, reusable patterns, and these are exactly the things that you want when agents are on the scene. So, it's not
like we're having a conversation today about what things do we need to bolt on to Drupal to make them good for agents. We have in our fundamentals. And in a lot of ways, agent experience is a way for Drupal to lean harder into what we've always been good at, which is really structure, governance, and repeatability. let's start with the action service. If the only real interface your
hat a system has is click around the UI and figure it out, you're going to invite wandering. And we see this in humans, too, right? You give somebody access to the system, and they're probably going to figure out a way to get done what they need to get done, and it's probably not going to be how you wanted it to be. So, that's where you need a
good action service that gives actors a reliable way to act. The biggest parallel I see in this with humans is over time, you've probably all seen a site that started with Okay, here's my Drupal site, and it has an a blog. And then eventually, you added a video field to it. But at some point, you also had a video field, and then you added some text to
it. Those kind of things happen over the years. Then you invariably run into a situation the human doesn't know which one of those they want to do. Which content type should I use? So, you end up with a confusing mess that ultimately leads you to have to account for that when you're theming, when you're building views, and things like that. That same stuff happens with agents. So,
stable APIs, clear command lines, entry points. I mean, part of the reason that the demo today, the lovable demo worked, was the Canvas CLI. So, Canvas was there. Canvas made some incredible decisions over the years about verifiability, having the right information in there. All context that is really, really important. And then having some CLIs and some ways to interact with it. Now, there's still some interesting things
here when it comes to thinking of a principal or an actor as possibly being a hybrid, a person and an agent working together. So, we did notice a situation where the fields that a human would see, or the the selectors were done with JavaScript. So, the human was seeing one term. It would say left or right, whereas the agent would see the system or machine name for
it. That causes problems when the human is trying to talk to the agent that they're working with to get something done. They're not speaking the same language. don't design for one or the other. Just remember that you may not know who it is or they're going to be working as a So, get fewer human-only paths in this. Fewer implied steps. this is the part when I told
my the path to the environmental parity wasn't clear, right? So, in that case, what I hadn't told the agent was I have Acquia command line interface installed here. Please use it. Please read the documentation. Because I didn't tell it that, it SSH'd into the server and it was just trying to hack the Git repo apart. It got it done, but it wasn't the way I wanted it
to get done because I didn't give it clear instructions. Impro- Improvisation is expensive. And again, this is one of those keys, it's not new. We see this over and over. If you hand a developer a ticket and you haven't given them clear requirements or clear acceptance criteria, you're going to get something and it's probably not going to be what you wanted to get. So, the second service
is governance. And that's allow you what's allow you to turn experiments into systems and understand who did what, whose behalf did they do it on, what permissions apply. And it's it's trust. At the end of the day, it's trust. Now, this is going to be a big conversation for us to have. So, one and an opportunity, right? You know, by now we've all heard the term vibe
coding over and over even though that term is about a year old at this point. Feels like it's been around much longer. What is going to quickly happen is many of those sites and projects are going to decide that they need to grow up, right? People are building things that are very successful vibe coding, but they need to scale. They will need governance and they don't want
to spend their time answering the same questions that Drupal's answered for all of us over the last 20 years. So, governance is absolutely critical here. At the same time, governance is going to lead to some interesting questions that we as a community have to answer, right? So, right now, you will generally give an agent access either it's own account if you want to, like most of us,
myself included, probably just let the agent work under your own account. That's problematic for a number of reasons. Ultimately, we what we want is for agents to be able to work on under their own identity, but it's going to lead to questions. So, if we have something like "I can see and edit my own content." That breaks down if I have an agent under my control that
I want to be able to see and edit their content before it's published. The middle ground here, and this is one of the things we're running in in the core and crew chip space, is people want to use agents, but it can be highly disruptive to everyone else upstream if a pull request comes out. So, we're going to need to figure out a way that you can
let your own army of agents loose, whereas you're the only one impacted. You're the human reviewer of that information before it moves on to something else. This is also where agent experience stops being a conversation about developer tooling, and really is a platform maturity conversation. What does it really and truly mean to scale after launch? And then the final surface is context. And I'm going to dig
into this one a little more deeply, because this is again where you can have the biggest impact as a human, and where your expertise is really important. So, we're going to go through things like agent MD, project instructions, skills, this is really your best place to guide the agents to do what you want to do. And we're seeing a fundamental shift. It doesn't matter if you're a
manager now or an individual contributor, you all effectively have a large, unlimited alien co-workers that you can tell what to do. And there are management skills, instructions, and organizational skills that are highly impactful here. what I want to do first is kind of walk through the ecosystem because these are all terms that we kind of hear a lot, but they really do have a difference in how
they're used and how they're important. So, the very first one you'll hear is tools. Um and tools are just very basic. You can think of it just like tool use like a hammer, like command line tools, grep for search. All of those things are that are available. Agents can use those if given access. This is why things like Claude code have become so powerful. They weren't necessarily
magical. They weren't a different model necessarily than what you got using Anthropic or Claude.com or ChatGPT. The thing is that they had access to tools. And just like a human given access to a tool, you can multiply what you can do quite significantly. Within this, we'll talk about MCP a little bit. If you're unfamiliar with MT MCP, you can just think of it like an API. It
is a way for agents to communicate with another system. Again, it's not magic. It doesn't need to be overcomplicated. And MCP, you know, there's some interesting fun two-way stuff that can happen there. But at the end of the day, it is a way for an agent to access and interact and do things in an API-like form. The next two, and these are probably the important ones that
you can start with now. And we're having some conversations in the Dribbble community about how we should approach these things. First one is agents.md. And that is just like your readme in a file in in the project folder that the agent will read before it does anything. And then agent skills are on-demand procedural knowledge. So, let's kind of dig in to these a little bit. So, agents.md
specifically are things that you want the agent to be aware of every time they do something. And in practice, what this looks like, if you prompt into a system, Claude code, ChatGPT, at the very top level there's going to be a system prompt. Something that you often don't see that is put in and says, "You are a helpful assistant. You do the things that is influencing the
behavior." The next step is going to be what is in the agents.md file. So, you can write something in there that says, "Please never fake a test." Right? Or if you put in there, you know, "Only speak Spanish to me." It's It's always going to do that every single time and it's not going to forget it because it's put in like you typed it in at the
top of every single prompt. These are really good for the things that you would want to tell a developer to do every single time. "Don't work on something if there's not a ticket. Use correct punctuation." All of that stuff. But just like a human developer, these aren't enforceable rules. You still have to check it upstream somewhere. The agent is going to add this to the context and
depending on what is going on, they may very well ignore it. Just like a developer would with your read me. So, it is there. Now, what you have to balance is you don't want to throw everything you have inside an agents file because again, it's put into your message every single time that that is sent. Best case, that's using up a lot of tokens. Worst case, that's
really going to start to confuse um the agent. there is a discovery and precedence when we talk about agents.md files. And again, at the end of the day, it's just a text file, but the agents will pick them up from different areas of a code base. So, a lot of projects what I'll see happen an agents MD file that's in the project root and it says, "This
is what this project is for. This is how we work with this client or customer. Here's how we Within that, individual elements may have their own agents file. So, this is where our conversations about should we have an agents MD in Drupal core get really tricky because if it's there, the agents is going to look at it. So, eventually we're likely going to get a system where
a person has their own agents MD file within the project. They may very well have their own kind of developer tool in one that gets included. Drupal and other systems may have some specific modules may have some. And the way that the agents pull these in, even though this is a standard, is not really standard yet, right? And so, it's problematic in understanding how they're going to
interact, what is going to take precedence. But, it is a really kind of important thing to know about. Agents MD files were really important in this global migration because what I would do is as I started doing that import, you know, the first time we went through we let it go. Then I added to the agents file, "Don't build this whole site in the theme, right? Actually
use these tools." And it prevented me from having to rewrite that into every context. You've probably been in that situation you have a hard-fought battle with an agent. You get something done. Then you start talking about something else and it forgets about what you solved earlier. Those kind of things generally belong in agents MD files, especially if non-negotiables, things that you want reminded of every single time.
And again, the best practice though, you have to balance not overstuffing. Now, that problem is what has led to agent skills. Now, like the agent's MD file, at the end of the day, agent skills aren't magic. They are text files in a folder. You can bundle some other stuff with it, but it is a folder that agents can and use. And all it really requires is a
skill markdown file in it. agent skills is nice because it is an open standard that most, if not all, of the coding assistants are starting to use right now. There is, again, even though it's a standard, some differences in where they need to live, what they need to be called. It's coming together, but there is some still confusion at this point. But, the cool part of how
agents work is when an agent boots up, it loads just the front matter, the description. So, you can create a skill that says, "This is the skill that helps you deploy to Acquia Cloud." Right? That skill can have 100 pages of information in it. The agent is going to ignore that until it's doing something relevant to what's in the front matter. So, then it will say, "Oh,
the user, the human, has asked me to deploy to Acquia Cloud. I have the skill, which is effectively a runbook on how to do it. I'm going to follow through and do my best practices here." Right? And so, those are really interesting and really useful for those things where you want to provide on-demand guidance for an agent that is not overall important. We have one that we
use at Acquia, like when an agent is looking at logs. There's a lot of information there, right? You want to give it some guidance and say, "When you're looking into the logs, do it in this way." You don't want that to be in every single prompt. It's irrelevant to most of what you're doing, but it is important when it's needed. the activation and execution is interesting because
the agent picks. Yes, in the prompt, you can specify a skill if you want to and tell it to do it. And that's nice if you remember it. But a lot of times, it is just the agent deciding that it is relevant. So, the front matter is really important. It's kind of like a weird agent SEO type thing. Is this relevant to our use case? Over time,
you'll get better at getting these skills to You'll say like, "Why didn't you use this skill, right?" And the agent will say, "Well, because you said send to production, not deploy." And it was looking for the term deploy. At that point, ask the agent to fix the front matter so it catches it next time. And then, the execution. So, it reads the information, but it still is
going to decide if it wants to do it or not or if it's relevant. So, with agents and skills, remember that they are just guidance for an agent. They will hopefully help an agent work better at what we need, but it's not enforcement. It's not rules. So, you still need the upstream rules. You still need things that are going to, you know, don't have an agent working
on your code base without having a CI/CD upstream. Just the same as Yes, you would hope a developer ran tests locally, but you're going to check it when the pull request comes in. Very similar situation on So, at the end of the day, Oh, sorry. Go back one slide. So, the recaps on the agents versus the MCP, the main thing to remember is that agents are always
Agents and me is always on. It's always going to be in your prompt. Skills are as needed, and MCP are a way for it to add additional context. At the end of the day, it's all about the context that the agent has. Now, there's importance to the context when working with agents, again, think of it how context works in humans. You will probably remember the first thing
I said in the session and the last and everything in the middle, if it was important to you, you might. That happens with agents, too. They will look at your first paragraph, they will look at your last paragraph and they'll kind of have a blurry impression of everything in the middle. So, it's really important. That's why you can't tell an agent early on, if you are ever
looking at the logs, do it in this way because if you're 15 turns down in the conversation, it will no longer remember that. It needs to come into the conversation when it's important. at the end of the day, it is the same task and that's why I showed these prompts at the beginning because when we started that lovable demo to when we ended that lovable demo, the
prompt that we used to build the site never changed, but the context did. We were giving the agent recaps of meetings, we were giving it some guidance in our agent's file, we were improving our skills as it went forward so it could build things that were better and better. So, with that, I kind of want to open it up to questions and thoughts here. Yeah, I was
just thinking about your the skills for the agent and it seems like at least when I'm coding with an I have wants some of the skills within that single session. You don't want it but don't want that item to be remembered the next day if you maybe you're like test it out it's not working. You're like But then it sometimes is like, "Hey, remember that thing?" Yeah.
Please don't remember that thing, you know? Yeah. I mean and that's where the progressive pro >> a question? Oh yeah, sorry. The question was so if you have skills and you have a number of skills, sometimes correct me if I'm I'm saying it wrong. Sometimes they're really important and you want them to be in the conversation and then tomorrow you want that to be forgotten, right? It's
no longer important. And that's exactly why skills exist and why the front matter is so important because if I tell my agent, "We're going to go look into the logs right now." and it triggers that skill, it throws it into its context window. Now, the context window is finite, right? So even probably by the next conversation if I look at the logs and I say, "Here's what
we did." it's probably already forgotten about what was in that skill initially, right? So if in the next turn of the conversation we're still talking about logs, it might pull it back in. But say we jump and we move to implementation, it's probably going to forget it. Now one of the ways to get around this is just to not have long kind of meandering conversations. You know,
in Codex and Cloud Code like you can fork and you can create new conversations and you can resume them. You can also be telling the agent, "Update our documentation on this stuff." right? Because as you're bringing agents in, it's very similar to bringing other developers into the project. So but you know, that's where the team management type thing is important. It is like an employee that walks
in on day one, you don't want to give them a 500-page manual of everything they will ever need to know at the company because that's useless, right? You need to give them on-demand procedural training when they run into the situation. Back over there? I want to suggest looking up the Ralph Wiggum loop, which is this which is a mode that it goes into for this specific thing
that you're talking about, which is wake up every day as an idiot and you just don't remember anything. Like, "Oh, look at me, where I am." And And so, every day it forgets. So, it's called the Ralph Wiggum loop. It's a way that it's it's a sort of like expensive auto away of having it go through that process. It forgets every time. >> Yeah. I know. And
And there's an So, he he was talking about the Ralph Wiggum loop, which is a way to put a loop in an agent and it forgets. And And this is an important thing, like forgetting is important as well. Like, I I think there are conversations around what if we have these unlimited context windows? I think if there was value in that, us as humans would probably have
unlimited context windows. There is a benefit in forgetting and focus because at the end of the day and it it all comes down to attention and what you're paying attention to in the moment, so you don't want to have too much context there at any one point. So, if you could suggest something for module contributors in Drupal, what should they provide like together with their modules? So,
here here's some placement from the AI initiative here, right? So, yeah, I'll do a quick pitch on that. So, with the the AI initiative, um this is an area where we're always looking for areas of people that are using these AI tools and want to contribute to them. And you know, one of the things I I love to hear from both people that are very excited about
AI and people that are not excited about AI. It's a really important conversation to have because at the end of the day, what we're working on is the fundamentals of Drupal that apply to humans and agents together, and we can do things in ways that's good for everyone. So, the long pitch on that, if you're interested, come be involved in the Drupal AI initiative. Um Many companies
can join or individuals can join as well. So. My question was like what should what do contributors you know supply with their modules? Should they supply agent MD5s in your opinion or skill files or both or like do you have any opinion on this? don't necessarily think they should have agent MD5s. It's the same to me as if you have to explain an interface it's not a
good interface. So, if your code is written well and clear, documented and makes sense and is not overwhelmingly convoluted, the agent will be able to figure that out. Now, if it's beyond the module, the same principles we've used for accessibility are incredibly important. Right? Keep those in mind. Everything we've done for accessibility and SEO, everything about multilingual, that is all really critical for how agents will interact
with the systems. Follow up question. I am seeing in modules one aspect of including examples being essential. Some people know me as the webform maintainer and I was shocked to see AI generating webforms and it's because there's hundreds of examples. Like if you actually go into the test module I'm it's up to like 350 YAML files that are examples of individual things >> Mhm. that AI could
go and grab. I guess my question to you is this general thought is it best that we focus on these examples in our community so that the LLMs learn before we don't need skills. If we give that if we have a lot of examples on drupal.org for all the code standards, every new feature, every recipe, you generate a directory with examples of every single config action that
you might want. Will that help LLMs understand things, you know, the next iteration of thinking six months into the future where we don't need these skills anymore. We don't need to create a skill on how to create a recipe because it's already general knowledge and it brings up like another point. We have an examples module, Mhm. but I'm starting to think that needs to be That's examples
for humans. Yeah. >> there's something different with examples for AI. You don't need a lot of doc block comments. Yeah. Working code that's, you know, good variable names. Yeah. And it So, so the question is I I keep forgetting to like listen to the question and re-state it, but um so with something like the web form of the form module, how much do we include in the
module that is like examples of how to use it, assuming that that the agent will then know it and not necessarily need a skill? Yeah, even in our community, we start adding more general examples like I mean it's a perfect example that I ran into is there's no simple example on drupal.org for a file upload. You can use the managed file field, but that is the only
place that that's well documented. But, if you just have a form where you want to upload something, Yeah. grab that data, doesn't exist. It's in It's in a gist somewhere that someone wrote like 4 years ago. And AI can find that. Yeah. So, this is It's complicated, but this is where it comes into the human expertise is really important because if it's a general answer that generally
applies to all situations, yes, put it in that example, right? And so, something like I mean, this might be a bad example, but how do I clear the cache? There are some basics that are going to be relatively the same even if you're using different interfaces just to do But, if your question is how do I deploy That is very different based on where you're deploying it
to. And that's where a skill would come in because you we wouldn't want Drupal to have information about here's how you deploy it to Acquia, and here's how you deploy to Pantheon, and here's how you set up in DDEV, right? It's useful to have that information out there, but we don't want to wrap it up because it is irrelevant information depending on what they're doing. So, skills
are really useful there, especially because skills can be both from the agent or at a project, where I can say, "This is a Drupal site that is deployed on Acquia, so I have a skill specific to that. And this is a WordPress site that I deployed to my own AWS." You don't necessarily need the skills even within the same. So, it really gets into that, like, is
it the right information at the right time without overwhelming. So, yeah, I would say if it's if it's fundamental to how the module works, like, but if that point, like, examples are good. Um, you know, like there's something like a PHP API file or something like that, like, you could see a lot of value in that, and they will read it, and they will understand it. And
that's like the same kind of thing that you would use if you were a developer trying to implement uh, like PHP API file, we're very guilty of putting the hook name in and not filling in any code. Yeah. And it almost works like the AI fill that fill in the blanks a little bit. Yeah. Yeah, and and those are great examples AI usage, too, is like, what
are the things we always wanted to do that we never did, and no one's ever going to do them? Can we use AI to do it? So. Back in the corner. So, I made a skill for a Drupal site, um, and I used an AI to create the skill in the first place, and I was wondering just more about, like, where to put these skill files. It
was specifically suggesting we put it under a dot blog folder. Uh, and because most of the most of the AI agents read it under there, even though I was using Open Code. Um, is there like a standard place that these skill files should go? I'm we have so many different things with modules and core in your deployment process. You know, we I'm thinking we should have a
library of these somewhere, but where should that live so that we're not conflicting with everybody else's skills at the Yeah. So, the question's is where to put your There is a standard and it is not standard. It's early. I mean, and this is one of the fun parts about AI and I think where open source can help these conversations they're making the same mistakes we made 20
years ago to some extent, right? And so like there's different vendors doing different things and you lead to all these skill package managers that at the end of the day there scripts that put your skills in 15 different places there is a standard for what is in the skill, but the standard hasn't extended where the skills live and how they're loaded by the agent specifically. There's also
not necessarily standards for what is the NPM of skills. There are things like skills.sh that help you pull it down, but it doesn't have a lot of the stuff that we would expect like version pinning you know, hash or stuff like that. So the standards are emerging, but it's going so fast that some of these fundamental things that we expect aren't necessarily there. So, that's where like
if you're just getting into AI, your expertise from open source can be incredibly beneficial to these So, I think we're probably time for one more question if there's any. Awesome. Well, thank you all for coming. I want to bring up one more thing. Um Acquia agent experience hackathon, you can win $3,000. Um I will be at the booth later today. This is just a place. There are
prizes for kind of who builds best things using agents as well as the best and most responsible contribution back to Drupal using an agent. Um I'll give you a little tip on this. We are going to have an agent judge this and I'm not going to correct the agent if you trick it. So do with that what you will. So, thank
