One Year of AX

Today marks year one since I published “AX, Agent Experience and why it matters”. And the term is more crucial and important today than ever.

This year promises to be the year of Agents. Claude Code cracked the code for how to build a true autonomous computer using agent by making the agent live in the CLI. Discovering the primary form factor for generalized agents in the digital world.

During the last couple of weeks Clawdbot took the web by storm, turning Claude Code into a mad, generalized, hyperconnected truly autonomous computer using agents freely interacting with products and communication channels. An early sign of where we’re going in what might be a decade of agents. Popularizing the general personal agent running on its own computer.

More and more people are starting to realize that most of the products or platforms we build will become irrelevant unless autonomous agents can use them efficiently on behalf of their users.

The initial adoption of the term AX when I coined it about a year ago was dominated by developer tool founders or builders. This year we’ll start to see the term appeal much more widely.

The first AX job postings have started to appear, the venture fond BVP named AX as their Law #1 in their AI Developer laws, and Sequoia Capital’s Sonya Huang stated that we are going from the age of product led growth to the age of agent-led growth.

From AX is the new DX, to AX is the new UX

In the first year AX was mainly received as the new developer experience.

At Netlify the term emerged as an internal rallying cry to radically shift the North Star of our product from DX to AX and put all of our focus on being the platform of choice for AI agents building on the web - without forgetting the humans building through them. Our top of funnel exploded and we crossed 10 million developers as we welcomed a whole new audience and pioneered new workflows for builders.

Software development has been the first field to get disrupted by agents. At first vibecoding platforms were seen as toys for hobbyists, but by the end of last year agents like Claude Code or Codex was transforming how experienced software developers work.

That’s why forward looking dev tool founders from companies like WorkOS, Stytch, Resend, Clerk, Auth0, Neon, Vite, Daytona and many more, were the first to adopt the term, have me speak at their events or podcast or wrote their own AX articles or presentations after I initially coined the term.

They were all starting to experience first hand the change coding agents would make in how people find, choose and use developer tools and infrastructure products.

But outside of a few visionaries like Dharmesh Shah, John Maeda or Ben Moskowitz we are still in the very early stages of any adoption of the AX discipline from broader SaaS services, E-commerce businesses or consumer products. This will no doubt change as the learnings from Claude Code, Codex CLI and Gemini CLI makes their ways into agents truly build for consumers and business users.

Clawdbot triggered a moment of excitement, similar to the moment when the first vibe coding tools came out. A moment that sets the direction of how future personal and general agents working for individuals will disrupt the way we work and collaborate.

As these emerge, we’ll go from a world where AX is primarily understood as a new type of developer experience, to a world where AX will be as generally applicable as UX itself.

The discipline so far

As we’ve been practicing agent experience at Netlify during the last year and observed the discipline across the industry, here are four areas of agent experience that I think any digital product should start investing in and focusing on:

• Access Can the Agent access your product? Do they have the right permissions? Must the human be in the loop?

• Context Does the LLM know about your product? Does it have the right context to use your product? Do your responses build the right context?

• Tools Are you building your product for agents? Do you offer the right tools for agents? Can you reduce friction for a human working through an agent?

• Orchestration Can you trigger agent runs from your product? Can you pass the right context along? Do you offer sandboxes and environments?

I’ll be writing and talking more in depth on each of these in the future as I expand on Agent Experience in Practice, but some initial pointers.

Access

To a larger and larger extent, we should expect humans to access our products indirectly through agents. Often agents will be the ones to first suggest our product to a human, and often they will do the work in our product on behalf of a user.

To do that, the agent need to know about our product, and there’s a whole field of Generative Engine Optimization, GEO being shaped as search engines becomes less directly relevant.

They also need to be able to access your product on behalf of a user.

To some degree they can always do this whether you want it or not. Claude Code can drive browsers like Chrome through tools like Playwright or the Claude Browser extension, some agents will be directly built into browsers, and the boundary between browsers and agents will probably become blurry anyway.

So it’s not so much about giving the agent access, as it is about removing friction and making it a great experience for both the agent and the user prompting the agent to get access to your product.

All product have an Agent Experience, it’s purely a question of whether it is good or bad.

Context

In the initial world of GenAI there was a lot of focus on Prompt Engineering as an emerging discipline, but as LLMs got better at understanding instructions and strong enough to drive agent loops, it became clear that the specific shape of a prompt is much less important that the process of Context engineering: managing the internal context of the agent so it can successfully accomplish goals given to it in a prompt.

Anthropic gave the simple and useful definition of an agent: “Agents are models using tools in a loop”.

Managing and affecting the context for the LLM calls inside that loop is Context Engineering, and when working on the AX of our product we have a whole set of tools at our disposal to make sure the context helps the agent use our tool.

MCP or Model Context Protocol was one of the first standards aimed at letting services interact with the context inside the agent loop to make it better at doing tool calls or solving problems.

Skills are a newer standard with similar goals.

Techniques such as Content negotiation for docs sites, to make them respond with pure markdown when accessed from an agent, or helpful feedback to agents from cli tools all fall under the context engineering part of AX, and are essential to making agent successful and happy users of your products.

Tools

The agent needs access to tools to interact with the world inside the core agent loop. Some of these we can provide through protocols like MCP or standards like Skills that can include custom scripts, and some are system tools that can interact with our software by calling our CLIs or APIs.

Today many of the most successful agents like Claude Code or Codex CLI builds these tools into the core agent and wrap system tools like file access, shell command execution and browser access, but MCP servers are becoming more and more common and act as a way to extend the available tools agents can use during their agent loop.

Building the right tools is crucial to bring the agency of agents into your software. The MCP specification is still maturing and may at some point even be replaced or vastly extended, but thinking about tools as an integral part of our AX is essential to give agents a great experience on our platform.

Orchestration

Finally, for those of us building platforms that developers rely on, we need to start thinking about our products as potential orchestrators of agents.

For Netlify this is something we’ve given a lot of thought to already. We’ve launched the ability to trigger agents from within your netlify sites through the Claude MCP tool, and explored different workflows like Git Workflows for agent orchestration.

We will see new patterns emerge for how to run agents at scale, whether that’s through serverless execution or orchestration systems, and as platforms we will need to embrace and enable these new ways to orchestrate agentic workflows as a core aspect of the AX of our platforms.