Pilot: evaluate LangGraph as a bounded AES runtime adapter

[sergstack]

Goal

Evaluate whether LangGraph can serve as a bounded runtime adapter for the existing Autonomous Execution Standard (AES) without changing AI-OS semantics, routing, authority, acceptance logic, or source-of-truth boundaries.

The pilot must answer one question:

Does LangGraph reduce orchestration / continuation overhead while preserving the existing AES execution contract and without creating a second source of truth?

Status

• Decision status: candidate decision
• Production promotion: NOT AUTHORIZED
• Architecture adoption: NOT AUTHORIZED
• Scope: reversible pilot only

Context

AI-OS already defines the execution semantics that matter:

requirements
-> execution
-> validation
-> defect registration
-> corrective action
-> affected-scope rerun
-> revalidation
-> requirements traceability
-> Closure Review
-> terminal acceptance / stopped

It also separates:

• overall_delivery
• qa_status
• judge_verdict
• authority_status
• merge_status
• production_status

The pilot must treat those semantics as authoritative. LangGraph is only a candidate execution mechanism.

Architectural rule

Target dependency direction:

AI-OS semantics
      ↓
AES contract
      ↓
optional runtime adapter
      ↓
LangGraph

Forbidden direction:

LangGraph semantics
      ↓
AI-OS redesign

LangGraph must not become a semantic owner for execution state, defects, approval, routing, acceptance, or production authority.

Pilot scope

Implement a minimal isolated prototype that maps one AES execution into a LangGraph state machine.

Suggested path:

START
 ↓
load_execution
 ↓
scope
 ↓
execute
 ↓
validate
 ├── PASS ──> closure_review ──> COMPLETE
 └── FAIL
       ↓
 register_defect
       ↓
 correction_allowed?
   ├── NO ──> STOPPED
   └── YES
         ↓
      correct
         ↓
      revalidate
         ↓
   closure_review

Required state preservation

The prototype must preserve the canonical AES execution record rather than inventing a parallel state model.

At minimum verify persistence / resume for:

• execution_id
• original goal / task boundary
• requirements and requirement IDs
• defects and defect IDs
• current iteration
• validation evidence
• source revision / freshness state
• acceptance criteria
• qa_status
• judge_verdict
• authority_status
• rollback data
• continuation / resume stage

Hard constraints

1. No AES semantic changes.
2. No routing changes.
3. No authority-model changes.
4. No new production status namespace.
5. No automatic owner approval.
6. No automatic merge or deploy.
7. No scope widening by the runtime.
8. No self-acceptance of residual risk.
9. No multi-agent architecture in the first pilot.
10. LangGraph execution state must not become a second source of truth.

First real-case candidate

After a toy execution passes, use one bounded Codex-style execution:

task package
-> implementation
-> tests
-> FAILED
-> defect registration
-> one permitted correction
-> affected-scope rerun
-> regression check
-> Closure Review
-> owner review

The pilot must respect the existing stricter Codex one-fix policy where applicable.

Required failure / resume test

Explicitly test process interruption:

run
-> persist state
-> kill process
-> restart
-> resume same execution

After resume, verify that the execution still has the same:

• execution ID
• requirements
• defects
• iteration
• source revision
• evidence boundary
• authority state
• acceptance criteria

A mismatch is a pilot failure.

Acceptance criteria

The pilot passes only if all of the following hold:

• AES semantics changed: 0
• Routing semantics changed: 0
• Authority semantics changed: 0
• Requirement IDs preserved across transitions and resume
• Defect IDs preserved across transitions and resume
• Failed mandatory validation cannot resolve to overall_delivery: pass
• Stale evidence is not reused after relevant state/source changes
• Human / owner gate cannot be bypassed
• Resume continues the same execution rather than reconstructing a new implicit execution
• Rollback removes the LangGraph adapter without breaking the existing AI-OS/AES workflow
• No parallel status namespace becomes authoritative
• Closure Review still evaluates the original goal / acceptance boundary

Operational KPI

Primary KPI is not framework throughput.

Measure:

How many human interventions are required only to coordinate state, continuation, handoff, retry, validation and closure — where no material owner decision is actually required?

Compare baseline vs pilot for:

• manual continuation / resume actions;
• repeated context reconstruction;
• handoff/state recovery;
• manual next-step routing;
• premature or invalid closure attempts;
• owner interventions that could have been deterministic policy execution.

Non-goals

Do not include in this issue:

• AI-OS-wide runtime migration;
• multi-agent orchestration;
• Mastra comparison implementation;
• LangChain abstraction migration;
• changes to AES schema solely for LangGraph convenience;
• changes to Thinkers, Analytics or RIOS;
• production automation;
• automatic approvals;
• automatic PR creation / merge / deploy;
• new governance concepts.

Stop conditions

Stop the pilot and mark revise / blocked if:

• LangGraph requires semantic duplication of AES state;
• resume loses IDs, authority, requirements, defects or acceptance boundary;
• framework state can contradict canonical AES state;
• implementation requires routing or governance redesign;
• complexity added is greater than coordination removed;
• rollback is not clean and local;
• a new agentic layer is required to make the pilot work.

Rollback

Rollback must be trivial:

1. remove / disable the isolated LangGraph adapter;
2. restore the prior direct AES execution path;
3. preserve pilot evidence and execution records;
4. rerun the relevant existing validators / smoke checks;
5. make no changes to canonical AES semantics.

Decision gate after pilot

After the toy case and one bounded real execution, run Judge review on:

Does LangGraph materially reduce orchestration complexity and human coordination without weakening AES semantics, evidence integrity, reversibility or authority boundaries?

Possible outcomes:

• pass -> candidate runtime component for additional pilots;
• revise -> retain evidence, narrow design and retry only if the defect is bounded;
• blocked -> remove adapter and keep current AI-OS execution model.

Revisit trigger

Revisit this decision if:

• pilot evidence contradicts the expected coordination reduction;
• state drift appears;
• authority / closure boundaries are weakened;
• implementation requires architecture-wide changes;
• a simpler runtime mechanism achieves the same result;
• framework maintenance cost materially changes.

Handoff

If this issue is accepted for implementation, hand off separately to [Codex] with:

• exact allowed files;
• minimal prototype boundary;
• tests;
• failure / resume scenario;
• rollback procedure;
• acceptance criteria above.

No implementation is authorized by this issue alone.