Skip to main content
skill CX Codex

agent-operated-software — Claude Code skill: agents in the live

A skill for designing and debugging applications whose live backend or control loop includes OpenRig agents.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add mvschwarz/openrig --skill agent-operated-software -a claude-code
Open on GitHub

What agent-operated-software does

The skill lays out a shared taxonomy. AI-enabled software keeps the control loop in application code and calls a model as one capability. An Agent-Operated Workflow is one bounded procedure with a start and stop condition. Agent-Operated Software is when agents take part in an ongoing application's functioning runtime. The distinction matters: a product can compose many bounded workflows and still not be agent-operated.

Behaviour in this architecture is spread across agents, skills, instructions, bootstrap files, schemas, Markdown, YAML, JSON, folders and deterministic tools. So a surprising result may be a code defect or a coherence gap in the control plane. The skill tells you to trace the path that actually produced the behaviour before picking a layer to repair. Fix a code defect in code, a missing trigger in the skill, a malformed contract in its schema. Editing a rendered or installed copy makes a temporary fork, not a repair.

There is a section on self-certifying artifacts: write to a partial path, verify the property that can actually be wrong, flush and atomically rename to the final path, write the manifest, then a .done sentinel last. Consumers fail closed on that shared proof, since a filename or exit code is not content verification. Installing needs Node.js and npx; GitHub Copilot uses gh skill install.

What it helps with

  • tell AI-enabled software apart from a bounded workflow and agent-operated software
  • trace which layer produced a strange agent result instead of patching an installed copy
  • make artifacts self-certifying with a partial path and a .done sentinel
  • move intent, work state and decisions into addressed Markdown artifacts
  • check item readiness through the judgment path rather than capture alone

Example prompts for the agent

  • Help me design the control plane for an application built on OpenRig agents
  • Why did the agent produce this odd result — trace the path back to the layer that caused it
  • Make report generation self-certifying: partial path, verification, atomic rename, .done

How to install agent-operated-software

1Skills CLI (Vercel)

npx skills add mvschwarz/openrig --skill agent-operated-software -a claude-code

2Manually: put the files in place

~/.claude/skills/agent-operated-software/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/agent-operated-software/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about agent-operated-software

How do I install agent-operated-software in Claude?

Run npx skills add mvschwarz/openrig --skill agent-operated-software -a claude-code. The skill file lands at ~/.claude/skills/agent-operated-software/SKILL.md.

What does agent-operated-software do?

It covers designing, building, operating and diagnosing an application whose live backend or control loop includes OpenRig agents. It supplies the taxonomy, rules for Markdown as the control plane, and an order for repairing the right layer.

How is agent-operated software different from AI-enabled software?

In AI-enabled software the application code owns the control loop and calls a model as one capability. In agent-operated software agents take part in the functioning runtime rather than in a single bounded procedure.

Source text

SKILL.md · Apache-2.0
---
name: agent-operated-software
description: >-
  Use when designing, building, operating, or diagnosing an ongoing application whose live backend
  or control loop includes OpenRig agents, including applications with a Markdown, YAML, or JSON
  agent control plane or a thin surface over specialist agent roles.
metadata:
  openrig:
    stage: provisional
    audience: any agent building or operating an agent-backed application
    sibling_skills:
      - agent-operated-workflows
      - forming-an-openrig-mental-model
      - mission-slice-sop
      - openrig-user
---

# Agent-Operated Software

**Agent-Operated Software** is an ongoing application whose functioning runtime includes an OpenRig
agent or rig in its live backend or control loop. The application surface can be thin: structured
state and specialist roles do the work, while the UI makes that work legible and steerable.

## Start with the shared taxonomy

- **AI-enabled software:** application code owns the control loop and calls a model as one capability.
- **Agent-Operated Workflow:** an agent owns one bounded procedure with a start and stop condition;
  see `agent-operated-workflows`.
- **Agent-Operated Software:** agents participate in an ongoing application's functioning runtime.

An application may compose many Agent-Operated Workflows. A bounded workflow does not by itself make
its surrounding product Agent-Operated Software, and a model call is neither category unless an agent
owns part of the control loop.

## Agents are part of the backend

In this architecture, behavior is not located only in functions. It is distributed across agents,
skills, instructions, bootstrap files, schemas, Markdown, YAML, JSON, folders, and deterministic
tools. A surprising result may therefore be a code defect or a coherence gap in this control plane.
Trace the path that actually produced the behavior before choosing which layer to repair.

This is not permission to tolerate defects in OpenRig core or another rock-solid substrate. There,
reproduce the bug, fix the code, and hold the full gate. The faster coherence-first posture belongs
to recoverable agent-operated application layers whose state and behavior can be inspected and
repaired cheaply.

## Markdown is the control plane

Markdown is maximally useful to an agent while remaining legible enough for a human to steer. Put
intent, work state, evidence, and decisions into stable addressed artifacts rather than private chat
or an opaque custom database. Keep schemas and conventions aligned with the running behavior: the
agent population acts on those files as executable context.

Use **progressive disclosure**. A skill's name and description are the hot trigger; its body is cold
procedure. Descriptions say when to load, not how to work. The body should route the reader to exact
sources instead of copying them into another doctrine fork.

Scripts can act as prompts. A good script returns the context or exact effect an agent needs; when it
cannot, its failure teaches what it observed, why it stopped, and safe next actions. Keep deterministic
mechanics in tools and judgment in agents.

## Make artifacts self-certifying

When a tool produces an artifact, do not make every consumer invent a completeness test:

1. Write to a partial path, never the final path.
2. Verify the property that can actually be wrong, such as duration, streams, resolution, or schema.
3. Flush and atomically rename the partial artifact to its final path.
4. Write the manifest, then a `.done` sentinel last.

Consumers fail closed on the shared proof. A filename or exit code is not content verification.

## Build with an agent SDLC

Select the rigor required by the outcome and the project's policy. Scope relationships,
attributed evidence-backed item judgment, and genuinely distinct higher judgment have separate
owners. One item judgment derives its upstream readiness; agents do not synchronize parent
checkboxes, queue tags, or status prose. Capture alone is not acceptance, and readiness does not
publish or advance a workflow. Use `openrig-operating-model` and `rig proof --help` for the
supported judgment, correction, and read path. Keep historical locks and evidence addressable.
The human supplies steering, taste, and decisions the project's authority reserves for them.

For studio applications, the running product is usually the best iteration surface. A separate mockup
earns its cost only when it resolves a real design uncertainty that the running app cannot expose as
cheaply. This removes a redundant artifact, not the visual review or proof contract.

## Repair the narrowest authoritative layer

Find the generator or source that every affected agent actually consumes. Fix a code defect in code;
fix a missing trigger in the skill; fix a malformed contract in its schema. Then verify through the
consumer. Editing a rendered or installed copy creates a temporary fork, not a repair.

The payoff compounds: a correction to the shared application control plane changes the next agent's
starting point. That is how an ongoing agent-operated system improves without making one human its
permanent router.

© mvschwarz · Apache-2.0 · mvschwarz/openrig

Similar skills

All skills for Agent setup: memory, context, orchestration →

From the same set14

session-compaction-and-restore A skill for anyone who assumes a seat survives compaction, restart or a refresh: it keeps working state and product intent from slipping away. CX Codex +1 ★ 8,172repo stars openrig-user A reference skill for the rig CLI: exact command syntax, JSON shape, defaults and error meanings once you already know which command to run. CX Codex +1 ★ 8,172repo stars loading-addressable-markdown Pulls exactly one Markdown section out of a filesystem tree by an address like file.md#h2-slug. Handy when a task points at a spec section instead of a whole file. CX Codex +1 ★ 8,172repo stars claude-compaction-restore Keeps the connections between files and decisions alive across context compaction: write a restore map before the squeeze, read it back after and rebuild the picture. CX Codex +1 ★ 8,172repo stars context-engineering A skill about how an agent's context window gets filled, pruned and shared. Useful when an agent drifts or forgets constraints mid-task. CX Codex +1 ★ 8,172repo stars orchestration-team An orchestration skill: it splits work into assignments, dispatches them, and watches for idle or blocked agents instead of doing the implementation itself. CX Codex +1 ★ 8,172repo stars requirements-writer Talks a product manager through rough feature notes and turns them into a single SPEC.md with observable acceptance criteria and explicit scope. CX Codex +1 ★ 8,172repo stars exec-summary Turns a feature folder into one 600–800 word document: a sales pitch, a leadership brief and a behavioral overview for engineering. CX Codex +1 ★ 8,172repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor