// Blog

Conversation state and retrieved context lead naturally into memory, but only if we're clear about what memory is for. Rules, skills, and instruction files package what you already know. Memory should capture what the work itself teaches the system, and that means reflection, verification, and forgetting matter just as much as recall.

Context engineering gets more useful when the knowledge it depends on is packaged for reuse. In this post I map the portable core (AGENTS.md and SKILL.md), Copilot-specific concepts like custom instructions, agents and prompt files, and how to decide what knowledge belongs where.

Better prompts help, but they're only part of the story. Context engineering is the craft of designing what an AI agent sees, when it sees it, and how that changes across the session. The goal isn't a bigger context window. It's a more effective one.

There's a pattern I've seen play out across dozens of DevRel conversations, confirmed in my MBA dissertation research: teams without a clear golden thread from company strategy to daily activity get 'randomised' by whoever asks most urgently. Here's what the research says about why it happens and how to build your way out of it.

DevRel is often framed as the voice of the developer. My research suggests a broader job: gathering representative feedback, reducing friction, and showing developers what changed.

Of the 13 DevRel leaders I interviewed for my MBA dissertation, only two could clearly demonstrate a coherent link between tactical activity and organisational strategy. In this post, I talk through how focusing on the developer journey can help bridge that gap.

Academic research on brand communities can help DevRel, but only up to a point. The bigger lesson is where the model breaks: developer communities run on trust in the technology, not loyalty to the brand.

Two companies can have similarly capable DevRel teams doing similar work and still get different results. In my research, company type, lifecycle stage, and technology cycles kept shaping what DevRel could realistically do.

Education. Success. Marketing. Programs. These four pillars describe what Developer Relations teams do. But the more important question is what makes that work credible, useful, and trusted by developers.

Developer Experience isn't just central to DevRel strategy. It's both what your team depends on before it can succeed, and what it actively shapes through its work.