// Content

A static Astro website for a South Wales carpentry and construction business, built with no CMS, database, or client-side framework, and deployed to GitHub Pages on a custom domain.

One model reviewing its own plan tends to agree with itself. So I built a cleanup workflow shaped like a jury: separate critics from a deliberate mix of model families weigh the evidence, with a simple forcing function that keeps neighbouring reviewers off the same family. The orchestrator presides as judge, refuting rather than merging, votes promote shared findings, and a post-approval diff check can overrule a verdict that was unanimous and still wrong.

Building with one agent is familiar. Orchestrating a fleet of them in parallel across local, background, and cloud surfaces is where it gets real. This session covers the decisions that matter, how to decompose work across agents, when to fork vs. delegate, and how to verify quality when agents outnumber you — with patterns for multi-agent workflows you can apply to your own codebase.

An interactive mental model for agentic AI that explains how instructions, retrieved context, session state, memory, MCP servers, sandbox execution, tool results, and the Think-Act-Observe loop fit together.

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.

Start with minimal AGENTS.md and SKILL.md examples, then adapt the portable core alongside Copilot-specific concepts like custom instructions, agents and prompt files. This post explains what belongs where and how to check that the files improve a real agent task.

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.