BytesNation

Agentic Claude Code: How Agents, Hooks, and Orchestration Actually Work

Sun, 03 May 2026 00:00:00 GMT

Most people use Claude Code like a chatbot. Real agentic workflows use specialized agents, an orchestrator that routes without coding, and hooks that guard every dangerous operation. Here is how all of it works and how to configure it yourself.

[Field Notes] Proxmox VE Node Hardening: SSH Lockdown and Non-Root Admin Access

Sun, 26 Apr 2026 00:00:00 GMT

Default Proxmox hands root SSH to anyone who can reach port 22. Three targeted layers close that gap: a non-root admin with sudo, root SSH disabled, and iptables restricting SSH to your bastion only.

[Field Notes] Building a Zero-Trust Homelab with YubiKey PIV

Sat, 25 Apr 2026 00:00:00 GMT

Hardware-backed authentication for your homelab using YubiKey PIV smart cards, a private CA, SSH hardening, digital signing, and a Bastion server. No cloud dependencies. No subscriptions. Full control.

How Do You Know That Download Is Safe? Checksums, GPG, and File Integrity Explained.

Thu, 23 Apr 2026 00:00:00 GMT

Downloading a file and running it is an act of trust. Checksums prove the file wasn't corrupted. GPG signatures prove who sent it. Here is how to verify both, from first principles.

167 Vulnerabilities, One Exploited Zero-Day, and a Secure Boot Clock: Microsoft April 2026 Patch Tuesday

Thu, 16 Apr 2026 00:00:00 GMT

167 Vulnerabilities, One Exploited Zero-Day, and a Secure Boot Clock: Microsoft April 2026 Patch Tuesday

One zero-day is being actively exploited right now. A second was publicly disclosed before Microsoft had a fix ready. A third vulnerability has working exploit code sitting on GitHub. And in 71 days, Secure Boot certificates issued in 2011 expire across every Windows device that has not applied this week’s update.

That is the state of Microsoft’s April 2026 Patch Tuesday, released April 14.

167 vulnerabilities. Eight rated Critical. Two zero-days. One of them landed in CISA’s Known Exploited Vulnerabilities catalog the same day the patches dropped.

This is not a routine monthly update.

What Patch Tuesday Actually Is

Every second Tuesday of the month, Microsoft releases security updates for Windows, Office, SharePoint, Defender, and dozens of other products. It is the primary mechanism through which Microsoft closes vulnerabilities that researchers, its own teams, and sometimes attackers have identified.

Most months, a typical enterprise IT team reviews the list, triages by severity, and schedules deployments. Home users with automatic updates enabled get it in the background without thinking about it.

This month, triage means acknowledging that at least one of these flaws is already being used against real targets. The clock started before the patches dropped.

The SharePoint Zero-Day

CVE-2026-32201 is a spoofing vulnerability in Microsoft SharePoint Server. CVSS score: 6.5. That rating sounds moderate, but the exploitation status changes the calculus entirely.

The flaw stems from improper input validation in SharePoint. An unauthenticated attacker can reach it over the network with no privileges required and no user interaction needed. That is the most dangerous combination on the CVSS attack vector scale. No phishing email. No employee clicking anything. An attacker with network access triggers the flaw and gains the ability to view sensitive information and modify it.

Affected versions are the on-premises deployments: SharePoint Enterprise Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition. Organizations running SharePoint Online through Microsoft 365 are not affected by this CVE. Microsoft patches the cloud version on their side.

For SMBs and organizations that host SharePoint Server on their own infrastructure, this vulnerability is actively being weaponized. Microsoft confirmed exploitation in the wild but has not released attribution, indicators of compromise, or details about the scale of attacks. CISA added CVE-2026-32201 to its Known Exploited Vulnerabilities catalog on April 14, the same day patches were published. Federal agencies have until April 28 to remediate. That 14-day window signals how seriously the vulnerability is being treated.

The information CISA does not release matters here too. The absence of public indicators means your detection capability for active exploitation of this flaw is limited until more telemetry surfaces. Patching eliminates the exposure. Waiting to patch while hoping logs will catch it is not a viable strategy.

The Remote Desktop Spoofing Zero-Day

CVE-2026-26151 is a spoofing vulnerability in Remote Desktop Protocol with a CVSS score of 7.1. It was publicly disclosed before Microsoft had a patch available. The disclosure came from the UK National Cyber Security Centre.

Public disclosure before a patch means every threat actor with access to the NCSC advisory had a description of the flaw and days or weeks to develop exploit capability before a fix existed. Microsoft rates CVE-2026-26151 as “Exploitation More Likely,” which is a specific internal determination that their analysts believe the technical barrier to weaponizing this flaw is low.

RDP spoofing vulnerabilities allow an attacker to intercept or impersonate remote sessions. In an environment where remote work is standard and RDP is the primary access mechanism for thousands of SMBs, a spoofing flaw creates the conditions for credential theft, session hijacking, and lateral movement through an internal network.

This one was patched without known active exploitation confirmed. That window narrows the moment the exploit development community finishes analyzing the diff between the patched and unpatched binaries.

The Defender Flaw with Code on GitHub

CVE-2026-33825 is an elevation of privilege vulnerability in Microsoft Defender. It was publicly disclosed before the patch, and working exploit code was posted to GitHub on April 3. That is eleven days of public exposure before today’s fix.

Elevation of privilege vulnerabilities are rarely standalone attacks. An attacker uses initial access through phishing, an unpatched RCE, or a compromised credential to gain a low-privileged foothold, then runs the EoP to escalate to SYSTEM or Administrator. CVE-2026-33825 is the escalation half of that chain.

The difference between a disclosed EoP with no public exploit and one with code on GitHub is operational. Attackers do not need to develop their own. They copy, compile, and run. That lowers the skill floor for exploitation significantly.

Microsoft Defender is installed on essentially every modern Windows system. The reach of this vulnerability is total.

The New RDP Phishing Protection

Beyond the zero-days, KB5083769 introduces a behavioral change to how Windows handles .rdp files.

When a user opens a Remote Desktop configuration file, Windows now displays all requested connection settings before establishing any connection. Each setting is shown and disabled by default. A one-time security warning fires the first time an .rdp file is opened on a given device.

This matters because .rdp files have become a common phishing payload. Attackers craft configuration files that point the victim’s machine at an attacker-controlled RDP server. When the victim opens the file, their machine connects, presenting credentials that the attacker captures. The session itself may be invisible to the user if the connection parameters are set to minimize the window or redirect input silently.

The previous default behavior allowed .rdp files to connect silently with no user review of the connection parameters. Tax season phishing campaigns documented by Proofpoint in early 2026 included RDP file delivery as one of their payload methods, alongside RMM tools and malware loaders. The new Windows behavior surfaces the connection request and gives the user a chance to reject it.

It does not prevent someone from ignoring the warning. It does eliminate the silent, automatic execution that made .rdp phishing effective.

The Secure Boot Certificate Clock

The April update also begins the migration away from Secure Boot certificates issued in 2011. Those certificates expire on June 26, 2026. That is 71 days from today.

Secure Boot is the firmware-level protection that validates the digital signature of boot-critical components before the operating system loads. It is the primary defense against bootkit malware that installs itself below the OS level and survives full reinstalls.

BlackLotus is the concrete example. It was confirmed active in the wild in 2023 and 2024, capable of bypassing Secure Boot on unpatched systems, persisting through OS reinstallation, and disabling security software before the OS fully initializes. Protecting against BlackLotus requires specific Secure Boot certificate revocations that depend on the updated certificate infrastructure. Once the 2011 certificates expire in June, devices without updated Secure Boot certificates lose that protection layer entirely.

This is not a vulnerability in the traditional sense. It is scheduled expiration of foundational cryptographic infrastructure. The impact is structural: it removes a core layer of boot-level defense across every unpatched Windows device simultaneously on June 26.

A prior patch cycle had introduced a bug where applying the Secure Boot certificate update triggered BitLocker Recovery mode on affected devices, forcing users to enter their BitLocker recovery key on every reboot. That bug is resolved in KB5083769. Devices that avoided the earlier update due to the BitLocker loop can now apply the April patch without that risk.

What to Do Right Now

For home Windows users:

Open Settings and navigate to Windows Update. Install all pending updates now. KB5083769 applies to Windows 11 versions 24H2 and 25H2. Windows 10 has a corresponding update in the same release cycle.
Verify the update installed. Go to Settings, then Windows Update, then Update History. Confirm KB5083769 appears in the list as successfully installed.
Locate your BitLocker recovery key before rebooting after the update. The known bug that caused BitLocker Recovery loops is fixed in this patch, but systems in a partial update state from earlier cycles may still trigger it. Your BitLocker recovery key is stored in your Microsoft account at account.microsoft.com under the Devices section if you connected your device to a Microsoft account. Write it down or save it somewhere accessible from another device before you update.
Expect a new dialog when opening .rdp files. If you use Remote Desktop for work or home lab access and store .rdp configuration files, Windows will now prompt you to review connection settings before connecting. This is intentional. Review what the file is requesting before accepting.

For SMBs running SharePoint Server on-premises:

Patch immediately. CVE-2026-32201 is under active exploitation. Every hour without the patch is exposure. Microsoft has released updates for SharePoint 2016, 2019, and Subscription Edition. Apply them now, not during the next maintenance window.
Pull SharePoint access logs for the past 30 days and look for requests from unfamiliar IP addresses, unusual authentication patterns, or access to documents by accounts that do not normally access them. You may not find indicators, but you need to look.
If your SharePoint Server is reachable from the public internet, evaluate whether that exposure is operationally necessary. Network-layer controls and access restrictions reduce exposure while patching is being staged.
Monitor CISA’s KEV catalog and Microsoft’s Security Response Center for updated indicators as more becomes known about the active exploitation campaign.

For anyone using Remote Desktop:

If you received an .rdp file by email that you were not expecting, do not open it. Verify with the sender through a separate channel before touching the file.
Ensure your system has applied the April update to get the CVE-2026-26151 patch. Home users with automatic updates enabled are covered. Check your update history to confirm.
If you run an RDP server for home lab access or remote work, confirm it is behind a VPN or network-level authentication and not directly exposed to the internet on port 3389. Direct internet exposure of RDP is a persistent attack surface.

The Bigger Picture

April 2026 Patch Tuesday is among the largest in Microsoft’s history by CVE count. The trend line is not favorable. Monthly patch volumes have grown year over year, the proportion of vulnerabilities rated Important or Critical has not declined, and active exploitation at patch release is increasingly the norm rather than the exception.

The gap between patch availability and actual deployment is where attackers operate. For CVE-2026-32201, CISA’s 14-day federal remediation mandate reflects the reality that exploitation is live and the window is short. Organizations that treat Patch Tuesday as a routine two-week cycle are already inside that window.

The Secure Boot certificate expiry is a different kind of pressure. It is not a vulnerability someone discovered. It is scheduled infrastructure failure. The deadline is on the calendar. Devices that do not apply the chain of updates before June 26 lose their boot-level defense against one of the most persistent malware categories known. That outcome is preventable with updates that are already available.

The new RDP file protection is a small change with meaningful impact on a real attack vector that has been in active use. Microsoft making this the default behavior across Windows 11 closes a door that should have been closed earlier.

Patch Tuesday arrives on a schedule. The threats that exploit the gap do not.

Sources:

Operation Masquerade: FBI, NSA, and DOJ Dismantle Russian GRU Router Hijacking Network

Wed, 15 Apr 2026 00:00:00 GMT

Operation Masquerade: FBI, NSA, and DOJ Dismantle GRU Router Hijacking Network

Your home router might have been a Russian intelligence asset. That is not speculation. That is what the FBI, NSA, and Department of Justice confirmed on April 7, 2026, when they announced the court-authorized disruption of a DNS hijacking network operated by Russian military intelligence.

The operation’s name: Masquerade.

The Threat

GRU Unit 26165, the 85th Main Special Service Center (85th GTsSS), ran this campaign. You might know them better as APT28 or Fancy Bear. They are the same group behind the 2016 DNC breach, the SolarWinds campaign follow-on operations, and a long list of espionage operations targeting NATO governments.

This time, they went after something most people never think about: the DNS resolver settings on consumer-grade routers.

How It Worked

The attack chain started with CVE-2023-50224, a remote code execution vulnerability in TP-Link router firmware. The GRU exploited this flaw to gain administrative access to devices without any user interaction. No phishing email. No credential theft. Just a vulnerable router connected to the internet.

Once inside, the operators modified the router’s DNS configuration to point at GRU-controlled resolvers. Every device on that network, laptops, phones, smart home gear, then had its DNS queries routed through Russian intelligence infrastructure.

That enabled an Adversary-in-the-Middle (AiTM) attack chain. The GRU resolvers could redirect traffic to spoofed login pages, intercept authentication tokens, inject malicious payloads into unencrypted connections, and quietly map every device and service on the target network. The compromised router owners had no visible indication anything had changed.

This follows a pattern. In February 2024, a joint cybersecurity advisory warned that Russian state actors were compromising Ubiquiti EdgeRouters for the same purpose: converting consumer networking equipment into espionage infrastructure. Operation Masquerade shows the GRU simply shifted to a different vendor when the first vector got burned.

The Scale

Routers were compromised across 23 U.S. states. The FBI’s Internet Crime Complaint Center published a public service announcement confirming the geographic spread. This was not a targeted strike against defense contractors or government agencies. It was a broad collection operation touching residential and small business networks.

As FBI Cyber Division Assistant Director Brett Leatherman told CyberScoop, the operation represented a shift in Russian cyber tradecraft toward leveraging commodity hardware at scale rather than investing in bespoke implants for high-value targets.

Microsoft threat intelligence confirmed overlap between the infrastructure used in Operation Masquerade and previous APT28 campaigns targeting European government networks, indicating this was one node in a larger global operation.

What Stopped It

The DOJ obtained court authorization in the Eastern District of Pennsylvania to disrupt the network. The operation, executed jointly by the FBI and NSA, neutralized the GRU-controlled DNS infrastructure and severed the command-and-control links to compromised routers.

This is the same legal and operational playbook the FBI used to dismantle the Cyclops Blink botnet in 2022 and the GRU’s Ubiquiti router network in 2024. Court-authorized, technically precise, and focused on cutting the adversary’s access without bricking the devices.

The NSA’s press release emphasized that the disruption was a joint effort across intelligence and law enforcement, reflecting the growing convergence of cyber defense and counterintelligence operations.

What You Should Do

The takedown cut the GRU’s access to the command infrastructure. It did not patch your router. If you have a TP-Link device, assume it needs attention.

Immediate actions:

Check your DNS settings. Log into your router’s admin panel. If the DNS servers are set to anything you did not configure, your device was likely compromised. Reset them to your ISP’s defaults or a trusted resolver (1.1.1.1, 8.8.8.8, 9.9.9.9).
Update firmware. Check TP-Link’s support site for the latest firmware addressing CVE-2023-50224. Apply it now.
Factory reset. If your router was compromised, a firmware update alone may not be sufficient. Factory reset the device, apply the latest firmware, and reconfigure from scratch.
Change credentials. If the default admin password was still in place, that was part of the problem. Set a strong, unique password for the router admin interface.
Disable remote management. Unless you have a specific operational need for remote admin access, turn it off. It is an attack surface you do not need.
Consider replacement. If your TP-Link device is end-of-life and no longer receiving firmware updates, replace it. Running unpatched networking equipment on the internet is not a risk you can manage your way out of.
Report. If you believe your router was compromised, file a report with the FBI’s IC3.

The Bottom Line

Foreign intelligence services are not just targeting Fortune 500 companies and government agencies. They are targeting the $40 router sitting on your desk. The device you set up once and forgot about is exactly the kind of infrastructure a nation-state operator loves: always on, rarely monitored, broadly trusted by every device behind it.

Operation Masquerade is a reminder that network security starts at the edge. Your router is your perimeter. Treat it like one.

Sources:

Stanford Just Dropped AI's Report Card. The Numbers Do Not Care About Your Feelings.

Tue, 14 Apr 2026 00:00:00 GMT

Stanford Just Dropped AI’s Report Card. The Numbers Do Not Care About Your Feelings.

Stanford HAI publishes the AI Index every year. It is the closest thing the industry has to an objective, data-backed SITREP on where AI actually stands. Not the VC pitch. Not the Twitter hype cycle. The data.

The 2026 report dropped today. 300+ pages of charts, benchmarks, economic data, policy analysis. You are not going to read it. Here is what matters.

Models Are Outrunning Everything

SWE-bench Verified, the software engineering benchmark, jumped from 60% top scores in 2024 to nearly 100% in 2025. AI agents handling real-world tasks went from a 20% success rate to 77.3%. Cybersecurity agents hit 93% problem resolution, up from 15% in 2024.

Frontier models now match or exceed human experts on PhD-level science, competition math, and multimodal reasoning.

Sounds like a clean win. It is not.

The Benchmarks Are Broken

The tests measuring AI progress are failing. A widely used math benchmark has a 42% error rate in its own questions. Models trained on benchmark data game the scores without getting smarter. Strong benchmark numbers do not translate to real-world performance. For AI agents and robotics, reliable benchmarks barely exist.

The Foundation Model Transparency Index dropped from 58 to 40. Companies are disclosing less about training data, parameter counts, and safety evaluations. The most powerful models are the ones we know the least about.

That is not a measurement problem. That is an operational risk.

US and China: Razor Thin Margins

The geopolitical race is tighter than the headlines suggest. Anthropic leads the Arena leaderboard as of March 2026. xAI, Google, OpenAI trail close. DeepSeek and Alibaba lag by single digits. In February 2025, DeepSeek R1 briefly matched the top US model.

The US has 5,427 data centers. 10x more than any other country. China leads in research publications, patents, and industrial robotics. Different playbooks, same objective.

The talent pipeline is a problem. AI researcher migration to the US dropped 89% since 2017. Down 80% in the last year alone. The US is still building the best models but the bench is getting thin.

The Power Bill

29.6 gigawatts. That is what AI data centers draw globally. Enough to run the entire state of New York at peak demand.

GPT-4o annual water consumption exceeds the drinking water needs of 12 million people. Training Grok 4 produced 72,816 tons of CO2. Equivalent to 17,000 cars running for a year.

This is not a side effect. This is the cost of operations. Every model improvement requires more compute, more power, more cooling, more physical infrastructure.

Global corporate AI investment hit $581.7 billion in 2025. Up 130%. Private investment: $344.7 billion. The US alone: $285.9 billion, 23x China’s reported private spend. The World Economic Forum puts the total hardware buildout at $7 trillion.

One company in Taiwan fabricates almost every leading AI chip. TSMC. That is a single point of failure for the entire global AI supply chain. One geopolitical incident and the whole stack is compromised.

The Job Market Is Already Moving

Employment for software developers aged 22 to 25 is down nearly 20% since 2022. Older developer hiring is still growing. Same pattern in customer support and other high-AI-exposure roles.

Productivity gains: 26% in software development, 14% in customer service. A third of organizations surveyed by McKinsey plan to cut headcount this year. Deepest cuts: service operations and software engineering.

53% of the global population adopted generative AI within three years. Faster than the PC. Faster than the internet. 88% of organizations are running it. 80% of university students use it.

Entry-level roles built on repetitive, well-documented tasks are getting compressed first. That is not a prediction. That is the current trendline.

Operational Takeaways

Early career: The 20% drop is real. It is concentrated in pure-execution roles. The antidote: understand systems, not syntax. Judgment over keystrokes. Learn to deploy and evaluate AI, not just use it.

Mid-career tech: Your domain knowledge is the moat. AI handles implementation. You handle architecture, business translation, and institutional context. That is not automatable.

Security:

AI agents solving 93% of cybersecurity problems means the defensive side is automating. So is the offensive side. CrowdStrike’s 2026 threat report shows 89% year-over-year increase in AI-enabled attacks. Average eCrime breakout time: 29 minutes. Both sides of this arms race are accelerating.

Infrastructure: 29.6 GW and climbing. Water, power, cooling, supply chain resilience. The bottleneck is physical, not digital. Datacenter architecture, power engineering, network operations, cooling systems. If you have those skills, your value just went up.

The AI Index does not tell you what to think. It tells you what is happening. Act accordingly.

Sources

10 Tools. One Brain. The Stack That Actually Builds Things.

Mon, 13 Apr 2026 00:00:00 GMT

10 Tools. One Brain. The Stack That Actually Builds Things.

You have forty tabs open. Three AI chats going. A notes app you stopped trusting two weeks ago. A folder called “research” that is actually a graveyard. You ask an AI a question, get an answer, close the tab. Tomorrow you ask the same question because nothing persisted. Nothing connected. Nothing compounded.

That is not a workflow. That is a fancy search engine with amnesia.

The people actually shipping things are not smarter than you. They are not using secret tools. They wired their tools together. Their AI does not answer questions and vanish. It reads context, calls other tools, writes outputs that feed the next step, and remembers what happened yesterday.

AI is not the destination. It is the nervous system. The tools are the organs. And the whole thing is useless until it is connected.

The Foundation

Before any of this matters, you need a place where what you learn stops disappearing.

Obsidian is that place. Not because it is the best note-taking app. Because it is plain markdown files on your machine. Nothing proprietary. No subscription required to access your own thoughts. No company between you and your data.

Your vault is your external memory. Every note, every research output, every AI conversation worth keeping lives there. You organize it your way. You search it your way. It is yours.

But here is where it gets real. Obsidian has a Model Context Protocol server. That means your AI can read your vault, search it, and write to it directly. The moment you connect that, Obsidian stops being a notes app and becomes a living knowledge base. Your AI has memory that persists between sessions, grounded in your actual work, not some cloud-hosted summary it generated about itself.

Start here. Everything else plugs into this.

The Nervous System

Claude Code is the orchestration layer. It does not answer questions and wait for the next one. It reads your vault through MCP. It calls external tools as servers. It writes code, executes it, handles errors, and chains outputs across the entire stack.

Think of it as the central nervous system. Obsidian is the memory. The tools below are the limbs. Claude Code is the thing that coordinates all of them, decides what to call, when, and what to do with the result.

Nothing else in this list runs without it. Every tool below connects to Claude Code as an MCP server or gets called directly from the terminal. One orchestrator. Ten capabilities. One brain.

The Stack

You do not need to learn these in order. You do not need all of them. Each one exists because a specific friction point demanded a solution.

The web is your richest data source, and copy-pasting is killing you.

You need clean, structured content from websites, and you need it fast. Firecrawl turns entire sites into LLM-ready markdown in one API call. JavaScript-heavy pages, dynamic content, nested links. It handles all of it and returns clean structured output your agent can actually use. It runs as an MCP server directly inside Claude Code. Point it at a URL. Get back usable data. No scraping scripts, no BeautifulSoup, no regex nightmares.

Then you hit a login wall.

Firecrawl handles public pages. But the moment authentication is required, a form needs filling, or you need to interact with a live application, you need a browser that can act. Playwright is Microsoft’s browser automation library. It drives real browser sessions: clicking, typing, navigating, waiting for elements. When Firecrawl cannot reach something because it is behind a login, Playwright walks through the door.

You collected everything. Now it is a mess of PDFs, charts, tables, and diagrams.

Standard retrieval pipelines choke on anything that is not clean text. Charts get ignored. Tables get mangled. Diagrams disappear. RAG-Anything from HKUDS processes text, images, tables, and equations together in one pipeline. Your AI understands the whole document, not the 60% of it that happened to be paragraphs.

You need to write code, scaffold projects, and stop babysitting the terminal.

Codex CLI from OpenAI runs locally on your machine. Built in Rust. Reads and modifies files in your working directory. It is not a chatbot that generates snippets you paste somewhere. It is an agent that operates on your actual codebase. Pair it alongside Claude Code when you want two agents running in parallel on different parts of a project. One writes the backend. The other writes the tests. You review.

You want research loops that run overnight without you.

You describe what good looks like. The metrics, the evaluation criteria, the goal. Autoresearch from Karpathy runs propose-train-evaluate cycles, keeping only changes that improve the target metric, and loops without human intervention. You go to sleep. It keeps working. You wake up to results, not prompts asking what to do next.

You have raw research dumps and zero desire to read every word.

You spent the day collecting. Now there are twenty documents in your vault you need to absorb. NotebookLM from Google takes your Obsidian outputs and generates briefings, summaries, and audio overviews. The Audio Overview feature turns a stack of research into a listenable briefing you can absorb on a walk, on a drive, wherever you are not staring at a screen.

Your AI generates code that looks like a programmer made it, not a designer.

Every AI-generated UI looks the same. Generic spacing. Default everything. No personality. awesome-design-md is a plain-text DESIGN.md file that AI agents read to generate consistent, branded interfaces. No Figma exports, no JSON schemas, no special tooling. Drop it in your project root. Claude Code reads it and builds to your design spec, not its own defaults.

Your outputs are stuck in a local folder nobody sees.

The pipeline produces results. Reports sit in a directory. Summaries live in your vault. Nobody else can see them. Google Workspace CLI pushes reports to Drive, sends summaries via Gmail, populates spreadsheets. It closes the last mile between “done” and “delivered.”

The Full Loop

Here is what this looks like when it is all wired together.

You are running competitive intelligence on three companies entering your market. One prompt to Claude Code: “Research these three companies. Build a comparison report. Drop it in the vault.”

Claude Code calls Firecrawl to ingest the companies’ public web presence. One of them has pricing behind a login wall. Playwright opens a browser session, authenticates, and pulls the gated content. Everything lands in your vault as clean markdown.

The sources include investor decks with charts and a product comparison table buried in a PDF. RAG-Anything indexes all of it, charts, tables, and text, into a retrieval layer that actually understands the full picture.

Claude Code synthesizes the findings. It reads the existing notes in your vault for context on your own positioning. It writes a structured competitive analysis and drops it into Obsidian with proper tags and backlinks.

You feed that report to NotebookLM. It generates an audio briefing you listen to on your morning walk. While you walk, Codex CLI is scaffolding a dashboard to track these competitors over time. Autoresearch is running overnight loops to refine the retrieval pipeline itself, optimizing the system that produced today’s report for tomorrow’s run.

The final report hits Google Drive via GWS CLI. A summary lands in your inbox. Your team has it before you finish your coffee.

One brain. Ten organs. One prompt started it.

Start Somewhere

Nobody needs all ten of these on day one. That is the trap. You see a stack like this and think you need to learn everything before you can build anything.

Wrong.

You start with Obsidian. You build one habit: capture what you learn in markdown. That is it. You do that for a week.

Then you notice the friction. Maybe it is manual web research. So you add Firecrawl. Maybe it is losing AI conversations. So you wire up Claude Code to your vault. Maybe it is drowning in documents. So you point NotebookLM at your output folder.

The stack reveals itself as you grow into it. Each tool earns its place by solving a problem you actually have, not a problem someone told you to worry about.

The goal was never ten tools. The goal was to stop being passive. Stop consuming and start building. Stop asking AI one-off questions and start wiring it into a system that compounds.

Start somewhere. The rest follows.

Stay wired.

Your Homelab Has a Brain Now. Here Is How to Wire It.

Sun, 12 Apr 2026 00:00:00 GMT

Your Homelab Has a Brain Now. Here Is How to Wire It.

Every conversation with your AI starts from zero. You paste context. You re-explain your project. You copy notes in like it is 2023 and you are feeding a search bar. Meanwhile, you have a vault full of notes, a lab full of hardware, and an automation stack collecting dust. There is a better way.

What if Claude could read your entire Obsidian vault? Search it. Write to it. And your automation layer could trigger workflows based on what it finds. All on your hardware. Zero subscriptions.

That is what we are building.

The Stack

Four layers. Each one does one thing.

Proxmox: the infrastructure. Runs everything on your hardware.
n8n: the automation. Lives in an LXC container on Proxmox. Handles triggers, webhooks, workflows.
Obsidian MCP Server: the knowledge layer. Exposes your vault to Claude over the Model Context Protocol.
Claude via MCP: the intelligence. Connects to your vault, reads your notes, acts on what it finds.

graph TD
    A["Claude (MCP Host)"] -->|"JSON-RPC 2.0"| B["MCP Client"]
    B -->|"STDIO"| C["Obsidian MCP Server"]
    C -->|"REST API"| D["Obsidian Vault"]
    E["n8n (LXC)"] -->|"Proxmox API"| F["Proxmox VE"]
    E -->|"Webhooks / Triggers"| C
    E -->|"API Calls"| A

The result: an AI that knows everything you have ever written, running on your own iron, talking to your automation stack, costing you nothing per month.

How It Actually Works

MCP stands for Model Context Protocol. It is an open standard that lets AI applications connect to external data sources through a clean client-server architecture. Think of it like a USB port for AI. The AI does not need to know how your data is stored. It just needs a server that speaks the protocol.

The architecture has four participants. The Host is the AI application (Claude Desktop or Claude Code). Inside the host lives the Client, which manages the actual connection. The Server is the program that exposes your data (in this case, your Obsidian vault via the Local REST API plugin). Communication between client and server happens over STDIO (standard input/output) for local setups, using JSON-RPC 2.0 messages. The host decides what Claude can access. The server just makes things available.

Here is the real config. This goes in your Claude Desktop config file:

Mac: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "mcp-obsidian": {
      "command": "uvx",
      "args": ["mcp-obsidian"],
      "env": {
        "OBSIDIAN_API_KEY": "<your_api_key_here>",
        "OBSIDIAN_HOST": "localhost",
        "OBSIDIAN_PORT": "27124"
      }
    }
  }
}

command tells Claude how to launch the server. uvx runs it directly from PyPI without installing globally. args is the package name. env passes your Obsidian Local REST API credentials. The API key comes from the plugin settings inside Obsidian. Port 27124 is the default.

When Claude needs a note, here is what actually happens:

sequenceDiagram
    participant C as Claude
    participant MC as MCP Client
    participant MS as MCP Server
    participant V as Vault

    C->>MC: 1. tools/call
    MC->>MS: 2. JSON-RPC request (stdin)
    MS->>V: 3. GET /vault/note (REST API)
    V-->>MS: 4. Note content
    MS-->>MC: 5. JSON-RPC response (stdout)
    MC-->>C: 6. Tool result

Claude issues a tools/call request. The MCP client serializes it as a JSON-RPC 2.0 message and writes it to the server’s stdin. The server hits the Obsidian REST API, gets the note content, and writes the response back to stdout. Claude now has your note. The whole round trip happens locally. No cloud. No latency worth measuring.

Why Your Homelab Is the Right Place for This

You own the data. Your notes never leave your network. No cloud sync shipping your vault to someone else’s servers. No training data contribution you did not consent to. Your knowledge stays on your hardware, behind your firewall. Full stop.

Zero subscription cost. Proxmox is free. Self-hosted n8n is free. Obsidian is free. The MCP server is open source. The only thing you are paying for is the Claude subscription you already have (or API credits if you are running headless). Compare that to cobbling together three SaaS tools at $20/month each to get half the capability.

The lab becomes intelligent. This is the part most people miss. Once n8n can talk to Claude and Claude can talk to your vault, you are not just searching notes anymore. You are building workflows that reason over your knowledge base. n8n triggers a workflow, Claude reads your vault for context, makes a decision, writes the result back. That is a different category of automation than “if this then that.”

What You Can Build With This

Stop thinking about this as a note-reading trick. Think about what becomes possible when your AI has memory and your automation stack has intelligence.

Morning briefing from your daily notes. n8n fires at 6 AM, tells Claude to read yesterday’s daily note and your task board, generates a prioritized summary of what carried over and what is due. Written back to today’s note before you pour coffee.
Auto-tagging based on vault context. New note lands in your inbox. Claude reads it, compares it against your existing tag taxonomy and MOC structure, applies tags and links it to related notes. Your vault organizes itself.
Proxmox alerts summarized and logged. n8n watches your Proxmox API for resource alerts. When a container spikes CPU or a disk fills up, Claude gets the alert, pulls recent related notes from your infra log, writes a contextualized incident note with recommended actions.
Research pipelines triggered by webhook. You find an article worth reading. Hit a webhook from your phone. n8n sends the URL to Claude, which reads it, extracts key points, cross-references your vault for related notes, and writes a literature note with backlinks already in place.
Weekly review automation. Every Sunday, Claude scans your completed tasks, meeting notes, and daily logs for the week. Generates a review draft: what shipped, what slipped, what patterns are emerging. You edit and publish. Ten minutes instead of an hour.

The pattern is the same every time: trigger, context from vault, intelligence from Claude, output back to vault or another system. Once you see it, you cannot unsee it.

Where to Start

Step 1: Get Proxmox running. If you do not have a hypervisor yet, install Proxmox VE on any spare hardware. Old desktop, mini PC, rack server. It does not matter. Proxmox is free and it is what the rest of the stack runs on.

Step 2: Deploy n8n in an LXC container. Spin up a lightweight Debian LXC on Proxmox and install n8n. It runs on Node.js, pulls minimal resources, and gives you a visual workflow builder with access to the Proxmox API, webhooks, schedules, and hundreds of integrations.

Step 3: Wire up the MCP server. Install the Obsidian Local REST API community plugin in your vault. Enable it, copy the API key. Add the config block above to your Claude Desktop config. Restart Claude. Ask it to search your vault. Watch it work.

That is the path. Three steps to a homelab that thinks.

The Close

Your notes are not just files. Your lab is not just hardware. And your AI should not be starting from scratch every time you open a chat window.

Wire these pieces together and you have something most people do not even know is possible yet: a personal AI that knows your entire knowledge base, runs on your own infrastructure, and costs you nothing beyond what you are already paying. No vendor lock-in. No data leaving your network. Just your brain, extended.

Next post: the full n8n + Claude + Proxmox automation deep dive. We are going to build the actual workflows. The morning briefing. The auto-tagger. The whole damn thing.

Stay wired.

Sources

Model Context Protocol Specification (official docs)
mcp-obsidian (PyPI)
Obsidian Local REST API Plugin
Proxmox VE
n8n

Prompt Engineering Is Not Magic. It Is Instruction Writing.

Sat, 11 Apr 2026 00:00:00 GMT

You Know How the Engine Works. Now Learn to Drive.

The last post broke down tokens, context windows, attention, and sampling. You know the internals. That knowledge is useless if you keep writing prompts like you are texting a friend.

Prompt engineering is not a creative skill. It is not vibes. It is instruction writing. The same discipline that goes into a military operations order, a network configuration template, or an API specification. Precise. Structured. Unambiguous.

The model does exactly what you tell it to do. When the output is garbage, the input was garbage. Full stop.

Everything in this post is sourced from the official documentation of the three major AI platforms: Anthropic’s Claude prompting best practices, OpenAI’s GPT-5 prompting guide, and Google’s Gemini prompt design strategies. Not blog opinions. Not Twitter threads. Primary sources from the people who built the models.

The Five Principles

Before the techniques. Before the examples. Internalize these.

Be explicit. The model cannot read your mind. If you did not say it, it does not exist.
Be structured. Prose instructions produce prose-quality compliance. Structured inputs produce structured outputs.
Be specific about format. Tell it what the output looks like. JSON, bullet points, a table, a single word. If you leave format open, you get whatever the training data averaged out to.
Constrain the scope. Every degree of freedom you leave open is a degree of freedom the model fills with its best guess. Best guesses are not good enough.
Provide examples. One concrete example communicates more than five paragraphs of description.

These principles are universal. Anthropic’s documentation puts it this way: “Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.” (Source)

Google’s Gemini 3 guide says the same thing differently: “State your goal clearly and concisely. Avoid unnecessary or overly persuasive language.” (Source)

OpenAI’s GPT-5 guide warns that contradictory instructions force the model to waste reasoning tokens reconciling conflicts instead of solving your actual problem. (Source)

Same conclusion from three independent engineering teams. Clarity wins.

Technique 1: Role and Context Assignment

Tell the model who it is before you tell it what to do. This is not roleplay. It is context loading. A role activates relevant patterns from training data and suppresses irrelevant ones.

Anthropic’s documentation confirms this: “Setting a role in the system prompt focuses Claude’s behavior and tone for your use case. Even a single sentence makes a difference.” (Source)

Google’s Gemini 3 guide adds a critical caveat: assign personas explicitly, but review them carefully because the model “prioritizes maintaining persona adherence even over other instructions.” (Source)

Weak prompt:

What ports should I open on my firewall?

You will get a generic list. Every default port for every common service. Useless.

Strong prompt:

You are a senior network security engineer conducting a firewall
audit for a PCI-DSS compliant e-commerce environment running
Kubernetes on AWS. The environment serves HTTPS traffic through
an ALB, uses RDS PostgreSQL for the backend database, and runs
Redis for session caching.

List only the ports that must be open on the VPC security groups,
grouped by tier (public, application, data). For each port,
specify the protocol, source CIDR restriction, and justification.
Flag any port that introduces PCI-DSS compliance risk.

Same question. Completely different output. The role and context eliminated 90% of the noise before the model generated a single token.

Why it works: Remember attention from the last post. The model weighs every token against every other token. When you load the context with “PCI-DSS,” “Kubernetes,” and “AWS,” the attention mechanism amplifies patterns associated with those domains. Without that context, it distributes attention across everything it knows about firewalls, including home routers and gaming setups.

Anthropic also recommends providing the motivation behind your instructions. Instead of saying “NEVER use ellipses,” explain: “Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them.” Claude generalizes from the explanation. (Source)

Technique 2: Few-Shot Examples

The model learns patterns from examples faster than it learns from descriptions. This is called few-shot prompting. You provide input/output pairs, and the model extrapolates the pattern.

Anthropic recommends 3 to 5 examples for best results and advises wrapping them in <example> tags so the model can distinguish examples from instructions. (Source)

Google’s Gemini documentation recommends 2 to 5 varied examples and warns against providing too many, which can cause overfitting where the model mimics examples too literally instead of generalizing the pattern. (Source)

Task: Extract structured data from unstructured network alerts.

Prompt:

Extract structured incident data from network alerts.

<example>
Input:
"Critical alert: Unauthorized SSH login attempt detected on
10.0.3.47 from external IP 203.0.113.42 at 14:32 UTC.
5 failed attempts in 60 seconds. Account: root."

Output:
{
  "severity": "critical",
  "event_type": "brute_force_attempt",
  "target_host": "10.0.3.47",
  "source_ip": "203.0.113.42",
  "protocol": "SSH",
  "timestamp": "14:32 UTC",
  "attempt_count": 5,
  "window_seconds": 60,
  "target_account": "root",
  "recommended_action": "Block source IP, force password
    reset on target account, review auth logs for lateral
    movement"
}
</example>

Now extract from this alert:
"Warning: DNS exfiltration pattern detected. Host 10.0.1.15
made 847 TXT record queries to suspicious domain
x4k9.badactor.net over 300 seconds starting at 09:17 UTC.
Average query length exceeds normal baseline by 340%."

One example. The model now knows the exact schema, the field names, the value formats, and that you want a recommended_action field with operational guidance. One example replaced an entire specification document.

The rule: One strong example beats three paragraphs of description. Two examples nail edge cases. Three to five is the sweet spot for consistent patterns. Beyond that, you are wasting tokens and risking overfitting.

Technique 3: Structured Formatting with Tags

All three major platforms agree on this: structure your prompts with clear delimiters. The specific format varies, but the principle is universal.

Anthropic recommends XML tags and has specifically trained Claude to parse them. Tags like <instructions>, <context>, and <examples> reduce misinterpretation. (Source)

OpenAI recommends <instruction_spec> tags for organizing complex requirements, allowing clear internal referencing across prompt sections. (Source)

Google recommends XML-style tags or Markdown headings, advising you to choose one format and use it consistently within a single prompt. (Source)

Example: Multi-section prompt with XML structure

<role>
You are a senior infrastructure engineer reviewing Kubernetes
deployment manifests for production readiness. You follow the
CIS Kubernetes Benchmark v1.8.
</role>

<standards>
- All containers must run as non-root (runAsNonRoot: true)
- Resource limits are mandatory (no unbounded containers)
- Image tags must be SHA digests, not :latest
- Liveness and readiness probes required on all containers
- No hostNetwork, hostPID, or hostIPC unless approved
</standards>

<output_format>
For each violation, return a JSON object:
{
  "field": "<YAML path>",
  "violation": "<which standard>",
  "severity": "critical | warning",
  "fix": "<exact YAML to replace it with>"
}
Return a JSON array. No commentary. No markdown fences.
</output_format>

<input>
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: gateway
        image: company/api-gateway:latest
        ports:
        - containerPort: 8080
</input>

Every section has a purpose. The model knows exactly where the role ends and the standards begin. No ambiguity. No guessing.

Technique 4: Chain of Thought

When you need the model to reason through a problem, tell it to show its work. This forces the model to activate its reasoning pathways before committing to an answer.

Anthropic’s documentation notes that for Claude 4.6, “a prompt like ‘think thoroughly’ often produces better reasoning than a hand-written step-by-step plan. Claude’s reasoning frequently exceeds what a human would prescribe.” They also recommend asking Claude to self-check: “Before you finish, verify your answer against [test criteria].” (Source)

Google’s Gemini 3 guide takes a different approach, recommending split-step verification: first verify that information exists before generating answers. This prevents “plausible-sounding but incorrect outputs.” (Source)

Without chain of thought:

Is this subnet configuration valid?
10.0.1.0/24 with gateway 10.0.2.1

The model might say “yes” or “no” with no way to verify if it actually evaluated the configuration.

With chain of thought:

Evaluate this subnet configuration step by step.
Show your reasoning for each check before the final verdict.

Configuration:
- Subnet: 10.0.1.0/24
- Gateway: 10.0.2.1

Check:
1. Is the gateway IP within the subnet range?
2. Is the subnet mask valid for the stated network?
3. Are there any RFC violations?
4. What is the usable host range?

After all checks, state VALID or INVALID with justification.

Output:

1. Subnet range: 10.0.1.0 to 10.0.1.255. Gateway 10.0.2.1
   is NOT within this range. The gateway must reside within
   the subnet or be reachable via a connected interface.

2. /24 (255.255.255.0) is valid for 10.0.1.0.

3. No RFC violations on the subnet itself, but gateway
   placement violates standard Layer 3 design.

4. Usable range: 10.0.1.1 to 10.0.1.254 (254 hosts).

INVALID. Gateway 10.0.2.1 is outside 10.0.1.0/24.
Correct to 10.0.1.1 or re-architect the routing.

The step-by-step requirement forced the model to evaluate each condition instead of guessing at the aggregate. This is the difference between a tech who checks every cable and one who says “looks fine” from across the room.

Technique 5: Output Constraints

If you do not define the output format, the model picks one. It will be verbose, inconsistent, and different every time. Lock it down.

OpenAI’s GPT-5 guide introduces a dual verbosity strategy: set a low verbosity parameter globally while requesting high verbosity only for specific contexts like code output. This keeps status updates concise while maintaining readable code. (Source)

Google’s Gemini 3 documentation notes that Gemini 3 models default to concise, direct answers. If you need more detail, you must explicitly request it. (Source)

Anthropic recommends telling Claude what to do instead of what not to do. Instead of “Do not use markdown in your response,” try “Your response should be composed of smoothly flowing prose paragraphs.” (Source)

Unconstrained:

Analyze this log entry for security issues.

You get a three-paragraph essay. Sometimes bullets. Sometimes narrative. Never consistent.

Constrained:

Analyze the log entry below. Respond with ONLY a JSON object.
No markdown fences. No explanation text.

{
  "log_line": "<original log entry>",
  "classification": "benign | suspicious | malicious",
  "confidence": <float 0.0-1.0>,
  "indicators": ["<specific indicators found>"],
  "mitre_technique": "<ATT&CK technique ID or null>",
  "recommended_action": "<one sentence>"
}

Log entry:
POST /wp-login.php HTTP/1.1 from 198.51.100.23 - 47 requests
in 12 seconds - all returned 401 - User-Agent: python-requests/2.28

Machine-parseable output. Every time. Same schema. Same fields. You can pipe this into a SIEM, a database, or a downstream automation. That is the difference between a tool and a toy.

Technique 6: Context Placement

Where you put information in your prompt matters as much as what you put in it. This is the practical application of the lost-in-the-middle problem covered in the last post.

Anthropic is explicit: “Put longform data at the top. Place your long documents and inputs near the top of your prompt, above your query, instructions, and examples. Queries at the end can improve response quality by up to 30% in tests, especially with complex, multi-document inputs.” (Source)

Google’s Gemini 3 guide mirrors this: “Place specific questions after large context blocks and anchor reasoning with phrases like ‘Based on the information above.’” It also advises placing critical restrictions at the end of the prompt to prevent the model from dropping them. (Source)

The placement rule:

[LONG REFERENCE DOCUMENTS / DATA]

[YOUR SPECIFIC QUESTION OR TASK]

[CRITICAL CONSTRAINTS AND FORMAT REQUIREMENTS]

Data first. Task second. Constraints last. The model attends most strongly to the beginning (your reference material) and the end (your constraints). Your task sits in between, anchored by both.

For multi-document prompts, Anthropic recommends wrapping each document in indexed tags:

<documents>
  <document index="1">
    <source>firewall_rules_prod.csv</source>
    <document_content>
      ... rule data ...
    </document_content>
  </document>
  <document index="2">
    <source>incident_report_2026-04.pdf</source>
    <document_content>
      ... report content ...
    </document_content>
  </document>
</documents>

Based on the documents above, identify any firewall rules
that would have permitted the attack vector described in
the incident report. Output as a table with columns:
Rule ID, Source, Destination, Port, Risk Assessment.

Technique 7: Negative Constraints

Telling the model what NOT to do is as important as telling it what to do. Models have strong defaults from training. If those defaults conflict with what you need, override them explicitly.

Anthropic’s documentation includes a detailed prompt template for suppressing common unwanted behaviors like excessive markdown, bullet points, and bold/italic formatting. (Source)

Google specifically warns against broad negative instructions like “do not infer.” Instead, specify what the model should use for reasoning. (Source)

Common defaults to suppress:

Do not include introductory text like "Sure!" or
"Here is the analysis."

Do not wrap code in markdown fences unless asked.

Do not add disclaimers about limitations.

Do not explain reasoning unless asked. Output the result.

Do not use placeholder values. If data is missing,
output null.

Real-world example: Generating Terraform configurations.

Generate a Terraform resource block for an AWS security group
allowing inbound HTTPS (443) from 0.0.0.0/0 and SSH (22)
from 10.0.0.0/8 only.

Output ONLY the resource block.
- No provider block
- No variable declarations
- No comments
- No egress rules
- No tags
- Resource name: "web_server_sg"

Without those constraints, the model produces a complete Terraform file with provider config, variables, outputs, inline comments, and invented tags. All of which you strip out. Save the tokens. Save the time.

One prompt rarely produces a perfect result. Plan for iteration, but do it systematically.

OpenAI’s GPT-5 guide introduces the concept of metaprompting: ask the model itself “what phrases could be added or deleted from this prompt to elicit desired behavior.” Use the model to improve the prompt that drives it. (Source)

Google frames prompt engineering explicitly as “a test-driven and iterative process” and recommends rephrasing requests multiple ways, switching to analogous tasks, and reordering prompt content to test impact. (Source)

Round 1: Get the structure right.

Draft a network diagram description for a three-tier web
application on AWS. Output as a structured list, not prose.
Include VPC layout, subnet tiers, and security group
boundaries.

Round 2: Add precision.

Good structure. Now add:
- Specific CIDR blocks (10.0.0.0/16 VPC)
- NAT gateway placement
- Which tier gets public IPs
- Cross-AZ redundancy notation

Round 3: Pressure test.

Review this architecture for single points of failure.
For each one, propose a mitigation and rate cost impact
as low/medium/high.

Round 4: Use metaprompting.

Review the prompt I used to generate this architecture.
What instructions could I add or remove to get a more
production-ready result on the first pass?

Each round builds on the last. You are not starting over. You are narrowing. And in round 4, you are using the model to improve your own process.

The Anti-Patterns

These waste time and tokens. Stop doing them.

Vague delegation. “Make this better” is not an instruction. Better how? Faster? More secure? More readable? If you cannot articulate what “better” means, you do not know what you want. The model cannot fix that.

Prompt stuffing. Dumping 50 pages of documentation and saying “analyze this” guarantees the model will miss the parts that matter. Remember the lost-in-the-middle problem. Curate your context.

Politeness tokens. “Could you please kindly help me with” burns tokens and adds zero signal. The model processes instructions. Give it instructions.

Ambiguous references. “Update it to use the new format” after a long conversation. What is “it”? What is “the new format”? Name the file. Specify the format. The model will not ask for clarification. It will guess.

Over-prompting for modern models. Both Anthropic and OpenAI warn about this. Instructions that were necessary for older models (“CRITICAL: You MUST use this tool”) will cause current models to overtrigger. Anthropic’s guidance: “Where you might have said ‘CRITICAL: You MUST use this tool when…’, you can use more normal prompting like ‘Use this tool when…’” OpenAI’s guidance: soften thoroughness instructions because “GPT-5 is already naturally introspective about context gathering.” (Sources, OpenAI)

Platform-Specific Tips

Claude (Anthropic)

XML tags are first-class. Claude is specifically trained to parse XML structure. Use <context>, <instructions>, <examples> to delineate sections.
3 to 5 examples is the recommended range for few-shot prompting.
Long documents go at the top of the prompt, queries at the bottom. This improves response quality up to 30%.
Ground responses in quotes. For long document tasks, ask Claude to quote relevant parts before answering. This cuts through noise.
CLAUDE.md files for Claude Code users provide persistent instructions that load every session without burning tokens on repeated prompts.

GPT-5 (OpenAI)

Metaprompting. Ask GPT-5 to review and improve your prompt. It will suggest phrases to add or remove.
Reasoning effort parameter. Adjust reasoning_effort (low/medium/high) to control how much the model explores before answering.
Persistence framing. Use “keep going until the user’s query is completely resolved” to prevent premature task termination.
Self-reflection rubrics. For complex generation tasks, have the model create a 5 to 7 category excellence rubric internally, then iterate against it.

Gemini 3 (Google)

Keep temperature at 1.0. Gemini 3’s reasoning is optimized for the default. Lowering it can cause looping or degraded performance on complex tasks.
Split-step verification. Verify information exists before generating answers to prevent confident but incorrect outputs.
Concise by default. Gemini 3 gives direct, efficient answers. Request detail explicitly if you need it.
Avoid broad negatives. “Do not infer” causes problems. Instead, specify what the model should use for reasoning.

Quick Reference: Technique Cheat Sheet

Technique	What It Does	When to Use
Role Assignment	Activates domain-specific patterns	Every prompt with a specialized context
Few-Shot Examples	Teaches output format by pattern	Structured extraction, classification, formatting
XML/Tag Structure	Eliminates ambiguity between sections	Multi-part prompts, mixed instructions and data
Chain of Thought	Forces step-by-step reasoning	Validation, debugging, complex analysis
Output Constraints	Locks format and schema	API integrations, automation pipelines
Context Placement	Exploits attention distribution	Long documents, multi-source analysis
Negative Constraints	Overrides training defaults	Terraform, code gen, any structured output
Iterative Refinement	Narrows toward precision over rounds	Architecture, planning, complex deliverables
Metaprompting	Uses the model to improve your prompts	Prompt optimization, workflow development

Bottom Line

Prompt engineering is instruction writing. That is it. No mysticism. No secret sauce.

The model is a system that follows orders literally. Vague orders produce vague results. Precise orders produce precise results. Three independent engineering teams at Anthropic, OpenAI, and Google arrived at the same conclusion: be clear, be structured, be specific, provide examples, and constrain the output.

You would not hand a junior admin a firewall change request that says “make it more secure.” You would specify the exact rules, the exact interfaces, the exact traffic flows, and the expected behavior. Treat the model the same way.

Write your prompts like operations orders. State the situation. Define the task. Specify the constraints. Dictate the format. Provide examples. Execute.

Next post: RAG (retrieval-augmented generation) and how to give your AI access to knowledge it was never trained on. The context window is not the only way to feed data to a model. It is not even the best way.

Sources

How AI Actually Works: Tokens, Context Windows, and Why Your Chatbot Forgets Things

Fri, 10 Apr 2026 00:00:00 GMT

How LLMs actually work: tokens, transformers, context windows, attention, and output sampling. Plus proven techniques to optimize token usage in Claude and ChatGPT. Interactive demos included.

MCP Hit 97 Million Installs. The Protocol War Is Over.

Fri, 10 Apr 2026 00:00:00 GMT

Your AI Tools Are About to Get a Lot More Useful

Every AI assistant you use is about to stop being a fancy autocomplete and start actually doing things. The reason is a protocol most people have never heard of.

Anthropic’s Model Context Protocol crossed 97 million monthly SDK downloads in March 2026. For context, Kubernetes took nearly four years to reach comparable deployment density. MCP did it in sixteen months.

The Linux Foundation announced the Agentic AI Foundation (AAIF) to house MCP under open governance, alongside OpenAI’s AGENTS.md and Block’s goose. This is not one company’s project anymore. OpenAI, Google, Microsoft, AWS, and Cloudflare all ship MCP-compatible tooling. Over 5,800 community and enterprise MCP servers are live, covering everything from databases to CRMs to dev tools.

What MCP Actually Is

Most people encounter AI through a chat interface and assume the model is the product. It is not. The model is the reasoning engine. The product is everything the model can connect to.

MCP is the protocol that defines how AI models connect to external tools and data sources. It gives a model a standardized way to say “I need to query your database” or “I need to write to your calendar” or “I need to run a command in your shell” and have the target system respond in a format the model can use.

Before MCP, every AI integration was bespoke. Connecting Claude to your Notion database required Anthropic to build a Notion integration or you to write one from scratch, with custom JSON formats, one-off authentication handling, and code that broke every time either API changed. Multiply that by every tool you want to connect, and you have an integration surface that nobody can maintain.

MCP replaces that with a single protocol. Build one MCP server for Notion, and every MCP-compatible model can connect to it. Build one client in Claude Desktop, and it connects to every MCP-compatible server. The USB port analogy holds because it is exactly right: one interface, everything plugs in.

How It Works Under the Hood

MCP uses a client-server architecture over a local socket or stdio transport. The model (or the application hosting the model) runs an MCP client. Each tool or data source runs an MCP server. The client discovers available servers, queries their capabilities, and invokes tools via JSON-RPC messages.

A minimal MCP server looks like this:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server({ name: "file-reader", version: "1.0.0" });

server.setRequestHandler("tools/list", async () => ({
  tools: [{
    name: "read_file",
    description: "Read the contents of a file from the filesystem",
    inputSchema: {
      type: "object",
      properties: { path: { type: "string" } },
      required: ["path"],
    },
  }],
}));

server.setRequestHandler("tools/call", async (request) => {
  const { path } = request.params.arguments;
  const content = await fs.readFile(path, "utf-8");
  return { content: [{ type: "text", text: content }] };
});

const transport = new StdioServerTransport();
await server.connect(transport);

The model sends a tools/list request, gets back a description of what the server can do, and then calls tools/call with arguments when it needs to use a tool. The server executes the action and returns structured data. The model uses that data to continue its reasoning.

That is the entire protocol. The complexity is in what you build on top of it, not in MCP itself.

The Three Resource Types

MCP servers can expose three kinds of resources to a model:

Tools are actions the model can invoke: run a query, write a file, send an email, make an API call. Tools have side effects. They change state in the world.

Resources are data the model can read: documents, database records, configuration files, log output. Resources are generally read-only. The model uses them to build context without taking action.

Prompts are templated instructions the server can inject into the model’s context: system prompts, workflow templates, contextual guidance. Prompts let server operators influence how the model reasons about their domain.

A full-featured MCP server for a task management system might expose tools to create, update, and close tasks; resources to read task lists, project details, and user assignments; and prompts that instruct the model to always check for blocking dependencies before marking a task complete. The model gets tools, data, and operational guidance from a single server connection.

The Competitive Landscape

Rivals exist. IBM has the Agent Communication Protocol (ACP). Google has Agent-to-Agent (A2A). Both emerged in 2025 as alternatives to MCP.

ACP targets enterprise workflows and is designed to handle more complex multi-agent coordination patterns. A2A focuses on agent-to-agent communication rather than agent-to-tool communication. Neither is wrong. But both are fighting adoption curves that MCP had already won.

97 million monthly installs is not a lead. It is a moat. Developer tooling network effects compound fast. When 5,800 MCP servers already exist covering your database, your CRM, your code repository, your calendar, and your filesystem, the switching cost of adopting a different protocol is the cost of rebuilding every integration you already have.

The Linux Foundation governance announcement matters because it removes the remaining objection for enterprise adoption. MCP is no longer an Anthropic project. It is an open standard with foundation backing, the same path that HTTP, Docker, and Kubernetes walked before it.

Why This Matters Right Now

If you are building AI-powered workflows, MCP is the integration layer you need to understand. Not “eventually” understand. Now.

The tooling is mature. The SDK is stable. The server ecosystem covers the tools most developers and teams actually use. Claude Desktop, Cursor, Zed, and VS Code all support MCP. The barrier to entry for running your first MCP server is about thirty minutes and a package install.

More importantly: MCP is the difference between AI that reasons about your work and AI that actually does your work. The gap between those two things is everything.

The BytesNation Angle

We have a full MCP series coming. Obsidian MCP for wiring your personal knowledge vault into Claude. Granola MCP for surfacing meeting transcripts during active sessions. Claude Code MCP for exposing homelab infrastructure to AI-driven automation. The tools we use every day in this lab all run on this protocol. You will see exactly how they work, hands on, with real configs and real results.

MCP is the thing that makes AI stop talking and start working. Pay attention.

Sources

AI Agents Are Already Making Decisions for You. Here Is What That Means.

Thu, 09 Apr 2026 00:00:00 GMT

You Are Already Interacting with AI Agents

That customer support ticket you filed last week? An AI agent triaged it, diagnosed the issue, and resolved it without a human touching it. The loan application you submitted? An AI agent ran your credit profile, verified your identity documents, and made a preliminary approval decision before a human ever reviewed the file.

This is not a concept paper. This is not a startup pitch deck. This is what is deployed, in production, right now across banking, healthcare, telecom, and enterprise IT.

72% of medium and large enterprises are already running agentic AI systems. Gartner projects that 40% of enterprise applications will embed task-specific AI agents by the end of this year, up from less than 5% in 2025. That is not gradual adoption. That is a phase shift.

If you do not understand what an AI agent is, how it operates, and what it means for your career and your security, you are flying blind into a landscape that is already reshaping around you.

What an AI Agent Actually Is

Strip away the marketing. An AI agent is software that receives a goal, breaks it into steps, executes those steps using tools, and adjusts its approach based on what happens. It does not wait for you to click “next.” It operates.

A chatbot waits for your input and responds. An agent takes your request and goes to work. It reads databases, calls APIs, sends emails, writes code, schedules meetings, and makes decisions in sequence without stopping to ask permission at every step.

The difference matters. A chatbot is a tool you use. An agent is a system that acts on your behalf. That distinction changes everything about trust, accountability, and attack surface.

Three properties define an AI agent:

Autonomy. It executes multi-step tasks without continuous human input.
Tool use. It interacts with external systems: databases, APIs, file systems, browsers, other agents.
Adaptive reasoning. It adjusts its plan when something fails or when new information arrives.

When you chain multiple agents together, each with a specialized role, you get a multi-agent system. One agent handles research, another writes the report, a third reviews it for quality. They coordinate, delegate, and produce output that would have taken a team of people days to assemble.

What Agentic AI Is Doing Right Now

This is not theoretical. These are documented, production deployments as of early 2026.

Banking and Finance. AI agents are running Know Your Customer (KYC) and Anti-Money Laundering (AML) checks autonomously. Banks report 200% to 2,000% productivity gains on these workflows. Agents are adjusting credit scores, calculating loan terms, and monitoring financial health indicators without manual intervention.

Healthcare. Agents are updating electronic health records by pulling data from lab systems, wearable devices, and telehealth visits. Hospitals are using them to optimize patient flow, manage staff scheduling, and triage incoming cases based on severity and resource availability.

Enterprise IT and HR. One major chipmaker deployed AI-powered HR agents that reduced time-to-resolution on employee inquiries by 80% and hit 70% employee satisfaction within 90 days. A major telecom reports saving 40 minutes per AI interaction across its workforce.

Supply Chain. Agentic control towers are monitoring end-to-end supply chain KPIs in real time, identifying emerging disruptions before they cascade, executing contingency plans, and coordinating stakeholders across the network. No human in the loop until the situation exceeds the agent’s authority threshold.

Customer Support. AI agents are independently triaging, diagnosing, and resolving support tickets end to end. Not routing them to a human queue. Resolving them. Companies deploying this report measurable ROI within weeks, not quarters.

This is the new baseline. If your employer is not deploying agents, your competitor’s employer is.

The Threat Angle: Agents as Attack Vectors

Here is where it gets serious. Every capability that makes AI agents useful also makes them dangerous.

The CrowdStrike 2026 Global Threat Report documents an 89% year-over-year increase in AI-enabled attacks. Average eCrime breakout time is now 29 minutes, a 65% acceleration from 2024. Attackers are faster because they are using agents too.

Prompt injection remains the most common attack vector against agentic systems. An attacker embeds malicious instructions inside data that an agent processes (an email, a document, a web page). The agent reads it, treats it as a legitimate instruction, and executes it. Success rates on prompt injection attacks still exceed 85% against many deployed defenses. The agent does not know it has been compromised. It just follows the instructions it was given.

Memory poisoning is the sleeper threat. Unlike prompt injection that ends when the session closes, memory poisoning plants false information in an agent’s long-term storage. The agent “learns” the malicious instruction and recalls it in future sessions, days or weeks later. This is persistent compromise of an autonomous system.

Privilege escalation through tool misuse happens when an agent with access to sensitive systems gets manipulated into performing actions outside its intended scope. If an agent has database access and email access, an attacker who compromises the agent gets both.

Cascading failures occur in multi-agent systems. One compromised agent feeds bad data to downstream agents. Each agent trusts the output of the previous one. The corruption propagates through the entire pipeline before anyone detects it.

48% of security leaders surveyed believe agentic AI will represent the top attack vector for cybercriminals and nation-state threats by the end of 2026. That is not a fringe opinion. That is nearly half the industry.

The defenses that matter are not exotic. Strong identity controls. Network segmentation. Behavior-based anomaly detection. Least privilege access for every agent. Monitoring agent actions the same way you monitor user actions. The fundamentals have not changed. The attack surface has.

The Opportunity: Why This Is Your On-Ramp

Here is the part most people miss. You do not need a computer science degree to work with AI agents. The barrier to entry has never been lower.

Job postings mentioning agentic AI skills jumped 986% between 2023 and 2024. Companies across every industry are building teams around this technology and they cannot find enough people. The demand is outpacing the supply of talent by a wide margin.

The roles emerging are not all engineering roles:

AI Operations Manager. Monitors deployed agents, ensures uptime, handles escalations when agents exceed their authority. This is IT operations adapted for autonomous systems.
AI Compliance and Policy Advisor. Interprets regulations around AI automation, ensures agents operate within legal and ethical boundaries. Legal and compliance backgrounds are directly applicable.
Workflow Architect. Designs the multi-step processes that agents execute. This requires understanding business operations, not writing code.
Prompt Engineer and Agent Designer. Crafts the instructions and guardrails that shape agent behavior. Writing clear, precise instructions is a skill that transfers from technical writing, military operations orders, and process documentation.

The skills that matter most are not technical in the traditional sense. Adaptability. Critical thinking. Data interpretation. Clear communication. Understanding how systems connect and where they break. If you have operational experience in any field, you already have transferable skills.

Low-code and no-code platforms for building agent workflows exist right now. You can connect APIs, define decision logic, set up triggers and responses, and deploy functional automation without writing a framework from scratch. The tools are accessible. What is missing is the understanding of how to use them deliberately and safely.

This is where the real gap is. Not in coding ability. In systems thinking. Understanding what an agent should and should not do. Knowing where to put guardrails. Recognizing when an automated process needs a human checkpoint. That judgment comes from experience, not credentials.

What to Do About It

Stop watching from the sidelines. The window where “I am not a tech person” was a valid excuse is closing.

You do not need to build AI agents from scratch. You need to understand how they work, what they can do, what they cannot do, and where they break. You need enough literacy to evaluate whether the AI system your company is deploying is secure, effective, and aligned with the outcomes it claims to deliver.

Start here:

Learn the vocabulary. Agents, tool use, prompt injection, multi-agent orchestration, guardrails. You cannot evaluate what you cannot name.
Build something small. Use a no-code automation platform. Connect two services. Set up a trigger. Watch an agent execute a workflow. The hands-on experience is worth more than a hundred articles.
Study the threat model. Understand prompt injection, memory poisoning, and privilege escalation. If you are deploying agents or working alongside them, you need to know how they get compromised.
Think in systems. Every agent operates within a larger context: data sources, permissions, downstream consumers, failure modes. Map those connections. That is where the value is.

BytesNation exists to give people without traditional backgrounds the field notes they need to become builders, not bystanders. The content here is not theoretical. It is operational. Built by someone who deploys these systems, breaks them, and documents the process.

Agentic AI is not the future of work. It is the present of work. The question is whether you are going to understand it or get automated by it.

Your move.

Obsidian as a Knowledge Vault: The Field Manual

Thu, 09 Apr 2026 00:00:00 GMT

Stop Taking Notes. Start Building a System.

You have notes scattered across six apps. Half of them are duplicates. The other half are orphans you will never find again. You tell yourself you will organize them “later.” Later never comes.

Obsidian fixes this, but only if you stop treating it like a notepad and start treating it like infrastructure. A knowledge vault is not a collection of files. It is an architecture. It has routing, a hierarchy, an inbox, automated pipelines, and a daily operating rhythm.

This is how to build one that actually works.

What Is Obsidian

Obsidian is a local-first, markdown-based knowledge management application. Your notes are plain .md files on your filesystem. No cloud lock-in. No proprietary format. No subscription required for core functionality.

Why that matters:

Portability. Your notes work in any text editor, forever. If Obsidian disappears tomorrow, you still have your vault.
Speed. Local files are instant. No API latency, no sync lag on search.
Privacy. Your data stays on your machine unless you explicitly sync it.
Git-friendly. Version control your entire knowledge base. Track changes, branch experiments, revert mistakes.

Obsidian’s real power is in its linking system. Every note can reference every other note using [[wikilinks]]. Over time, this creates a graph of connected knowledge that surfaces relationships you would never find in a folder tree.

The ACE Framework

Folder structure is where most people either overthink or underthink. They either create 47 nested folders or dump everything into one pile. Both fail at scale.

The ACE framework (Atlas, Calendar, Efforts) was created by Nick Milo as part of his Linking Your Thinking (LYT) methodology. It is the best organizational model I have found for Obsidian, and the foundation of how my vault is structured. Full credit to Nick for this framework; what follows is how I adapted it.

ACE solves the folder problem with three clear domains:

Atlas: What You Know

This is your permanent knowledge base. Reference material, technical notes, how-to guides, concept breakdowns. Organized by topic, not by project or time.

Atlas/
  API Documentation/ # API references and specs
  MOCs/              # Maps of Content (navigation hubs)
  Notes/             # Topic-organized knowledge
    Cyber Security/
    Gaming/
    Hardware/
    Networking/
    Operating Systems/
    Programming/
    Systems Administration/
  Sources/           # Book notes, articles, external references
  Spaces/            # Personal life areas
    About/
    Family/
    Home Office/
    House/
    Military/
    Music/
    Pets/
    Recipes/

MOCs (Maps of Content) are the key innovation here. A MOC is a note that links to all related notes in a topic. Think of it as a manually curated index page. Your “Networking MOC” links to every networking note you have: DNS, DHCP, VPN, wireless, protocols, guides.

MOCs give you a two-hop navigation pattern: Note > MOC > Home. You can always find anything within two clicks.

Calendar: What Happened When

Time-stamped content. Daily notes, meeting notes, weekly reviews. Anything where the date is the primary context.

Calendar/
  Daily Notes/       # YYYY/MM/YYYY-MM-DD.md
  Meeting Notes/     # Organized by entity/project

Daily notes are the heartbeat of the system. More on that below.

Efforts: What You Are Working On

Active projects and initiatives. Each effort gets its own folder with a MOC, tasks, and relevant documentation. When a project wraps up, move it to a Dormant folder. Do not delete it.

Efforts/
  Active/
    Project Alpha/
    Project Bravo/
  Dormant/
    Archived Project/

The Inbox

One more folder outside ACE: the inbox. Call it +Encounters/ or Inbox/. The + prefix keeps it sorted to the top of the file explorer. In my vault, +Encounters/ is the manual capture inbox, and a separate Clippings/ folder at the vault root receives web articles saved by the Obsidian Web Clipper browser extension.

This concept comes from the Zettelkasten method, the slip-box system developed by German sociologist Niklas Luhmann. In Zettelkasten, the inbox is where raw captures land before being processed into permanent, atomic notes. Luhmann used this system to produce over 70 books and 400 academic papers from a single collection of 90,000 handwritten notes. The principle is simple: capture everything, process deliberately, connect intentionally.

Every new note starts here. Raw captures, quick thoughts, meeting dumps. Nothing stays in the inbox permanently. During your daily review, you file each note into the correct ACE location, apply frontmatter, and link it to the appropriate MOC.

If your inbox has more than 20 items in it, you are behind on processing. Fix that.

Frontmatter: Your Metadata Layer

Every note in the vault should have YAML frontmatter. This is non-negotiable. Frontmatter enables search, filtering, Dataview queries, and graph organization.

Standard format:

---
up: "[[Parent MOC]]"
tags:
  - domain/topic
created: 2026-04-09
---

up is the upstream link. It tells you where this note lives in the hierarchy. Your “DNS Deep Dive” note points up to [[Networking MOC]]. The Networking MOC points up to [[Home]]. This creates a navigable chain from any note back to the vault root.

tags use a hierarchical prefix system:

atlas/networking, atlas/cyber-security for knowledge notes
effort/project-name for project notes
calendar/daily, calendar/meeting for time-stamped notes
spaces/personal for life areas

created is the creation date. Simple, but critical for filtering and sorting.

The Daily Note System

This is where most knowledge management systems fall apart. People build beautiful folder structures and then never use them because there is no daily habit to drive input.

The daily note is your operating system. One note per day, auto-generated from a template, structured to capture everything and route it to the right place.

My daily note system is heavily influenced by Dan Martell and his work on time management, the Perfect Week, and shutdown routines. His book Buy Back Your Time and his content on designing your ideal day shaped how I think about daily planning, energy management, and the hard stop. What follows is my adaptation of those principles built directly into Obsidian.

The Rhythm

Night before (15 min): Brain dump, park open loops, set tomorrow’s top 2. Hard stop. Walk away.

Morning (30 min): Hydrate. Brain dump. Confirm priorities. Gratitude. This is not optional. This is how you start the day with intention instead of reaction.

Throughout the day: Capture tasks to the Task Board with context tags. Log meeting notes. Add items to the Ingest Log.

End of day (15 min): What got done. What got punted. One improvement for tomorrow. Check North Star Metrics. Shutdown complete.

Total daily overhead: about 60 minutes. The return on that hour is every other hour of your day being more focused.

Automating the Rhythm

The daily rhythm works. But it has friction. Opening yesterday’s note, copying uncompleted tasks, building the template, filling in navigation links. That is 10 minutes of bookkeeping before you even start thinking. At the end of the day, it is worse: pulling meeting notes, cross-referencing what got done, building tomorrow’s note. That overhead is what kills the habit.

I automated both ends with Claude Code skills: custom command sequences that execute against the vault with full filesystem access.

Morning Stack

One command. The LLM locates the most recent daily note, extracts the Night Before Shutdown section (brain dump, open loops, tomorrow’s top 2), carries forward any uncompleted tasks from the Task Board with their priority scores intact, and creates today’s daily note from the template. Then it walks through the morning questions one at a time: confirm or drop carried-over tasks, brain dump, today’s top 2, gratitude. Every answer gets written directly into the daily note.

No copy-pasting. No template fiddling. You sit down, run the command, answer the questions, and your day is set.

End of Day Shutdown

Same concept, reverse direction. The LLM reads today’s daily note, gathers completed and uncompleted tasks, pulls meeting transcripts from the day, and creates standalone meeting notes filed into the correct project folder with proper frontmatter and cross-links. It pre-populates “what got done” grouped by project, then walks through the shutdown questions: confirm accomplishments, identify what got punted, one thing to do differently, North Star Metrics check, brain dump, open loops, and tomorrow’s top 2 priorities.

Once complete, it writes everything to today’s daily note and creates tomorrow’s note pre-filled with the Night Before Shutdown section and the carried-over Task Board.

Where the Data Comes From

The skills do not operate in a vacuum. They pull from multiple sources to build a complete picture of your day.

The vault itself. The LLM reads the previous daily note to extract carried-over tasks, open loops, and planned priorities. It reads the Task Board to know what is still incomplete and what priority scores are assigned. It reads the Night Before Shutdown section to know what you brain-dumped before bed. All of this is just markdown files on disk; the LLM parses them directly.

Meeting transcription services. If you use a meeting recorder (Granola, Otter.ai, Fireflies, or any tool that produces transcripts), the EOD skill can pull the day’s meetings via API or MCP connector, extract key decisions and action items, and generate structured meeting notes. The richer your transcript source, the better the output. At minimum, you need attendee names, a title, and a transcript or summary. The LLM handles the rest: routing the note to the right project folder, applying frontmatter, cross-linking to related vault content.

Calendar integrations. Connected calendars (Google Calendar, Outlook, iCloud) give the LLM context on what meetings happened, when, and with whom. This lets it cross-reference transcripts against your schedule and fill gaps where a meeting was on the calendar but no transcript exists.

Email and messaging. If you connect email or Slack via MCP, the LLM can surface action items or threads relevant to your open tasks. This is optional but useful for catching things that did not make it into the Task Board during the day.

The schema file. The skill definition itself tells the LLM how to route notes, what frontmatter to apply, what folder structure to follow, and what questions to ask. Change the schema, change the behavior. No code changes required.

The more sources you connect, the more complete the daily note becomes. Start with just the vault and add integrations as you need them. The system works at any level of connectivity.

Why This Matters

The daily note system described above is a 60-minute manual process. With automation, the human input drops to the parts that actually require thinking: answering the questions, making decisions about priorities, and reflecting on the day. The LLM handles the rest. File creation, task carryover, meeting note extraction, cross-linking, template population. All the bookkeeping that causes people to abandon the habit after two weeks.

The skills are just text files that describe the workflow. The LLM reads the instructions, reads the vault, and executes. No custom code, no API integrations, no build step. If the workflow needs to change, you edit the skill file. The LLM adapts on the next run.

The Priority Matrix

The Task Board is not a to-do list. It is a scoring system.

Each task gets scored on two axes:

Impact (1-3): How much does completing this move the needle?
Urgency (1-3): How time-sensitive is it?

Score = Impact x Urgency. Highest score gets done first. Ties go to the task with higher impact.

This prevents the common failure mode of spending all day on urgent-but-low-impact tasks while the important work sits untouched.

For more complex tasks, use RICE scoring:

Reach: How many people/systems does this affect?
Impact: How significant is the effect?
Confidence: How sure are you about the estimates?
Effort: How much time/resources required?

RICE Score = (Reach x Impact x Confidence) / Effort

Plugins That Matter

Obsidian’s plugin ecosystem is massive. Most of it is noise. Here are the ones that earn their keep, organized by function.

Core Data Layer

Dataview

The single most important plugin. Dataview lets you write queries against your vault metadata and render dynamic tables, lists, and task views.

Example: Show all notes created this week in your Networking folder:

TABLE WITHOUT ID
  link(file.link, file.name) AS "Note",
  dateformat(file.ctime, "MMM dd") AS "Added"
FROM "Atlas/Notes/Networking"
WHERE file.ctime >= date(today) - dur(7 days)
SORT file.ctime DESC

Your Home note becomes a live dashboard. Overdue tasks, notes created today, effort status, meeting history. All generated dynamically from your actual notes.

Tasks

Tasks turns markdown checkboxes into a full task management system with due dates, priorities, recurrence, and global queries. Your Home note can aggregate every open task across the entire vault using context tags, grouped by project, with overdue, due today, and due this week views.

Daily Operations

Templater

Templater is a template engine with variable interpolation and logic. Your daily note template auto-generates the date, day of week, previous/next day navigation links, and Dataview queries specific to that date. Templates live in Extras/Templates/ and use tp.file.title to derive the date from the filename.

Without Templater, you are manually creating structured notes every day. That friction kills the habit within a week.

Calendar and Periodic Notes

Calendar gives you a visual sidebar for navigating daily notes. Click a date, jump to that note. Periodic Notes extends this with weekly, monthly, and quarterly note templates on the same calendar interface.

Day Planner

Day Planner lets you time-block your tasks directly in the daily note. Renders a visual timeline from markdown task lists with time annotations.

Knowledge and Search

Omnisearch

Omnisearch is full-text search that actually works. Obsidian’s built-in search is decent. Omnisearch is better, especially in large vaults.

Smart Connections

Smart Connections provides AI-powered note linking. It surfaces semantically related notes you might not have linked manually. Useful for finding connections across domains that keyword search would miss.

Visual and Editing

Excalidraw

Excalidraw provides embedded diagramming directly inside Obsidian. Network topologies, architecture decisions, flowcharts, mind maps. The diagrams live as .excalidraw.md files in your vault, linked to the context they belong to.

Advanced Tables

Advanced Tables makes editing markdown tables tolerable. Tab between cells, add/remove rows and columns without fighting pipe characters.

Outliner

Outliner enhances bullet list editing with folding, indenting, and reordering shortcuts. Turns Obsidian into an outliner when you need it.

Iconize and Style Settings

Iconize adds visual icons to folders and files in the file explorer for faster scanning. Style Settings exposes theme customization options as a settings panel.

Integration Layer

Local REST API

Local REST API exposes your vault to external tools via HTTP. This is how you integrate Obsidian with automation platforms, scripts, or AI tools. Programmatic access to create, read, and update notes without opening Obsidian.

MCP Tools

MCP Tools provides Model Context Protocol integration. This lets LLM agents interact with your vault through a standardized tool interface. Combined with the Local REST API, it is the bridge that makes the LLM Wiki pattern work with agents that do not have direct filesystem access.

For the full list of tools, software, and services that power the lab (including Obsidian), check the Tools and Resources page.

Maps of Content deserve their own section because they are the difference between a vault you use and a vault you abandon.

A MOC is a note that serves as a curated index for a topic. It is not auto-generated. You maintain it manually, which forces you to think about how your knowledge connects.

Example structure for a Networking MOC:

---
up: "[[Home]]"
tags:
  - MOC
  - atlas/networking
created: 2026-01-15
---

# Networking

## Fundamentals
- [[DNS Deep Dive]]
- [[DHCP Architecture]]
- [[Subnetting Reference]]

## Protocols
- [[802.1X Authentication]]
- [[WPA3 Hardening]]
- [[BGP Basics]]

## Lab
- [[VLAN Design]]
- [[Homelab Network Topology]]
- [[VPN Comparison]]

## Guides
- [[Firewall Rule Methodology]]
- [[Packet Capture Workflow]]

When you create a new networking note, you add it to this MOC. When you need to find something about networking, you start here. The MOC is your table of contents for that domain.

Aim for one MOC per major knowledge area. Six to twelve MOCs is the sweet spot for most people. More than twenty and you are over-indexing.

The Graph View

Obsidian’s graph view visualizes every note and link in your vault as a network diagram. It looks impressive in screenshots. Its real value is diagnostic.

Use the graph to find:

Orphan notes. Notes with no links in or out. These need to be filed and connected, or deleted.
Clusters. Dense clusters indicate well-developed knowledge areas. Sparse areas are gaps.
Bridge notes. Notes that connect two otherwise separate clusters. These are often your most valuable notes because they represent cross-domain insights.

Color-code your graph groups by domain (knowledge, efforts, calendar, personal) so you can visually scan the balance of your vault at a glance.

The Weekly Review

Once a week, step back from the daily notes and review at a higher altitude.

Last week:

Did you hit your North Star Metrics?
What worked? What broke down?
What patterns need to die?

This week:

Two objectives per active project. No more.
Project health check: Red, Yellow, Green for each effort.
Blockers identified and escalation planned.

Environment audit:

Is your workspace set up for deep work?
Are your calendar blocks protecting focus time?
What are you avoiding?

The weekly review takes 30 to 45 minutes. It prevents drift. Without it, you will slowly stop using the daily notes, the task board goes stale, and the vault becomes a graveyard of good intentions.

Scaling the Vault

A vault with 50 notes works no matter how you organize it. A vault with 500 notes exposes every structural weakness. A vault with 5,000 notes either runs like a machine or collapses under its own weight.

Rules for scale:

Frontmatter on everything. No exceptions. Notes without metadata are invisible to Dataview and useless for automation.

File before you forget. Process your inbox daily. A note left in the inbox for a week is a note that will never be filed.

Link aggressively. Every note should link to at least one MOC and one related note. Isolated notes are wasted notes.

Prune regularly. Delete notes that add no value. Merge duplicates. Update stale content. A lean vault is a fast vault.

Templates for everything repeatable. Daily notes, meeting notes, project kickoffs, task breakdowns. If you create the same structure more than twice, it needs a template. Store them in a dedicated folder (mine lives at Extras/Templates/) and use the Templater plugin to auto-populate dates, navigation links, and Dataview queries on creation.

The LLM Wiki: Letting AI Maintain Your Vault

Everything above is manual. You build the structure, you file the notes, you maintain the MOCs, you process the inbox. It works. It also creates a maintenance burden that grows with every note you add. Cross-references go stale. Summaries fall behind. Connections get missed because you forgot what you wrote six months ago.

This is the problem Andrej Karpathy addressed in his LLM Wiki pattern: a framework where LLMs incrementally build and maintain a persistent, interlinked wiki on top of your raw sources. Instead of retrieving from documents on every query (the standard RAG approach), the LLM compiles knowledge once and keeps it current. Cross-references are already there. Contradictions are already flagged. The synthesis reflects everything in the vault.

As Karpathy puts it: “The tedious part of maintaining a knowledge base is not the reading or the thinking; it is the bookkeeping.” LLMs handle that bookkeeping at near-zero cost.

I integrated this pattern directly into my Obsidian vault. Here is how it works alongside the ACE framework.

The Three-Layer Architecture

Open diagram in new tab for full zoom controls

Karpathy’s pattern defines three layers that map cleanly onto what already exists in the vault:

Raw sources. Your curated collection of source documents: articles, papers, transcripts, data files. These are immutable. The LLM reads from them but never modifies them. In the ACE framework, these live in Atlas/Sources/ and +Encounters/ (the inbox).

The wiki. LLM-generated markdown files: summaries, entity pages, concept pages, comparisons, synthesis documents. The LLM owns this layer. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. In my vault, these pages land in Atlas/Notes/ organized by topic, with proper frontmatter and MOC links.

The schema. A configuration document that tells the LLM how the wiki is structured, what conventions to follow, and what workflows to execute. If you are using Claude Code, this is your CLAUDE.md. For OpenAI Codex, it is AGENTS.md. The schema describes your folder structure, frontmatter conventions, routing rules, and operational workflows in the format that agent expects. This is the difference between a disciplined wiki maintainer and a generic chatbot. You and the LLM co-evolve it over time.

The Core Operations

Ingest. Drop a new source into the raw collection and tell the LLM to process it. The LLM reads the source, writes a summary page, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source can touch 10 to 15 wiki pages. I prefer to ingest one source at a time and stay involved, checking summaries and guiding emphasis. Batch ingestion with less supervision is also viable.

Query. Ask questions against the wiki. The LLM searches relevant pages, reads them, and synthesizes an answer with citations. The critical insight from Karpathy: good answers should be filed back into the wiki as new pages. A comparison you asked for, an analysis, a connection you discovered. These compound in the knowledge base instead of disappearing into chat history.

Lint. Periodically, the LLM health-checks the wiki. It looks for contradictions between pages, stale claims superseded by newer sources, orphan pages with no inbound links, important concepts that lack their own page, and missing cross-references. It also suggests new questions to investigate and new sources to seek out.

How This Integrates With ACE

The LLM Wiki pattern does not replace the ACE framework. It automates the parts of ACE that humans abandon. The bridge between the two is the ingest operation.

The Ingest Skill

This is the workhorse. You point the LLM at a source (a file in your inbox, a URL, pasted text, a meeting transcript) and tell it to ingest. The LLM executes a defined sequence:

1. Analyze. Read the source. Extract the title, key concepts, source type (article, meeting, video, book, transcript, note), any actionable items, and which knowledge domains it touches.

2. Route. Determine where the note belongs in the ACE structure. Meeting with attendees and a date goes to Calendar/Meeting Notes/. Technical knowledge matching an existing MOC topic goes to Atlas/Notes/<Topic>/. External reference material goes to Atlas/Sources/. Project-specific content goes to Efforts/Active/<Project>/. The routing rules are defined in the schema file, not hardcoded. Change the rules, change the behavior.

3. Build frontmatter. Construct the YAML metadata: up: link to the parent MOC, hierarchical tags, creation date, source type, source URL or file path, and an ingested date. Every note gets the full metadata layer from the moment it is created. No cleanup pass needed later.

4. Write and link. Create the note with organized content sections, wikilinks to related existing notes (found by searching the vault), and an Action Items section if tasks were extracted. Tasks get formatted with project context tags and due dates where applicable.

5. Update the MOC. Read the parent MOC and add a wikilink to the new note in the appropriate section. This is the step humans skip. The LLM does not skip it.

6. Log the ingest. Append an entry to today’s daily note under the Ingest Log section: timestamp, what was ingested, where it was filed, which MOC was updated. This creates a chronological record of everything that entered the vault and where it went.

7. Mark the source. If the source came from the inbox (+Encounters/), the LLM marks it as processed in its frontmatter. The original is never deleted. You always have the raw source to reference.

Duplicate Detection and Edge Cases

Before creating a note, the LLM searches the vault for existing notes with the same or similar title. If a match is found, it asks whether to merge, rename, or skip. For large sources (over 2,000 words), it creates a summary with key takeaways instead of a verbatim copy, linking back to the original. If the content spans multiple projects, it files under the primary and cross-links to the secondary. If the content does not fit any existing MOC, it suggests creating a new one.

What This Means for Inbox Processing

The inbox (+Encounters/) is where raw captures land. Without the ingest skill, you process them manually: read the note, decide where it goes, move it, add frontmatter, link it to a MOC, update the MOC. That is five steps per note. Fall behind for a week and you have 20 unfiled notes. Fall behind for a month and the inbox is a graveyard.

With the ingest skill, you point the LLM at an inbox item and it handles all five steps. One command per note. Batch through the whole inbox in minutes instead of an hour.

MOC Maintenance

The ingest skill handles this as a side effect. Every time the LLM creates or updates a note, it also updates the corresponding MOC. No more stale navigation hubs. No more orphan notes sitting outside the link graph because you forgot to add them to the index.

Meeting Note Processing

Meeting transcripts get ingested through the same pipeline. The LLM creates structured meeting notes with attendees, key decisions, discussion sections organized by topic, and action items. The note gets filed into the correct project folder, linked to the parent MOC, and cross-referenced against related vault content. If you are already using the EOD shutdown skill described earlier, meeting ingestion happens automatically at the end of each day.

Two Index Files

Karpathy recommends index.md (a content-oriented catalog of every wiki page with one-line summaries) and log.md (an append-only chronological record of ingests, queries, and lint passes). The index replaces embedding-based search at moderate scale. The log gives you a timeline of the wiki’s evolution. In the ACE vault, the daily note’s Ingest Log serves the same purpose as log.md, and the MOCs collectively serve as the index.

The Workflow in Practice

Karpathy describes the working arrangement: “I have the LLM agent open on one side and Obsidian open on the other. The LLM makes edits based on our conversation, and I browse the results in real time, following links, checking the graph view, reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.”

That is exactly how I run it. Claude Code (or any LLM agent with filesystem access) operates on the vault files. Obsidian renders them in real time with graph view, backlinks, and Dataview queries. The human curates sources, directs analysis, and asks the right questions. The LLM does the filing, cross-referencing, and bookkeeping.

Scaling With LLM Maintenance

This changes the scaling equation entirely. The manual rules from the previous section still apply: frontmatter on everything, link aggressively, prune regularly. But the LLM handles the bulk of that work. A vault with 5,000 notes is no longer a maintenance nightmare when the LLM can touch 15 files in one pass without getting bored, forgetting a cross-reference, or losing context.

The idea traces back to Vannevar Bush’s Memex (1945): a personal, curated knowledge store with associative trails between documents. Bush’s vision was closer to this than to what the web became. Private, actively curated, with the connections between documents as valuable as the documents themselves. The part he could not solve was who does the maintenance. The LLM handles that.

The Bottom Line

Obsidian is not a note-taking app. It is a knowledge operating system. The ACE framework gives it structure. The daily rhythm gives it input. The LLM Wiki pattern gives it a maintenance engine that scales.

Build the ACE framework. Set up your frontmatter standard. Create your MOCs. Use your daily note every single day. Review weekly. Prune monthly. Then hand the bookkeeping to an LLM and focus on what humans are actually good at: sourcing, exploring, and thinking.

The vault is not the goal. The goal is to think more clearly, decide more quickly, and never lose track of what matters.

The vault is just the infrastructure that makes that possible.

Building a Proxmox Cluster on Beelink Mini PCs

Thu, 09 Apr 2026 00:00:00 GMT

Rack Servers Are Overrated

Here is the pitch most homelab content gives you: buy a decommissioned Dell R720, shove it in a closet, and pretend you are running a datacenter. Then your power bill spikes, your spouse hears a jet engine at 2am, and you realize you are cooling a server that idles at 200W to run three containers.

Stop that.

Mini PCs changed the game. Low power draw, dead silent, and enough compute for everything short of heavy GPU workloads. Two Beelink nodes running Proxmox VE give you a real cluster with HA, live migration, and room to grow.

The Hardware

Beelink SER5 MAX (AMD Ryzen 7 5800H)

Spec	Value
CPU	AMD Ryzen 7 5800H, 8C/16T, up to 4.4 GHz
TDP	54W (upgraded from the standard 45W 5800H config)
RAM	32 GB DDR4
Storage	1 TB NVMe M.2 2280 SSD
Networking	WiFi 6, Gigabit Ethernet
Bluetooth	BT 5.2
Display	4K triple output (HDMI + DP + USB-C)
Form Factor	Desktop mini PC, roughly 5” x 5”

Two of these. That is your cluster. 64 GB total RAM, 16 cores / 32 threads, 2 TB NVMe. Quiet enough to sit on your desk.

Total hardware cost: under $700 for both units.

Compare that to a used R720 at $300+ that pulls 150W idle and sounds like a leaf blower. The math is not close.

Why Proxmox VE

Proxmox is a Type 1 hypervisor built on Debian. KVM for full VMs, LXC for lightweight containers, and a web UI that does not make you want to throw your keyboard. Free tier is production-ready. No license keys, no feature gates.

What matters for this build:

Native clustering with two or more nodes
Live migration between nodes
ZFS support for snapshots and replication
Web management on port 8006
LXC containers that boot in seconds and use minimal overhead

If you have used ESXi, Proxmox is the same weight class without the licensing headache. VMware killed their free tier. Proxmox never had one to kill because the whole thing is free.

Cluster Architecture

Two Proxmox nodes on a dedicated management VLAN. Nothing else lives on this segment.

PVE-01: 10.10.10.10  |  pve01.bytesnation.com:8006
PVE-02: 10.10.10.20  |  pve02.bytesnation.com:8006

Both nodes joined into a single Proxmox cluster. Corosync handles quorum and inter-node communication. With two nodes, quorum is the critical design decision.

The Two-Node Quorum Problem

In a standard three-node cluster, losing one node still leaves two votes. Quorum holds. With two nodes, losing one means the survivor has one vote out of two. That is not a majority. The cluster goes read-only. HA stops. VMs will not start.

Three options:

QDevice (recommended). A lightweight Corosync daemon running on a third machine (a Raspberry Pi, a NAS, an LXC container on a different host). It acts as a tie-breaking voter. It does not run VMs or store data. It just votes. The QDevice must be physically separate from both nodes and reachable by both. If you put it on one of the nodes, you have solved nothing.
Manual quorum override. Set expected_votes to 1 on the surviving node during an outage. This works but requires SSH access and manual intervention. Not ideal at 2am.
Accept the limitation. If HA is not critical and you are fine manually starting VMs after a node failure, skip the complexity.

For a homelab that runs real services, option 1 is the right call. A Raspberry Pi running the QDevice daemon costs $35 and eliminates the split-brain risk entirely.

Network Segmentation

This is not a flat network. Every workload type gets its own VLAN with firewall rules controlling east-west traffic.

VLAN	ID	Subnet	Purpose
Management	10	10.10.10.0/24	Proxmox nodes, infrastructure management
Security Ops	20	10.10.20.0/24	Wazuh, security tooling
Workstations	30	192.168.30.0/24	User machines
IoT	40	172.16.40.0/24	IoT devices, fully isolated
Cameras	50	192.168.50.0/24	Surveillance, no internet egress
DMZ	66	192.168.66.0/24	Public-facing services
Lab	99	192.168.99.0/24	Hands-on testing and breakable things

Core routing handled by a UniFi Dream Machine Pro. Inter-VLAN firewall rules enforce least privilege. The Proxmox management interface is only accessible from VLAN 10. Nothing else touches it.

If you are running a homelab on a flat network with everything on the default VLAN: fix that before you do anything else. Segmentation is not optional. It is baseline hygiene.

Installation

Download the Proxmox VE ISO. Flash it to USB with Balena Etcher or Ventoy. Boot from USB. Follow the installer. Set a static IP on the management VLAN.

Post-install on each node:

apt update && apt full-upgrade -y

Then hit the web UI at https://<node-ip>:8006. Create the cluster on PVE-01:

pvecm create bytesnation-cluster

Join PVE-02:

pvecm add 10.10.10.10

Verify:

pvecm status

You should see two nodes, two votes, quorum achieved. The whole process takes about 20 minutes per node.

Proxmox community helper scripts can automate post-install housekeeping: removing the enterprise repo nag, enabling the no-subscription repo, disabling the subscription notice. Worth running on a fresh install.

Storage Strategy

Each node has 1 TB NVMe local storage. For this cluster size, local ZFS is the right call.

ZFS gives you:

Copy-on-write snapshots (instant, zero-cost)
Built-in compression (LZ4 default, roughly 1.5x space savings on VM disks)
Data integrity checksums on every block
Replication between nodes for disaster recovery

One thing to know: ZFS is memory-hungry. The general guidance is 1 GB of ARC cache per 1 TB of storage. With 32 GB per node and 1 TB drives, you have plenty of headroom. But if you expand storage later, account for it or you will watch your VMs swap.

For bulk storage (media, backups, ISOs), a separate TrueNAS box handles that over NFS or SMB. The Proxmox nodes stay compute-focused.

Backup strategy follows 3-2-1: three copies, two different media types, one off-site. Proxmox Backup Server integrates natively and handles incremental, deduplicated backups. For off-site, Restic or Duplicati push encrypted snapshots to cloud storage.

What Runs on the Cluster

The cluster is not a science project. It runs real workloads.

Full VMs (KVM):

Wazuh: XDR and SIEM for threat detection across the entire network
GitLab: self-hosted source control and CI runners
Fedora workstations: testing and development

LXC Containers:

Nginx Proxy Manager: reverse proxy with automatic Let’s Encrypt SSL
Docker host: runs lightweight containerized services
K3s: single-node Kubernetes for orchestration experiments
Dev/test environments that get rebuilt constantly

LXC containers are the force multiplier here. They boot in under a second, share the host kernel, and use a fraction of the resources a full VM needs. For anything that does not require a custom kernel or Windows, LXC is the move. A container running Nginx Proxy Manager uses about 128 MB of RAM. The equivalent VM would burn 512 MB minimum just on the OS.

Power and Thermals

Two Beelink SER5 MAX nodes under moderate load pull roughly 70 to 100W combined. The 54W TDP is per-node max, but sustained homelab workloads rarely pin the CPU. Real-world draw sits closer to 25 to 35W per node.

Compare that to a single rack server idling at 150 to 200W doing nothing.

No fans screaming. No dedicated cooling. No heat buildup in a closet. These sit on a shelf and do their job.

At $0.12/kWh, two Beelink nodes cost roughly $8 to $10 per month in electricity. A rack server idles at $15 to $20. Over a year, the savings cover a meaningful chunk of the hardware cost.

Lessons Learned

Start with VLANs. Retrofitting network segmentation after you have 20 services running is painful. Design your VLAN scheme before you deploy the first VM.

Plan quorum before you need it. A two-node cluster without a QDevice will bite you during the one outage you did not plan for. Spend the $35 on a Pi and set it up on day one.

LXC over VMs when possible. Every full VM you replace with an LXC container frees up RAM and CPU for workloads that actually need isolation. Most services do not.

ZFS replication is your safety net. Schedule replication jobs between nodes. If a drive fails, you have a recent copy on the other node ready to promote. This is not backup. This is continuity.

Document everything. Your future self at 2am troubleshooting a VLAN firewall rule will thank you. If it is not written down, it does not exist.

Bottom Line

You do not need enterprise hardware to run enterprise workloads at home. Two Beelink mini PCs, Proxmox VE, and deliberate network design give you a cluster that is silent, efficient, and capable of running security monitoring, source control, reverse proxies, and Kubernetes.

Total investment: under $700 in hardware and zero in software licensing.

Stop overbuilding. Start operating.

Claude Code Hooks: The Field Manual You Actually Need

Wed, 08 Apr 2026 00:00:00 GMT

Stop Letting Claude Run Unsupervised

Here is the problem. You hand Claude Code a task, it starts executing tools, and you are sitting there babysitting every permission prompt like a hall monitor. Or worse, you turn on auto-accept and pray nothing catches fire.

Hooks fix this. They are shell commands, HTTP calls, or AI prompts that fire at specific points in Claude’s execution lifecycle. Think of them as tripwires and gate checks you plant across the workflow. Claude hits a trigger point, your hook runs, and you decide what happens next: allow, deny, modify, log, or block.

No plugins. No extensions. Just config and scripts.

What Hooks Actually Are

A hook is a user-defined action that executes when Claude Code hits a specific event during a session. You are not modifying Claude’s behavior. You are inserting control points around it.

The mental model: hooks are middleware for your AI coding assistant. Same concept as Git hooks, CI pipeline stages, or request interceptors. An event fires, your code runs, and the output determines what happens next.

Hooks can be:

Command hooks: Shell scripts or CLI commands that run locally
HTTP hooks: Outbound requests to a local or remote endpoint
Prompt hooks: An AI prompt that gets evaluated inline
Agent hooks: A sub-agent that spins up to handle the check

Most of the time, you are writing command hooks. Shell scripts. The thing you already know how to do.

Where Hooks Live

Configuration goes in JSON files. Three scopes, hierarchical precedence:

File	Scope	Shared
`~/.claude/settings.json`	All projects on this machine	No
`.claude/settings.json`	This project, all contributors	Yes, commit it
`.claude/settings.local.json`	This project, only you	No, gitignore it

Higher specificity wins. Local overrides project. Project overrides user. Simple chain of command.

The structure inside any of these files:

{
  "hooks": {
    "EventName": [
      {
        "matcher": "ToolNameOrPattern",
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/your/script.sh",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

That is the skeleton. Every hook config follows this pattern. Event name as the key, array of matcher objects, each matcher containing an array of hook definitions.

The Event Catalog

Claude Code fires events at every meaningful lifecycle point. Here are the ones that matter for day-to-day operations, grouped by when you would actually care about them.

Session Lifecycle

SessionStart: Fires when a session begins or resumes. Use this to load environment variables, set up tooling context, or initialize project-specific state. Your script gets access to CLAUDE_ENV_FILE; write exports to that file and they persist for the entire session.

SessionEnd: Session terminates. Cleanup, logging, metrics collection.

CwdChanged: Working directory changes mid-session. Reload environment configs, update path-dependent state.

Before a Tool Runs

PreToolUse: The big one. Fires before any tool executes. You can inspect what Claude is about to do and return a decision:

allow: Let it through, skip the permission prompt
deny: Kill it. Tool does not execute. Claude gets your reason.
ask: Force the permission prompt regardless of mode
defer: Pause execution for external approval (CI, Slack, whatever)

You can also return updatedInput to modify the tool’s parameters before execution. Rewrite a command, change a file path, sanitize an argument. Claude never knows you touched it.

PermissionRequest: Fires when the permission dialog would appear. Same decision options. This is your programmatic “approve all” or “deny all” gate.

After a Tool Runs

PostToolUse: Tool succeeded. Inspect the output, run validation, trigger linters, log the action, or inject feedback that Claude will see in its context.

PostToolUseFailure: Tool failed. Provide corrective context so Claude adjusts its approach instead of blindly retrying.

Response Lifecycle

Stop: Claude finished its response. You can block the completion and force it to continue, or inject a system message. Useful for enforcing output standards.

SubagentStop: A sub-agent finished. Same controls as Stop but scoped to delegated work.

UserPromptSubmit: Fires before Claude processes what you typed. Add context, validate input, or block the prompt entirely.

Notification Events

Notification: Fires on permission prompts, idle states, auth events. The matcher filters by notification type: permission_prompt, idle_prompt, auth_success.

Matchers: Targeting Your Hooks

The matcher field is a regex pattern that filters which specific tools or event subtypes trigger your hook. No matcher means it fires on everything for that event.

Common patterns:

"Bash"              # Only Bash tool calls
"Write|Edit"        # File write or edit operations
"mcp__memory__.*"   # Any tool from the memory MCP server
"mcp__.*__write.*"  # Any write operation on any MCP server
"*"                 # Everything (same as omitting matcher)

For PreToolUse and PostToolUse, the matcher targets tool names. For Notification, it targets notification types. For SubagentStop, it targets agent types.

There is also the if field for tighter filtering within tool events:

{
  "matcher": "Bash",
  "hooks": [
    {
      "type": "command",
      "if": "Bash(rm *)",
      "command": "./hooks/block-destructive.sh"
    }
  ]
}

The if pattern matches against the tool name and a substring of its arguments. This hook only fires on Bash calls that contain “rm” in the command. Everything else passes through untouched.

What Your Hook Receives

Every hook gets a JSON payload on stdin with context about the event. The common fields across all events:

{
  "session_id": "abc123",
  "transcript_path": "/path/to/transcript.jsonl",
  "cwd": "/current/working/directory",
  "permission_mode": "default",
  "hook_event_name": "PreToolUse"
}

Tool events add tool_name and tool_input with the full parameters Claude passed. A Bash hook gets tool_input.command. A Write hook gets tool_input.file_path and tool_input.content. You parse what you need with jq and act on it.

Environment variables available to command hooks:

Variable	Purpose
`CLAUDE_PROJECT_DIR`	Root of the current project
`CLAUDE_ENV_FILE`	File path for persisting env vars (SessionStart)
`CLAUDE_CODE_REMOTE`	”true” if running in web mode

What Your Hook Returns

Your hook communicates back through exit codes and JSON on stdout.

Exit codes:

0: Success. stdout JSON is processed.
2: Blocking error. stderr is fed back to Claude. Execution halts for this hook.
1, 3+: Non-blocking error on most events. Hook failure does not stop the workflow.

JSON output for PreToolUse:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Blocked: destructive filesystem operation",
    "additionalContext": "Use targeted rm commands instead of recursive wildcards"
  }
}

JSON output for PostToolUse/Stop (blocking):

{
  "decision": "block",
  "reason": "Output failed validation. Fix lint errors before continuing."
}

Universal fields any hook can return:

{
  "continue": true,
  "suppressOutput": false,
  "systemMessage": "Warning shown to the user in the UI",
  "additionalContext": "Injected into Claude's context window"
}

Set continue to false with a stopReason to kill the session. Use additionalContext to feed Claude information it would not otherwise have. Use systemMessage to surface warnings in the terminal.

Practical Cases That Actually Matter

Theory is useless without application. Here are real scenarios, configured and explained.

Case 1: Block Destructive Commands

You do not want Claude running rm -rf, git push --force, DROP TABLE, or anything that nukes state. This is your first hook. Deploy it before anything else.

Script at .claude/hooks/guard-destructive.sh:

#!/bin/bash
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

if [ -z "$COMMAND" ]; then
  exit 0
fi

BLOCKED_PATTERNS=(
  'rm -rf'
  'rm -r /'
  'git push.*--force'
  'git reset --hard'
  'DROP TABLE'
  'DROP DATABASE'
  'mkfs\.'
  '> /dev/sd'
)

for PATTERN in "${BLOCKED_PATTERNS[@]}"; do
  if echo "$COMMAND" | grep -qE "$PATTERN"; then
    echo "{
      \"hookSpecificOutput\": {
        \"hookEventName\": \"PreToolUse\",
        \"permissionDecision\": \"deny\",
        \"permissionDecisionReason\": \"Blocked: matched destructive pattern '$PATTERN'\"
      }
    }"
    exit 0
  fi
done

exit 0

Config in .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/guard-destructive.sh",
            "timeout": 10,
            "statusMessage": "Checking command safety..."
          }
        ]
      }
    ]
  }
}

Make the script executable: chmod +x .claude/hooks/guard-destructive.sh

Claude tries rm -rf /tmp/build, the hook catches it, denies it, and tells Claude why. Claude adjusts. No data lost. No drama.

Case 2: Auto-Lint After Every File Change

Every time Claude writes or edits a file, run the linter. If it fails, feed the errors back so Claude fixes them in the same pass instead of you catching it later.

Script at .claude/hooks/lint-on-write.sh:

#!/bin/bash
INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

if [ -z "$FILE_PATH" ]; then
  exit 0
fi

case "$FILE_PATH" in
  *.ts|*.tsx|*.js|*.jsx)
    LINT_OUTPUT=$(cd "$CLAUDE_PROJECT_DIR" && npx eslint "$FILE_PATH" 2>&1)
    LINT_EXIT=$?
    ;;
  *.py)
    LINT_OUTPUT=$(cd "$CLAUDE_PROJECT_DIR" && python -m ruff check "$FILE_PATH" 2>&1)
    LINT_EXIT=$?
    ;;
  *)
    exit 0
    ;;
esac

if [ $LINT_EXIT -ne 0 ]; then
  ESCAPED=$(echo "$LINT_OUTPUT" | jq -Rs .)
  echo "{
    \"additionalContext\": \"Lint errors detected in $FILE_PATH. Fix these before moving on:\\n$LINT_OUTPUT\"
  }"
fi

exit 0

Config:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/lint-on-write.sh",
            "timeout": 30,
            "statusMessage": "Running linter..."
          }
        ]
      }
    ]
  }
}

Claude writes a TypeScript file with an unused import. The hook catches it, feeds the error back, and Claude removes the import. All in one cycle. No second pass needed.

Case 3: Session Bootstrap

Load your NVM version, set environment variables, and prime the session with project context on startup. No more “please use Node 20” prompts.

Script at .claude/hooks/session-init.sh:

#!/bin/bash
if [ -z "$CLAUDE_ENV_FILE" ]; then
  exit 0
fi

# Load NVM and set Node version
export NVM_DIR="$HOME/.nvm"
if [ -s "$NVM_DIR/nvm.sh" ]; then
  source "$NVM_DIR/nvm.sh"
  nvm use 20 > /dev/null 2>&1
fi

# Persist environment for the session
echo "export NODE_ENV=development" >> "$CLAUDE_ENV_FILE"
echo "export EDITOR=vim" >> "$CLAUDE_ENV_FILE"

# If there is a .nvmrc, respect it
if [ -f "$CLAUDE_PROJECT_DIR/.nvmrc" ]; then
  NODE_VERSION=$(cat "$CLAUDE_PROJECT_DIR/.nvmrc")
  echo "export PATH=\"$NVM_DIR/versions/node/v$NODE_VERSION/bin:\$PATH\"" >> "$CLAUDE_ENV_FILE"
fi

exit 0

Config:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/session-init.sh",
            "timeout": 15,
            "statusMessage": "Initializing session environment..."
          }
        ]
      }
    ]
  }
}

Session starts. Environment is loaded. No asking, no prompting, no wasted cycles.

Case 4: Audit Log for Compliance

Every tool call gets logged with a timestamp, tool name, and parameters. Useful for security reviews, incident reconstruction, or just knowing what happened in a session.

Script at .claude/hooks/audit-log.sh:

#!/bin/bash
INPUT=$(cat)
TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // "unknown"')
EVENT=$(echo "$INPUT" | jq -r '.hook_event_name // "unknown"')
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
SESSION=$(echo "$INPUT" | jq -r '.session_id // "unknown"')

LOG_DIR="$CLAUDE_PROJECT_DIR/.claude/logs"
mkdir -p "$LOG_DIR"

echo "$INPUT" | jq -c "{
  timestamp: \"$TIMESTAMP\",
  session: \"$SESSION\",
  event: \"$EVENT\",
  tool: \"$TOOL_NAME\",
  input: .tool_input
}" >> "$LOG_DIR/audit-$(date +%Y-%m-%d).jsonl"

exit 0

Config:

{
  "hooks": {
    "PreToolUse": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/audit-log.sh",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

Every action, timestamped, structured, searchable. Pipe it into your SIEM, grep it for incident response, or just keep receipts.

Case 5: Protect Sensitive Files

Deny reads or writes to files that contain secrets, credentials, or infrastructure configs that Claude has no business touching.

Script at .claude/hooks/protect-sensitive.sh:

#!/bin/bash
INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_input.command // empty')

PROTECTED_PATTERNS=(
  '\.env'
  'credentials'
  '\.pem$'
  '\.key$'
  'secrets\.'
  'terraform\.tfstate'
  'kubeconfig'
  '\.kube/config'
)

for PATTERN in "${PROTECTED_PATTERNS[@]}"; do
  if echo "$FILE_PATH" | grep -qE "$PATTERN"; then
    echo "{
      \"hookSpecificOutput\": {
        \"hookEventName\": \"PreToolUse\",
        \"permissionDecision\": \"deny\",
        \"permissionDecisionReason\": \"Access denied: '$FILE_PATH' matches protected pattern. Sensitive files are off limits.\"
      }
    }"
    exit 0
  fi
done

exit 0

Config:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Write|Edit|Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect-sensitive.sh",
            "timeout": 5,
            "statusMessage": "Checking file access..."
          }
        ]
      }
    ]
  }
}

Claude tries to read your .env file to “check the database URL.” Hook says no. Claude works with what it has or asks you for the value. Your secrets stay where they belong.

Case 6: MCP Server Tool Monitoring

If you are running MCP servers (memory, database, external services), you want visibility into what Claude is doing with those tools.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "mcp__.*",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/audit-log.sh",
            "timeout": 5,
            "statusMessage": "Logging MCP operation..."
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "mcp__.*__write.*|mcp__.*__delete.*|mcp__.*__update.*",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/audit-log.sh",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

The mcp__<server>__<tool> naming convention makes regex targeting clean. Log everything, or scope it to write/delete operations. Your call.

Case 7: HTTP Webhook for Team Visibility

Push hook events to an external endpoint. Slack notifications, dashboards, approval workflows. Whatever your team needs.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "http",
            "url": "http://localhost:9090/hooks/pre-tool",
            "timeout": 15,
            "headers": {
              "Authorization": "Bearer $HOOK_API_TOKEN"
            },
            "allowedEnvVars": ["HOOK_API_TOKEN"]
          }
        ]
      }
    ]
  }
}

The allowedEnvVars field explicitly whitelists which environment variables get resolved in the headers. Nothing leaks that you did not approve.

Combining Multiple Hooks

You can stack hooks on the same event. They execute in order. If any hook denies or blocks, the chain stops.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/guard-destructive.sh",
            "timeout": 10
          },
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/audit-log.sh",
            "timeout": 5
          }
        ]
      },
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect-sensitive.sh",
            "timeout": 5
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/lint-on-write.sh",
            "timeout": 30
          }
        ]
      }
    ],
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/session-init.sh",
            "timeout": 15
          }
        ]
      }
    ]
  }
}

This is a real production config. Destructive command guard, audit logging, sensitive file protection, auto-linting, and session bootstrap. All running without you lifting a finger after initial setup.

Async Hooks

Some hooks do not need to block execution. Logging is a perfect example. Set "async": true and the hook fires in the background. Claude does not wait for it.

{
  "type": "command",
  "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/audit-log.sh",
  "async": true,
  "timeout": 10
}

Use async for: logging, metrics, notifications. Keep synchronous for: guards, validators, linters.

Debugging Hooks

Hooks not firing? Here is the checklist:

Check the file location. Is your config in the right settings file for the scope you need?
Validate the JSON. One misplaced comma kills the entire hooks config. Use jq . .claude/settings.json to validate.
Check script permissions. chmod +x on your hook scripts. This catches people more than anything.
Check the matcher. Regex is exact. "Bash" matches Bash, not bash. Tool names are PascalCase.
Check exit codes. Exit 0 means success. Exit 2 means blocking error. Anything else is a soft failure.
Read stderr. If your script errors, stderr output shows in the Claude Code interface.
Use /hooks in the CLI. Type it during a session to see all configured hooks and their status.
Test your script standalone. Pipe sample JSON into your script and check the output: echo '{"tool_input":{"command":"rm -rf /"}}' | ./hooks/guard-destructive.sh

Security Considerations

Hooks run with your user permissions. They can do anything you can do. That means:

Do not put secrets in hook scripts. Use environment variables.
Do not fetch or execute remote code in hooks without verifying the source.
Commit .claude/settings.json with your hook configs so the team gets the same guardrails.
Keep .claude/settings.local.json in .gitignore for machine-specific overrides.
Review hook scripts in PRs the same way you review application code. They are part of your security posture.
The allowedEnvVars field on HTTP hooks exists for a reason. Use it. Do not leak tokens through lazy wildcard configs.

When Not to Use Hooks

Hooks are not a silver bullet. Do not use them for:

Complex business logic. If your hook script exceeds 50 lines, you are building a service, not a hook. Extract it.
Replacing CI/CD. Hooks run locally. They are not a substitute for pipeline gates.
Micromanaging Claude. If you are writing a hook for every possible edge case, you are fighting the tool instead of using it. Set the big guardrails and trust the model for the rest.

The Bottom Line

Hooks give you programmatic control over Claude Code’s execution lifecycle. Set them up once, forget about them, and let them enforce your standards automatically. The five minutes you spend writing a guard script saves you from the one time Claude decides rm -rf is the right answer.

Start with the destructive command guard. Add the sensitive file protector. Layer in audit logging. Then customize from there. That is your deployment order. That is your minimum viable hook setup.

Now stop reading and go configure them.

Welcome to the Lab

Wed, 08 Apr 2026 00:00:00 GMT

Welcome to the Lab

This is BytesNation, a handcrafted tech lab where I document builds, experiments, and field notes across 3D printing, networking, cybersecurity, and datacenter architecture.

Everything here is built by one person, broken on purpose, and written down so the next person does not start from scratch.

Who Is Running This Lab

Combat veteran. Self-taught systems architect. Sixteen years of enterprise infrastructure, firewalls, datacenter design, and network operations. Started hosting gaming servers as a teenager. That turned into managing enterprise networks. Networks turned into firewalls. Firewalls turned into datacenter architecture and capacity planning. Somewhere along the way, 3D printers and microcontrollers showed up on the bench, because the fastest way to understand a system is to build one from the floor up.

No computer science degree. No formal training pipeline. Just obsessive curiosity and a habit of breaking things until they work.

The Physical Lab

The current setup is a two-node Proxmox cluster running on Beelink mini PCs. Quiet enough to run in a home office, powerful enough to virtualize a real network stack. VMs for pfSense, a VLAN-segmented flat network, Unifi access points, and a monitoring stack built on Prometheus and Grafana. The cluster runs continuously on a UPS.

On the bench right now: a 3D printer for enclosures and cable management hardware, a Raspberry Pi cluster for experimenting with edge compute, and a dedicated test network for running attack-and-defend scenarios without touching production.

The lab is not a showroom. It is a working environment. Things break. That is the point.

What Gets Documented Here

Homelab and Infrastructure: Proxmox builds, network topologies, VLAN segmentation, storage configuration, monitoring stacks. The kind of setup you can replicate at home for a few hundred dollars instead of a few hundred thousand.

Cybersecurity: Threat modeling, firewall configuration, incident response workflows, CTF writeups, and analysis of real-world breaches. Defensive security first, always.

AI and Automation: Large language models, agentic workflows, Model Context Protocol integrations, and what it actually means to wire AI into a production environment. Not hype. Hands-on builds.

3D Printing and Hardware: Functional prints, not decorative ones. Enclosures, rack accessories, cable management, custom brackets. If it saves time or improves a build, it gets documented.

Networking: Protocols, architecture, routing decisions, and the reasoning behind them. Why you would choose one topology over another. How to think about network design when budget, noise, and physical space are all real constraints.

Why Build in the Open

Most of what I know came from someone else’s build log. A forum post from 2014. A GitHub repo with no README but a config file that answered the exact question I had been stuck on for three days. A YouTube video from a homelab channel with 800 subscribers that explained subnetting better than any book I read.

Knowledge hoarding is a dead end. The field moves fast enough that yesterday’s secrets are tomorrow’s blog posts anyway. BytesNation exists because I got tired of being the person who figured something out and never wrote it down.

When I document a build, I document the failures too. The things that looked right on paper and did not work in practice. The edge cases. The second and third attempts. The polished end result without that context is useless to the next person who hits the same wall.

The Stack Running This Site

This site is built with Astro, a static site framework that outputs plain HTML. Blog posts are markdown files processed at build time. No CMS, no database, no runtime server, no dependencies I cannot audit. React handles the interactive pieces, Tailwind handles the styling, and the whole thing deploys to Render as a static site.

The code is available on GitHub. If something looks wrong or could be done better, the repository is open.

export function getAllPosts(): BlogPost[] {
  const markdownFiles = import.meta.glob(
    "../content/blog/*.md",
    { query: "?raw", import: "default", eager: true }
  );

  return Object.entries(markdownFiles)
    .map(([filepath, raw]) => parsePost(filepath, raw))
    .filter((post) => post.published)
    .sort((a, b) => b.date.localeCompare(a.date));
}

Static output means every page is pre-rendered HTML. No JavaScript required to read an article. No tracking pixels beyond Google Analytics, which you can block. No paywalls.

What Is Next

The first batch of posts covers the foundational layer: understanding how AI models actually work, building a Proxmox cluster on mini PCs, configuring network firewalls and WAFs, and wiring AI into your personal knowledge management system. From there, the content follows what is actually on the bench.

If you have a question about a build, a post, or the lab setup, the About page has the channels I actually check. The lab is open. Come in.

Network Firewalls vs. Web Application Firewalls: What Each One Actually Defends

Thu, 26 Dec 2024 00:00:00 GMT

Network Firewalls vs. Web Application Firewalls: What Each One Actually Defends

Both devices are called firewalls. Both block traffic. That is where the similarity ends.

Network firewalls and Web Application Firewalls (WAFs) operate at different layers of the OSI model, inspect different things, and fail against different attack types. Running one without the other leaves real gaps. Understanding the difference is not an academic exercise; it is the foundation of any layered security architecture.

The Core Distinction: Which Layer They Inspect

A network firewall works at Layers 3 and 4 of the OSI model, the Network and Transport layers. It sees IP addresses, ports, and protocols. It makes decisions based on those values: allow TCP from this IP to port 443, block everything else from this subnet, deny UDP except from these sources.

A WAF works at Layer 7, the Application layer. It sees the actual content of HTTP and HTTPS requests: the URL path, query parameters, headers, cookies, and request body. It makes decisions based on what is inside the traffic, not just where it came from.

That distinction determines everything about what each device can and cannot protect against.

What Network Firewalls Do Well

Network firewalls are the perimeter. They answer the question: should this connection be allowed to exist at all?

A well-configured network firewall blocks inbound connections to ports you are not running services on. It prevents direct access to your database server from the public internet. It enforces network segmentation so a compromised web server cannot directly reach your internal DNS or Active Directory. It rate-limits or drops flood traffic before it saturates upstream links.

Stateful packet inspection lets a modern firewall track connection state, not just individual packets. It can allow an outbound TCP connection to be initiated from inside your network and permit the inbound response traffic without opening a broad inbound rule. This is the difference between a stateless packet filter and an actual firewall.

Intrusion prevention capabilities in next-generation firewalls (NGFWs) extend this further. They can detect and block known exploit patterns, command-and-control callbacks, and malicious DNS lookups using signature-based detection at the network layer.

What a network firewall cannot do: it cannot read the contents of an HTTP request that arrives on port 443. If the connection is allowed, the firewall lets it through. What happens inside that HTTP request is invisible to it.

What Web Application Firewalls Do Well

A WAF defends the application from traffic that already has permission to connect.

SQL injection is the canonical example. An attacker sends a POST request to your login form with a payload like ' OR 1=1 -- in the username field. The connection came from a legitimate IP, over port 443, using HTTPS. A network firewall sees nothing wrong. The WAF reads the request body, matches the payload against SQL injection signatures, and blocks the request before it reaches your application code.

The same principle applies to cross-site scripting (XSS), where an attacker tries to inject <script> tags into a form field that will later be rendered in another user’s browser. Or path traversal attacks, where a request to /api/files?path=../../etc/passwd is trying to read your server’s password file. Or HTTP request smuggling, where malformed headers try to desynchronize a proxy and backend server to sneak unauthorized requests through.

All of these attacks arrive on allowed ports from non-blocked IPs. The network firewall has no mechanism to detect them. The WAF exists specifically to inspect the HTTP layer and block them.

WAFs also handle rate limiting at the application layer. Not just “this IP is sending too many TCP connections” but “this IP has submitted 50 login attempts in 30 seconds” or “this client is scraping every product page on your site at 200 requests per minute.” Application-layer rate limiting lets you enforce much more meaningful thresholds than connection-level throttling.

Where Each One Fails

Network firewall blind spots:

Encrypted HTTPS traffic is the biggest gap. A network firewall sees that encrypted data is flowing over port 443, but it cannot inspect the contents without performing TLS termination, which introduces latency, certificates, and complexity that most organizations skip. Everything inside TLS is opaque to a standard network firewall.

Zero-day application exploits that do not match known signatures will pass through most network firewall inspection engines. A novel SQL injection technique or a new deserialization gadget chain in your Java application is not a network-layer event.

Authorized users abusing their access. If an authenticated user is exfiltrating data through a legitimate API endpoint, the network firewall sees legitimate traffic from an authorized source.

WAF blind spots:

Network-layer attacks are completely out of scope. A volumetric DDoS flood, a port scan, an attempt to connect directly to a database port, ARP spoofing on the local network. The WAF only sees HTTP/HTTPS. Everything else is invisible to it.

Encrypted bypasses. If a WAF is deployed in a pass-through mode without TLS termination, encrypted traffic is as opaque to it as it is to the network firewall. Many WAFs require you to terminate TLS at the WAF to inspect traffic properly, which means your WAF holds your SSL certificates.

Business logic flaws. A WAF cannot understand that your application should only allow a user to purchase one unit of a limited item, or that a password reset token should expire after one use, or that an account should lock after five failed login attempts if you have not implemented that logic in your app. WAFs block known attack patterns; they do not understand your application’s intent.

OSI Layer Reference

Device	OSI Layers	Sees	Cannot See
Network Firewall	3-4 (Network, Transport)	IP, port, protocol, connection state	HTTP content, URLs, query params, cookies
WAF	7 (Application)	HTTP/HTTPS content, headers, body, URLs	Non-HTTP traffic, IP-level attacks
NGFW with TLS inspection	3-7	Everything above, decrypted	Attacks that evade signatures

Deployment Patterns

Edge network firewall, WAF in front of web tier:

The most common architecture. Network firewall at the perimeter handles all inbound traffic. Only ports 80 and 443 pass through to the DMZ. WAF sits in front of the web servers, terminates TLS, inspects HTTP, and forwards clean traffic. Network firewall also enforces east-west rules: the web tier cannot initiate connections to the database tier except on the application port.

Internet
    |
[Network Firewall]  ← blocks all non-80/443 inbound
    |
[WAF / Load Balancer]  ← terminates TLS, inspects HTTP
    |
[Web Servers]
    |
[Network Firewall]  ← internal segmentation rule
    |
[Database Servers]

Cloud WAF with on-prem network firewall:

If you are running on AWS, GCP, or Azure, you likely have cloud-native WAF options (AWS WAF, Azure Application Gateway with WAF, Cloudflare WAF). These sit in front of your cloud-hosted application and handle HTTP inspection. Your VPC security groups or cloud firewall rules handle network-layer access control. The two layers stack without requiring you to run your own WAF appliance.

Reverse proxy as WAF:

NGINX and HAProxy can perform basic WAF functions via ModSecurity or similar modules. If you do not have budget for a dedicated WAF appliance, a reverse proxy configured with the OWASP Core Rule Set (CRS) provides a meaningful baseline. It is not a full commercial WAF, but it will catch the most common automated attacks.

When You Need Both

The answer to “do I need both?” is almost always yes if you are running any web-facing application.

The network firewall protects your infrastructure. It enforces the principle that only the services you intend to expose are reachable from the internet. It prevents lateral movement if a host is compromised. It gives you the ability to block entire IP ranges, countries, or ASNs at scale.

The WAF protects your application. It handles the attack surface that exists within legitimate HTTP traffic, which is the attack surface that matters most for anything a user can reach through a browser.

Neither replaces the other. A network firewall with no WAF leaves your application unprotected against SQL injection, XSS, and every other Layer 7 attack. A WAF with no network firewall leaves your infrastructure directly exposed: a misconfigured port, an unintended service, a debug endpoint that should never have been reachable from the internet.

Run both. Put the network firewall at the edge. Put the WAF in front of the application tier. Configure rules on both. Review logs on both.

Virtual Firewalls in Cloud Environments

Cloud environments blur the hardware distinction but not the functional one. Virtual firewalls and security groups handle Layer 3 and 4 access control for your cloud network: which VMs can talk to which, which ports are open, what traffic is allowed in from the internet. Cloud WAFs handle Layer 7 inspection for web-facing services.

Aspect	WAF	Virtual Firewall / Security Group
OSI Layer	7 (Application)	3-4 (Network, Transport)
Protection Target	Web servers, APIs, applications	Networks, VMs, containers, cloud resources
Attack Types	XSS, SQLi, path traversal, API abuse	Port scans, unauthorized connections, DDoS at L3/4
Traffic Inspected	HTTP/HTTPS content	Any protocol (TCP, UDP, ICMP)
Typical Deployment	In front of application tier	VPC/network perimeter and internal segments

The cloud provider gives you both primitives. Use both. Security groups are not optional because you have a WAF. A WAF is not optional because you have security groups.

The Practical Summary

If someone compromises a router on your network, a network firewall controls whether that router can reach your database. A WAF has nothing to say about it. If someone submits a SQL injection payload through your contact form, a WAF catches it. A network firewall has nothing to say about it.

Different threats. Different defenses. Neither is complete without the other.

BytesNation

Agentic Claude Code: How Agents, Hooks, and Orchestration Actually Work

[Field Notes] Proxmox VE Node Hardening: SSH Lockdown and Non-Root Admin Access

[Field Notes] Building a Zero-Trust Homelab with YubiKey PIV

How Do You Know That Download Is Safe? Checksums, GPG, and File Integrity Explained.

167 Vulnerabilities, One Exploited Zero-Day, and a Secure Boot Clock: Microsoft April 2026 Patch Tuesday

167 Vulnerabilities, One Exploited Zero-Day, and a Secure Boot Clock: Microsoft April 2026 Patch Tuesday

What Patch Tuesday Actually Is

The SharePoint Zero-Day

The Remote Desktop Spoofing Zero-Day

The Defender Flaw with Code on GitHub

The New RDP Phishing Protection

The Secure Boot Certificate Clock

What to Do Right Now

The Bigger Picture

Operation Masquerade: FBI, NSA, and DOJ Dismantle Russian GRU Router Hijacking Network

Operation Masquerade: FBI, NSA, and DOJ Dismantle GRU Router Hijacking Network

The Threat

How It Worked

The Scale

What Stopped It

What You Should Do

The Bottom Line

Stanford Just Dropped AI's Report Card. The Numbers Do Not Care About Your Feelings.

Stanford Just Dropped AI’s Report Card. The Numbers Do Not Care About Your Feelings.

Models Are Outrunning Everything

The Benchmarks Are Broken

US and China: Razor Thin Margins

The Power Bill

The Job Market Is Already Moving

Operational Takeaways

Sources

10 Tools. One Brain. The Stack That Actually Builds Things.

10 Tools. One Brain. The Stack That Actually Builds Things.

The Foundation

The Nervous System

The Stack

The Full Loop

Start Somewhere

Your Homelab Has a Brain Now. Here Is How to Wire It.

Your Homelab Has a Brain Now. Here Is How to Wire It.

The Stack

How It Actually Works

Why Your Homelab Is the Right Place for This

What You Can Build With This

Where to Start

The Close

Sources

Prompt Engineering Is Not Magic. It Is Instruction Writing.

You Know How the Engine Works. Now Learn to Drive.

The Five Principles

Technique 1: Role and Context Assignment

Technique 2: Few-Shot Examples

Technique 3: Structured Formatting with Tags

Technique 4: Chain of Thought

Technique 5: Output Constraints

Technique 6: Context Placement

Technique 7: Negative Constraints

Technique 8: Iterative Refinement

The Anti-Patterns

Platform-Specific Tips

Claude (Anthropic)

GPT-5 (OpenAI)

Gemini 3 (Google)

Quick Reference: Technique Cheat Sheet

Bottom Line

Sources

How AI Actually Works: Tokens, Context Windows, and Why Your Chatbot Forgets Things

MCP Hit 97 Million Installs. The Protocol War Is Over.

Your AI Tools Are About to Get a Lot More Useful

What MCP Actually Is

How It Works Under the Hood

The Three Resource Types

The Competitive Landscape

Why This Matters Right Now

The BytesNation Angle

Sources

AI Agents Are Already Making Decisions for You. Here Is What That Means.

You Are Already Interacting with AI Agents

What an AI Agent Actually Is