# Week 4 Takeoff proposal · MEGA Developer

John Lindquist's proposal for MEGA Developer Week 4 (Takeoff): five one-hour videos, S04E01–S04E05, each split into five 12-minute sections with the demo, the evergreen idea, and the workshop lessons it reuses.

- Status: proposal for team discussion; updated 2026-09-23.
- Human view: https://mega-week4-proposal.johnlindquist.workers.dev/ · Structured JSON: https://mega-week4-proposal.johnlindquist.workers.dev/proposal.json · Agent guide: https://mega-week4-proposal.johnlindquist.workers.dev/llms.txt
- Format: Each episode is one hour, split into five 12-minute sections. Each section opens with something the audience already knows, then what they can also do.
- The loop that runs through every day: trigger → decide → act → check → record → report.

## Episodes at a glance

| Episode | Title | Sections |
|---|---|---|
| S04E01 | Mechanics Behind Autonomous Systems | Autonomy; Triggers; Memory; Control; Recovery |
| S04E02 | Building Portable Agent Control Planes | Configuration; Portability; Knowledge at startup; Versioning the whys; Proof |
| S04E03 | Orchestrating Autonomous Agent Teams | Delegation; Coordination; Parallelism; Environment; Supervision |
| S04E04 | Automating Work Beyond Code | Events beyond code; Sorting; Pipelines; Research and product work; Dogfooding loop and boundaries |
| S04E05 | Building Self-Improving Engineering Systems | Feedback; Evaluation; Auto-research; The harness improves itself; Finale |

## S04E01 · Mechanics Behind Autonomous Systems

Agree on the goal, trigger on more than pull requests, remember as a team, send decisions to people, and prove a problem before fixing it.

Brief: https://mega-dot-dev.github.io/mega-content/videos/s04e01/main/ · MEGA lesson: https://mega-dot-dev.github.io/mega-content/lessons/s04e01/

### The brief (from MEGA)

Most people still work with agents directly, sometimes with simple schedules or routines on GitHub and/or Cursor. They are rarely creative about this and often worry about agents making mistakes. They also struggle to find time for automation and tend to over-engineer their solutions.
- **Autonomy:** we need **to show** people what is already possible and how far AI-based automation can be pushed. Basic GitHub Actions will not impress anyone at this point, but the proactive behavior of cloud agents will.
- **Runtime:** when thinking about events, triggers, heartbeats, schedules, and similar, programmers often think in terms of the pre-AI era of “dumb crons.” Now we have Cursor Automations, GitHub Actions, Devin, and custom VPS agents that can respond to those actions.
- **State:** we could show setups on Cloudflare (Durable Objects, for example) or even a simple filesystem-based setup where the agent is aware of what it has done recently, not just in the current session.
- **Control:** because ambient agents often operate without supervision, there are concerns about control — mixing data, taking unwanted actions, or spending too much money. It would be useful to show that even in the most sensitive systems, there are processes that can be automated and still bring value without a real risk of damage.
- **Observation:** observability was discussed in Angie’s week, but here we should emphasize that observability for ambient agents has to be centralized. Depending on the setup, tools such as Langfuse or Braintrust may be useful.

We may want to showcase scenarios such as:
1. This session has to be inspirational, so we may present as many use cases as possible, mentioning the tools and platforms people can use.
2. Examples may cover: **incident (Sentry, for example) → PR**, **PR enriched with a video of clicking through the app**, **UI/UX review against a design system**, **support ticket to evidence and rich context**, **scanning telemetry logs**, and similar.

### MEGA lesson outline

- Autonomy: supervision levels, bounded independence, proactive behavior, trust calibration
- Runtime: events, triggers, jobs, queues, schedules, heartbeats, long-running loops
- State: persistent sessions, checkpoints, resumability, shared state, continuity across runs
- Control: permissions, budgets, approval gates, cancellation, escalation, human intervention
- Observation and Recovery: progress, traces, costs, failures, retries, rollbacks, repairs

### Proposal · five 12-minute sections

#### 1. Autonomy: agree first, then keep the session on track (0:00–12:00)

- **You already know:** Typing a prompt and letting the agent run.
- **You can also:** Use the first turn to agree on the goal. The agent restates the goal, its assumptions, the risks, and how much could break before it changes anything.
- **Show:** An agreed session is running and you notice something interesting. Instead of asking in the main thread, send it to a side lane: a quick side question, a separate exploration, or background work. Only the result comes back, and you check it before adding it to the main conversation.
- **Evergreen:** An agreed-on conversation is your most valuable asset. Explore on the side instead of derailing it.
- **Worth saying:** Before, one side question derailed the chat and you started over. Now the main conversation keeps its focus while side lanes explore.
- **Workshop lessons:** Get aligned before asking for execution; Ask side questions without derailing the task

#### 2. Triggers: code review is just the first event (12:00–24:00)

- **You already know:** Review bots that comment when a pull request opens.
- **You can also:** Set off the same kind of reviewer at other moments in the harness: when the agent stops, when you submit a prompt, before a tool runs.
- **Show:** An advisor with one rule on the agent-stop event, and a hook that reacts to a word or intent in a prompt. Then an app-level trigger: a dev-server error automatically starts an investigation. Scheduled jobs could go here too.
- **Evergreen:** One rule, one moment, one response, and silence otherwise.
- **Worth saying:** Fast classification models make these triggers cheap enough to run all the time. Mention it here; teach it later.
- **Workshop lessons:** Know when an AI advisor helps; Make a focused advisor from an example

#### 3. Memory: agent-readable workbooks (24:00–36:00)

- **You already know:** Team wikis and READMEs that go out of date.
- **You can also:** Keep a team workbook built for agents. Anyone points their agent at it and gets walked through what they need, anyone can drop notes in, and the agent keeps it organized.
- **Show:** Create a workbook, drop in a few rough notes, then point a fresh agent at it and ask for one exact fact. This is where the isAgentic approach fits.
- **Evergreen:** Use the memory system built into your harness. The harness and its models are tuned for it, and each harness does it differently.
- **Workshop lessons:** Save learning in an agent-readable workbook

#### 4. Control: send decisions to the right person (36:00–48:00)

- **You already know:** Approval prompts in the terminal and required pull-request reviewers.
- **You can also:** Have the agent send a decision to the person who owns it, wherever they are: a phone alert, Slack, or the issue tracker, where people can discuss it.
- **Show:** The agent reaches a decision point and opens or updates an issue with the options, its recommendation, the evidence, and what each choice leads to. It alerts the owner, the owner replies, and the same task continues.
- **Evergreen:** A decision request stands on its own: enough to decide without reading the whole conversation.
- **Worth saying:** Tools for teams to manage agents together are coming. Today the issue tracker is the simple, reliable place for decisions.
- **Workshop lessons:** Help the whole team make safe small changes; Phone notification → decision → continuation

#### 5. Recovery: the minimal reproduction (48:00–60:00)

- **You already know:** A library maintainer replying “can you give me the smallest example that reproduces this?”
- **You can also:** Ask your agent to build that example for any problem you notice.
- **Show:** You notice a problem. The agent builds the smallest example that fails, which proves the problem is real. It makes the smallest fix, the example passes, and the example becomes a regression test. Broken and fixed side by side.
- **Evergreen:** Prove the problem before fixing it. The reproduction is the evidence; the test keeps it fixed.
- **Workshop lessons:** Isolate a slow component before guessing

### Open items

- Dogfooding loop: covered in E04, section 5.
- Classification model: previewed in section 2; taught in E04, section 2, as the step that sorts incoming work.
- Section 2 triggers: one more brainstorm round on dev-server errors and scheduled jobs.

## S04E02 · Building Portable Agent Control Planes

Turn repeated work into configured harnesses: role files with narrow tools and preloaded context, defined where their responsibility lives, with the reasons behind every line kept on record.

Brief: https://mega-dot-dev.github.io/mega-content/videos/s04e02/main/ · MEGA lesson: https://mega-dot-dev.github.io/mega-content/lessons/s04e02/

### The brief (from MEGA)

This session is about **managing knowledge and setup** that is harness-agnostic and covers everything durable agents need to make as many decisions as possible without human involvement. They also have to be able to reach the right person when needed.
- **Configuration:** the setup should not be over-engineered. We can show some Markdown templates and an Obsidian-like knowledge system that works as a wiki for both agents and humans.
- **Environment:** we should show how centralization (a VPS or a dedicated machine) helps with managing ambient agents. That does not necessarily mean everything has to be centralized, but knowledge about the setup should be — at the end of the day, ambient agents have to be managed by other agents.
- **Knowledge Delivery:** the problem with most knowledge bases is that they quickly become outdated. That is less true with agents, especially when they work with templates and dynamic templates (the agent decides on the structure, but within some rules, rather than a rigid structure).
- **Operations:** ambient agents will operate from system prompts, profiles, and skills that evolve over time, often improved semi-autonomously. All of this has to be versioned, with an easy way to roll back. Git is the obvious choice, but not the only one — platforms such as Langfuse can extend this, so agents and a given setup can be evaluated.

We may want to showcase scenarios such as:
1. A setup that **starts simple** and can self-evolve and self-heal over time. This can be achieved fairly easily through centralization and foundations that leave agents free to modify every aspect of the system.

### MEGA lesson outline

- Configuration: executable Markdown, profiles, skills, rules, hooks, tools, agent rosters
- Portability: durable workflow definitions with explicit adapters for different harnesses
- Environment: shims, policies, sandboxes, secrets, resources, safe defaults
- Knowledge Delivery: contextual loading, routing, push-based injection, code maps, documentation
- Operations: versioning, inspection, reuse, migration, rollback, Git-native recovery

### Proposal · five 12-minute sections

#### 1. Configuration: from scripts to configured harnesses (0:00–12:00)

- **You already know:** Running a script, then reading and interpreting its output yourself.
- **You can also:** Launch a configured harness: a Markdown role file (“you are the pull-request person”, “you are the benchmarker”) plus launch flags for its tools, model, reasoning level, and starting context for the folders it works in. Anyone on the team can use the same role file.
- **Show:** Ask an agent to look through past conversations, and talk with the team about which jobs keep coming back. Save two or three as role files. Launch the benchmarker with a narrow tool set and low reasoning, and compare it with the general agent. On a slide: Claude Code --append-system-prompt, --agent, --allowedTools, --effort; Pi --append-system-prompt, --tools, sonnet:high; OpenCode --agent; Codex --profile.
- **Evergreen:** Repeatable work that still needs judgment deserves a narrow, preloaded agent — and good context lets a cheaper, faster model do it.
- **Worth saying:** A skill is picked up by the general agent and can leak into shared context. A role is a whole agent set up for one kind of job.
- **Workshop lessons:** Think in responsibilities and shared memory; Make a harness feel like your own

#### 2. Portability: roles above the project (12:00–24:00)

- **You already know:** Project settings, such as the AGENTS.md in a repo.
- **You can also:** Define agents at the user or team level, so they aren’t tied to one project: personal tools, business tasks, and team roles that work across every repo.
- **Show:** The same role saved in a project versus saved for the user. Then agents that work outside any project — an offer checker, campaign editor, and video publisher — and a team role shared from a team repo.
- **Evergreen:** Define the agent once, wherever its responsibility sits: the project, the person, or the team.
- **Worth saying:** Tools like Grok Bot (Cursor and SpaceXAI) organize around agent teammates — each with its own cloud computer, sign-ins, and learned routines — instead of projects. Agents become team members that work across projects.
- **Workshop lessons:** Use the harness's natural delegation pattern

#### 3. Knowledge at startup: script it before the first turn (24:00–36:00)

- **You already know:** Asking the agent to “load the last five pull requests and open issues.”
- **You can also:** Have a script fetch it, and the harness loads it into context before the conversation starts — no model thinking, no turns spent.
- **Show:** A startup script uses the GitHub CLI to pull recent pull requests, issues, and messages from other projects, then launches the role with it all loaded. Compare the time and turns against asking the agent to fetch it. Same sources the agent would call, just called ahead of time.
- **Evergreen:** Anything a script can load, a script should load. Save the model’s thinking for decisions.
- **Worth saying:** A role plus its startup context is what makes a configured harness.
- **Workshop lessons:** Feed agents fresh context and system signals

#### 4. Versioning the whys (36:00–48:00)

- **You already know:** Git history for code.
- **You can also:** Record why each line of a role or skill exists. The record isn’t loaded into the running agent, but the agent that edits the configuration reads it first.
- **Show:** Ask a config-manager agent to “simplify this role.” Without the record, it deletes a line that mattered. With the commit history and decision notes linking back to the original conversation, it keeps the line and explains why. Then the change process: evidence, intended change, a scenario that shows the difference, and a way to undo it.
- **Evergreen:** The wording in instructions carries real weight. Keep the why next to the config, not inside it.
- **Worth saying:** Comments explain code; decision records explain instructions.
- **Workshop lessons:** Keep decisions, throw away variations

#### 5. Proof: the cheaper role holds up (48:00–60:00)

- **You already know:** Trusting that a smaller or cheaper model is “good enough.”
- **You can also:** Benchmark the configured role on a low-reasoning model against the general agent on the same tasks, and keep the result with the role.
- **Show:** Run a handful of real, repeated tasks through both. Compare quality, time, and cost side by side, then record which model and settings the role is approved for.
- **Evergreen:** A cheaper setup is a claim until the same tasks prove it.
- **Worth saying:** Pays off section 1’s cost claim and reuses the benchmarker role.
- **Workshop lessons:** Pick a model for each kind of work

### Open items

- Environment (main machine plus delegated machines over Tailscale, a benchmark-only Mac mini, Herdr or tmux) is covered in E03, section 4.

## S04E03 · Orchestrating Autonomous Agent Teams

Agents managing agents: helpers with one job each, a record that outlives them, ownership that prevents collisions, machines with room, and a way to find and stop any agent.

Brief: https://mega-dot-dev.github.io/mega-content/videos/s04e03/main/ · MEGA lesson: https://mega-dot-dev.github.io/mega-content/lessons/s04e03/

### The brief (from MEGA)

This one gets us to a point where **agents manage other agents** within **an environment we shape**. Our job becomes building primitives agents can use to **build and manage tools, integrations, and workflows**. This gets very close to a software factory — or becomes one — though it covers not only the development process but also the other areas that make a product.
- **Organization:** when we think about agentic teams, we often imagine a complicated setup designed from scratch. Here, we will focus instead on making a system that can **evolve**.
- **Coordination:** agents have to be short-lived, but the system itself has to be durable. Those agents need to be aware of **what they are doing, what they have done, and what is planned**.
- **Parallelism:** autonomous agents get messy quickly, especially when they are managed by multiple people. If more than one agent works on something similar, they often collide and start fighting each other. Even if we do not have answers to all of these issues, we should show that they exist and have to be considered.
- **Supervision:** say we have Pi instances spawned on multiple machines. An AI agent has to be able to get us to any of those instances and its history, and explain what has been done, what failed, and so on. We may show scenarios where agents **monitor** a system on a schedule, suggest improvements, and find issues.

We may want to showcase scenarios such as:
1. A custom setup based on Omp, a few agent templates, and a knowledge system. It would be useful to include as many insights, ideas, tools, and configs as possible — all oriented toward self-evolving systems.

### MEGA lesson outline

- Organization: planner, researcher, builder, reviewer, validator roles with bounded access
- Coordination: shared goals, isolated contexts, task dependencies, bidirectional handoffs
- Parallelism: worktrees, branches, sessions, tiled panes, queues, merge points
- Routing: matching work to agents, tools, and models based on capability, risk, cost, and speed
- Supervision: progress visibility, collision detection, intervention, escalation, final human control

### Proposal · five 12-minute sections

#### 1. Delegation: one manager, helpers with one job each (0:00–12:00)

- **You already know:** Asking one agent to do everything, or running several chats yourself and stitching the results together.
- **You can also:** Let one manager agent split the work by responsibility, give each helper one job, one output, and one stop point, and keep one integrator accountable for the result.
- **Show:** Run the plain single-agent version first as a baseline. Then split it with the harness’s built-in helper pattern and compare. The day-two role files become the team members here.
- **Evergreen:** Delegate outcomes, not activity. One accountable integrator.
- **Worth saying:** Organization grows from real needs: add a reviewer when reviews are the bottleneck, not because an org chart says so.
- **Workshop lessons:** Use the harness's natural delegation pattern; Think in responsibilities and shared memory

#### 2. Coordination: short-lived agents, lasting record (12:00–24:00)

- **You already know:** A kanban board or issue tracker that keeps a human team in sync.
- **You can also:** Have agents read and write the same task record — what they’re doing, what they’ve done, what’s planned — and hand over in a note that stands on its own.
- **Show:** One agent works a task and ends. A brand-new agent picks it up from the record alone and continues without the old conversation.
- **Evergreen:** Agents are disposable; the record isn’t.
- **Workshop lessons:** Look inside delegated work; Give each task a clear workspace and pane

#### 3. Parallelism: collisions and ownership (24:00–36:00)

- **You already know:** Git branches and merge conflicts.
- **You can also:** Give every parallel agent its own workspace or worktree, decide who owns which files and shared contracts before anyone starts, and merge through one integrator.
- **Show:** The honest story: a parallel polish swarm where agents edited the same files and some quietly ran on the wrong model. Then the fix — ownership boundaries, contracts stated up front, a model check, one integrator.
- **Evergreen:** Parallelize by ownership, not by agent count.
- **Worth saying:** Even without answers to every collision, show that the problem exists and has to be designed for.
- **Workshop lessons:** Give each task a clear workspace and pane; Pick a model for each kind of work

#### 4. Environment: a main machine and machines with room (36:00–48:00)

- **You already know:** Running everything on your own laptop.
- **You can also:** Work from one main machine and hand jobs to other machines on your private Tailscale network, with Herdr or tmux so the remote machine feels like the terminal you’re already in.
- **Show:** A Mac mini used only for benchmarks, so it always has full resources. Then other jobs worth moving: long batch runs, media encoding, overnight research. Keep the interactive loop on the main machine.
- **Evergreen:** Move work only when measurement says it helps. More agents on one overloaded machine don’t add capacity.
- **Workshop lessons:** Spread heavy work across machines

#### 5. Supervision: find, explain, and stop any agent (48:00–60:00)

- **You already know:** Clicking through terminal tabs to check on each agent.
- **You can also:** Ask one agent to take you to any other — on any machine — show its history, and explain what it did and what failed. Watch from your phone; steer or stop on purpose.
- **Show:** Search across workspaces and jump to a pane; a read-only fleet view where steering asks for confirmation every time; joining a live session from the phone. Then a scheduled monitor agent that reviews the fleet and suggests improvements.
- **Evergreen:** If you can start an agent, you must be able to find it, inspect it, and stop it.
- **Workshop lessons:** Look inside delegated work; Collaborate in one live agent session; Control a local session from your phone

### Open items

- [new] Scheduled monitor agent that reviews the fleet and suggests improvements.
- Decide whether the wrong-model swarm story goes on camera.

## S04E04 · Automating Work Beyond Code

The same loop works outside code: meetings and messages become events, a fast classifier sorts them, small stages act, and someone uses the result before it counts.

Brief: https://mega-dot-dev.github.io/mega-content/videos/s04e04/main/ · MEGA lesson: https://mega-dot-dev.github.io/mega-content/lessons/s04e04/

> On the MEGA page, the brief’s Delivery point ends mid-thought.

### The brief (from MEGA)

This lesson is about getting beyond code, and the good news is that **most of what we have shown so far easily translates to other fields** — UI/UX, marketing, customer support, business decisions, and more.
- **Events:** we need to show that an event may arrive not only from a system, but also from messages, emails, meetings, calls, social media, and various actions taken by a human or other agents.
- **Pipelines:** automations quickly get complicated because they depend on one another. We need to show that even though we have AI now, the entire system must remain straightforward and flexible.
- **Delivery:** it is easy to think that most input for automation has to come from a human.

### MEGA lesson outline

- Events: repository changes, issues, messages, schedules, tool calls, failures, external signals
- Hooks: inspecting, redirecting, blocking, enriching, or continuing agent actions
- Pipelines: observe, classify, route, execute, verify, communicate
- Push Systems: delivering knowledge and instructions when needed instead of relying on agent discovery
- Boundaries: deduplication, backpressure, budgets, permissions, failure containment, human checkpoints

### Proposal · five 12-minute sections

#### 1. Events beyond code: a meeting is an event (0:00–12:00)

- **You already know:** Webhooks and CI jobs that run when code is pushed.
- **You can also:** Treat a meeting recording, an email, a support message, or a social post as the event that starts the work.
- **Show:** A workshop Zoom recording becomes 40 clips by subject, a privacy check, 127 reference links, and a hosted site — the whole chain started from one recording.
- **Evergreen:** Anything with a source and a timestamp can be an event.
- **Workshop lessons:** Think beyond text: images, video, and voice

#### 2. Sorting: a classifier, not a chat (12:00–24:00)

- **You already know:** Email filters with exact rules, or pasting messages into a chat and asking “what kind is this?”
- **You can also:** Use a fast classification model to put each item in a known bucket with a score — cheap enough to run on everything — and keep “unknown” as a real answer.
- **Show:** Incoming messages sorted into support, sales, bug, and ignore, then routed. Show a message that says “ignore your rules” staying data, not an instruction.
- **Evergreen:** Plain code for exact rules, a classifier for fuzzy choices from a fixed list, a reasoning model for new problems.
- **Worth saying:** This pays off the day-one preview: classifiers make always-on triggers affordable.
- **Workshop lessons:** Sort data without a chat loop

#### 3. Pipelines: small stages, one decision each (24:00–36:00)

- **You already know:** Drag-and-drop flow builders that chain apps together.
- **You can also:** Build a pipeline — notice, sort, route, do, check, report — where each stage owns one decision and an agent appears only where judgment is needed.
- **Show:** A marketing pipeline: check the offer’s link, price, and dates → write the copy → schedule posts → upload the video. The checker is read-only; publishing needs explicit approval.
- **Evergreen:** Verify facts before creative work, and keep the whole pipeline simple enough to explain.
- **Workshop lessons:** Help the whole team make safe small changes

#### 4. Research and product work (36:00–48:00)

- **You already know:** Reading reviews and running user interviews by hand.
- **You can also:** Have agents watch real people use real products in public videos, pull out observations with timestamps you can check, and hand hard questions to a deep-research helper.
- **Show:** Public videos of people using a product → timestamped observations → a short synthesis that doesn’t overclaim. Then one hard question sent to deep research with the sources and files kept.
- **Evergreen:** Keep the source and timestamp; check the AI’s notes yourself; protect the people in the footage.
- **Workshop lessons:** Watch real people use real products; Give hard questions to a deep-research helper

#### 5. Dogfooding loop and boundaries (48:00–60:00)

- **You already know:** A QA pass before launch.
- **You can also:** Run a loop where an agent uses the result like a customer: pick one journey, observe, propose one improvement, use it again, a person decides, save a receipt.
- **Show:** Run the loop on the pipeline’s own output — the clip site or a campaign page. Then the boundaries: no duplicate runs, budgets, and a person before anything is published.
- **Evergreen:** Work isn’t done until someone used the result.
- **Workshop lessons:** Use the product, not just the generated code

### Open items

- [new] Classifier demo on a realistic inbox or support queue.
- Decide whether Zoom-to-clips is the main demo.

## S04E05 · Building Self-Improving Engineering Systems

Pure inspiration: a personal system that learns from corrections, proves its own improvements, researches overnight, extends its own harness, and builds features when you ask.

Brief: https://mega-dot-dev.github.io/mega-content/videos/s04e05/main/ · MEGA lesson: https://mega-dot-dev.github.io/mega-content/lessons/s04e05/

### The brief (from MEGA)

The final MEGA.dev video is **purely inspirational**, with a little wink toward what comes next. We can really go off the rails here and leave students mind-blown.

Within the lesson, I will cover something that loosely references auto-research, but translated into a personal, self-evolving system. Maybe things like a mobile app that can build features on the fly using WASM modules, or something along those lines.

I am leaving this note deliberately open-ended because I know what you can do, and that is basically what we need here. Don’t hold yourself back.

### MEGA lesson outline

- Feedback: traces, failures, corrections, evaluations, review findings, human decisions
- Evaluation: proof ladders, baselines, validators, regression checks, versioned results
- Distillation: turning successful runs into skills, rules, workflows, context, reusable agents
- Optimization: refining profiles, routing, tools, environments, model selection based on observed outcomes
- Governance: proposing, testing, approving, versioning, rolling back system changes

### Proposal · five 12-minute sections

#### 1. Feedback: corrections become skills (0:00–12:00)

- **You already know:** Retrospectives and postmortems that end in a document nobody reads.
- **You can also:** Let the system turn your corrections into saved lessons and skills that show up in the next session — reviewed, not silently accepted.
- **Show:** Correct the agent mid-session. Start a fresh session and watch the lesson apply without being told again.
- **Evergreen:** Every correction is evidence about the goal.

#### 2. Evaluation: prove it before promoting it (12:00–24:00)

- **You already know:** CI tests that gate a merge.
- **You can also:** Gate changes to the system itself: a separate evaluator decides whether a goal is met, and a change counts only if it measurably improved the result.
- **Show:** A goal judged by an independent evaluator, with a before-and-after on the same tasks. Unlike day two’s one-time benchmark, this runs every time the system changes itself.
- **Evergreen:** The agent that does the work isn’t the one that judges it.
- **Workshop lessons:** Use review tools as a pause for judgment

#### 3. Auto-research: the system experiments overnight (24:00–36:00)

- **You already know:** You research, then you build.
- **You can also:** Let the system run its own experiments: form a hypothesis, try variations, measure, keep the winner, and record why.
- **Show:** Hundred Worlds — 100 reference images turned into 100 sites — as exploration at scale. Then image batches compared, one winner kept, and a decision note left behind.
- **Evergreen:** Explore widely, keep decisions, throw away variations.
- **Workshop lessons:** Generate and compare image batches; Keep decisions, throw away variations

#### 4. The harness improves itself (36:00–48:00)

- **You already know:** Filing a feature request and waiting for a release.
- **You can also:** When the agent hits a limit, it opens the harness’s own code, writes a harness extension, tests it, and proposes it as a change you can undo.
- **Show:** A growing folder of real harness extensions as the evidence trail, and one built live from a limit hit on camera — reviewed with the day-two why-record.
- **Evergreen:** Start small, add one change, keep it only if it helps.
- **Workshop lessons:** Make a harness feel like your own

#### 5. Finale: software that builds itself on request (48:00–60:00)

- **You already know:** Waiting for an app update to get a feature.
- **You can also:** Ask for a feature on your phone and have your own machine build it and load it into the app on the fly — the brief suggests WASM modules.
- **Show:** An app hosted on your own machine over Tailscale. Dictate a feature from the phone; it appears. Close on the day-one loop — trigger, decide, act, check, record, report — now running on itself.
- **Evergreen:** Intent in, a working result out, checked where it’s used.
- **Worth saying:** The names of tools will change; the loop and the guardrails won’t.
- **Workshop lessons:** Control a local session from your phone

### Open items

- [new] The feature-on-request phone app (build it, or show it as a concept).

## How the five days connect

- **S04E01:** The day-one loop — trigger, decide, act, check, record, report — runs through every day and closes the week in E05.
- **S04E02:** Day-two role files become the day-three team members.
- **S04E01:** The classifier previewed on day one pays off on day four as the sorting step.
- **S04E02:** Day-two why-records guide the day-five review of extensions the harness writes itself.
- **S04E02:** Day two benchmarks a role once; day five re-checks every change the system makes to itself.
- **S04E01:** The phone appears three ways: decisions on day one, supervision on day three, building features on day five.

## New work to build or record

- **S04E01:** Event-triggered review on agent stop and prompt submit; dev-server error trigger
- **S04E03:** Scheduled monitor agent that reviews the fleet
- **S04E04:** Classifier demo on a realistic inbox or support queue
- **S04E05:** Feature-on-request phone app

## One home per idea

| Material | Home |
|---|---|
| Agreeing on the goal; side lanes during a session | S04E01 |
| Advisors and triggers beyond pull requests | S04E01 |
| Agent-readable team workbooks | S04E01 |
| Decisions sent to people (phone, Slack, issue tracker) | S04E01 |
| Minimal reproduction → fix → regression test | S04E01 |
| Role files and configured harnesses | S04E02 |
| User- and team-level agent definitions | S04E02 |
| Scripted startup context | S04E02 |
| Why-records for instructions | S04E02 |
| Benchmarking a cheaper role | S04E02 |
| Environment: main machine + delegated machines | S04E03 |
| Supervising across machines, from your phone | S04E03 |
| Meeting recording as an event (Zoom → clips) | S04E04 |
| Classification model (sorting step) | S04E04 |
| Dogfooding loop | S04E04 |
| Corrections → skills; independent evaluator | S04E05 |
| Harness extensions the agent writes itself | S04E05 |
| Phone “build a feature” app | S04E05 |

## Open questions for the team

- **S04E04:** Is the Zoom-to-clips project the main demo?
- **S04E03:** Show the wrong-model swarm incident on camera?
- **S04E05:** Build the feature-on-request phone app, or show it as a concept?

## About this site

- [About](https://mega-week4-proposal.johnlindquist.workers.dev/about.html) · [Contact](https://mega-week4-proposal.johnlindquist.workers.dev/contact.html) · [Privacy](https://mega-week4-proposal.johnlindquist.workers.dev/privacy.html)