Fractal Accelerator - Class 4 notes

Summary

Class 4 covered two separate topics:

1. Debugging failures by inspecting the actual interaction, locating the failure in the surrounding system, fixing the source, and running the task again.
2. Turning firsthand problems into small products by identifying a useful outcome, making the smallest version that could deliver it, and asking a real person to pay.

1. Debugging an agent is a diagnostic process

When an agent does something wrong, “try harder” is not a diagnosis. Start with one specific failure and inspect what actually happened:

• What was the exact request or instruction?
• What did the agent actually do?
• What did you expect instead?
• What did the agent say it was trying to do?
• What information could it see, and what information was missing?

Agents combine fuzzy, non-deterministic reasoning with hard constraints imposed by the surrounding computer and platform. A useful debugging process separates those layers instead of treating every failure as a prompting problem.

2. Five places a failure can live

The debugging worksheet organizes possible causes into five categories:

1. Instructions — The prompt, automation, or standing instructions may be vague, stale, pointed at the wrong files, or missing a definition of done.
2. Skills — The agent may not have the relevant capability, may not be able to see the skill, or may be operating in a context where the skill is unavailable.
3. Files and data — The needed information may be missing, duplicated, stale, in the wrong location, or not actually synchronized.
4. Actions and connections — The agent may not be logged in, may lack permission, or may be unable to perform the requested action in the target account or file.
5. The platform — The product itself may be failing. Opaque internal errors, broken integrations, or a task that works on retry can indicate a platform problem rather than a setup problem.

The right fix depends on the category. Change the instruction when the instruction is wrong; repair the file or source of truth when the data is wrong; change permissions or connections when the action is unavailable; and report or work around a platform failure instead of endlessly rewriting the prompt.

3. The agent debugging process

The Agent Debugging Process exercise uses groups of three or four. Each person brings one real failure from the week—or the workflow they trust least if nothing obviously broke.

Examine the interaction

Open the actual conversation, automation, or output. The group should work from the request and response on screen rather than from memory or a general impression that the agent “usually gets this wrong.”

Analyze the agent’s reasoning

Ask the agent to explain what it was trying to do, what information it could access, and why it took the path it took. The explanation may be incomplete or wrong, but it can reveal which assumptions need to be checked.

Name the most likely cause

The group writes one sentence:

It most likely failed because ____.

The person whose agent failed has to agree that this is the most likely cause before the group moves on. There can be more than one cause, but the group needs a concrete hypothesis it can test.

Fix the source and rerun the task

The fix should change what the next run will actually read or use. That might mean rewriting an instruction, moving or repairing a file, correcting synchronization, reconnecting an account, changing permissions, or reporting a platform bug. A correction typed into one conversation is not a durable fix unless the next run can see it.

The finish line is evidence: run the original request again, or a small version of it, and record what changed and how the result was verified.

4. What the debugging examples showed

The class examples illustrated several recurring patterns:

• A plausible explanation from an agent can be wrong. A broken link problem that looked like a character-encoding issue turned out to be caused by a VPN blocking the site.
• Safety rules are more reliable when they are enforced by the surrounding system. A restricted account or permission boundary can prevent an unwanted deployment more reliably than repeating “do not deploy” in instructions.
• A workflow can fail because the agent is using the wrong source of truth, an old model, or an outdated instruction—even when the current conversation sounds clear.
• Agents need access to the results of their work. If an agent cannot inspect the output, test the behavior, or receive a meaningful critique, it cannot reliably improve it.

5. Start a startup today

The second exercise turned the cohort’s recent experience with agents into possible products. The Start a Startup Today exercise links to the supporting prompts used for the work.

The worksheet’s shared group tabs show that the in-class work concentrated on ideation and offer structure. The later build, public-post, and homework sections describe the follow-up assignment rather than completed in-class deliverables.

Generate ideas from firsthand experience

Each person asks the agent that knows them for first-dollar ideas, using its knowledge of their work, problems, experiments, and interests. The group then adds two kinds of evidence:

• Frustrations: What keeps breaking? Where does the agent misunderstand you? What feels too technical or untrustworthy?
• Wonders: What is unusually useful? What do you love? Which prompt or conversation produced a result you want more people to experience?

The point is not to invent a generic startup. It is to notice a problem or useful outcome the person has experienced directly and may be able to solve for someone similar.

Structure the offer around an outcome

Groups interview one person at a time and reduce the idea to a result someone might pay for. The key questions are:

• What is the simplest version someone might pay $1 for?
• What wonderful result does the customer get?
• Why should they believe it will work?
• How quickly can they receive the value?
• Who else might want the same outcome?

The worksheet’s offer structure is:

I am making [a simple product] for [a kind of person] who [has a painful or valuable moment]. It gives them [the result they want] for [the price].

The important distinction is between selling a product and selling a result. People may not want a game, prompt, report, or app in the abstract. They may want the concrete change that one of those things creates in their lives.

Build, post, and learn from a real response

After the offer is clear, the next steps are to:

• use the build prompt to make a barely-good-enough version;
• build only what is needed to deliver the first result, whether that means a product page, onboarding, payment, a direct message, or a payment link;
• make a public post and invite people to buy or respond;
• use Make a Plan to turn the idea into a week of work.

The exercise treats public sharing as part of the learning process. A post, reply, preorder, payment, or clear rejection gives more information than another private round of polishing.

6. Long-running work needs a target and feedback

The class also examined long-running “gauntlet” prompts: instructions that ask an agent to keep working on a project through many cycles. The useful general principle is not “run agents for as long as possible.” It is:

• give the agent a clear target;
• give it a signal that shows whether it is getting closer;
• let it inspect the work or run a test;
• provide criticism or comparison when the result is not good enough;
• stop when the target is met or when the next failure teaches you something important.

Without a target and feedback signal, an agent cannot tell whether it is finished. It will either stop too early or keep producing work without meaningful improvement.

There are two legitimate ways to work with a powerful agent. You can teach it your process through context, skills, and repeated feedback, or you can treat it more like an independent worker: give it an outcome, inspect what it produces, remove blockers, and allow it to choose its own method. The right choice depends on whether the process itself matters as much as the result.

7. Homework

The assigned challenge was to earn at least one dollar online by the next class. The follow-up work is:

1. Finish a barely-good-enough product or offer.
2. Post it publicly with a way for someone to buy it.
3. Collect at least $1 from a real customer by Saturday, August 8, 2026.
4. Bring the result to the next class for a demo.

The reference library and its guide-specific prompts were also offered as resources for learning a skill in the context of a student’s own project. Office hours were available for debugging the work and moving past blockers.

Compact glossary