Pegasus AgentOps Case Study

Operational problem

Agents needed reliable local operations without a generic shell escape hatch.

Repeated command construction created friction, inconsistent error reporting, and unclear authority boundaries. The meaningful problem was not merely command execution: it was how to offer a bounded catalog that could be called consistently, audited durably, recovered safely, and exercised from both agent and product-local workflows.

Users & constraints

One operation contract, two execution surfaces, explicit authority.

MCP and the product-local PAO CLI share the same fixed typed operation catalog.
Generic command strings are excluded from the contract.
Authenticated user and System execution remain separated rather than blurred by convenience.
Filesystem work must defend against unsafe paths and reparse behavior.
Process identity, bounded output, cancellation, durable receipts, installation, repair, and rollback are part of the system—not afterthoughts.

Architecture & tradeoffs

A service-backed execution boundary rather than a collection of scripts.

Typed clients

MCP and PAO CLI submit one named operation plus separately validated arguments.

Authority boundary

User and System work remain explicit across the local named-pipe and service boundary.

Durable execution

SQLite/WAL queueing, idempotent receipts, bounded output, and deterministic cleanup preserve recoverability.

Install and repair

Self-contained packaging, service/tray lifecycle, repair, ACL restoration, migration, and rollback stay within the product contract.

Sanitized conceptual view. Internal paths, identities, authentication material, service configuration, package hashes, and raw diagnostics are omitted.

What Shayne owned

The field contract and acceptance boundary.

Problem discoveryIdentified recurring agent friction and mapped where shell-oriented behavior created unusable or unsafe boundaries.

Requirements and usabilityDefined typed schemas, mapped-path behavior, authorization expectations, installer/PATH behavior, and migration outcomes.

Authority decisionsRequired explicit user-versus-System separation and recoverable security-sensitive lifecycle behavior.

AcceptanceReproduced failures and accepted results across executable, service, MCP, installer, repair, and live runtime evidence.

AI role

Specialist implementation under human technical direction.

AI agents contributed implementation, testing, diagnosis, and review work within bounded modules. Shayne retained the problem definition, schema and usability requirements, authority decisions, architecture tradeoffs, correction of false assumptions, and final acceptance. The public ownership model distinguishes Shayne's technical direction and acceptance from the implementation work performed by specialist agents.

Verification

Multiple evidence layers, plus a real repair scenario.

Focused module suitesCore operation, lifecycle, and failure-path coverage.

Service harnessAuthentication, identity, and service-boundary checks.

Clean release checkpointBuild and packaging completed cleanly.

Install + repairReal initial installation and same-version repair on one workstation.

The repair fixture restored deliberately damaged access controls and restarted a stopped service after an active MCP client drained. Together, these checks establish the installed single-workstation Prod Alpha and its repair behavior.

Result & next stage

A self-contained, installed Windows Prod Alpha.

The result is an implemented and tested self-contained Windows x64 Prod Alpha that was packaged, installed, and live-verified on one developer workstation. The next validation stage expands compatibility and lifecycle testing across additional Windows systems and operating conditions.

Current evidence covers one developer workstation, named test lanes, installation, repair, service behavior, and local MCP/CLI operation.

Pegasus AgentOps.