You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Proposal: Codex-native evidence-driven semantic escalation for dynamic multi-agent graphs #40037
Update, 2026-09-05: this experiment produced the Slopdex source and Windows CLI preview. The release update summarizes what shipped. A separate semantic-escalation mechanism remains unvalidated; in field runs, the current owner made these decisions.
The original question: when execution reveals that an agent's task is failing or incorrectly scoped, who should resolve it next?
Depending on the evidence, the useful action may be to retry locally, change model, return the problem to its parent, split or replan the subtree, or abort. Choosing a stronger model does not repair a wrong task boundary.
The proposed experiment was a compact handoff containing the task contract, ownership chain, attempts, relevant failure evidence and remaining budget. The owner or a temporary child would choose the next action using existing graph primitives. Compare that policy with local retries and automatic tier-ups, measuring recovery, rework and cost where observable. That comparison has not been completed.
Models interpret evidence and revise the workflow. Runtime enforces identity, permissions, budgets, cancellation and delivery. A permanent escalation agent or fixed pipeline is unnecessary unless experiments demonstrate a need.
Questions for maintainers:
Is the current owner the intended place for evidence-driven replanning?
Which native attempt/receipt surface should carry a compact failure handoff?
Which planned lifecycle or backend capabilities would make local work redundant?
Related: #34278 and #32705 for model routing; #15723 for completion delivery and owner wake.
Starting a graph and authorizing its cost are separate decisions
Before replanning a failed branch, the system must decide whether the task needs a graph at all.
Four concepts should remain separate:
Model: the intelligence used for a step.
Role: the function being performed.
Thread/context: where the working history lives.
Authority and spend: which actions and additional compute are permitted.
A stronger model does not gain write authority or permission to expand the graph. A coordinator can be temporary, and a simple task can remain single-agent. Local trials used the same coordinator role in different thread/lifetime arrangements; that is behavioral evidence, not a runtime guarantee.
The product proposal is one user-facing conversation with independently configurable delegation and compute policies. Adaptive delegation could permit several agents while retaining a strict model ceiling. Conversely, a single-agent task could allow stronger reasoning without spawning children. Additional actions remain subject to user policy and runtime admission.
A compact execution receipt should expose effective model/effort, relevant permissions, graph changes and attributed spend where available. Requested configuration alone cannot establish what ran.
This material shares recurring agent-boundary patterns observed across a purpose-selected set of 100 public openai/codex Issues. It is not an assignment of responsibility to any individual Issue or reporter, and it is not a claim about OpenAI-internal causes. It is provided as improvement-oriented analysis.
Method
Fixed, non-exclusive A–F taxonomy: Authority, Interface, Provenance, Role Boundary, Lifecycle, Human Load.
Every row retains the public Issue number, title, labels, URL, A–F flags, combined tag set, and classification rationale.
All 100 assignments are explicitly marked INFERRED_FROM_METADATA.
Exact Issue-number traceability was verified for 100/100 rows.
Related observation: DOCX/PDF artifact pipeline failure pattern.
Observed:
DOCX package can remain valid and open normally.
Failure can appear only in downstream rendering/export (for example PDF generation).
Similar classes of issues exist around document conversion/rendering pipelines, but no exact match for the following root cause was found in the checked OpenAI issues.
Specific case:
OOXML package was modified/repacked.
Word opened the DOCX successfully.
PDF export failed/hung.
Preserving original OOXML part ordering restored PDF generation.
Suspected trigger: relationship/package part ordering affecting downstream export behavior.
Status:
Observation only.
Not claiming a general OOXML specification violation.
Included as a reproducibility/data point for document artifact pipelines.
Implemented locally: exact owner continuation after finalization
Condensed historical report. V9/V10 below are local iteration names, not official Codex releases.
We initially misdiagnosed native waiting. wait_agent already suspends asynchronously; keeping a turn open does not continuously run model inference during the wait. The remaining problem was continuing the correct owner after its turn had finalized.
The local join_agents path lets a parent register exact direct-child dependencies, finalize, and receive a fresh continuation when they are ready. It:
arms observation before rechecking readiness;
binds completion to the exact owned target set;
routes through the immediate parent, so a grandchild cannot bypass its coordinator;
suppresses duplicate handoffs, defers to user input, and excludes unrelated children.
The hierarchical case completed both owned leaves, continued the coordinator for synthesis, then continued the root. A detached child's later completion woke neither owner.
At the V10 checkpoint, recorded checks passed join_agents 7/7 and owned_join 15/15. Neutral native-wait and hierarchical exact-artifact trace checks passed 13/13 and 26/26. The live summary had an observer-finalization race and remained INCOMPLETE / WARNING; saved-trace replay passed. These are distinct evidence surfaces.
The reviewed Windows artifact was activated through the normal Desktop surface. Historical SHA-256: 009f044ef239fc365df9562e8218f379b774a460f457d40ac9cd36870800a95c.
A rejected candidate explains why tests alone were insufficient: failed user-turn preparation cleared a reservation but left an already-ready join without a continuation trigger. The repair reused the existing handoff after reservation cleanup. Cancellation and competing-delivery races also required targeted regressions.
Boundary: accepted continuation behavior was limited to a live process. Restart-safe terminal persistence, receiver acknowledgement, replay and recovered authority were not established. Lifecycle completion also does not prove useful output or external effects.
#40932 illustrates the lifecycle problem; its reporter scenario was not run against this artifact. The relevant branch of #15723 remained plausibly addressed but unverified; #32203 remained an unexecuted negative control. None is claimed fixed.
Field results: recursive trees, useful width and host pressure
Condensed historical report. Counts describe separate runs, not a benchmark.
Raising graph limits to 128 did not automatically produce wider decomposition: one early run still chose six participants. We then added a policy to split independent questions recursively, stop duplicate branches and name the consumer of each result.
An early live run reached 14 participants including the root, ten concurrent leaves and four ownership edges of depth. It found scope and evidence problems before mutation, then contracted to two participants after aggregation. A separate topology fixture exercised six ownership edges; that was fixture evidence, not the same live run.
In another review, twelve specialist leaves returned a consolidated defect packet: three findings were rejected, one duplicate removed and one P1 retained. The practical benefit was earlier discovery of independent risks before repeated mutation/review cycles.
A later campaign reached the 128-slot logical ceiling. Its simultaneous execution distribution was not recorded. Host pressure was clear: a trivial read took 59.2 seconds without useful output, alongside queue, initialization and join problems. Capacity alone did not make the workload operable.
The useful working shape became:
a campaign DAG records dependencies and selects ready work;
temporary recursive trees investigate and execute that work;
results aggregate through the nearest owner;
coupled changes converge on one writer;
independent review widens again, then the tree collapses at an accepted checkpoint.
The DAG describes readiness; the tree describes execution and ownership. Instructions and accumulated context changed the behavior; model weights did not change. Parallel mutation remained an open question at this checkpoint.
This needs bounded physical admission, capacity for parent continuation and cleanup, and backpressure under load. Reaching 128 proves neither reliability nor economic value. The observed benefit was less serial discovery and rework; no controlled speedup or token-saving result was established.
We began as subscription users: a predictable bill made sustained experiments practical. Wide recursive campaigns exposed burst demand that made usage-based API access interesting as an optional larger compute envelope. Subscription remained the foundation: keep the technique within predictable managed limits, let users deliberately buy more usage through API-key Codex, and support embedding through the SDK. These are proposed access models, not current entitlement guarantees. Changing authentication alone does not supply the missing graph mechanics.
Public-safe control pattern: Mutable-Scope Concurrency Guard
Author: Almási Andor Aladár
One simple userland rule from an older thread-discipline method remains useful for dynamic multi-agent graphs:
For any shared mutable scope, allow only one HEAVY mutation owner at a time unless the runtime can prove the operations are conflict-free.
A minimal public-safe version:
Classify active work as either:
HEAVY — long-running, state-changing, cross-file, architectural, or otherwise consequential work;
LIGHT — bounded read-only analysis, lookup, review, or discussion with no shared-state mutation.
Before starting a new HEAVY branch, identify its mutable scope and current owner.
If another HEAVY task already owns an overlapping mutable scope, do not start concurrent mutation. Pause, finish, re-scope, or explicitly transfer ownership first.
LIGHT work may run in parallel only while it remains non-mutating and does not redefine the active task contract.
Every active branch should have an explicit state such as ACTIVE, PAUSED, DONE, or BLOCKED, plus a clear owner and scope.
Parent/child delegation must not silently create a second mutation owner for the same files/resources.
Before merging a delegated result back into the mainline, revalidate the latest user instruction and current live state; a child result is evidence/proposal until ownership and applicability are confirmed.
When conflict cannot be ruled out, fail closed rather than relying on agents to negotiate implicitly through stale context.
This is intentionally only a small public-safe concurrency principle. It does not disclose the private thread registry, state-machine design, synchronization modules, or broader GEH orchestration logic from which the original operational practice was derived.
Updated 2026-09-05: the source and Windows x64 preview are available. Slopdex is an independent experimental Codex derivative.
The release contains:
concurrency defaults of 128, including the root in V2, and configurable depth with a default of 128;
direct-child/turn-bound joins, retained ownership across the covered successor continuation, and nearest-parent delivery;
duplicate suppression, user-turn priority and recovery after a lagged terminal signal;
required spawn-edge persistence with fail-closed admission, plus capacity/residency lifecycle changes;
optional orchestration skills and an instruction sample.
The source-only diff contains 57 changed/added paths. The recorded owner test group passed 82/82 and independent source review accepted that candidate. These results do not establish an entirely passing upstream suite or arbitrary graph reliability.
Field work changed three decisions. We deferred a separate semantic-escalation layer because the owner handled replanning. We used native wait for active supervision and join for finalized-owner continuation. Two writers worked on demonstrated independent surfaces; no general runtime guarantee against write conflicts is claimed.
Our early wide runs burned allowance in bursts and raised fears that recursive graphs would multiply costs. Later, after narrow contracts, deliberate model routing, dependency-ready waves and nearest-owner aggregation became disciplined, we observed substantially more accepted progress with usage in roughly the same order of magnitude. Fewer serial repair/review loops and less premium context spent on mechanics may explain it. This is a qualitative field observation, not a controlled cost or token benchmark; arbitrary width remains expensive.
Sol led the source campaign, with Terra and Luna contributing. Astra joined for final installed-build checks and coordinated the later downloadable rebuild. One live nested sample supported retained successor ownership, using the earlier binary; the downloadable archive has build, offline-launch and local-path-scan evidence, not a new live-model test.
Restart-safe acknowledgement/replay, broad sandbox safety and measured speed/cost gains remain unproven. The Windows temporary-directory permission seam is unresolved; Luna was exercised as a leaf. Astra's overall benefit remains to be measured.
The original proposal acknowledged the native graph primitives. But later, our "opening the cage" story overstated Slopdex's contribution: we mixed up configuring existing capabilities with adding new ones. That was our mistake.
Perhaps the biggest piece of user-facing dogfood from this whole journey is discoverability. I wanted a simple, obvious way to say: "Let capable models delegate recursively; here is the concurrency budget." And I realized far too late how much of that was already a configuration choice.
I would really like an obvious place in the app to configure this, showing the effective limits and model-specific restrictions. That does not take away our responsibility to have checked the configuration earlier.
Follow-up from daily use after moving back to stock Codex.
As I acknowledged above, native Codex already had the recursive delegation and configurable concurrency I wanted. I have moved back to the native app, and the ability to delegate broadly is great.
But I still really miss reliable parent wake-up / join semantics. Today I hit the same frustrating user-visible pattern again: the parent dispatched work to children, then stopped instead of carrying the delegated workflow through to synthesis. A separate task inspection showed the parent as idle. I have not isolated whether this instance was premature finalization, a delivery problem, or another lifecycle issue; this is a field report, not a root-cause diagnosis.
The behavior I want is the contract discussed in the earlier Slopdex join experiment: a parent explicitly registers the children it depends on, can finish its current turn, and is resumed automatically when those dependencies are ready, so it can inspect the results and continue. Nested work should return through its immediate owner, with duplicate wake-ups suppressed and user stops respected.
Native wait_agent already covers waiting within an active turn. The part I still miss in practice is dependable continuation after the owner has finalized. Having lots of subagents is useful, but having to notice that their parent went idle and manually nudge it back to work is still a real pain.
Is there now a supported native mechanism for this exact finalized-parent continuation contract, or is it still planned? I would much rather use it in stock Codex than maintain a custom fork.
Activity
SlopSurfer4444 commentedon Aug 22, 2026
Starting a graph and authorizing its cost are separate decisions
Before replanning a failed branch, the system must decide whether the task needs a graph at all.
Four concepts should remain separate:
A stronger model does not gain write authority or permission to expand the graph. A coordinator can be temporary, and a simple task can remain single-agent. Local trials used the same coordinator role in different thread/lifetime arrangements; that is behavioral evidence, not a runtime guarantee.
The product proposal is one user-facing conversation with independently configurable delegation and compute policies. Adaptive delegation could permit several agents while retaining a strict model ceiling. Conversely, a single-agent task could allow stronger reasoning without spawning children. Additional actions remain subject to user policy and runtime admission.
A compact execution receipt should expose effective model/effort, relevant permissions, graph changes and attributed spend where available. Requested configuration alone cannot establish what ran.
Related source precedents: role overrides and authority, #39299, and root authorization provenance, #39975. Neither establishes a general orchestration or spend-admission mechanism.
Open question: what native surface should admit graph growth and compute changes separately from the model's judgment that they would help?
Yamrail commentedon Aug 23, 2026
Purpose and boundary
This is a public attachment for cross-Issue analysis of agent-boundary patterns observed in a purpose-selected 100-Issue
openai/codexcorpus.Reviewed analysis
OpenAI/Codex public-Issue agent-boundary pattern classification (100-Issue corpus)
Purpose
This material shares recurring agent-boundary patterns observed across a purpose-selected set of 100 public
openai/codexIssues. It is not an assignment of responsibility to any individual Issue or reporter, and it is not a claim about OpenAI-internal causes. It is provided as improvement-oriented analysis.Method
INFERRED_FROM_METADATA.Reproduced counts
Tags are non-exclusive; shares do not sum to 100%.
Most frequent pair co-occurrences
Supervisor review
Result:
PASS_WITH_LIMITATIONS.Required limitations
openai/codexIssue; the counts are not product-wide prevalence estimates.Artifact SHA-256
9b265d8e78b99b05f6bda8c6d1f5ab8087d6b4777d5c95158d3d888302171e0175997d2c83dc3fdd5b3054be84a03e25bb19962a9e165a2d1cfc3baee83fcf8c0cf2837073b6c3b6fd40759cc7dfd3ab2647a0834d816788b39147d01d7ab2026259b48c7ac26677cb98cb716d51299838501aa32a313e9d5666a683002a19a4100-row public classification CSV (Issue links, A–F flags, tag sets, rationales, review status)
Public manifest
Yamrail commentedon Aug 24, 2026
Related observation: DOCX/PDF artifact pipeline failure pattern.
Observed:
Specific case:
Status:
Yamrail commentedon Aug 24, 2026
Related observation: GitHub write/reachability variance across chat execution contexts.
Observed:
Status:
Reproducibility point:
SlopSurfer4444 commentedon Aug 25, 2026
Removed.
SlopSurfer4444 commentedon Aug 26, 2026
Implemented locally: exact owner continuation after finalization
Condensed historical report. V9/V10 below are local iteration names, not official Codex releases.
We initially misdiagnosed native waiting.
wait_agentalready suspends asynchronously; keeping a turn open does not continuously run model inference during the wait. The remaining problem was continuing the correct owner after its turn had finalized.The local
join_agentspath lets a parent register exact direct-child dependencies, finalize, and receive a fresh continuation when they are ready. It:The hierarchical case completed both owned leaves, continued the coordinator for synthesis, then continued the root. A detached child's later completion woke neither owner.
At the V10 checkpoint, recorded checks passed
join_agents7/7 andowned_join15/15. Neutral native-wait and hierarchical exact-artifact trace checks passed 13/13 and 26/26. The live summary had an observer-finalization race and remainedINCOMPLETE / WARNING; saved-trace replay passed. These are distinct evidence surfaces.The reviewed Windows artifact was activated through the normal Desktop surface. Historical SHA-256:
009f044ef239fc365df9562e8218f379b774a460f457d40ac9cd36870800a95c.A rejected candidate explains why tests alone were insufficient: failed user-turn preparation cleared a reservation but left an already-ready join without a continuation trigger. The repair reused the existing handoff after reservation cleanup. Cancellation and competing-delivery races also required targeted regressions.
Boundary: accepted continuation behavior was limited to a live process. Restart-safe terminal persistence, receiver acknowledgement, replay and recovered authority were not established. Lifecycle completion also does not prove useful output or external effects.
#40932 illustrates the lifecycle problem; its reporter scenario was not run against this artifact. The relevant branch of #15723 remained plausibly addressed but unverified; #32203 remained an unexecuted negative control. None is claimed fixed.
Later source, tests and release. Local patches should shrink when native behavior becomes sufficient for the same contract.
SlopSurfer4444 commentedon Aug 30, 2026
Field results: recursive trees, useful width and host pressure
Condensed historical report. Counts describe separate runs, not a benchmark.
Raising graph limits to 128 did not automatically produce wider decomposition: one early run still chose six participants. We then added a policy to split independent questions recursively, stop duplicate branches and name the consumer of each result.
An early live run reached 14 participants including the root, ten concurrent leaves and four ownership edges of depth. It found scope and evidence problems before mutation, then contracted to two participants after aggregation. A separate topology fixture exercised six ownership edges; that was fixture evidence, not the same live run.
In another review, twelve specialist leaves returned a consolidated defect packet: three findings were rejected, one duplicate removed and one P1 retained. The practical benefit was earlier discovery of independent risks before repeated mutation/review cycles.
A later campaign reached the 128-slot logical ceiling. Its simultaneous execution distribution was not recorded. Host pressure was clear: a trivial read took 59.2 seconds without useful output, alongside queue, initialization and join problems. Capacity alone did not make the workload operable.
The useful working shape became:
The DAG describes readiness; the tree describes execution and ownership. Instructions and accumulated context changed the behavior; model weights did not change. Parallel mutation remained an open question at this checkpoint.
This needs bounded physical admission, capacity for parent continuation and cleanup, and backpressure under load. Reaching 128 proves neither reliability nor economic value. The observed benefit was less serial discovery and rework; no controlled speedup or token-saving result was established.
We began as subscription users: a predictable bill made sustained experiments practical. Wide recursive campaigns exposed burst demand that made usage-based API access interesting as an optional larger compute envelope. Subscription remained the foundation: keep the technique within predictable managed limits, let users deliberately buy more usage through API-key Codex, and support embedding through the SDK. These are proposed access models, not current entitlement guarantees. Changing authentication alone does not supply the missing graph mechanics.
The subsequent source release contains the narrower implemented contracts and their remaining limitations.
hyperbetteri commentedon Sep 1, 2026
Public-safe control pattern: Mutable-Scope Concurrency Guard
Author: Almási Andor Aladár
One simple userland rule from an older thread-discipline method remains useful for dynamic multi-agent graphs:
A minimal public-safe version:
HEAVY— long-running, state-changing, cross-file, architectural, or otherwise consequential work;LIGHT— bounded read-only analysis, lookup, review, or discussion with no shared-state mutation.ACTIVE,PAUSED,DONE, orBLOCKED, plus a clear owner and scope.This is intentionally only a small public-safe concurrency principle. It does not disclose the private thread registry, state-machine design, synchronization modules, or broader GEH orchestration logic from which the original operational practice was derived.
Copyright © 2026 Almási Andor Aladár. Public-safe excerpt; no disclosure or license of the underlying private architecture.
SlopSurfer4444 commentedon Sep 4, 2026
Slopdex: source and Windows CLI preview
Updated 2026-09-05: the source and Windows x64 preview are available. Slopdex is an independent experimental Codex derivative.
The release contains:
The source-only diff contains 57 changed/added paths. The recorded owner test group passed 82/82 and independent source review accepted that candidate. These results do not establish an entirely passing upstream suite or arbitrary graph reliability.
Field work changed three decisions. We deferred a separate semantic-escalation layer because the owner handled replanning. We used native wait for active supervision and join for finalized-owner continuation. Two writers worked on demonstrated independent surfaces; no general runtime guarantee against write conflicts is claimed.
Our early wide runs burned allowance in bursts and raised fears that recursive graphs would multiply costs. Later, after narrow contracts, deliberate model routing, dependency-ready waves and nearest-owner aggregation became disciplined, we observed substantially more accepted progress with usage in roughly the same order of magnitude. Fewer serial repair/review loops and less premium context spent on mechanics may explain it. This is a qualitative field observation, not a controlled cost or token benchmark; arbitrary width remains expensive.
Sol led the source campaign, with Terra and Luna contributing. Astra joined for final installed-build checks and coordinated the later downloadable rebuild. One live nested sample supported retained successor ownership, using the earlier binary; the downloadable archive has build, offline-launch and local-path-scan evidence, not a new live-model test.
Restart-safe acknowledgement/replay, broad sandbox safety and measured speed/cost gains remain unproven. The Windows temporary-directory permission seam is unresolved; Luna was exercised as a leaf. Astra's overall benefit remains to be measured.
Review guide · Findings and limits · Operating skills · Build provenance
The useful external feedback is a reproducible failure or a real-task comparison of time to accepted result, rework, owner intervention and usage.
SlopSurfer4444 commentedon Sep 5, 2026
A very overdue realization. And yes, I'm dying of cringe a little as I write this.
Stock Codex already supported recursive delegation and configurable subagent concurrency before this issue was opened. For my main goal, a custom binary wasn't necessary. The history is clear: V2 concurrency was configurable by April 27, and V2 stopped applying the legacy depth limit on April 29.
The original proposal acknowledged the native graph primitives. But later, our "opening the cage" story overstated Slopdex's contribution: we mixed up configuring existing capabilities with adding new ones. That was our mistake.
Perhaps the biggest piece of user-facing dogfood from this whole journey is discoverability. I wanted a simple, obvious way to say: "Let capable models delegate recursively; here is the concurrency budget." And I realized far too late how much of that was already a configuration choice.
I would really like an obvious place in the app to configure this, showing the effective limits and model-specific restrictions. That does not take away our responsibility to have checked the configuration earlier.
SlopSurfer4444 commentedon Sep 23, 2026
Follow-up from daily use after moving back to stock Codex.
As I acknowledged above, native Codex already had the recursive delegation and configurable concurrency I wanted. I have moved back to the native app, and the ability to delegate broadly is great.
But I still really miss reliable parent wake-up / join semantics. Today I hit the same frustrating user-visible pattern again: the parent dispatched work to children, then stopped instead of carrying the delegated workflow through to synthesis. A separate task inspection showed the parent as idle. I have not isolated whether this instance was premature finalization, a delivery problem, or another lifecycle issue; this is a field report, not a root-cause diagnosis.
The behavior I want is the contract discussed in the earlier Slopdex join experiment: a parent explicitly registers the children it depends on, can finish its current turn, and is resumed automatically when those dependencies are ready, so it can inspect the results and continue. Nested work should return through its immediate owner, with duplicate wake-ups suppressed and user stops respected.
Native
wait_agentalready covers waiting within an active turn. The part I still miss in practice is dependable continuation after the owner has finalized. Having lots of subagents is useful, but having to notice that their parent went idle and manually nudge it back to work is still a real pain.Is there now a supported native mechanism for this exact finalized-parent continuation contract, or is it still planned? I would much rather use it in stock Codex than maintain a custom fork.