Stage 3.5 — AESOP Transformation OS

Operationalization

From certified agent to running program. The organizational infrastructure for deployment, adoption, maintenance, and governance.

The problem this solves

Organizations need to know how to run an AI program: who owns what, how work moves between stages, what happens when something breaks, and how to get stakeholders on board.

The operationalization layer closes that gap. It generates the documentation an organization needs to deploy, adopt, maintain, and govern the agent — using data the pipeline already collects. No new interviews, no extra data collection. One Claude API call produces four artifacts from structured pipeline data.

Working Agreement pre-engagement gate

Before any build work begins, AESOP OS generates a Working Agreement from the completed discovery session — a signed document establishing scope and commitments.

Scope

What will be delivered — six artifacts, from discovery brief through launch package.

Stakeholder
map

Executive sponsor, project owner, affected groups.

Autonomy
classification

Fully autonomous, semi-autonomous, or read-only.

Commitment
readiness

Team capacity, response-time SLA, change appetite.

Response
commitments

Who responds to what, and how fast.

The Working Agreement is a static markdown template with variable injection — not LLM-generated. It sits in the sidebar between Discover and Design. Design is gated behind a signed agreement, with a skip option for internal projects.

How to access it

1After
discovery

Complete a discovery interview. On the brief review page, click “Create Working Agreement” to generate the agreement from your session data.

2Sign and
proceed

Review the agreement, download as markdown if needed, then click “Mark as Signed” to unlock the Design stage.

3After build
completes

On the Build page, a “Generate Launch Package” button appears once the build pipeline completes. One pass generates all four artifacts.

4Review and
download

Each artifact expands inline, downloads as markdown, and marks as reviewed. Tiger Team findings can be pasted into the Repair page for the next repair cycle.

Data sources no new collection

Every artifact is generated from data already captured by the pipeline.

Discovery
session

Stakeholder map, autonomy level, commitment readiness, problem statement, constraints, risks.

Build summary
(Phase 5)

State-Change Hypothesis, Translation-Debt Assessment, Ripple Map, gap-analysis findings.

Evaluation
output

Optional. Certification level, dimension scores, known weak areas.

The Operationalization agent receives this structured data and produces all four artifacts in a single API call (max 16K output tokens).

The four artifacts

GovernanceRACI
Matrix

RACI Matrix — role-responsibility mapping across the full agent lifecycle, from discovery sign-off through decommission.

Covers 10–15 activities — discovery, design approval, KB preparation, build review, evaluation, repair, launch, training, KB maintenance, issue triage, re-evaluation, drift response, decommission.
Rule: every activity has exactly one Accountable (A). Executive sponsor is A for GO/NO-GO, I for operations; project owner is R or A for most operational tasks.
Rendered as: a markdown table, parsed to structured JSON for interactive rendering.

Stakeholder alignmentTiger Team
Brief

Tiger Team Brief — a plain-language stakeholder briefing: what changes, what we need, and a feedback mechanism.

Format: 5-minute read. Role-specific “what changes for you” scenarios, concrete asks with time commitments, thumbs-up / thumbs-down feedback.
Tone: direct, respectful, no corporate jargon. Written for busy people who need impact, not architecture.
Feedback loop: findings from stakeholder review paste into the Repair page, treated as real-world user-testing data alongside evaluation findings.

SustainabilityMaintenance
Plan

Maintenance Plan — evaluation cadence, KB review schedule, repair protocol, drift monitoring, decommission criteria.

Evaluation cadence tied to autonomy level — higher autonomy, more frequent evals. Includes triggers for unscheduled evaluation (score drop, KB change, process change).
Thresholds reference certification levels — Platinum 90+, Gold 85+, Silver 80+, Bronze 75+ — and define what score drop triggers action.
Drift monitoring: metrics to track, alert thresholds, escalation path.

RolloutAdoption
Plan

Adoption Plan — phased rollout calibrated to commitment-readiness scores, with measurable adoption metrics.

Phases: Pilot (a user subset), Expansion (a broader group with gate criteria), Full Deployment (all users, with handoff).
Calibration: low change appetite (1–2/5) recommends a longer pilot and more hands-on support; high readiness enables faster rollout.
Metrics: measurable adoption targets with specific measurement methods — not just “monitor usage.”

The generation pipeline

Two data sources, one agent, a single-pass fork to the four artifacts — then stakeholder feedback returns to Repair.

InputDiscovery
Session

Stakeholder map, autonomy level, commitment readiness, problem statement.

InputBuild
Summary

State-Change Hypothesis, Translation Debt, Ripple Map, gap analysis.

AgentOperationalization
Agent

Single-pass generation of all four artifacts from the structured data above.

Fork — launch packageFour
outputs

RACI Role-responsibility matrix.

Tiger Team Stakeholder brief.

Maintenance Eval cadence and thresholds.

Adoption Phased rollout plan.

Feedback loopTiger Team →
Repair

Stakeholder feedback feeds the Repair agent alongside evaluation reports for the next repair cycle.

Architecture principle: no new data collection. Every artifact is generated from structured data already captured during Discovery and Build. The Operationalization agent is a generation pass, not a new interview.