Ronald van der Plas · Nov 12, 2026
Agents are ungrateful. Your content strategy isn't ready for that.
At G2 Reach this week, Tim Sanders, Chief Innovation Officer at G2, made two statements that stuck with me: "Agents are loyal to the prompts" and "Agents are ungrateful." Both challenge something content marketers have relied on for years. Publishing useful content helps build trust, familiarity and, eventually, consideration. Someone reads your articles, attends your webinars and starts recognising your organisation as a credible source. When the time comes to buy, that relationship can influence the decision. AI agents don't build relationships in quite the same way. They can use your content to answer a question without giving your organisation any preference when recommending a product. Your article might be the best explanation of a problem, while your competitor is still the better answer to the buyer's requirements. That distinction has consequences beyond marketing. It changes what information we publish, how we structure it and how our digital platforms make it available. Being helpful doesn't make you the right choice Sanders illustrated this with an interesting distinction. An AI model can encounter CrowdStrike as a publisher of security content and CrowdStrike as a vendor of security products. Being excellent at explaining cybersecurity doesn't automatically prove that your product is the right choice. He described a recommendation process consisting of three stages: candidacy, validation and selection. During candidacy, a model identifies potential suppliers that meet the buyer's requirements. Validation involves looking for evidence that supports their claims, including independent sources. Finally, the model selects a recommendation based on the available information and its confidence in that evidence. This is a useful way to think about AI-assisted purchasing, although I wouldn't mistake it for a documented internal algorithm shared by every AI platform. Different models, retrieval systems and agent workflows can behave quite differently. What matters is the underlying principle: your claims need to be discoverable, understandable and supported by evidence. One example from the session made this particularly clear. A security vendor had a competitive advantage around agent latency, but its customer reviews mainly discussed ease of use, support and value for money. Those reviews were positive, yet they didn't validate the specific performance claim that mattered to potential buyers. It's a good reminder that collecting more testimonials isn't necessarily the answer. The evidence needs to support the reasons customers actually choose your product. Your content architecture is now part of the buying process This is where I think the conversation becomes particularly interesting. Much of the discussion around Answer Engine Optimisation (AEO) focuses on mentions, citations and visibility. Those are useful measurements, but they don't tell us whether an AI system can properly evaluate what an organisation offers. Consider a typical enterprise website. Product capabilities might be described across dozens of pages. Pricing information could be hidden inside downloadable documents, technical specifications might sit in separate systems, and essential content may only appear after client-side JavaScript has executed. A human visitor can often navigate around these limitations. An AI system attempting to compare fourteen suppliers against a detailed list of requirements may have a much harder time. The solution isn't simply to publish more content or add schema markup to every page. It starts with the content model itself. Product capabilities, specifications, eligibility criteria and commercial terms should be represented as explicit, maintainable information rather than being buried inside presentation components. From there, the delivery architecture needs to make that information accessible. Semantic HTML, reliable server-side rendering, predictable URLs and appropriate structured data all help. So does ensuring that relevant crawlers can actually retrieve the content. This is also why I don't believe organisations should immediately start building separate websites for AI agents. We've spent years advocating structured content and headless architectures precisely because content shouldn't be inseparable from its presentation. If we've implemented that separation properly, serving another type of consumer should be an extension of the architecture rather than another content management problem. There may be value in providing agents with a more concise representation of a page, such as Markdown. But that is a delivery optimisation, not a replacement for a well-structured content model or independently verifiable information. And it is worth remembering that not every AI system retrieves or interprets content in the same way. Optimising for one crawler or one response format is not an agent-readiness strategy. Being recommended is different from being actionable Sanders also discussed the next evolution: agents that move beyond recommending products and start completing tasks or purchases on behalf of users. I agree that the work organisations do today on content quality and evidence will remain relevant. But this is where the architectural requirements change significantly. An agent researching a product primarily needs reliable information. An agent requesting a quote, checking availability or placing an order needs access to business capabilities. Those capabilities might be exposed through existing APIs, supported commerce integrations or protocols such as the Model Context Protocol (MCP). The appropriate interface depends on the task and the systems involved. More importantly, agents need to operate within clear boundaries. Authentication, authorisation, approval workflows, transaction validation and auditability become essential once an agent can do more than retrieve information. We shouldn't assume that making a website readable to agents automatically makes the underlying business ready to transact with them. Being discoverable, being recommendable and being actionable are three related, but distinct, architectural challenges. And while autonomous purchasing attracts plenty of attention, it is worth keeping the current reality in perspective. G2's 2026 buyer research suggests that organisations are far more comfortable using AI for research and evaluation than allowing agents to execute purchases independently. The opportunity is real, but the transition will be gradual. Don't confuse visibility with recommendation One point I appreciated in Sanders' presentation was his distinction between being mentioned, being cited, and actually being recommended. These aren't equivalent outcomes. A company might appear frequently in AI-generated answers because it publishes excellent educational content. That doesn't necessarily mean it is being shortlisted when buyers ask for solutions to specific problems. For me, this changes how we should approach measurement. Rather than asking only whether our brand appears in AI search results, we should examine the questions potential customers are asking. Does our organisation appear when those questions include real requirements, constraints and buying criteria? If not, is the problem missing information, inaccessible content, insufficient supporting evidence or simply a product that doesn't meet the requirements? Those are very different problems, and buying another AEO dashboard won't solve all of them. The same critical thinking applies to G2's own recommendations. As a review platform, G2 naturally emphasises third-party validation. That doesn't invalidate its research, but independent evidence extends well beyond review platforms. Technical benchmarks, certifications, customer case studies and authoritative documentation can be equally important, depending on the claim being evaluated. Start with what actually wins you business If I were advising an organisation where to start, I wouldn't begin with an ambitious agentic commerce initiative or a complete website rebuild. I'd start with three questions. What are the two or three capabilities or differentiators that genuinely influence customers to choose us? Can an AI system find and understand those claims on our website, without navigating a maze of presentation components, PDFs and vague marketing language? Is there credible evidence available to substantiate those claims? If the answers reveal gaps, you already have a practical starting point. Some improvements will be editorial. Others will require changes to content modelling, rendering or integration architecture. The bigger lesson I took from Sanders' session is that AI-assisted discovery rewards organisations that can make their value explicit and verifiable. But I would take the argument one step further: the same architectural foundations will determine whether those organisations can eventually let agents interact with their services. Agents may be ungrateful, but that isn't necessarily a problem. They force us to confront something we should probably have addressed years ago. Is our digital experience actually designed to communicate what we offer, or have we become too dependent on humans figuring it out for themselves?
Read postRonald van der Plas · Nov 12, 2026
Sitecore Advantage: Closing the gap between features and value
During the Sitecore Symposium keynote in Orlando, most of the attention naturally went to MarketingIQ, AI agents and the new capabilities Sitecore is bringing to its platform. But towards the end of the session, another announcement caught my attention: **Sitecore Advantage**, a new approach to helping customers get more value from their Sitecore investment. It might not be as exciting as a new product launch, but I think it addresses a challenge that many customers and implementation partners will recognise. Delivering new capabilities is one thing. Making sure customers actually benefit from them is something else entirely. Keeping up with an evolving platform One of the challenges with modern SaaS platforms is the pace at which they evolve. A customer implements a solution, gets everything running and moves on to other priorities. Meanwhile, Sitecore continues introducing improvements, new capabilities and increasingly sophisticated AI functionality. During the keynote, Sitecore shared some impressive adoption figures, including more than a thousand agents built by customers and partners since the introduction of Agentic Studio. At the same time, it acknowledged that adoption differs significantly between customers. Some are already making extensive use of the new capabilities, while others are still figuring out where to begin. I recognise that challenge. Even when you're working with Sitecore every day, keeping track of everything that becomes available takes time. For customers, whose primary focus is running their business rather than following every product release, that challenge is even greater. This is where Sitecore Advantage comes in. Bringing Sitecore closer to the customer With Sitecore Advantage, Sitecore wants to take a more proactive role in helping customers identify opportunities to improve how they use the platform. The initiative introduces what Sitecore calls forward-deployed engineering, bringing product specialists closer to customers to help them connect new capabilities to their business challenges. The published service terms describe a tiered advisory model covering activities such as architecture reviews, technical guidance and optimisation. Hands-on implementation remains outside its scope, which is an important distinction when considering how this fits alongside existing implementation partners. Personally, I welcome the initiative. Customers already expect Sitecore to contribute its perspective, particularly when discussing product direction, new capabilities and opportunities to get more from their investment. Having that expertise more directly involved can only help, provided everyone is working towards the same objectives. Better together During the keynote, Sitecore emphasised that Advantage is intended to complement implementation partners rather than replace them. I think that is exactly the right approach. Implementation partners generally have a broader understanding of the customer's technology landscape, integrations, business processes and previous architectural decisions. They should continue to lead the solution architecture and implementation, while Sitecore contributes its detailed product knowledge and insight into where the platform is heading. These perspectives complement each other, and I believe the customer benefits most when they come together. A new Sitecore capability might look promising, but understanding whether it fits an existing architecture and actually solves a business problem requires both product expertise and customer context. The important thing is to avoid creating separate conversations where Sitecore and the implementation partner independently advise the same customer. That introduces unnecessary complexity and potentially conflicting recommendations. Instead, Sitecore Advantage should strengthen the collaboration that already exists, with everyone aligned on the customer's priorities and the best way to address them. Turning capabilities into value What I like about Sitecore Advantage is the recognition that releasing new features doesn't automatically mean customers will use them or benefit from them. Especially with the pace of AI development, having additional expertise available to identify relevant opportunities is valuable. Of course, the success of the initiative will depend on how it works in practice. The advisory model needs to deliver more than occasional product recommendations, and the collaboration between Sitecore, customers and partners needs to be effective. But the direction makes sense to me. When Sitecore brings its product expertise, partners contribute their architectural and business knowledge, and customers provide their priorities, we have a much better chance of turning new capabilities into meaningful improvements. And ultimately, that's what matters: not how many features a platform offers, but how much value customers get from using it.
Read postRonald van der Plas · Nov 12, 2026
A SitecoreAI site in four Agent hours. Where does the work go?
At Sitecore Symposium 2026, Christian Hahn demonstrated something impressive: a complete SitecoreAI website built by a team of AI agents, without writing the code himself or opening the Sitecore interface. The agents needed just four hours of execution time, while Christian spent only 42 minutes actively involved. However, the entire process took 40 hours. These were relatively straightforward websites, with limited integrations and none of the complexity that accumulates in long-running customer projects. Christian also experimented with converting older Sitecore sites, although those were similarly limited in scope. It would be a mistake to conclude that a complex enterprise implementation can suddenly be rebuilt in a few days. What interested me most was not the speed of implementation, but what happened around it. If building a website becomes significantly faster and cheaper, where does the remaining work go? And what should we invest in when writing code is no longer necessarily the most time-consuming activity? Four hours of work, forty hours to deliver Christian, a Technical Product Manager at Sitecore, shared figures from two projects built using his agentic development workflow. In the first project, the agents completed four hours of work, with Christian spending just 42 minutes actively involved. Yet the entire process took 40 hours from start to finish. His second, larger project required 34 hours of agent execution and two and a half hours of his own time, spread across four and a half days. The difference between execution time and elapsed time tells a more interesting story than the four-hour figure alone. During the first project, agents repeatedly stopped to ask questions. Christian was not always at his desk to answer them, so the workflow remained idle until he returned. The implementation was relatively quick, but progress still depended on someone being available to make decisions. Notifications that allow you to respond remotely would already help. A more interesting improvement would be teaching agents about your preferences, architectural principles and previous decisions, reducing the number of routine questions without removing the checkpoints where human judgement matters. The second project exposed another limitation. Much of the 34 hours went into repeatedly refining a design that Christian was not satisfied with. The agents could generate alternatives quickly, but they could not independently determine which result matched his expectations. AI can reduce implementation effort, but it does not eliminate the cost of uncertainty. When the desired outcome is unclear, faster generation can simply produce more iterations. The harness matters more than the prompt Christian's approach is built around a *harness*: a structured environment that coordinates agents, provides them with relevant knowledge and verifies their output. He used Claude Code, but the underlying concepts are not tied to a particular AI product. His setup consists of five building blocks: agents, commands, skills, rules and context. Agents have narrow responsibilities, commands define the tasks being executed, and skills provide domain knowledge about Sitecore and its development tools. Rules establish requirements that must be followed, while context determines which information each agent receives. Most of these building blocks are simply text files. Christian used thirteen specialised agents rather than relying on one general-purpose assistant, keeping the agents relatively lightweight and placing the actual platform knowledge in reusable skills. The workflow starts with two product-management agents that interview the user, prepare a specification and challenge it for missing information. Other agents inspect the Sitecore environment, define the architecture, produce a design and break the work into implementation tasks. Development then follows an iterative process in which implementation, code review and QA continue until the work passes its checks. The pipeline also handles provisioning, content authoring through Sitecore's Marketer MCP and publishing. What I particularly liked was how Christian handled human involvement. His pipeline contains configurable approval gates, including checkpoints around specifications, design and release. During his demonstration, he retained the design approval gate while allowing other stages to proceed autonomously, with safeguards around changes to the actual SitecoreAI environment. He summarised the philosophy rather well: "You leave the IDE to decide. Never to operate." Autonomy does not have to mean removing people from the process. It means deciding where their involvement adds value. The flow is yours to build One of Christian's strongest messages came towards the end of the session, when he explained which parts of his solution others should reuse. Rules, skills and agents are relatively universal and can often be adopted directly. Commands are more opinionated because they reflect his choices about how work should be performed. The complete workflow is even more specific, because it represents his approach to delivering a project. As he put it: "The pieces are copy and paste. The flow is not." I think this distinction matters for development teams considering agentic workflows. Installing a collection of Sitecore skills is relatively straightforward, but that does not automatically provide a reliable delivery process. The harder part is defining how those capabilities work together, how quality is measured and when decisions require human involvement. Christian suggested starting small: install the skills you need, introduce specialised agents and gradually develop your own workflow based on the friction you encounter. He has shared both a [reference implementation of his workflow](https://github.com/Chris1415/agentic.hahn-solo.content-sdk.greenfield.developer) and a [library of Sitecore skills](https://github.com/Chris1415/sitecore-skills-pocs) on GitHub. Both are personal proofs of concept rather than officially supported Sitecore products. The published materials provide a useful starting point, but the workflow itself is something each team needs to develop and improve. The cost of implementation is falling Christian also shared what running these agents costs. His first project consumed approximately $2,000 in model usage. After optimisation, he reported that a comparable demonstration website could be created for less than $500, with a delivery time of around two days. Two changes contributed significantly to that improvement. First, he restricted the context available to individual agents. In his initial implementation, one developer agent accumulated a context of 820,000 tokens. Providing only the information relevant to each task reduced unnecessary processing. Second, he stopped using the most expensive model everywhere. Claude Opus remained responsible for orchestration and requirements analysis, while implementation tasks moved to the less expensive Sonnet model. These figures are impressive, but token costs should not be confused with project costs. Requirements gathering, integrations, security, testing and ongoing maintenance still require substantial investment, particularly in enterprise environments. Nevertheless, the direction is interesting. As implementation becomes more efficient, the activities surrounding it account for an increasingly significant part of project delivery. Analysis and verification become more valuable For me, the most important lesson is that faster implementation places greater demands on what happens before and after the build. Christian's workflow starts by challenging the requirements rather than immediately generating code. That is important because agents are remarkably good at turning incomplete instructions into something that looks finished. When information is missing, they make assumptions that may seem reasonable but do not necessarily reflect what the customer expects. This problem is hardly new. Poor requirements have caused expensive rework long before AI entered software development. The difference is that agents can now turn those assumptions into working software much faster. Christian also had the advantage of being the customer, architect and final decision-maker. In a real project, requirements must often be reconciled between marketing, IT, security and other stakeholders. AI can help structure those conversations, but it cannot remove the need for people to agree on the outcome. The same applies to quality. Christian discovered early on that his agents could produce visually convincing components without supporting inline editing in the Sitecore page editor. He turned that experience into a hard rule: fields that support inline editing must expose that capability; otherwise the implementation fails its checks. He applied a similar principle to performance, using an agent to monitor Lighthouse scores and create GitHub issues when performance deteriorated. This is exactly the kind of platform knowledge I would want to capture in a harness. Requirements around inline editing, accessibility, performance and security should become repeatable quality checks rather than depending entirely on manual reviews. Automated checks cannot replace every assessment, but they can remove a considerable amount of repetitive verification. Design deserves similar attention. Christian's repeated design iterations illustrated the cost of working without a sufficiently clear visual reference. Connecting agents to an established design system through tools such as Figma and Storybook would provide a more reliable foundation than asking them to interpret written descriptions repeatedly. The point is not to eliminate human judgement. It is to use that judgement where it matters most, while making everything else as repeatable and verifiable as possible. Where I would invest Christian's session demonstrated how much can already be achieved with a collection of specialised agents, reusable skills and a well-structured workflow. More importantly, it showed that the real value comes from the way those capabilities are brought together. For development teams, I see several investments worth making: improving how we translate business requirements into testable specifications, capturing platform knowledge in reusable skills, providing reliable design systems and turning quality requirements into automated checks. But perhaps the most important investment is learning to design the workflow itself. Which tasks can agents execute independently? What information do they need? Which checks provide sufficient confidence, and where should a person remain involved? I would also want to measure the results beyond execution time and token consumption. Human intervention, rework, escaped defects, and the time required to reach production readiness tell us much more about whether a workflow actually improves delivery. Christian suggested that he might never write code again, before acknowledging that this was perhaps a little too drastic. I understand the sentiment, although I do not believe writing code will disappear from our work entirely. What I do expect is a shift in where our expertise creates the most value. Analysis, architecture, design and verification become increasingly important as implementation is automated. So does our ability to turn that expertise into a process that agents can execute reliably. The four-hour website was an impressive demonstration, but the bigger lesson for me was not about generating code faster. It was about designing a better way to deliver software. And that is a workflow worth owning.
Read post