Agent Experience as design discipline

Netlify's Billman introduces Agent Experience (AX) as a four-pillar framework for platforms built around AI agents Devworld Conference
TL;DW
  • Agent experience (AX) is the holistic experience AI agents have using a product, analogous to how UX and DX shaped platforms—critical for any company whose product agents will use.
  • Four pillars of AX: access (frictionless agent onboarding), context (markdown docs, MCP servers as UI for agents), tools (intentional agent-friendly APIs, not just raw endpoints), and orchestration (agents using your product and your product triggering agents).
  • Think of context as the UI for agents—design documentation, skills, and MCP servers to surface only the relevant information agents need, not every API endpoint.
  • Remove interactive prompts from CLIs and docs; give agents explicit non-interactive commands they can call directly without workarounds or trial-and-error.
  • Open agent ecosystems beat closed ones—orchestrate third-party agents (Claude Code, Codex CLI) inside your product rather than forcing users to use proprietary agents.
  • Netlify's internal teams (HR, support) built production software with minimal developers using agent assistance, shifting the build-vs-buy equation fundamentally.
  • Agents will use your product whether you optimize for them or not—via computer use, browser automation, or other workarounds—so intentional AX beats accidental friction.
  • Content negotiation pattern: serve markdown directly to agents (via Accept headers) while humans get formatted websites, reducing context pollution and improving agent comprehension.
  • MCP and skills are UIs for agents, not API wrappers—expose five curated, composable tools instead of wrapping all 100+ API endpoints to keep agent context clean.
  • Every person building software with agents is now a developer; teams shift from stakeholders-only to domain experts collaborating with technical builders, reshaping how software gets built.

Billman's framework covers access (removing agent-hostile friction like interactive CLI prompts), context (docs and protocols as agent UI), tools (intentional abstractions over raw APIs), and orchestration (letting Claude, Codex, and Gemini operate inside Netlify without forcing Netlify-specific agents on users).

Software-as-investment vs firefighting trap

Losen's platform team cut chronic firefighting by reclassifying software as investment, not cost DevOpsDays Zurich
TL;DW
  • Firefighting loop: complexity creates more firefighting; faster work spins the loop faster. It's a system problem, not a people problem.
  • Shift mindset from software-as-cost to software-as-investment. Change equals capability, not risk. Adaptability, not stability, is the goal.
  • Limit work-in-progress with hard caps—Losen reduced from 7–8 concurrent items to far fewer. Three things done beats seven half-done.
  • Protect team capacity mid-week for systems work, not Friday afternoons. If everything is urgent, nothing improves.
  • Measure flow, not heroics: time-to-production, predictability, surprise frequency. Stop counting tickets closed.
  • Design for safe change: eliminate cross-team dependencies, validate data internally, use reverse proxies to decouple partners.
  • Kill the hero pattern by building shared ownership and safe inquiry. When team members ask 'I don't understand this,' systems get documented and simplified.
  • Make systems easier to understand so multiple people can change them. Ship small, frequent changes instead of big risky releases.
  • Build trust early: make it safe to say 'I don't understand.' Unasked questions mean systems stay unexplained and complex forever.
  • Change what you optimize for explicitly. Your system is perfectly designed to produce your current results. Name the optimization, then change it.

Olga Kristjansdottir at DevOpsDays Zurich outlines five operational shifts—WIP limits, deployment-frequency metrics, dependency untangling, shared ownership—that broke a vicious loop where urgent patches added complexity and bred more incidents, illustrated by an 18-year-old router activation bug finally fixed at root cause.

Org structure as bottleneck

DevOpsDays Zurich: system bottlenecks are org-structure failures, not technical debt DevOpsDays Zurich
TL;DW
  • Hero culture creates fragile systems: single engineers become bottlenecks in code review, incident response, and knowledge. Prevent by directly asking engineers to share knowledge, not just protecting them from unwanted work.
  • Local team optimization causes global system failure. Different teams with different charters (generic vs. specific solutions) naturally conflict on technical merit. Solve by clarifying organizational ownership and decision authority, not winning technical arguments.
  • Managers who stay tactical too long become the team's ceiling. Use the two-week vacation test: if everything collapses when you're gone, you haven't empowered your team enough.
  • Best engineers promoted to manager often keep making decisions for their team, blocking autonomy and preventing direct reports' advancement. Successful managers want to help others be the best engineers, not be the best themselves.
  • Unclear decision authority between product and engineering (or any two functions) causes delay and frustration. Define who makes which decisions upfront to move fast.
  • Use the Scalable DevOps Leadership Loop: clarify ownership (who is accountable for each service?), reduce cognitive load (one team per mission), create shared context, and enable safe debate.
  • Cognitive load audit: one team doing too many unrelated things (Linux OS, virtualization, event processing, distributed systems) can't hire or operate effectively. Split responsibilities by domain.
  • High-performing teams disagree openly and healthily, then commit and move. Disagreements hidden in PR comments are toxic; bring them to open discussion first with 'strong opinions, weakly held.'
  • AI increases velocity but also increases bugs 54%, incidents per PR 3.4x, and code churn 861%. Tooling and automation cannot replace alignment and decision-making speed.
  • Use weekly impact audit: identify work only you can do (unique value), work you're comfortable doing (comfort zone tax), and delegate/automate the rest to grow and focus on high-impact work.

Limor Bergman Gross, drawing on her time leading DigitalOcean's compute group, maps five leadership failure modes—hero culture, local optimization, unclear decision authority, tactical managers, and conflict avoidance—and argues that ownership mapping and cognitive load checks fix what DevOps tooling and AI cannot.