diff --git a/website/blog/2026-07-31-progressive-promotion-skills-to-autonomous.md b/website/blog/2026-07-31-progressive-promotion-skills-to-autonomous.md new file mode 100644 index 0000000..1de6def --- /dev/null +++ b/website/blog/2026-07-31-progressive-promotion-skills-to-autonomous.md @@ -0,0 +1,549 @@ +--- +slug: /2026-07-31-progressive-promotion-skills-to-autonomous +date: 2026-07-31 +canonical_url: https://dfberry.github.io/blog/2026-07-31-progressive-promotion-skills-to-autonomous +custom_edit_url: null +sidebar_label: "2026.07.31 Progressive promotion" +title: "From Natural Language to Autonomous Actions: A Progressive Promotion Model" +description: "A progressive promotion model for helping domain experts capture process knowledge in natural language, keep ownership, and promote validated workflows to MCP tools and autonomy." +tags: + - AI + - Architecture + - Copilot CLI + - MCP + - Skills + - Agents + - Automation +keywords: + - progressive promotion model + - domain expert workflow + - process automation + - natural language automation + - no-code process capture + - process ownership + - mcp tools + - model context protocol + - copilot skills + - autonomous agents + - prompt caching + - skill to agent pipeline + - copilot cli + - determinism extraction +--- + +:::note[CLI version] +CLI examples written for **GitHub Copilot CLI v1.0.77**. Flag names and behavior may change in later releases. +::: + + + +![A pink-haired girl examining nesting dolls that grow from a small scroll to a winged figure, watercolor illustration](./media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-01-hero.png) + +If you know how work should be done, you should be able to capture that process in natural language, run it, correct it, and keep ownership while it matures. You do not need to wait for a software team to build it for you first. + +A skill gives domain and process experts a place to express decisions and workflow in plain language. AI helps where it saves time, while people stay responsible for their own work and decisions. The process starts with human judgment. Automation comes later, after repeated correct outcomes prove the flow. + +I found this through forty working skills that were carrying around more process knowledge than I realized. + +Some of those skills had scripts doing real work: calling APIs, generating reports, creating pull requests. The scripts were good, but each one lived inside one skill. Useful work had become a set of tiny nesting dolls, and a few of the dolls were carrying around power tools. + +The work also does not have to get tossed over the wall and hope it lands upright. The person who understands the process stays close to it. + +The architecture I landed on is a progressive promotion model: domain expertise starts as a natural language skill, hardens into typed MCP tools, and promotes to autonomous execution only when the process is ready. + +--- + +## The automation tradeoff changed + +The old tradeoff was business value versus engineering work. If automation took a developer project to build, only high-value work usually made the cut. The domain expert often had to describe the workflow, hand it to developers, and wait for someone else to turn it into software. + +This model changes the cost of the next step. The domain expert hones the workflow in natural language while they use it. When repeated correct outcomes prove the process, the stable parts can move behind MCP tools without a large rewrite. Cached tool definitions, reusable scripts, and typed contracts make promotion cheap enough for smaller workflows too. + +That is the empowerment piece. The expert gets time back while keeping ownership of the process and the decisions inside it. + +--- + +## The four layers + +Here is the path at a high level. The model puts each concern in its own layer. MCP stands for Model Context Protocol. In this post, an MCP tool is the typed interface that lets a skill, agent, or CI job call code in a predictable way: + +| Layer | What it does | Who uses it | +|-------|-------------|-------------| +| **Script** | The actual logic (API calls, file operations, data transforms) | Everything below | +| **MCP tool** | Typed interface around the script (JSON input → JSON output) | Skills, agents, CI, other tools | +| **Skill** | Natural language orchestration (when to call which tool, in what order) | Human-driven sessions | +| **Agent** | Autonomous driver (same skill logic, but it decides when to run) | Cron, webhooks, event triggers | + +The script is the logic. The MCP tool is the interface. The skill is the orchestration. The agent is the driver. + +The important move is physical: the script leaves the skill and moves behind the MCP tool. + +The nesting-doll part works better when the smallest doll is not holding every tool. + +```mermaid +%%{init: { "theme": "base", "themeVariables": { "fontFamily": "Inter, ui-sans-serif", "primaryColor": "#f5e6d3", "primaryTextColor": "#3d2817", "primaryBorderColor": "#d4896b", "lineColor": "#c9956b", "secondaryColor": "#fdf4e8", "tertiaryColor": "#f9ead8", "background": "#fef9f5" } } }%% +graph LR + subgraph Before[" BEFORE: script-in-skill "] + direction TB + subgraph SkillBefore[" 💬 Skill "] + direction TB + InstrBefore[" Natural-language instructions "] + ScriptBefore[" 🔒 Script inside skill
only this skill can use it "] + InstrBefore --> ScriptBefore + end + end + + ScriptBefore ==>|extract and relocate| ScriptAfter + + subgraph After[" AFTER: script behind MCP "] + direction TB + subgraph SkillAfter[" 💬 Skill "] + direction TB + InstrAfter[" Natural-language instructions only "] + end + subgraph MCPAfter[" 🔧 MCP Tool "] + direction TB + ToolAfter[" Typed tool contract "] + ScriptAfter[" 📜 Script inside MCP tool
reusable logic "] + ToolAfter --> ScriptAfter + end + InstrAfter -->|"calls"| ToolAfter + AgentAfter[" 🤖 Agent "] -->|"calls"| ToolAfter + CIAfter[" ⚙️ CI "] -->|"calls"| ToolAfter + OtherAfter[" 💬 Other skills "] -->|"call"| ToolAfter + end + + style Before fill:#fef9f5,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style After fill:#fef9f5,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style SkillBefore fill:#f9ead8,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style SkillAfter fill:#fdf4e8,stroke:#b8836f,stroke-width:3px,color:#3d2817 + style MCPAfter fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style InstrBefore fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style ScriptBefore fill:#f9ead8,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style InstrAfter fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style ToolAfter fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style ScriptAfter fill:#f9ead8,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style AgentAfter fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style CIAfter fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style OtherAfter fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 +``` + +The resulting stack looks like this: + +```mermaid +%%{init: { "theme": "base", "themeVariables": { "fontFamily": "Inter, ui-sans-serif", "primaryColor": "#f5e6d3", "primaryTextColor": "#3d2817", "primaryBorderColor": "#d4896b", "lineColor": "#c9956b", "secondaryColor": "#fdf4e8", "tertiaryColor": "#f9ead8", "background": "#fef9f5" } } }%% +graph TD + A[" 📜 Script
The logic "] --> B[" 🔧 MCP Tool
Typed interface "] + B --> C[" 💬 Skill
Orchestration "] + B --> D[" 🤖 Agent
Autonomous driver "] + B --> E[" ⚙️ CI/CD
No LLM needed "] + + style A fill:#f9ead8,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style B fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style C fill:#fdf4e8,stroke:#b8836f,stroke-width:3px,color:#3d2817 + style D fill:#fdf4e8,stroke:#b8836f,stroke-width:3px,color:#3d2817 + style E fill:#fdf4e8,stroke:#b8836f,stroke-width:3px,color:#3d2817 +``` + +The script gets written once, wrapped in a typed tool once, and then only the driver changes during promotion from interactive to autonomous. + +--- + +## How work naturally evolves + +This architecture came later. The pattern showed up as process knowledge matured across dozens of skills. + +> Start in natural language. Let the domain expert hone the process. Promote only after repeated correct outcomes prove the flow. + +### Phase A: Exploration + +A new skill starts with the LLM doing everything inline on purpose. The instructions say something like "query the GitHub API for recent releases, then compare against our changelog." A domain or process expert can own that workflow because the first version is written in plain language, not code. + +At this stage, correctness matters more than speed. The person with the domain knowledge can run the skill, adjust the instructions, and decide whether the outcome matches their judgment. The process should produce the right outcome more than once before any part of it gets frozen into a tool. + +The domain expert keeps the process close. They keep running it, correcting it, and deciding when it is ready for more structure. + +### Phase B: Determinism emerges + +After a few runs, a pattern shows up: step 2 is always the same. Same API call, same parsing, same output format. The LLM is not adding judgment here. It is following a mechanical procedure inside a process the expert has already validated. + +This is the signal. When the same tool calls and parsing steps keep showing up in the skill instructions, and the outcomes have been correct, the process is mature enough to extract that deterministic part. + +### Phase C: Extract to MCP (not script-in-skill) + +This is the decision point. The deterministic logic becomes a typed MCP tool instead of a script inside the skill. The domain expert still controls the workflow through the skill. The stable part moves behind a typed interface. + +```mermaid +%%{init: { "theme": "base", "themeVariables": { "fontFamily": "Inter, ui-sans-serif", "primaryColor": "#f5e6d3", "primaryTextColor": "#3d2817", "primaryBorderColor": "#d4896b", "lineColor": "#c9956b", "secondaryColor": "#fdf4e8", "tertiaryColor": "#f9ead8", "background": "#fef9f5" } } }%% +graph LR + subgraph "❌ Wrong path" + W1[" Skill owns the script "] --> W2[" 🔒 Script stays inside skill "] --> W3[" Only this skill can use it "] + end + subgraph "✅ Right path" + R1[" Extract script "] --> R2[" 🔧 MCP tool owns the script "] --> R3[" Skill calls tool "] --> R4[" Agents, CI, other skills can call too "] + end + + style W1 fill:#f9ead8,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style W2 fill:#f9ead8,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style W3 fill:#fef9f5,stroke:#b8836f,stroke-width:2px,color:#4a3428 + style R1 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style R2 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style R3 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style R4 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 +``` + +The skill now says "call `detect_releases`" instead of embedding the detection logic. The tool has a JSON input schema, a JSON output schema, and error handling. It is independently testable. Any consumer, including another skill, an agent, or a CI pipeline, can call it. + +### Phase D: Promote to agent + +The path starts with the skill and promotes to autonomy only when the process is reliable and unattended execution is useful. The agent uses the same MCP tools. The only difference is who drives: me (interactive) or the agent (autonomous). + +```mermaid +%%{init: { "theme": "base", "themeVariables": { "fontFamily": "Inter, ui-sans-serif", "primaryColor": "#f5e6d3", "primaryTextColor": "#3d2817", "primaryBorderColor": "#d4896b", "lineColor": "#c9956b", "secondaryColor": "#fdf4e8", "tertiaryColor": "#f9ead8", "background": "#fef9f5" } } }%% +graph TB + subgraph MCP[" 🔧 MCP Server (built once) "] + T1[" detect_releases "] + T2[" generate_metadata "] + T3[" analyze_impact "] + end + + subgraph Interactive[" 💬 Phase C: Skill drives "] + S[" You say: 'sync releases' "] + S --> T1 + T1 --> T2 + T2 -->|"⏸ You approve PRs"| T3 + end + + subgraph Autonomous[" 🤖 Phase D: Agent drives "] + AG[" Cron: daily 8am "] + AG --> T1 + T1 --> T2 + T2 -->|"📱 Teams notification"| T3 + end + + style MCP fill:#fef9f5,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style Interactive fill:#fef9f5,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style Autonomous fill:#fef9f5,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style T1 fill:#f5e6d3,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style T2 fill:#f5e6d3,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style T3 fill:#f5e6d3,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style S fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style AG fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 +``` + +The MCP server does not change. The tools do not change. The scripts do not change. Only the driver changes. + +--- + +## Where my first design stopped + +My own forty-skill batch showed me where this path breaks if it stops too early. The first development path was: + +1. Write a skill (natural language instructions for the LLM) +2. Notice that part of the skill is deterministic (same inputs → same outputs every time) +3. Extract that logic into a script inside the skill +4. Done + +Step 4 is where the design stopped too early. The skill captured the process, and the script worked, but only from that skill. No other skill can call it. No agent can use it. No CI pipeline can run it. The same logic gets copy-pasted when it is needed somewhere else. + +After forty skills, there were forty pieces of process knowledge with scripts scoped to individual skills, no typed contracts, no shared interfaces, and no clear path to autonomous execution. The scripts were going nowhere fast, mostly because they had nowhere else to go. + + + +![A pink-haired girl at a garden crossroads, with boxes stacked against a dead-end wall, watercolor illustration](./media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-02-dead-end.png) + +## Why MCP tools instead of scripts-in-skills + +The decision to extract into MCP rather than keep scripts inside skills comes down to three things: + +### Reusability + +A script inside `echo-release-detection/scripts/detect.ps1` is only callable by the echo-release-detection skill. An MCP tool called `detect_releases` is callable by any skill, any agent, any CI pipeline, and any future tool that speaks the MCP protocol. + +### Typed contracts + +A script takes string arguments from a shell command. An MCP tool has a JSON input schema and a JSON output schema. The LLM knows exactly what to send and what to expect back. No parsing surprises. + +### Prompt caching + +The cost reason came from Burke Holland's [prompt caching video](https://www.youtube.com/watch?v=TYOhNRp5n7Y). The math was clear: MCP tool definitions live in the system prompt prefix and get cached at a 50-90% discount. Agent spawns create fresh uncached context windows every time. + +| What | Token cost | Cache behavior | +|------|-----------|----------------| +| Skill instructions | ~0 (loaded on invocation) | Part of system prompt (cached) | +| MCP tool definitions | ~400-1600 (when enabled) | Part of system prompt (cached) | +| Agent spawn | ~10-25K per invocation | Fresh context window (uncached) | + +For this workflow, MCP tools reduced uncached per-invocation tokens by roughly 90%+ compared with agent spawns. + +--- + +## The decision point + +When you find yourself writing a script inside a skill, ask one question: + +> Will anything other than this skill ever need to call this logic? + +- If **yes** → MCP tool immediately +- If **maybe someday** → MCP tool (future reuse is easier than a later move) +- If **truly never** (one-off, will be deleted) → script-in-skill is fine + +In my portfolio of forty skills, the answer was almost always yes. + +--- + +## What promotion looks like in practice + +I have a content pipeline called Echo that detects new SDK releases, generates documentation metadata, and produces content impact reports. It ran as a Squad agent with a fresh ~25K token context window every invocation. + +After extracting to MCP + skill: + +| Before (agent) | After (skill + MCP) | +|----------------|-------------------| +| ~25K uncached tokens | ~1-2K uncached tokens | +| Squad coordinator + agent spawn | Skill in cached system prompt | +| Two context windows | Zero new context windows | +| Scripts available only to agent | Tools callable by anything | + +The scripts did not change. The structured output envelopes they already produced worked as MCP tool responses: same JSON schema, different transport. + +``` +Before: Script → JSON file → next skill reads file from disk +After: Script → JSON → MCP protocol → any consumer receives it directly +``` + +That gave me a useful signal. The earlier structured-output spec was already close to an MCP response contract. It just did not have that name yet. + +--- + +## The cost model across stages + + + +![A pink-haired girl climbing a tower staircase with price tags getting smaller at each level, watercolor illustration](./media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-03-cost-ladder.png) + +Each promotion stage changes the driver but keeps the same tools. The cost changes because the driver changes: + +| Stage | Per-run cost | Who drives | What changes | +|-------|-------------|-----------|-------------| +| **Skill + MCP** | ~1-2K uncached tokens | You, interactively | Lowest token use. Tools cached. Only I/O is new. | +| **Agent + MCP** | ~5-10K uncached tokens | Agent, autonomously | Agent charter is a fresh window, but tools stay cached. | +| **CI/CD** | 0 tokens | GitHub Action | No LLM at all for deterministic steps. | +| **Agent spawn (old way)** | ~25K uncached tokens | Squad coordinator | Two fresh windows every time. Highest token use here. | + +The progression changes both autonomy and cost. As work hardens, it needs less LLM reasoning per run, until the final stage needs no LLM at all. + +--- + +## Context occupation cost of MCP + +MCP tools have lower per-token cost when cached, but they occupy context window space every turn they are enabled, even when unused. A 4-tool server adds ~600-1600 tokens to every conversation. + +Grouping and toggling handle this: + +| Strategy | How it works | +|----------|-------------| +| **Group by workflow** | Combine related tools into one server (`content-pipeline-mcp` for all content tools) | +| **Toggle per task** | Enable the server when doing content work, disable when doing email | +| **Skill as entry point** | The skill reminds you to enable the MCP if it is off | + +The pattern here: **skill triggers workflow** (zero idle cost) → **skill activates MCP tools** (cost only when needed) → **tools do I/O** (cached calls). The MCP stays enabled only when it is needed. + +--- + +## Running autonomously with Copilot CLI + +Once a skill is promoted to an agent, the next need is running it without a human session. Copilot CLI supports this today: + +```bash +# Simplest autonomous run +copilot -p "Run the echo pipeline" --yolo --silent + +# With specific agent and model +copilot -p "Execute" \ + --agent echo-pipeline \ + --autopilot --no-ask-user \ + --yolo --silent \ + --model gpt-5.4 + +# Sealed sandbox: only specific tools available +copilot -p "Sync releases" \ + --additional-mcp-config @workflows/echo-sync/mcp-config.json \ + --available-tools='content-pipeline-mcp/*' \ + --no-ask-user --autopilot --silent +``` + +The key flags: + +| Flag | What it does | +|------|-------------| +| `-p "prompt"` | Non-interactive mode (exits after completion) | +| `--agent name` | Use a specific `.agent.md` file | +| `--autopilot` | Agent continues without asking permission | +| `--no-ask-user` | Disable all user questions | +| `--yolo` | Approve all tools, paths, and URLs | +| `--available-tools='...'` | Only these tools exist (sealed sandbox) | +| `--silent` | Output only the agent's response | + +For CI/CD, authenticate with a fine-grained PAT: + +```bash +COPILOT_GITHUB_TOKEN=github_pat_xxx copilot -p "Run pipeline" \ + --agent echo-pipeline --yolo --silent --no-auto-update +``` + +--- + +## The sealed sandbox + + + +![A pink-haired girl placing an automaton inside a sealed glass bell jar with exactly three tools, watercolor illustration](./media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-04-sandbox.png) + +When something runs autonomously, the context must be fully specified at launch and immutable during execution. The agent gets exactly the tools it needs and no extra tools. The glass bell jar is boring on purpose. + +A sealed sandbox manifest specifies: + +1. **Identity**: who the agent is +2. **Available tools**: exhaustive list (nothing else exists) +3. **Execution plan**: exact steps, no deviation +4. **Error handling**: complete rules, no improvisation +5. **Output routing**: where results go +6. **Boundaries**: hard constraints (violation = immediate exit) + +Copilot CLI implements this through `--available-tools` and the `"tools"` allowlist in MCP config: + +```json +{ + "mcpServers": { + "content-pipeline": { + "command": "node", + "args": [" ./mcp-servers/content-pipeline/index.js "], + "tools": ["detect_releases", "generate_metadata", "analyze_impact"] + } + } +} +``` + +The MCP server might have twenty tools. The agent only sees three. + +--- + +## Related patterns + +A common name for this pattern did not turn up, but similar progressions did: + +```mermaid +%%{init: { "theme": "base", "themeVariables": { "fontFamily": "Inter, ui-sans-serif", "primaryColor": "#f5e6d3", "primaryTextColor": "#3d2817", "primaryBorderColor": "#d4896b", "lineColor": "#c9956b", "secondaryColor": "#fdf4e8", "tertiaryColor": "#f9ead8", "background": "#fef9f5" } } }%% +graph LR + subgraph "This model" + A1[" Skill "] --> A2[" MCP Tool "] --> A3[" Agent "] --> A4[" CI/CD "] + end + subgraph "Anthropic" + B1[" Augmented LLM "] --> B2[" Workflows "] --> B3[" Agents "] + end + subgraph "Autonomous vehicles" + C1[" L0: No automation "] --> C2[" L2: Partial "] --> C3[" L4: High "] --> C4[" L5: Full "] + end + subgraph "SRE" + D1[" Runbook "] --> D2[" Automation "] --> D3[" Self-healing "] + end + + style A1 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style A2 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style A3 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style A4 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style B1 fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style B2 fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style B3 fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style C1 fill:#f9ead8,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style C2 fill:#f9ead8,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style C3 fill:#f9ead8,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style C4 fill:#f9ead8,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style D1 fill:#fef9f5,stroke:#b8836f,stroke-width:2px,color:#4a3428 + style D2 fill:#fef9f5,stroke:#b8836f,stroke-width:2px,color:#4a3428 + style D3 fill:#fef9f5,stroke:#b8836f,stroke-width:2px,color:#4a3428 +``` + +| Source | Their pattern | The mapping | +|--------|--------------|-------------| +| Anthropic, "Building Effective Agents" | Start simple, promote complexity | Augmented LLM → Workflows → Agents | +| Claude Agent SDK | Permission modes as autonomy dial | `plan` → `acceptEdits` → `dontAsk` | +| MCP Skills Working Group | Progressive disclosure | Tools → Skills → Agents | +| SAE J3016 (autonomous vehicles) | L0–L5 autonomy levels | Human-in-loop → human-on-loop → human-out-of-loop | +| SRE | Runbook → Automation → Self-Healing | Manual → scripted → autonomous | +| LangGraph | `interrupt()` architecture | Remove interrupts = autonomous | + +No named, concrete "Skill → MCP → Agent → CI" promotion model with extraction checklists and validation gates turned up. The pattern exists in pieces. A practical version was the missing piece for my work. + +--- + +## The rule I use now + +> When a process proves repeatable, reusable logic moves directly to an MCP tool. Scripts-in-skills are prototype code. + +The useful questions are who owns the process, how mature it is, and what driver it needs right now. + +| If the work is... | Use... | +|-------------------|--------| +| Still being figured out | Skill (exploration, cheap) | +| Deterministic and repeatable | MCP tool (typed, reusable) | +| Needs to run without you | Agent (autonomous driver) | +| Fully deterministic, no judgment needed | CI/CD (no LLM at all) | + +--- + +## What's next + + + +![A pink-haired girl on a hilltop watching automatons travel between villages, watercolor illustration](./media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-05-horizon.png) + +Echo is the pilot. Once the content-pipeline MCP server wraps Echo's three scripts and the `/echo-sync` skill drives them interactively, the first validation has two parts: the process still produces the right outcome, and the token savings are real. + +After that comes Finn, the reporting tools, and the remaining skills one at a time. + +The pattern is simple: start with the person who owns the domain knowledge, capture the workflow in a skill, run it until the outcomes are consistently right, move the repeatable parts behind MCP tools, and change the driver only when autonomy helps. + +The ownership stays with the person who understands the process. The system matures around that expertise. diff --git a/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/batch.json b/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/batch.json new file mode 100644 index 0000000..211b75f --- /dev/null +++ b/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/batch.json @@ -0,0 +1,43 @@ +{ + "description": "Blog images for PR #78 — From Natural Language to Autonomous Actions. Dina's watercolor style, tuned for crispness: SDXL refiner ON (second-stage detail pass), 35 steps, quality negatives (blurry/muddy/smudged). Protagonist is a modern, confident pink-haired woman (maker, not subservient/domestic). Prompts are concept-forward and token-tight so the concept survives CLIP's 77-token truncation; crisp/fine-detail tags trail the concept.", + "settings": { + "steps": 35, + "guidance": 7.5, + "width": 1024, + "height": 1024, + "refine": true, + "cpu": true + }, + "prompts": [ + { + "filename": "watercolor-01-hero.png", + "seed": 101, + "prompt": "Watercolor painting, wet-on-wet washes, warm muted tones. Confident pink-haired woman at a workbench, sleeves rolled up, lining up five brass clockwork figures that grow left to right from a tiny paper sketch to a tall winged machine lifting off the bench, self-assured posture, warm studio light, crisp clean watercolor, fine detail, luminous washes", + "negative_prompt": "text, watermark, signature, blurry, muddy, smudged, grainy, noisy, low detail, low contrast, dull, photorealistic, 3D render, cartoon, anime, ink, line art, bold outlines, hard edges, comic, storybook, chibi, subservient, submissive, housewife, apron, cooking, knitting, nesting dolls, kneeling, bowing, domestic chores, passive, deformed hands, extra limbs, bad anatomy" + }, + { + "filename": "watercolor-02-dead-end.png", + "seed": 102, + "prompt": "Watercolor painting, wet-on-wet washes, warm muted tones. Confident pink-haired woman turning away from a bricked-up doorway with identical wooden boxes piled against it, toward a bright open doorway leading out to rolling green hills, decisive stance, warm natural light, crisp clean watercolor, fine detail, luminous washes", + "negative_prompt": "text, watermark, signature, blurry, muddy, smudged, grainy, noisy, low detail, low contrast, dull, photorealistic, 3D render, cartoon, anime, ink, line art, bold outlines, hard edges, comic, storybook, chibi, subservient, submissive, housewife, apron, cooking, knitting, nesting dolls, kneeling, bowing, domestic chores, passive, deformed hands, extra limbs, bad anatomy" + }, + { + "filename": "watercolor-03-cost-ladder.png", + "seed": 103, + "prompt": "Watercolor painting, wet-on-wet washes, warm muted tones. Confident pink-haired woman striding up a spiral staircase toward glowing light at the top, one large price tag on the low railing and tiny price tags on the high railings, strong upward motion, warm light through tall windows, crisp clean watercolor, fine detail", + "negative_prompt": "text, watermark, signature, blurry, muddy, smudged, grainy, noisy, low detail, low contrast, dull, photorealistic, 3D render, cartoon, anime, ink, line art, bold outlines, hard edges, comic, storybook, chibi, subservient, submissive, housewife, apron, cooking, knitting, nesting dolls, kneeling, bowing, domestic chores, passive, deformed hands, extra limbs, bad anatomy" + }, + { + "filename": "watercolor-04-sandbox.png", + "seed": 104, + "prompt": "Watercolor painting, wet-on-wet washes, warm muted tones. Confident pink-haired woman at a workbench sealing a small brass clockwork figure under a clear glass dome, exactly three neat tools arranged inside the dome, many scattered tools on the bench outside it, focused expert posture, warm studio light, crisp clean watercolor, fine detail", + "negative_prompt": "text, watermark, signature, blurry, muddy, smudged, grainy, noisy, low detail, low contrast, dull, photorealistic, 3D render, cartoon, anime, ink, line art, bold outlines, hard edges, comic, storybook, chibi, subservient, submissive, housewife, apron, cooking, knitting, nesting dolls, kneeling, bowing, domestic chores, passive, deformed hands, extra limbs, bad anatomy" + }, + { + "filename": "watercolor-05-horizon.png", + "seed": 105, + "prompt": "Watercolor painting, wet-on-wet washes, warm muted tones. Confident pink-haired woman standing on a hilltop at sunrise holding an open notebook, watching several small brass figures walk along clear worn paths between distant villages, calm assured smile, warm golden light, crisp clean watercolor, fine detail", + "negative_prompt": "text, watermark, signature, blurry, muddy, smudged, grainy, noisy, low detail, low contrast, dull, photorealistic, 3D render, cartoon, anime, ink, line art, bold outlines, hard edges, comic, storybook, chibi, subservient, submissive, housewife, apron, cooking, knitting, nesting dolls, kneeling, bowing, domestic chores, passive, deformed hands, extra limbs, bad anatomy" + } + ] +} diff --git a/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-01-hero.png b/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-01-hero.png new file mode 100644 index 0000000..cc88462 Binary files /dev/null and b/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-01-hero.png differ diff --git a/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-02-dead-end.png b/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-02-dead-end.png new file mode 100644 index 0000000..a73c7c1 Binary files /dev/null and b/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-02-dead-end.png differ diff --git a/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-03-cost-ladder.png b/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-03-cost-ladder.png new file mode 100644 index 0000000..01e8fb2 Binary files /dev/null and b/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-03-cost-ladder.png differ diff --git a/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-04-sandbox.png b/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-04-sandbox.png new file mode 100644 index 0000000..837bebd Binary files /dev/null and b/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-04-sandbox.png differ diff --git a/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-05-horizon.png b/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-05-horizon.png new file mode 100644 index 0000000..b149161 Binary files /dev/null and b/website/blog/media/2026-07-31-progressive-promotion-skills-to-autonomous/watercolor-05-horizon.png differ diff --git a/website/blog/mermaid/2026-07-21-progressive-promotion-four-layers.mmd b/website/blog/mermaid/2026-07-21-progressive-promotion-four-layers.mmd new file mode 100644 index 0000000..f12d091 --- /dev/null +++ b/website/blog/mermaid/2026-07-21-progressive-promotion-four-layers.mmd @@ -0,0 +1,12 @@ +%%{init: { "theme": "base", "themeVariables": { "fontFamily": "Inter, ui-sans-serif", "primaryColor": "#f5e6d3", "primaryTextColor": "#3d2817", "primaryBorderColor": "#d4896b", "lineColor": "#c9956b", "secondaryColor": "#fdf4e8", "tertiaryColor": "#f9ead8", "background": "#fef9f5" } } }%% +graph TD + A["📜 Script
The logic"] --> B["🔧 MCP Tool
Typed interface"] + B --> C["💬 Skill
Orchestration"] + B --> D["🤖 Agent
Autonomous driver"] + B --> E["⚙️ CI/CD
No LLM needed"] + + style A fill:#f9ead8,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style B fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style C fill:#fdf4e8,stroke:#b8836f,stroke-width:3px,color:#3d2817 + style D fill:#fdf4e8,stroke:#b8836f,stroke-width:3px,color:#3d2817 + style E fill:#fdf4e8,stroke:#b8836f,stroke-width:3px,color:#3d2817 diff --git a/website/blog/mermaid/2026-07-21-progressive-promotion-industry-parallels.mmd b/website/blog/mermaid/2026-07-21-progressive-promotion-industry-parallels.mmd new file mode 100644 index 0000000..a92fbda --- /dev/null +++ b/website/blog/mermaid/2026-07-21-progressive-promotion-industry-parallels.mmd @@ -0,0 +1,29 @@ +%%{init: { "theme": "base", "themeVariables": { "fontFamily": "Inter, ui-sans-serif", "primaryColor": "#f5e6d3", "primaryTextColor": "#3d2817", "primaryBorderColor": "#d4896b", "lineColor": "#c9956b", "secondaryColor": "#fdf4e8", "tertiaryColor": "#f9ead8", "background": "#fef9f5" } } }%% +graph LR + subgraph thismodel["This model"] + A1["Skill"] --> A2["MCP Tool"] --> A3["Agent"] --> A4["CI/CD"] + end + subgraph anthropic["Anthropic"] + B1["Augmented LLM"] --> B2["Workflows"] --> B3["Agents"] + end + subgraph vehicles["Autonomous vehicles"] + C1["L0: No automation"] --> C2["L2: Partial"] --> C3["L4: High"] --> C4["L5: Full"] + end + subgraph sre["SRE"] + D1["Runbook"] --> D2["Automation"] --> D3["Self-healing"] + end + + style A1 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style A2 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style A3 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style A4 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style B1 fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style B2 fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style B3 fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style C1 fill:#f9ead8,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style C2 fill:#f9ead8,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style C3 fill:#f9ead8,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style C4 fill:#f9ead8,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style D1 fill:#fef9f5,stroke:#b8836f,stroke-width:2px,color:#4a3428 + style D2 fill:#fef9f5,stroke:#b8836f,stroke-width:2px,color:#4a3428 + style D3 fill:#fef9f5,stroke:#b8836f,stroke-width:2px,color:#4a3428 diff --git a/website/blog/mermaid/2026-07-21-progressive-promotion-skill-vs-agent-driver.mmd b/website/blog/mermaid/2026-07-21-progressive-promotion-skill-vs-agent-driver.mmd new file mode 100644 index 0000000..fdc9923 --- /dev/null +++ b/website/blog/mermaid/2026-07-21-progressive-promotion-skill-vs-agent-driver.mmd @@ -0,0 +1,30 @@ +%%{init: { "theme": "base", "themeVariables": { "fontFamily": "Inter, ui-sans-serif", "primaryColor": "#f5e6d3", "primaryTextColor": "#3d2817", "primaryBorderColor": "#d4896b", "lineColor": "#c9956b", "secondaryColor": "#fdf4e8", "tertiaryColor": "#f9ead8", "background": "#fef9f5" } } }%% +graph TB + subgraph MCP["🔧 MCP Server (built once)"] + T1["detect_releases"] + T2["generate_metadata"] + T3["analyze_impact"] + end + + subgraph Interactive["💬 Phase C: Skill drives"] + S["You say: 'sync releases'"] + S --> T1 + T1 --> T2 + T2 -->|"⏸ You approve PRs"| T3 + end + + subgraph Autonomous["🤖 Phase D: Agent drives"] + AG["Cron: daily 8am"] + AG --> T1 + T1 --> T2 + T2 -->|"📱 Teams notification"| T3 + end + + style MCP fill:#fef9f5,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style Interactive fill:#fef9f5,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style Autonomous fill:#fef9f5,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style T1 fill:#f5e6d3,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style T2 fill:#f5e6d3,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style T3 fill:#f5e6d3,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style S fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 + style AG fill:#fdf4e8,stroke:#b8836f,stroke-width:2px,color:#3d2817 diff --git a/website/blog/mermaid/2026-07-21-progressive-promotion-wrong-vs-right.mmd b/website/blog/mermaid/2026-07-21-progressive-promotion-wrong-vs-right.mmd new file mode 100644 index 0000000..69b5a46 --- /dev/null +++ b/website/blog/mermaid/2026-07-21-progressive-promotion-wrong-vs-right.mmd @@ -0,0 +1,16 @@ +%%{init: { "theme": "base", "themeVariables": { "fontFamily": "Inter, ui-sans-serif", "primaryColor": "#f5e6d3", "primaryTextColor": "#3d2817", "primaryBorderColor": "#d4896b", "lineColor": "#c9956b", "secondaryColor": "#fdf4e8", "tertiaryColor": "#f9ead8", "background": "#fef9f5" } } }%% +graph LR + subgraph wrong["❌ Wrong path"] + W1["Skill"] --> W2["Script-in-skill"] --> W3["Trapped forever"] + end + subgraph right["✅ Right path"] + R1["Skill"] --> R2["Script"] --> R3["MCP Tool"] --> R4["Skill calls tool"] + end + + style W1 fill:#f9ead8,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style W2 fill:#f9ead8,stroke:#d4896b,stroke-width:2px,color:#3d2817 + style W3 fill:#fef9f5,stroke:#b8836f,stroke-width:2px,color:#4a3428 + style R1 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style R2 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style R3 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817 + style R4 fill:#f5e6d3,stroke:#d4896b,stroke-width:3px,color:#3d2817