Fractal Accelerator - Class 1 notes

Summary

Class 1 introduced a practical way to work with AI agents and a simple map of the computing world.

The central habit is:

Ask the agent for what you need.

If you are confused, ask for a clearer explanation. If you are overwhelmed, ask for a plan. If you are stuck, describe the blocker and ask for the next step. If you do not know whether something is possible, ask the agent to investigate. The agent is not only a tool for producing finished work; it can also be a tutor, researcher, planner, technical collaborator, and guide through unfamiliar software.

The central technical model is:

• Your laptop is a local computer.
• A cloud computer is another real computer reached through the internet.
• An agent always runs somewhere—locally, in the cloud, or across services.
• The agent can only act through the tools, data, permissions, and context available in that environment.
• Local software is usually simpler and more private. Cloud software is useful when work must remain available, connect to online services, run while your laptop is asleep, or serve other people.
• Zo is your personal cloud computer: an always-available place where an agent can run programs, connect to services, store appropriate data, host resources, and communicate with you through internet-connected channels.

The class also introduced a repeatable development loop:

1. Clarify the goal and the real blocker.
2. Teach the agent the relevant context.
3. Design a solution and decide whether it should be local or cloud-based.
4. Build and test the smallest useful version, giving feedback as you go.

Class 1 ended after the build sprint, homework handoff, and Q&A.

1. A useful mental model for agents

An agent is like a highly capable alien living inside a computer. It can communicate in human language and may be able to do many things on a computer, but it does not think exactly like a person. If you assume it shares your unstated knowledge, preferences, or judgment, its behavior can be surprising, confusing, or frustrating.

At a high level, an agent combines:

• A language model that can interpret and produce language.
• Instructions describing its role and the work to perform.
• An environment in which it operates.
• Tools for reading files, searching, running commands, browsing, using connected services, or manipulating applications.
• Some degree of autonomy to take multiple steps toward a goal.

A chat assistant that can only produce text is limited to advising you. An agent with tools can inspect relevant evidence and act. This is why giving an agent the right tool was compared to giving the enchanted broom in The Sorcerer’s Apprentice a pair of hands: capability depends not only on intelligence, but also on what the agent can access and operate.

The five capabilities the course is designed to develop

The introductory lecture framed the accelerator around five forms of practice:

1. Build the habit of asking agents for help. Most people have spent their lives using computers without an agent, so reaching for one is not yet automatic. The habit develops through frequent, real attempts.
2. Give agents the tools they need. An agent cannot search an inbox, inspect a folder, update a document, or deploy an application unless it has an appropriate tool and permission.
3. Teach agents about you and your work. General intelligence is not personal context. Agents become more useful when they can learn your goals, preferences, projects, constraints, and repeated workflows.
4. Avoid harmful or unexpected outcomes. More agency creates more responsibility. Use scoped permissions, inspect consequential actions, protect private information, and understand how to stop or reverse what is running.
5. Learn the language of computers. Terms such as API, CLI, MCP, Git, server, database, URL, and hosting make it easier to ask precisely for powerful things. You do not need to master them all at once; when jargon is unclear, ask what it means.

Prompts can operate at different levels

You can ask an agent for a narrow action—“draft this reply” or “find this file”—or for a high-level outcome—“look across my work and identify good opportunities for automation.” At the higher level, the agent may need to investigate, infer patterns, and propose next steps.

A useful prompt usually establishes:

• What outcome you want.
• What evidence or sources the agent may use.
• What tools it is allowed to use.
• What constraints or safety boundaries apply.
• What the output should contain.
• What actions it must not take without approval.

You do not need to write a perfect prompt before beginning. Start with what you want, inspect what comes back, and give concrete feedback. Treat prompting as a conversation and design process, not a one-shot incantation.

2. The first context exercises

Students connected an email tool where appropriate and ran two read-only investigations in separate desktop-agent tasks:

• Ask the computer what it can infer about your work from selected files.
• Ask the inbox what recurring work, coordination loops, and automation opportunities it reveals.

The purpose was not to automate the inbox immediately. It was to experience an agent using tools and evidence to develop a picture of your work, sometimes surfacing patterns that are hard to see from inside your own routine.

The class debrief highlighted several principles:

• Give the agent access only to sources you are comfortable sharing.
• A connected tool supplies capabilities; the prompt still defines the task and boundaries.
• Read the result critically. Notice what is accurate, what is surprising, and what is wrong.
• Ask how the agent reached its conclusions and what evidence it used.
• Turn useful observations into follow-up work; do not treat the first report as unquestionable truth.
• If a broad filesystem scan feels uncomfortable, point the agent at one deliberately chosen folder instead.

The full versions of these exercises are in the Class 1 prompt library.

3. The map of the computing world

The lecture’s core simplification was:

“The cloud” means computers somewhere else, connected through the internet.

The cloud is not an abstract substance. Data centers contain physical computers, and programs run on those machines just as programs run on your laptop. “Cloud” describes where those machines are and how they are reached and operated.

Start with four places

Picture a map containing:

1. Your laptop and phone.
2. Other people’s devices.
3. The internet connecting devices.
4. Cloud computers operated by you or by companies.

Your laptop and phone are personal devices. A company such as Facebook operates cloud computers that store data and run services. Your Zo computer is different from a typical company service because it is intended to function as your own general-purpose computer in the cloud.

Keep code, processes, and data separate

When asking “Where does this live?”, distinguish three things:

• Code or app: the instructions that define the software.
• Process or agent: those instructions actively running on a particular computer.
• Data: information stored or moving between computers.

For example, when you use Facebook on a phone:

• A client app runs locally on the phone.
• Facebook’s server-side processes run on cloud computers.
• Your phone and the servers exchange data over the internet.
• Much of the authoritative data is stored on Facebook’s systems.
• If you download a photo or archive, an additional copy now exists on your device.

This same map applies to websites, Google Docs, games, coding agents, automations, and most networked applications. Asking where each component runs is often enough to make a mysterious system understandable.

Why use the cloud?

A cloud computer is useful when a process needs one or more of these properties:

1. Availability: it should remain reachable while your laptop is asleep, closed, disconnected, or elsewhere.
2. Persistence: it should store data or keep a service running over time.
3. Internet access: other people, devices, or services need to reach it.

Examples include:

• A website that other people can visit.
• A multiplayer application whose participants need a shared meeting point.
• A scheduled process that runs every morning.
• A service that receives messages while you are asleep.
• A shared database or application backend.
• A personal agent you want to reach from your phone.

A laptop can technically perform many server tasks, but it is often an unreliable always-on home: it sleeps, moves, disconnects, and may not be safely exposed to the public internet.

When is local software better?

Cloud is not automatically better. The lecture used the locally running class slideshow as an example: it only needed to work on the instructor’s laptop in the room, so sending it to a remote server would add distance, configuration, and failure points without adding value.

Local software is often:

• Simpler to build and debug.
• Faster to access from the same machine.
• Less expensive to operate.
• Easier to keep private.
• Usable without an internet connection.

Use the simplest architecture that reliably meets the goal. Reach for the cloud because the problem requires its properties, not because “cloud” sounds more advanced.

4. Servers, hosting, databases, and addresses

These words describe related but different parts of the map.

Server

A server is a computer—or, more precisely in some contexts, a program—that receives requests and provides something in response. In the class’s simplified map, “server” generally meant an internet-connected computer designed to keep services available.

Hosting

Hosting means keeping a website, application, service, or data available on an internet-connected computer so other computers can access it. If you ask Zo to host a small website, Zo puts the required code and process on your cloud computer and makes the result reachable.

Database

A database is specialized software for storing and retrieving data. It runs on a computer; it is not itself the same thing as the computer. Different databases are optimized for different types of information and patterns of reading and writing.

Domain, URL, and HTTPS

• A domain is a human-readable internet name, such as example.com.
• A URL is the complete address of a resource, such as https://example.com/game.
• HTTPS is the secure web protocol used to encrypt traffic between the visitor and the host.

Short version: the host is the computer or service making something available; the domain helps people find it; the URL identifies the particular resource.

Historically, hosting even a small application required engineers to coordinate operating systems, terminals, SSH, IP addresses, DNS, web servers, ports, deployments, logs, and monitoring. Those technologies still exist. The change is that an agent can now handle much of that configuration on your behalf. You still need enough understanding to know what is running, who can access it, what it costs, and how to stop it.

5. Zo as a personal cloud computer

Zo combines a cloud computer with an agent that can help operate it conversationally. The lecture emphasized several practical affordances:

• It can run code and long-lived processes in the cloud.
• It can host websites and services.
• It can store appropriate files and project context.
• It can connect to supported online services through authenticated integrations.
• It can be reached through supported channels such as web chat, text, email, Telegram, or Discord.
• It can perform scheduled work while your laptop is unavailable.

Connected services are examples of agent tools. An authenticated connection may securely transmit credentials, but it also grants the agent real access to the selected account and data. “The connection is secure” does not mean “all data is automatically appropriate to share.” Avoid connecting sensitive customer, employer, financial, health, or private personal information unless you understand the policy and risk.

6. Permissions, autonomy, and safety

An agent’s environment includes everything it can theoretically reach through its tools. Permissions determine which parts of that environment it may actually use and which actions require confirmation.

During the supervised exercise, students used a setting that allowed safe background work while asking for approval when necessary. That was a choice for a bounded classroom task, not a universal rule. Use narrower access when the data or action is sensitive.

Good operating habits include:

• Begin with read-only investigation when modification is unnecessary.
• Give access to a selected folder instead of an entire filesystem when possible.
• Never paste passwords, private keys, or secrets into prompts or public applications.
• Require confirmation before sending messages, spending money, deleting data, publishing private information, or making other consequential changes.
• Ask the agent what it changed and how to reverse it.
• For a hosted process, know where it runs and how to inspect, stop, or remove it.
• Treat public URLs as genuinely public unless access controls have been verified.
• Keep backups or version history for important work.

There is no perfectly risk-free computer system. The practical goal is to match access and oversight to the stakes of the task.

7. The Personal OS: durable context for future agents

A chat contains temporary working context. A new chat or a different agent may not automatically know what happened in the old one. If important context exists only inside one thread, future work can start from zero.

The class introduced a Personal OS: one organized folder containing the projects, files, goals, preferences, and maps that help an agent collaborate with you. It is not a special application. It is a filesystem pattern—a dependable place for durable context.

Useful contents might include:

• Project folders containing requirements, decisions, source material, and outputs.
• Notes about preferences, people, recurring processes, and open questions.
• Raw brainstorming transcripts when they are worth preserving.

Do not create a giant hierarchy merely for appearance. Begin with one useful folder and a few files containing real information. Let the structure grow in response to actual work.

Nested context

You may have one broad personal folder, a work-specific area inside it, and individual project folders inside that. When working on a particular project, open your coding agent in that project’s folder rather than in the top-level Personal OS folder. This gives the agent the project’s files and instructions as its immediate working context, instead of making it begin from the entire top-level collection. Keep confidential or unrelated material outside the project context, and use actual access controls when the agent must not be able to reach it.

Syncing local and cloud context

Students were shown how to sync the Personal OS folder from their local computer to Zo. The goal is for both local and cloud agents to work from the same durable context. When you add or update a file locally, Zo can see the synchronized version; when you message Zo from your phone, it can locate the relevant project information.

Before relying on sync:

• Confirm that the intended folder—not a broader sensitive folder—is selected.
• Ask the agent to show the exact local and cloud paths.
• Make a harmless test change and verify that it appears on both sides.
• Keep secrets and inappropriate work data outside the synchronized context.

The deeper principle is broader than any sync product: important context should be stored in durable, inspectable files rather than trapped in one conversation.

8. The agent design process used in class

The second half of class used the Agent Design Game to turn a real-life goal into a proposed and partially built solution. The published activity was originally designed for groups, but the class skipped the group interviews to save time. Students instead spoke their own goals and problems into the desktop app, then worked individually with the transcript.

Step 1: Clarify the goal

Students recorded a short spoken “goal dump”: current goals, problems, repeated frustrations, delayed work, and ideas they were excited about. Speaking was encouraged because it can surface detail faster and more naturally than composing a formal prompt.

The goal is not simply to name a task. It is to identify:

• What outcome matters.
• Why it matters.
• What is actually blocking it.
• Whether the apparent problem is a symptom of another problem.
• What success would look like in observable terms.
• What a computer could plausibly help with.

Speaking out loud can be useful because you do not need to organize your thoughts before beginning. You can ramble, notice ideas as they emerge, and give the agent context that might not surface when you try to compose a polished written prompt. For some people, speaking activates a different mode of thinking and can help them get unstuck.

Imperfect transcription is often usable. A language model can usually recover meaning from minor errors if the topic and intention remain clear.

Step 2: Teach the agent what matters

Students asked the agent what it understood from the transcript:

Based on this transcript, what do you understand my goals and priorities to be? What would solve my problems?

The next step was a gut check: does the response feel like the agent actually understood the problem? Does the proposed outcome create a “hell yes—that would genuinely help” reaction?

If not, ask the agent to interview you one question at a time. Correct its assumptions. Distinguish symptoms from the underlying blocker. Do not start building until you and the agent agree on the problem and desired outcome.

Once the context is good, save it—usually in a text file in your Personal OS—so a future agent can understand the goal, constraints, agreed direction, success criteria, and remaining uncertainty.

Step 3: Decide where the solution should live

Ask whether the proposed solution should run locally or in the cloud. Evaluate:

• Must it work while your computer is off?
• Do other people need access?
• Must it receive messages or run on a schedule?
• Which online services must it connect to?
• What data does it use, and how sensitive is that data?
• What will it cost?
• How much setup and maintenance will it require?

Default toward the simplest design that reliably solves the problem. If both local and cloud approaches work, local is often the easier first version. Choose cloud when the desired behavior actually needs availability, persistence, shared access, or online integrations.

Step 4: Request and evaluate a proposal

Before building, ask the agent to explain:

• What it proposes to build.
• Which tools and services it will use.
• What information or permissions it needs.
• What happens when you use the finished system.
• What could go wrong.
• What the smallest useful first version contains.
• What can realistically be built in the current session.

You are the “CEO” of the project: you set the intention, evaluate the proposal, and give feedback even when you are not the technical expert. You do not need to accept the agent’s first design.

Pay attention to “hell no” reactions:

• Is the proposal too complicated?
• Does it use tools you dislike?
• Is the cost or maintenance unreasonable?
• Does it require data access you do not want to grant?
• Is it solving the wrong problem?
• Are important parts incomprehensible?

Tell the agent exactly what feels wrong and ask it to revise. Your reaction is useful design information. Continue until the scope feels understandable, manageable, and genuinely valuable.

Step 5: Build, test, and keep going

Once the proposal is approved, build the smallest version that proves the idea can work. The in-class sprint emphasized two habits:

1. Stay with the problem instead of abandoning it at the first confusing step.
2. When blocked, tell the agent what is happening and how you feel.

A good build instruction asks the agent to:

• Start with the smallest demonstrable version.
• Test its work.
• Show concrete evidence of what works.
• Ask for a decision or permission when required.
• Try safe alternatives when an approach fails.
• Track unfinished work.
• Avoid silently expanding the scope.

Being blocked is not proof that the project has failed. Ask for a plain-language explanation, the smallest input the agent needs from you, and the single best next action. If the approach fails, preserve the goal and change the approach.

Testing should return to the original problem. Verify the important flow from beginning to end and capture evidence—a screenshot, URL, log, output, or observed behavior. Record what remains incomplete and choose the next most valuable improvement.

9. Moving context between agents and conversations

The closing Q&A returned to a recurring problem: useful work may be “stuck” in a Codex chat, a Zo conversation, or another tool.

Remember that context is information, usually text and files. You can move it:

1. Ask the new agent to read the prior conversation if it has that capability.
2. Copy and paste the relevant material.
3. Ask the old agent to summarize the important context into a durable file.
4. Place that file in the shared project or Personal OS folder.
5. Ask the new agent to read it before continuing.

This is why project briefs, development logs, and decision notes matter. They decouple the project’s memory from one vendor, model, computer, or chat thread.

10. Homework and post-class direction

The homework is to apply the design loop repeatedly to a real goal in your life or work.

What to produce

By the next class, you should have:

• Something that helps you: a built and tested solution, even if it remains an early version.
• A development log: what you attempted, what changed, what broke, what you decided, and the major feedback loops.
• A work report: what you built, evidence that it works, its current state, wins, problems, frustrations, learning, next steps, and reflections on the process.
• A three-minute demo: a concise presentation dominated by evidence and the actual thing you made.

The important metric is not perfection. It is the number and quality of complete reps: clarify, propose, build, observe, give feedback, and improve.

How to work during the week

• Choose a meaningful but tractable outcome.
• Start early enough to encounter and resolve real blockers.
• Keep the agent informed about work done in other tools.
• Maintain the development log throughout the week rather than reconstructing it at the end.
• Test the important user flow and preserve literal evidence.
• Ask instructors in Discord when you need help; questions that unblock you may help the rest of the cohort too.
• Use whichever combination of local and cloud agents best fits the work. The project context should remain accessible to whichever agent continues it.

The complete project-management instructions are available in the Homework Setup prompt. Follow the current instructor deadlines if they differ from dates embedded in the captured Class 1 prompt.

Catch-up completion checklist

You are caught up on the essential Class 1 state when you can check these off:

• I have a working local desktop coding agent.
• I can ask the agent for an explanation, a plan, or help with a blocker.
• I understand what tools and data my agent can currently access.
• I have an active Zo computer connected to an appropriate subscription-backed provider.
• I have successfully sent Zo a test message.
• I can explain the difference between local software and cloud software.
• I can identify where an app, running process, agent, and data live.
• I understand why a task might need an always-on server.
• I understand what hosting means and that a public URL may actually be public.
• I have one Personal OS or project folder for durable agent context.
• I have verified the intended folder can be accessed by the agents that need it.
• I have saved my current goal and its constraints in a durable project file.
• I have used the design process to choose a local or cloud approach.
• I have requested, evaluated, and approved a small build proposal.
• I have begun building and testing the solution.
• I have started the homework setup and development log well before the next class.

Compact glossary