In manufacturing, a Manufacturing Execution System is the real-time control layer between ERP (business planning) and the shop floor. It tracks every part as it moves through workstations, logs receipts at each station (operator, machine parameters, QA pass/fail), routes parts to rework when they fail a gate, and exposes the whole state to operators via a visual kanban.
Here the parts are tickets (MESTask). The workstations are the 7 stages below. The receipts are the events streaming inside each card — every action gets a timestamp, an agent label, structured metadata, and a link to a full technical artifact. The rework route is the Review gate's Reject + Re-plan button, which sends the ticket back to Stage 1 with operator feedback baked into context.
Seven stages. Five lanes are pure agent throughput (1–4 and 6). Two lanes require human judgment — lane 5 Review (catches memory drift, operators can re-plan with feedback) and lane 7 Deploy & Maintain (ship-it gate for production code changes). Every stage below logs real receipts and links out to a full technical artifact.
evil.example.com. Stage 7 (Deploy) parks a standby sandbox for fast rollback.
hydrate(query, session_id) to pull related lessons. Stage 5 (Review) decrements confidence on drift. Stage 6 (Document) calls write_lesson(text, topics, negative_constraint) which XADDs to lessons:long_term. Stage 7 logs a monitoring breadcrumb.
query_entity("service", "svc_auth") for the canonical service record. Stage 5 (Review) calls verify_claim(claim, entity_type) on every hydrated memory — this is what catches the drift.
gh pr creates against benikigai/agent-mes. CODE tickets only — the human ship-it gate blocks before this runs. Real PRs land files under demo-runs/.
Opus 4.6 parses the raw Slack message, classifies the ticket (code/simple), extracts acceptance criteria, and defines blast radius. On re-plan loops, prior operator feedback is threaded in at the top of the context bundle so the re-run acknowledges it.
→ plan markdown · ACs · blast radius · feedback history
Redis hydrates relevant memories, Context Surfaces pulls ground-truth service metadata in parallel via asyncio.gather. Opus 4.6 sketches architecture, Codex scaffolds files in a worktree, Gemini reviews the sketch for consistency.
→ design brief · memory citations · target files · sketch verdict
Codex opens a worktree branch, reads ACs + the context bundle, drafts the fix pattern, and writes the actual output. CODE tickets get a real unified diff; SIMPLE tickets get a full markdown body assembled from skeleton + timeline + 5 whys + action items.
→ diff or draft · file path · line counts · rationale
Blaxel spins up a sandbox microVM with Plan's blast-radius constraints, copies the diff, installs deps, runs the ACs as a self-heal loop. Gemini interprets outputs. Egress kill fires on iter 2 to prove the blast radius actually holds.
→ iteration log · fail → kill → pass trajectory · violation receipt
Opus 4.6 cross-checks every hydrated memory against Context Surfaces ground truth. Contradictions fire a DRIFT event and the card blocks on a real human gate. Operators can Approve, or send Feedback to re-plan from Stage 1 with the correction baked into context.
→ drift report · human verdict · (optional) re-plan trigger
Redis composes a decision log from every event in the run, tags it with topics, and writes it as a long-term lesson. When drift was caught in Stage 5, the lesson becomes a negative constraint so future Plan stages steer around it.
→ decision log · lesson id · topics · negative-constraint flag
For CODE tickets, the card blocks on a second human gate — shipping to production needs explicit approval. On approve, GitHub assembles the PR body from stage receipts. Blaxel parks a standby sandbox for fast rollback. Redis logs a monitoring breadcrumb.
→ PR url · standby sandbox · monitoring log