Field Guides Tagged as "AI"

AI engineering, models, and building AI-powered apps.

← All field guides

The Agentic Playbook

The Agentic Playbook

Everyone agrees you should be building agents. Nobody agrees on how. One camp says drag nodes on a canvas and ship this afternoon. The other says real agents live in code, in your repo, behind your own API. They're both right, and the argument is a distraction: the loop is the same either way. A model, a set of tools, a memory, and a stopping condition. Once you see that, the question stops being "which side is right" and becomes "which lane fits this job." This playbook walks both lanes properly. The first half builds agents in n8n: the AI Agent node, tools it can actually call (including MCP servers), memory and RAG on the canvas, human approval gates, multi-agent patterns, and the Evaluations feature that tells you whether any of it works. The second half builds the same ideas in TypeScript with the Vercel AI SDK inside an Astro site: a streaming chat endpoint, real tool definitions with schemas, the ToolLoopAgent, approval gates in code, structured output, and MCP as the bridge that lets your n8n workflows and your code agents share the same tools. It pairs with [Mastering n8n](/guides/mastering-n8n) (which covers hosting and hardening the platform itself) and [Roll Your Own Coding Agent](/guides/roll-your-own-coding-agent) (which builds the raw loop from nothing), and once you're shipping agents, [QA in the Era of AI](/guides/qa-in-the-era-of-ai) shows what happens when you point them at your test suite. This one is about shipping: picking a lane, building the agent, and knowing when to switch lanes as the job outgrows the canvas. _This is a living document and will be updated as the tools and patterns evolve._

Read guide
QA in the Era of AI

QA in the Era of AI

I've worked at companies with entire QA departments: rooms of people clicking through the same flows before every release, filing tickets, arguing about repro steps. Most of that job is now something you can wire up. Not because testing got less important, but because agents got good at exactly the parts that burned humans out: reviewing every pull request, walking the same three flows every morning, catching the console error nobody looked for, filing the ticket with the screenshot actually attached. This guide is the system for doing that on purpose. It started with [a post about my dialer QA bot](/blog/how-to-use-claude-code-to-qa-your-website), where Claude Code drives a browser through real call flows and files GitHub issues for whatever breaks. Here we build the whole department around that idea: AI code review as the first gate (and the real tradeoffs between the tools), agents that write tests plus the mutation-testing trick that keeps those tests honest, browser agents that smoke-test every preview deploy, visual and accessibility passes, and the loop that turns every failure, from staging or production, into a filed issue that another agent fixes. (And if you want to build agents like these yourself, that craft is [The Agentic Playbook](/guides/the-agentic-playbook); this guide is about putting them to work.) And because I'd rather you trust this thing for the right reasons, we spend real time on where it breaks: agents that pass tests they should fail, self-healing tools that heal around genuine bugs, prompt injection hiding in the very pages your QA agent reads, and the work that still belongs to a human with product judgment. The goal isn't zero humans. It's humans doing the 30% that was always the actual job, with a tireless department underneath them. _This is a living document and will be updated as the tools and patterns evolve._

Read guide
Agent Skills: A Field Guide to the Third Pillar

Agent Skills: A Field Guide to the Third Pillar

Your agent can write code. But does it know how your team cuts a release? Can it run your incident playbook the same way twice, or does it improvise something a little different every time? That gap, between raw capability and a repeatable way of doing one specific job, is exactly what skills fill. A skill is procedural memory you write down once: a packaged, reusable how-to that the agent loads when it's relevant and runs the same way every time. This is the third leg of a trilogy with [Agent Memory](/guides/agent-memory-field-guide) and [The Agent's Self](/guides/agent-self-personality-identity), the three pillars from [Building Your Agentic OS](/guides/building-your-agentic-os). Identity is who the agent is, memory is what it knows, skills are how it does things. We start with what a skill really is, and what it isn't, then build one from a plain folder and a single file. We dig into the two halves of the craft that actually matter: writing a description that makes the agent reach for the skill at the right moment, and writing a body that makes it succeed once it does. We cover progressive disclosure (why the whole skill isn't sitting in context all the time), how to tell a skill apart from a memory or a tool, and how to version and share skills across a fleet without letting them rot. By the end you'll be able to take a capable, general-purpose agent and turn it into a specialist that does your specific jobs your specific way, on demand, every time. _This is a living document and will be updated as the tools and patterns evolve._

Read guide
The Agent's Self: A Field Guide to Personality & Identity

The Agent's Self: A Field Guide to Personality & Identity

Give two people the same agent and the same task and you'll often get two different results. The usual assumption is that the better result came from a better prompt. Just as often, it came from a better-defined _agent_ — one with a stable identity underneath the prompt: a voice it keeps, values it decides by, a role it stays inside. The other person is re-establishing who the agent is supposed to be at the start of every session, and it shows. Identity is the pillar people skip. They pour effort into memory and tools and leave the agent's _self_ to whatever the base model defaults to — which is how you end up with the same bland, hedge-everything, sounds-like-every-other-AI assistant no matter what you bolt onto it. This is a field guide to building the self on purpose: the constitution that anchors it, the voice that makes it recognizable, the values that steer it when the task is ambiguous, and the boundaries that give it a shape at all. We keep it in plain files (legible, versioned, portable), scale it across a fleet where every agent is a distinct citizen with shared values, and — the hard part — evolve a self over time without it drifting into someone else. It's the third leg of a trilogy with [Agent Memory](/guides/agent-memory-field-guide) and the skills pillar, all introduced in [Building Your Agentic OS](/guides/building-your-agentic-os): identity is the _who_, memory is the _what-happened_, skills are the _how_. Get identity right and the agent stops feeling like a tool you operate and starts feeling like someone you work with. _This is a living document and will be updated as the tools and patterns evolve._

Read guide
The 70/30 Engineer

The 70/30 Engineer

The machine does about 70% of the typing now. That part is real, and it's not going back in the box. But the work that's left — guiding the agent, verifying what it produces, and owning the result — is the other 30%, and it turns out that 30% is the entire job. This is a field guide to working that way on purpose: a real, adoptable workflow for coding with agents, built on the AC/DC loop (Guide, Generate, Verify, Solve), grounded in what a year of agentic development actually taught the industry — the wins, the data, and the failure modes nobody likes to talk about. It's for the engineer who wants to be faster without shipping 1.7x more bugs to prove it.

Read guide
Mastering n8n

Mastering n8n

If Directus is the first thing I stand up on a new project, n8n is the second. It's the workflow automation tool I reach for whenever something needs to talk to something else — webhooks, scheduled syncs, API orchestration, and increasingly, AI agents that actually do work instead of just chatting. The pitch is simple: a visual canvas where each node is a step, the data flows down the chain, and you can drop into real JavaScript any time the visual builder runs out of road. Self-host it on a single box, point it at Postgres and Redis, and you've got a durable automation engine you fully own — no per-task pricing, no vendor watching your data go by. This is the guide I'd hand a developer who's tired of gluing services together by hand: how to self-host n8n properly with Docker and queue mode, how the data model and expressions actually work, how to handle errors like you mean it, how to build real AI agents with the LangChain nodes, and how to wire it up to Directus so the two cover each other's weak spots. _This is a living document and will be updated as n8n updates._

Read guide
Running the Fleet: A Field Guide to Multi-Agent Orchestration

Running the Fleet: A Field Guide to Multi-Agent Orchestration

You built one agent that knows you cold — its own personality, a memory that survives, skills it runs your way. It's a great employee. It's also still one employee, doing one thing at a time, waiting on you to hand it the next task. This guide is about the next move: turning that single agent into a coordinated fleet that plans, executes, and monitors real goals while you supervise instead of operate. It's the deep-dive sequel to [Building Your Agentic OS](/guides/building-your-agentic-os) — where that guide ended by pointing at the horizon, this one walks the whole distance. We build it on Hermes, because Hermes already ships the hard parts: profiles (every agent a full citizen with its own identity and memory), a durable kanban board that coordinates them, a decomposer that routes a dropped-in goal to the right specialists, and a way to package a whole agent as a git repo and hand it to your team. Concrete throughout, honest about the sharp edges, and built so the foundation you already laid is exactly what scales up.

Read guide
Building Your Agentic OS: A Field Guide

Building Your Agentic OS: A Field Guide

Two people can use the exact same AI agent and get wildly different results. It's almost never the prompting. One of them built a system underneath the tool — a layer that gives the agent a persistent identity, a real memory, and a set of skills it runs the same way every time — and the other is still re-explaining themselves at the start of every session. This is a field guide to building that system, in three moves. First, the OS itself: a plain-files architecture you can stand up this afternoon on whatever agent you already use, built around three pillars — personality, memory, and skills. Second, the pivot — graduating that static setup onto Hermes, Nous Research's open-source, self-hosted agent, so the files stop being a brief you read aloud and become a teammate that runs on its own. And third, where it's all heading: coordinating many agents to plan, execute, and monitor real goals, with the orchestration, shared memory, and governance that make a true agentic OS. Everything here is portable by design, and you build it one working piece at a time — starting with a single agent that actually knows you.

Read guide
The AI-Era Fractional CTO's Field Guide

The AI-Era Fractional CTO's Field Guide

"Fractional CTO" has become one of those titles that means everything and nothing. If you're a founder, it's often unclear what you're actually buying — a part-time CTO? a fancy consultant? a cheaper hire? And if you're an experienced engineer, it looks like an appealing way out of full-time employment, but with no real map for how to do it well. This guide is for both of you — a straight, advisory look at what the role actually is, when a company needs one, what it costs in 2026, and the AI and agentic-team leadership that increasingly defines the job.

Read guide
The Product Engineer's Guide to AI-Powered Development Workflows

The Product Engineer's Guide to AI-Powered Development Workflows

It's 3 AM, and you're staring at a production issue that's affecting 15% of your users. The error logs are cryptic, the stack trace points to three different microservices, and your team lead is asking for an ETA on the fix. Six months ago, this would have meant hours of debugging, context switching between monitoring tools, and probably a very late night. But tonight is different. You paste the error details into Claude, describe the user impact, and within minutes you have a clear diagnosis: a race condition in your payment processing service triggered by a recent deployment. More importantly, you have a tested fix and a deployment strategy that minimizes risk. What used to be a 4-hour debugging session just became a 20-minute resolution. This isn't science fiction—it's the new reality for product engineers who have learned to work alongside AI. After two decades in this field, building everything from travel platforms to AI automation tools, I've witnessed many technological shifts. But nothing has transformed my daily workflow quite like the AI revolution we're experiencing right now. The difference between traditional developers and product engineers has never been more important. While developers optimize for technical elegance, product engineers think backwards from user needs. We're the bridge between "what's technically possible" and "what actually solves problems." And AI doesn't just make us faster coders—it amplifies our ability to maintain that crucial product context while handling increasing technical complexity. In this guide, you'll discover how to build an AI-enhanced development workflow that spans from initial product discovery to deployment and monitoring. I'll share the specific tools and integrations that have transformed not just my productivity, but my ability to deliver user value faster and more reliably. You'll see real examples from recent projects, learn a framework for evaluating AI tools, and understand how to implement these changes without disrupting your team's existing rhythm. This matters more than ever because we're at an inflection point. Recent data shows that 76% of product leaders expect their AI investment to grow in 2025, and developers using GitHub Copilot report up to 55% productivity improvements without sacrificing code quality. But here's what the statistics don't capture: AI isn't just making us faster—it's making us better product engineers by freeing us to focus on the strategic, creative, and deeply human aspects of building products that people love. The developers who thrive in the next decade won't be those who resist AI or those who blindly adopt every new tool. They'll be the ones who thoughtfully integrate AI as a force multiplier for product thinking, user empathy, and creative problem-solving. If you're ready to become one of them, let's dive in.

Read guide