Week 4 Takeoff proposal · MEGA Developer

Video brief · S04E01/Week 4 · Takeoff

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.

The brief

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:

This session has to be inspirational, so we may present as many use cases as possible, mentioning the tools and platforms people can use.
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.

Proposal · five 12-minute sections

01
0:00–12:00

Autonomy: agree first, then keep the session on track

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.
- Get aligned before asking for execution
- Ask side questions without derailing the task
02
12:00–24:00

Triggers: code review is just the first event

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.
- Know when an AI advisor helps
- Make a focused advisor from an example
03
24:00–36:00

Memory: agent-readable workbooks

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.
- Save learning in an agent-readable workbook
04
36:00–48:00

Control: send decisions to the right person

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.
- Help the whole team make safe small changes
- Phone notification → decision → continuation
05
48:00–60:00

Recovery: the minimal reproduction

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.
- 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.

Video brief · S04E02/Week 4 · Takeoff

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.

The brief

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:

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.

Proposal · five 12-minute sections

01
0:00–12:00

Configuration: from scripts to configured harnesses

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.
- Think in responsibilities and shared memory
- Make a harness feel like your own
02
12:00–24:00

Portability: roles above the project

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.
- Use the harness's natural delegation pattern
03
24:00–36:00

Knowledge at startup: script it before the first turn

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.
- Feed agents fresh context and system signals
04
36:00–48:00

Versioning the whys

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.
- Keep decisions, throw away variations
05
48:00–60:00

Proof: the cheaper role holds up

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.
- 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.

Video brief · S04E03/Week 4 · Takeoff

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.

The brief

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:

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.

Proposal · five 12-minute sections

01
0:00–12:00

Delegation: one manager, helpers with one job each

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.
- Use the harness's natural delegation pattern
- Think in responsibilities and shared memory
02
12:00–24:00

Coordination: short-lived agents, lasting record

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.
- Look inside delegated work
- Give each task a clear workspace and pane
03
24:00–36:00

Parallelism: collisions and ownership

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.
- Give each task a clear workspace and pane
- Pick a model for each kind of work
04
36:00–48:00

Environment: a main machine and machines with room

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.
- Spread heavy work across machines
05
48:00–60:00

Supervision: find, explain, and stop any agent

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.
- 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.

Video brief · S04E04/Week 4 · Takeoff

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.

The brief

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.

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

Proposal · five 12-minute sections

01
0:00–12:00

Events beyond code: a meeting is an event

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.
- Think beyond text: images, video, and voice
02
12:00–24:00

Sorting: a classifier, not a chat

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.
- Sort data without a chat loop
03
24:00–36:00

Pipelines: small stages, one decision each

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.
- Help the whole team make safe small changes
04
36:00–48:00

Research and product work

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.
- Watch real people use real products
- Give hard questions to a deep-research helper
05
48:00–60:00

Dogfooding loop and boundaries

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.
- 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.

Video brief · S04E05/Week 4 · Takeoff

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.

The brief

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.

Proposal · five 12-minute sections

01
0:00–12:00

Feedback: corrections become skills

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.
02
12:00–24:00

Evaluation: prove it before promoting it

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.
- Use review tools as a pause for judgment
03
24:00–36:00

Auto-research: the system experiments overnight

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.
- Generate and compare image batches
- Keep decisions, throw away variations
04
36:00–48:00

The harness improves itself

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.
- Make a harness feel like your own
05
48:00–60:00

Finale: software that builds itself on request

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.
- Control a local session from your phone

Open items

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

Across the week

How the five days connect

One loop runs through every day: trigger → decide → act → check → record → report. The tools will change; the loop and the guardrails won’t.

Threads between days

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

Keeping the videos separate

One home per idea

Some material could appear in several videos. Each piece gets one home so the episodes don’t repeat each other.

Material → home

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

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?

John’s Week 4, laid out end to end

Mechanics Behind Autonomous Systems

Autonomy: agree first, then keep the session on track

Triggers: code review is just the first event

Memory: agent-readable workbooks

Control: send decisions to the right person

Recovery: the minimal reproduction

Building Portable Agent Control Planes

Configuration: from scripts to configured harnesses

Portability: roles above the project

Knowledge at startup: script it before the first turn

Versioning the whys

Proof: the cheaper role holds up

Orchestrating Autonomous Agent Teams

Delegation: one manager, helpers with one job each

Coordination: short-lived agents, lasting record

Parallelism: collisions and ownership

Environment: a main machine and machines with room

Supervision: find, explain, and stop any agent

Automating Work Beyond Code

Events beyond code: a meeting is an event

Sorting: a classifier, not a chat

Pipelines: small stages, one decision each

Research and product work

Dogfooding loop and boundaries

Building Self-Improving Engineering Systems

Feedback: corrections become skills

Evaluation: prove it before promoting it

Auto-research: the system experiments overnight

The harness improves itself

Finale: software that builds itself on request

How the five days connect

One home per idea