The Rise of Agent Relations
As AI agents become the new intermediary between developers and tools, companies must optimize for two audiences at once, human inspiration and machine readability, reshaping what Developer Relations actually means.
A few months ago I wrote about this idea of Agent Relations. At the time it felt like a provocation, a way to shake loose the assumptions we'd built up over a decade of Developer Relations work. Looking at where the industry has moved since then, I think it's simply a description of where we already are.
Developer Relations used to be an exercise in creative instructional design. You wrote tutorials. You gave conference talks. You built clever demos, posted a video, and hoped the right engineer stumbled across it at the right moment. The whole discipline was organized around one central question: how do we get a developer's attention long enough to show them something useful?
That question hasn't gone away. But it's been joined by a different one: how do we get an agent to recommend us?
Two audiences, one team
DevRel practitioners in 2026 are writing for two very different audiences at the same time. The first is the human developer, someone who still wants to be inspired, who still watches demos on YouTube, who still discovers new tools through a Reddit thread or a friend's recommendation. The second is the agentic layer sitting between that developer and the internet: coding agents, research assistants, AI-powered IDEs that now mediate a growing share of how developers learn, choose, and build.
These two audiences have different needs. Human developers respond to narrative, creativity, and connection. Agents respond to structure, completeness, and machine readability. You can't inspire an agent. But you can make your product's documentation, APIs, and code samples clear and well-organized enough that when an agent is helping a developer solve a problem, your product becomes the obvious answer.
"You can't inspire an agent. But you can make your product the obvious answer when one is choosing for a developer."
This is reshaping what DevRel teams actually produce. Quickstart guides, long the backbone of developer onboarding, are becoming less relevant when an agent can read your full API reference and write the integration itself. The onboarding experience is shifting from "follow these five steps" to "give the agent everything it needs to succeed on your developer's behalf." Your API is the learning interface now. Your docs are consumed at machine speed, not human speed.
Agents inside the team
The transformation isn't only outward-facing. The most immediate change happening in DevRel teams right now is internal: we are building agents to handle the work we used to do manually.
At Postman , our team has built agents for blogging and copyediting using our own internal style guides, for hunting and submitting to calls for papers, for responding to common support questions in community forums, for social posting and sentiment analysis. These aren't experimental side projects. They are live, running workflows.
The goal isn't to replace advocates. It's to expand what they can do. When the repeatable, mechanical work is handled by agents, advocates get their time back for the things agents genuinely cannot do: showing up at events, building real relationships in community spaces, creating the kind of demo that makes a developer stop and think I need to try this. Speed and creativity, unlocked by AI, so we can get back to building the cool stuff that gets people excited.
The broader ecosystem is moving in the same direction. OpenAI is apparently building an agent-first alternative to GitHub, a platform where AI agents can manage dependencies, propose pull requests, and operate within the version control system natively rather than as a bolt-on. Platforms like Guild.ai are rethinking AI infrastructure from the ground up with agentic workflows in mind. Anthropic just released Dispatch. The pace of new innovation is staggering.The tooling layer is being rebuilt daily around agents as first-class participants.
The compounding DX flywheel
Developer Relations has always, at its core, been about inspiration. You make something cool. A developer sees it, gets excited, and builds something of their own. They share what they built. Other developers see it. The cycle continues.
Agent Relations adds a new loop to that flywheel. When a developer has a great experience with your product, because your docs were clear, your APIs were well-designed, your code samples were accurate, they build something and share it. That experience ends up in the places agents learn from: GitHub repositories, Reddit discussions, YouTube tutorials, blog posts. When another developer asks their coding agent for help with a similar problem, your product surfaces as the recommended answer because the evidence of a great developer experience is already in the training data and retrieved context.
"Good DX compounds. The quality of the developer experience doesn't just affect the human who had it — it propagates forward into how agents respond to the next developer who asks a related question."
And when agents start consuming your service directly, they have all the APIs, docs, and tools they need to produce quality output, which leads to a great developer experience, which generates more content, which trains better agent recommendations. The loop feeds itself.
Fight for the Developer
My first boss in Developer Relations kept a small pirate flag on his desk. Our job, he'd say, is to fight for the voice of the developer. To be the person inside the company who champions their experience, pushes back when the docs are confusing, and refuses to ship something that makes it hard for a developer to build.
That hasn't changed. If anything, the stakes are higher.
At the core of Developer Relations, now as much as ever, is owning that very first touch. At Twilio we called these magic moments: the instant a developer got something working, felt the product click into place, and fell a little bit in love with what they'd just built. Those moments don't happen by accident. They are the result of teams who obsess over every step of the developer journey, from the first line of a README to the first successful API call.
Agent Relations doesn't replace that mission. It extends it. Developers love to build and create. That's why they became developers. Our job is to inspire those builders, and to enable the agents working alongside them, so that the act of creation is the best possible experience it can be. When we get that right, developers build remarkable things. They share them. The signal travels further than it ever has before, picked up by other developers and by the agents that serve them.
The pirate flag is still on the desk. Developer experience is still the treasure chest we are fighting for. And, I've never been more excited to see where the winds take us.