DEV Community: Daniel Montes

Layer 3 of the Agentic OS: Taming AI with Deterministic Hooks and Workflows

Daniel Montes — Sat, 02 May 2026 17:26:18 +0000

In our previous article, we explored Layer 2 (On-Demand Capabilities), which scales an AI assistant's intelligence by providing specialized Prompts and Custom Agents precisely when a developer needs them.

But as you scale AI agents across an enterprise organization, a fundamental problem emerges: LLMs are inherently probabilistic. They guess the next best string of tokens based on vast parameter networks.

Enterprise platform engineering, however, absolutely demands determinism. You cannot rely on an AI's "best guess" when it decides to modify a critical infrastructure file, parse sensitive data, or interact with a deployment pipeline.

This is exactly where Layer 3 — Enforcement & Automation comes into play. It is the governance layer that wraps your probabilistic AI in strict, deterministic rules.

Achieving Determinism

Layer 3 introduces structural controls through system hooks and automated, autonomous workflows. It proves that an true Agentic OS isn't just about generating code faster inside your IDE; it is about operating a repository securely at scale.

This layer consists of two powerful primitives:

1. Hooks (`.github/hooks/*.json`)

Hooks are deterministic shell commands that fire automatically at specific moments during an agent's lifecycle. If you are familiar with Git hooks (like pre-commit or pre-push), agent hooks follow the exact same structural philosophy.

They are incredibly powerful for establishing policy gates and file access controls—without relying on the LLM to "follow the rules" defined in a standard prompt.

Common Lifecycle Events:

preToolUse: Fires before an agent is allowed to execute a tool. This is vital. A hook can run a shell script to verify if the AI has the organizational permission to modify a specific file or directory, and programmatically approve or deny the execution before any damage occurs.
postToolUse: Fires immediately after a tool is used, making it perfect for writing detailed audit logs for compliance tracking.
errorOccurred: Automatically triggers self-healing routines or alerts an engineering manager if an agent enters an infinite loop or fails catastrophically.

2. Agentic Workflows (`.github/workflows/`)

While developers interact with Copilot actively in their editors, a true Agentic OS runs 24/7 in the background.

Agentic Workflows allow platform teams to define natural language chore automations that compile down into functional YAML GitHub Actions (often via tools like the gh aw CLI). Because they run unattended in the background, they operate with read-only permissions by default, ensuring maximum safety.

Common Use Cases:

Autonomous Issue Triage: A background workflow wakes up, reads newly created GitHub issues, categorizes them, assigns appropriate technical tags, and attempts to flag duplicate bug reports.
CI/CD Failure Analysis: When a pipeline breaks, a background workflow analyzes the convoluted error logs, identifies the offending commit, and leaves a detailed issue comment explaining the exact fix to the responsible developer.

Conclusion

Layer 3 bridges the painful gap between an individual developer's productivity tool and a compliant, enterprise-grade development platform. By utilizing Hooks and Agentic Workflows, you ensure your AI assistants operate strictly and deterministically within the boundaries of your organizational policies.

At this point, you have built a perfect Agentic OS tailored for a single repository. But what if your company has 500 repositories fragmented across 20 different engineering teams?

In the fourth and final article of this series, we will explore Layer 4 — Distribution, detailing how to cleanly package your context, agents, and hooks into Plugins to share and enforce intelligence across your entire enterprise.

Note: This article is part of the "GitHub Copilot Agentic OS" series.

Layer 2 of the Agentic OS: On-Demand Capabilities for GitHub Copilot

Daniel Montes — Sat, 25 Apr 2026 17:28:13 +0000

In our previous article, we discussed how Layer 1 (Always-On Context) forms the bedrock of your Agentic OS by silently injecting global coding standards into every prompt. It is incredibly powerful, but it introduces a new scaling problem: context exhaustion.

If you stuff every architectural diagram, deployment runbook, and security protocol into your .github/copilot-instructions.md, you will inevitably overwhelm the Large Language Model (LLM). This dilutes the AI's focus, increases latency, and triggers the dreaded "hallucinations."

To keep the AI sharp, we need intentionality. Enter Layer 2 — On-Demand Capabilities.

The Philosophy of Layer 2: Progressive Loading

Layer 2 is all about providing context only when it is hyper-relevant to the task at hand. Instead of a single massive set of rules, you break down complex operations into discrete, manually invoked tools.

The Agentic OS defines three distinct primitives residing in Layer 2:

1. Prompt Files (`.github/prompts/*.prompt.md`)

Prompt files are essentially saved macros. They bundle up complex instructions and context into simple "slash commands" that a developer can invoke in the chat interface.

Why ask the AI: "Please review this code for security vulnerabilities, focusing specifically on SQL injection and XSS according to our internal security policy" when you can just type /security-review?

Common Use Cases:

/changelog: Automatically generate release notes from git history using a specific template.
/refactor-tests: Apply a specific mocking structure to legacy unit tests.

2. Custom Agents (`.github/agents/*.agent.md`)

While standard Copilot acts as a generalist, Custom Agents act as specialist personas.

You can define agents equipped with their own specific tools and Model Context Protocol (MCP) servers. The true power of Custom Agents lies in hand-offs (agent chaining).

Instead of asking one monolithic AI to build an entire feature, you can chain highly focused agents together:

Planning Agent: Analyzes the GitHub issue and generates an architecture document.
Implementation Agent: Reads the architecture document and writes the exact code.
Review Agent: Critiques the generated code against specific enterprise security standards.

3. Skills (`.github/skills/<name>/SKILL.md`)

Skills are self-contained folders that encapsulate instructions, scripts, and Markdown references for repeatable technical operations.

They rely on progressive loading. Copilot only reads the short description of the Skill at first. If it decides the specific Skill is needed to answer a developer's prompt (e.g., navigating a server outage), it will proactively load the full set of instructions inside SKILL.md into its active context window.

Common Use Cases:

Incident Triage: A skill that knows how to parse production logs and cross-reference them with recent deployments.
Infrastructure as Code (IaC) Risk Analysis: A skill explicitly invoked to check Terraform Pull Requests against cloud compliance rules.

Conclusion

Layer 2 transforms Copilot from a single chat window into an arsenal of specialized tools. By segmenting your team's knowledge into distinct Prompts, Agents, and Skills, you maintain a lean, highly articulate AI assistant capable of scaling up for complex tasks without losing its mind.

But what happens when things go wrong? What if you want to prevent an AI from executing a tool unless a human reviews it? Or what if you want a workflow to run autonomously in the background without a developer even opening their IDE?

In the next article, we will explore Layer 3 — Enforcement & Automation, where probabilistic AI finally meets enterprise-grade deterministic rules.

Note: This article is part of the "GitHub Copilot Agentic OS" series.

Layer 1 of the Agentic OS: Building Always-On Context for GitHub Copilot

Daniel Montes — Sat, 18 Apr 2026 17:52:29 +0000

In the previous article, we introduced the concept of the 4-Layer Agentic OS underlying modern AI assistants like GitHub Copilot. Today, we are diving deep into the absolute foundation of this stack: Layer 1 — Always-On Context.

If you have ever found yourself repeatedly telling an AI to "use TypeScript, avoid any use of any, and follow our Clean Architecture directory structure," you are suffering from a lack of Layer 1 configuration.

The Problem: Repetitive Prompt Fatigue

By default, an AI chat session is a blank slate. While it can scan your open tabs or the current repository, it doesn't inherently understand your team's opinions—your specific testing methodologies, naming conventions, or architectural boundaries.

Developers end up writing massive pre-ambles for every interaction just to ensure the generated code aligns with team standards. This is inefficient and leaves room for non-compliant code to slip through if a developer forgets to include the rules in their prompt.

The Solution: Passive Memory

Layer 1 solves this through what we call Passive Memory. In the GitHub Copilot ecosystem, this is primarily managed through Instruction files, the most critical being .github/copilot-instructions.md.

These files are automatically parsed by the assistant and silently applied as context to every single prompt executed within the repository.

Key Characteristics of Layer 1:

Zero-Friction: Developers do not need to manually invoke these rules via slash commands or mentions; they are always active in the background.
Global Enforcement: From junior developers to principal engineers, everyone gets the same baseline output aligned with the repository's rules.

Code Walkthrough: A Robust Instruction File

To implement Layer 1, you simply create a file at .github/copilot-instructions.md in the root of your repository.

Here is an example of what a highly effective instruction file looks like for a modern React/TypeScript repository:

# Engineering Standards

You are an expert Frontend Engineer helping build our core platform. Always adhere to the following rules:

### 1. TypeScript Strictness
- Never use `any`. Prioritize explicit typing or use `unknown` if truly necessary.
- Prefer `interface` over `type` for object shapes unless union types are required.

### 2. React Best Practices
- Use functional components exclusively. Do not use class components.
- State should be managed at the lowest sensible level. 
- Avoid `useEffect` for data fetching; use React Query hooks instead.

### 3. Architecture & Styling
- We use Tailwind CSS. Do not write inline styles or generic CSS files.
- All new UI components must be placed in `src/components/ui/` and follow the Atomic Design pattern.

When this file is present, any developer simply asking "Create a button component" will automatically receive a functional React component, typed properly, styled using Tailwind CSS, and structured for the correct directory—without typing a single extra condition.

Conclusion

Layer 1 relies on simplicity to be effective. By outsourcing your non-negotiable project standards to an "Always-On" file, you free up your developers to use their cognitive load on solving complex business logic rather than babysitting the AI's syntax.

However, there is a catch: loading every imaginable tool, runbook, and standard into this single passive file can overwhelm the LLM's context window, degrading performance and causing "hallucinations."

That is exactly where context segmentation comes in. In the next article, we will explore Layer 2 — On-Demand Capabilities, showing you how to progressively load specific Prompts, Custom Agents, and Skills precisely when you need them.

Note: This article is part of the "GitHub Copilot Agentic OS" series.

GitHub Copilot's Hidden Agentic OS: The 4 Layers You Are Missing

Daniel Montes — Sat, 11 Apr 2026 05:39:59 +0000

If your team is treating artificial intelligence coding assistants merely as an "autocomplete on steroids," you are likely leaving 70% of their capabilities untouched.

Recent evolutions in how developers interact with AI have transformed the humble .github folder into a full-fledged Agentic Operating System (OS). It's no longer just a place for a single instruction file; it's a composable, multi-layered ecosystem designed to manage context, enforce security, and execute autonomous workflows.

This introductory article explores the mental model of this Agentic OS and introduces its 4 distinct layers.

The Problem: "Stateless" AI Assistants

The biggest challenge engineering teams face when adopting AI coding assistants is context loss.

When an AI agent is stateless, every prompt requires developers to manually feed it coding standards, framework rules, and project conventions. This leads to inconsistent code, security vulnerabilities, and developer fatigue. Platform engineering teams need a way to ensure their AI agents operate within a governed, deterministic framework.

The Solution: The Agentic OS Architecture

An "Agentic OS" solves this by acting as the business brain for your repository. It manages resources, context, memory, and automated tasks so the AI has continuity and reliability.

Mapping out the .github ecosystem reveals 7 composable primitives structured across 4 functional layers:

1. Layer 1 — Always-On Context

This is the Passive Memory of your assistant. Files like .github/copilot-instructions.md apply to every single prompt automatically.

Use cases: Enforcing universal coding standards, repository naming conventions, and foundational framework rules.

2. Layer 2 — On-Demand Capabilities

This layer introduces specialized tools and memory loaded only when necessary (Progressive Loading). It includes:

Prompt Files: Pre-configured prompts invoked manually via slash commands (e.g., /security-review, /changelog).
Custom Agents: Specialist personas (e.g., a Planning Agent chaining work to an Implementation Agent).
Skills: Repeatable runbooks and incident triage scripts.

3. Layer 3 — Enforcement & Automation

This is where probabilistic LLMs meet deterministic guarantees. This layer introduces structural controls.

Hooks: Deterministic shell commands that trigger at lifecycle events (e.g., preToolUse to approve or deny an action before it executes).
Agentic Workflows: Natural language automations compiled into GitHub Actions for CI failure analysis or issue triage.

4. Layer 4 — Distribution

Once you have built your perfect Agentic OS for a project, you need to scale it.

Plugins: Decentralized packaging allows you to bundle agents, prompts, and skills to share team-specific configurations across the entire enterprise.

What's Next?

Understanding this 4-layer architecture shifts GitHub Copilot from a passive autocomplete tool into an active, governed participant in your software development lifecycle.

In the upcoming articles of this series, we will dive deep into each layer, starting with how to properly configure your Always-On Context to enforce coding standards without overloading the context window. Stay tuned!

Stop pasting broken Markdown into Jira: building md2jira

Daniel Montes — Sun, 05 Apr 2026 05:31:26 +0000

If you write Jira tickets in Markdown, you've probably hit the same problem I did: the moment you paste that text into Jira, the result is inconsistent.

Sometimes you get raw **bold**, # headers, and pipe tables. Sometimes Jira partially formats things. Tables and code blocks usually need manual cleanup.

I built md2jira to make that workflow predictable.

What is md2jira?

md2jira is a monorepo with three independent pieces that share the same conversion engine:

Web previewer (`apps/web`)

A live two-panel editor in the browser. Paste Markdown on the left, get Jira-ready output on the right — instantly, with no backend, no login, and no data sent anywhere.

Use this if: you want to convert Markdown to Jira format right now without installing anything.

Core package (`md2jira-core`)

A pure TypeScript library — zero browser or framework dependencies. It exports two functions:

convert(md) → Jira Wiki Markup string (for Jira Server / Data Center)
convertToAdf(md) → ADF JSON object (for Jira Cloud)

Use this if: you want to integrate Markdown-to-Jira conversion into your own Node.js app, script, or VS Code extension.

CLI (`md2jira-cli`)

A command-line tool that wraps md2jira-core. Reads a Markdown file (or stdin) and writes Jira Wiki Markup to stdout or a file.

Use this if: you want to convert files from the terminal or integrate the conversion into a shell script or CI pipeline.

md2jira input.md                  # stdout
md2jira input.md -o output.txt    # write to file
cat input.md | md2jira            # pipe from stdin

The problem in practice

Here's the difference between pasting raw Markdown directly into Jira and running it through md2jira first:

On the left, Jira gets raw Markdown and leaves it as plain text. On the right, the same content is converted into properly formatted Jira content with headings, emphasis, tables, nested lists, blockquotes, and code blocks.

The web previewer

The web app is designed for people who don't want to install anything. Go to the URL, paste your Markdown, copy the output.

The interface is a split panel:

Left panel: a Markdown editor with line numbers, keyboard shortcuts (Ctrl+B, Ctrl+I, Ctrl+Shift+K, Alt+↑↓…), import/export, and a "Copy MD" button
Right panel: live output with two independent toggles — format (Jira Cloud / Wiki Markup) and view (Preview / Code)

The "Copy for Jira" button is worth highlighting: it writes rich HTML plus plain text to the clipboard at the same time. When you paste directly into Jira Cloud, it renders as formatted content immediately — no manual cleanup needed. This is the main quality-of-life improvement over copying raw text.

What it converts

The core package currently handles:

# Heading → h1. Heading
**bold** → *bold*
_italic_ → _italic_
~~strike~~ → -strike-
`inline code` → {{inline code}}
fenced code blocks → {code} / {code:language=...}
unordered and ordered lists
links, blockquotes, horizontal rules, and tables

Tables were the hardest part. They needed special handling for multiline cells, unequal column counts, escaping pipes inside cells, and inline formatting inside the table content itself.

What turned out to be harder than expected

At first glance, Markdown-to-Jira sounds like a simple string replacement problem. It isn't.

The hardest parts were:

Tables: Jira table syntax is strict, and real Markdown tables are often messy
Clipboard behavior: Jira Cloud reacts differently depending on whether the clipboard contains plain text or rich HTML
ADF vs Wiki Markup: Jira Cloud prefers richer structured content, while Jira Server/Data Center workflows often still rely on Wiki Markup
Keeping the core reusable: packages/core had to stay free of React and browser APIs so it can be reused in a future CLI and VS Code extension

The npm packages

Both packages are published to npm independently:

# Core library — use in your own Node.js/TS projects
npm install md2jira-core

# CLI — convert files from the terminal
npm install -g md2jira-cli

md2jira-core is a pure TypeScript library with zero browser or framework dependencies — it works in Node.js, Deno, Bun, and VS Code extensions. md2jira-cli is a thin wrapper around it that adds file I/O and stdin/stdout support.

Basic usage

import { convert } from 'md2jira-core'

const jira = convert(`
# My Issue

Some **bold** text, _italic_, and ~~strikethrough~~.

| Field  | Value       |
|--------|-------------|
| Status | In Progress |
| Priority | **High**  |

- Item 1
- Item 2
  - Nested item

\`\`\`js
console.log("hello")
\`\`\`

> A blockquote

[Jira Docs](https://confluence.atlassian.com/jira)
`)

console.log(jira)

Output:

h1. My Issue

Some *bold* text, _italic_, and -strikethrough-.

|| Field || Value ||
| Status | In Progress |
| Priority | *High* |

* Item 1
* Item 2
** Nested item

{code:language=js}
console.log("hello")
{code}

bq. A blockquote

[Jira Docs|https://confluence.atlassian.com/jira]

ADF (Atlassian Document Format)

For Jira Cloud, you can also output ADF — the native JSON format that Jira Cloud uses internally:

import { convertToAdf } from 'md2jira-core'

const adf = convertToAdf(`# Hello **World**`)
console.log(JSON.stringify(adf, null, 2))

The web app uses this output to generate the preview and the rich clipboard content used by the "Copy for Jira" action, which is what makes paste into Jira Cloud behave much better than plain text.

How it's built

The conversion pipeline is:

Markdown string
  → remark-parse (AST)
  → transforms/ (visit each node type)
  → Jira Wiki Markup string

Each node type (heading, paragraph, table, list, etc.) has its own transform function in packages/core/src/transforms/. The table transform handles the most edge cases — multiline cells joined with <br>, missing cells padded with empty values, and inline formatting (bold, italic, links, code) inside cells.

The monorepo is structured so that packages/core is 100% framework-agnostic — powering the web app, the CLI (md2jira-cli), and a future VS Code extension.

Tech stack

Layer	Technology
MD Parser	`remark-parse` + `unified`
AST types	`@types/mdast`
UI	React 18 + Vite + Tailwind CSS v4
Testing	Vitest
Package manager	pnpm workspaces

If you work with Jira regularly, give it a try — feedback and PRs are very welcome!

DEV Community: Daniel Montes

Layer 3 of the Agentic OS: Taming AI with Deterministic Hooks and Workflows

Achieving Determinism

1. Hooks (.github/hooks/*.json)

2. Agentic Workflows (.github/workflows/)

Conclusion

Layer 2 of the Agentic OS: On-Demand Capabilities for GitHub Copilot

The Philosophy of Layer 2: Progressive Loading

1. Prompt Files (.github/prompts/*.prompt.md)

2. Custom Agents (.github/agents/*.agent.md)

3. Skills (.github/skills/<name>/SKILL.md)

Conclusion

Layer 1 of the Agentic OS: Building Always-On Context for GitHub Copilot

The Problem: Repetitive Prompt Fatigue

The Solution: Passive Memory

Key Characteristics of Layer 1:

Code Walkthrough: A Robust Instruction File

Conclusion

GitHub Copilot's Hidden Agentic OS: The 4 Layers You Are Missing

The Problem: "Stateless" AI Assistants

The Solution: The Agentic OS Architecture

1. Layer 1 — Always-On Context

2. Layer 2 — On-Demand Capabilities

3. Layer 3 — Enforcement & Automation

4. Layer 4 — Distribution

What's Next?

Stop pasting broken Markdown into Jira: building md2jira

What is md2jira?

Web previewer (apps/web)

Core package (md2jira-core)

CLI (md2jira-cli)

The problem in practice

The web previewer

What it converts

What turned out to be harder than expected

The npm packages

Basic usage

ADF (Atlassian Document Format)

How it's built

Tech stack

1. Hooks (`.github/hooks/*.json`)

2. Agentic Workflows (`.github/workflows/`)

1. Prompt Files (`.github/prompts/*.prompt.md`)

2. Custom Agents (`.github/agents/*.agent.md`)

3. Skills (`.github/skills/<name>/SKILL.md`)

Web previewer (`apps/web`)

Core package (`md2jira-core`)

CLI (`md2jira-cli`)