Autonomous Engineering Workflow Catalog
Turn “use agents for engineering” into a portfolio of explicit, governable workflow products.
A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
The chapter in one pass.
- Purpose: Turn “use agents for engineering” into a portfolio of explicit, governable workflow products.
- Best for: Leaders choosing an adoption sequence and builders defining workflow contracts.
- Prerequisites: Human-Agent Operating Model and Repository Onboarding.
- Reading time: 14 minutes.
- You will learn: How workflow classes differ in triggers, evidence, risk, human authority, and production feedback.
- Keep three ideas: autonomy is earned per workflow; work selection is an authority decision; and each workflow needs its own proof.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Open the source exercise
Choose three workflows and map trigger, intent owner, plan, authority, evidence, production observation, rollback, metrics, and promotion criteria. Show which platform components are shared and which policies remain workflow-specific.
3. Enduring Principle
Manage a catalog of workflow products
Each catalog entry declares:
- trigger and authoritative intake source;
- problem owner and intended outcome;
- supported repository and risk classes;
- planning, execution, and verification recipe;
- agents, skills, tools, environment, and budgets;
- human decisions and escalation;
- evidence, release, observation, and rollback requirements;
- success, failure, cost, attention, and trust measures; and
- current maturity and eligible autonomy.
The minimum useful portfolio is:
| Workflow | Trigger | Accepted outcome |
|---|---|---|
| Feature delivery | Approved product intent | Customer behavior delivered and verified |
| Defect remediation | Reproduced defect | Root cause corrected with regression proof |
| Test generation and maintenance | Coverage or change signal | Useful, stable tests protecting specified behavior |
| Dependency and security remediation | Vulnerability or lifecycle signal | Risk reduced without compatibility regression |
| Incident triage and root-cause analysis | Operational alert | Containment, evidence-backed cause, and corrective plan |
| Production validation | Deployment event | Technical and intended outcomes confirmed or rolled back |
| Technical-debt reduction | Maintainability signal | Measurable risk or cost reduced without behavior loss |
| Documentation and knowledge maintenance | System or policy change | Correct, discoverable, verified guidance published |
Govern work selection
An autonomous backlog selector may rank eligible work using value, urgency, risk, dependencies, readiness, capacity, and confidence. It may not invent product priority, widen scope, or consume unowned work. Work-in-progress limits and small batches reduce recovery cost and make outcomes attributable.
Earn autonomy independently
A repository may qualify Level 3 autonomy for test maintenance while production migrations remain Level 1. Metrics and incidents apply to the exact workflow, risk class, environment, and capability graph.
8. Notes and lessons learned
The unit of autonomy is not “the agent” or even “the repository.” It is a defined workflow operating on a bounded scope under measurable conditions.
9. Interview and discussion questions
- Which workflow should an organization automate first, and why?
- Who owns autonomous backlog selection?
- Why can test maintenance and production migration have different autonomy?
- Which metrics must be workflow-specific?
- What is the accepted outcome of incident triage?
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence