The mandate
Design the lightest operating system that still makes ownership real.
Plans operating procedures, ownership, service levels, controls, and exception handling.
The Operations Agent defines triggers, owners, inputs, outputs, service levels, exceptions, vendors, risks, reviews, and decisions. It avoids both founder-dependent improvisation and process weight the company has not earned.
What to bring
Bring one recurring process, its current owner, failure evidence, and desired service boundary.
The agent needs to know when work starts, where it fails, who is affected, and what recovery should look like—not only the ideal happy path.
- 01
The recurring process, vendor boundary, review, or company operation in scope.
- 02
What starts the process, who owns it now, and who contributes.
- 03
Delays, ambiguity, exceptions, vendor issues, incidents, and evidence of process failure.
- 04
Desired service level, capacity, exception tolerance, and recovery expectation.
- 05
The reliability, speed, ownership, cost, or risk outcome to improve.
What you receive
An operating rhythm and process register people can actually follow.
The operating system, service levels, and risk register connect everyday ownership to exceptions, recovery paths, vendors, and recurring decisions.
- 01
Company operating system
operations/operating-system.mdReady when
Meetings, decisions, artifacts, owners, and cadences are explicit.
- 02
Process and service-level register
operations/process-register.jsonReady when
Critical processes have triggers, owners, outputs, and recovery paths.
- 03
Operational risk register
operations/risks.mdReady when
Probability, impact, mitigation, trigger, and owner are maintained.
The method
Start with the critical flow and design exceptions before adding ceremony.
The plan aims for the smallest process that removes ambiguity, survives failure, and produces useful review evidence.
- 1
Identify the flow
Define trigger, inputs, decisions, outputs, customer consequence, and accountable owner.
- 2
Set ownership
Assign roles, handoffs, service expectations, vendor boundaries, and evidence.
- 3
Design exceptions
Map failure detection, escalation, recovery, idempotency, and safe fallback behavior.
- 4
Review
Schedule service, overdue-work, vendor, risk, and process-change decisions.
Signals & guardrails
Process is overhead unless it removes a recurring ambiguity or risk.
Unowned exceptions, vendor lock-in without an exit, undocumented external resources, or ceremony that exceeds company stage stop the operating design.
Signs the work is useful
- Critical process SLA attainment
- Overdue operating actions
- Material risks without owners
Reasons to pause
- Process overhead exceeds company stage
- Vendors lack ownership and exit plans
Approval boundary
This entrypoint declares no open-world effect. Applying its todos still requires an authenticated, scoped project run.
Technical appendix
The exact contract behind the profile.
Useful for operators who need to inspect the immutable Kit version, typed boundary, and verification surface.
- Kit
- company-suite@0.1.0
- Entrypoint
- plan-operations
- Function
- plan-operations
- Runtime
- python@3.12
- Input
- specialist-brief.schema.json
- Output
- specialist-plan.schema.json
Verification
specialist-plan-quality · specialist-plan-schema
Connected systems
No external connector required