Accumulated
Curiosity

A practical blueprint for learning, building, and creating independent value with AI.

For an overview of the thesis, system architecture, and all 24 chapter artifacts, begin with the executive summary.

Begin with a piece of work

Think of something you would like to be able to do that you cannot yet do reliably. It might be designing a useful workshop, investigating a question for a client, publishing a careful research brief, or creating a small tool that removes a recurring frustration. Choose something whose usefulness another person could recognize. Keep it small enough that you can examine the result yourself.

That piece of work is your starting point. You will return to it throughout this book. You will learn what the problem actually requires, what you can already contribute, what an AI system can help with, and what evidence would justify trusting the result. You will build a record of decisions, a repeatable way of working, and eventually a system that can carry more of the execution while you retain direction.

The title describes an ambition and a practice. Curiosity supplies questions. Accumulation happens when the work of answering those questions leaves something you can use again: an explanation you understand, a tested procedure, a source you can trace, a mistake you can avoid, or a relationship between ideas that makes a new problem easier to see. A large collection of saved conversations can contain very little of this. A short, well-used record of a single project can contain a great deal.

There is an economic question behind the practice. Could one person build a company worth a million dollars, or a company with a million dollars in annual revenue? Those are different questions. Neither can be answered by counting how many tools a person uses. A business needs a problem worth solving, customers who value the result, a way to reach them, a delivery process that works, and economics that leave enough room for the owner to continue. AI changes parts of the work. It does not remove the need to establish those things.

The book will return to the million-dollar question with concrete arithmetic and operating constraints. You do not need to adopt that number as your own goal. You might want a resilient practice, a useful product, a less fragile income, or greater independence in your current role. The methods are useful only insofar as they help you make something worth making and become more capable in the process.

Who this book is for

You do not need to know how to code. You do need a willingness to try a procedure, look closely at the result, and revise your understanding when the evidence disagrees with your expectation. A text editor, a place to keep files, and access to an AI assistant are enough for the opening work. The essential exercises have a path that does not require programming.

Later chapters introduce optional code. Each example explains its purpose before showing the code, supplies sample inputs, and states what a successful result looks like. The code is there to make an operation reproducible. Learning a programming language is not a hidden admission requirement. You should be able to describe what an example does, identify what it is allowed to touch, and recognize a failure before you decide to use it.

If you already build software, resist the temptation to skip directly to orchestration. Technical fluency can make an uncertain idea look finished unusually quickly. The early chapters ask whether you understand the problem, whether your claims have support, and whether anyone can evaluate the output. Those questions remain useful when implementation is easy.

If you are employed, studying, caring for someone, or working with a team, you do not need to leave that context to use the book. Independent capability can develop within cooperation. The amount of work you should automate depends on the task, the consequences, your responsibilities, and the time you can spend maintaining it. A system that makes your life harder to manage has not earned its place merely because it is sophisticated.

The journey through mind, memory, and system

The first arc develops your ability to investigate. You will choose worthwhile questions, separate observations from assumptions, explain unfamiliar ideas, and test connections across disciplines. Your output will be a collection of small, usable records connected to a real piece of work. The aim is to become better at deciding what to believe and what to try.

The second arc asks what should survive a session. You will organize temporary work, project knowledge, and reviewed long-term memory. You will practice turning an experience into a record another version of you can understand, preserving where a claim came from, and replacing knowledge that is no longer reliable. You will also test whether your files can be retrieved and restored. An external memory becomes useful through these operations, not through the act of collecting alone.

The third arc turns the accumulated work into delivery. You will design repeatable workflows, define bounded responsibilities for agents, review their outputs, and connect verdicts to future behavior. You will investigate demand, build a prototype, examine costs, and assemble an operating plan. Some projects will justify several cooperating agents. Others will work better with one assistant and a clear procedure. The evidence should determine that choice.

The order matters because later work uses earlier artifacts. The claims ledger helps you evaluate a research result. The memory charter tells you what a workflow may retain. The delegation contract makes the review policy actionable. The unit-economics model tells you whether a technically successful process makes sense as a business. If you jump ahead, return to the prerequisite whenever you find yourself guessing at a decision that should have been recorded.

The ladder already exists

The Solo Systems Architect Capability Maturity Model, or SSA-CMM, comes from The Future Is Solo. Its homepage describes six levels: Task Operator, AI-Assisted Operator, Workflow Orchestrator, Agent Supervisor, Multi-Agent Architect, and Sovereign Architect. This book uses those labels in that order. The Functional Life essay uses alternative labels for some levels; the source note in Chapter 23 explains the difference. The names are a way to organize development, not evidence that development has occurred. (The Future Is Solo, n.d.-b)

You may be able to design a reliable workflow in one domain while remaining a beginner in another. A person who supervises a tested document-processing agent does not automatically know how to supervise an agent handling a different kind of consequential decision. Keep each capability claim attached to the work, conditions, and evidence that support it.

The book therefore asks for demonstrations. Can you repeat a task and recognize a bad result? Can another person understand your procedure? Does the system stop when its inputs do not fit the conditions you designed for? Can you recover a previous state? Can you move your records to another tool and still use them? These questions produce more useful next steps than a flattering label.

The portfolio checks in the chapters are the book’s practical interpretation of the model. They are not an official certification, a validated psychological test, or a prediction of business success. You can use them to expose missing evidence and choose a manageable next experiment. A failed check is useful when it tells you exactly what to repair.

Follow a business that is allowed to fail

The running example is fictional. Audy is an experienced facilitator who is considering a small research and learning-design studio called Himura Inc. She wants to help independent educators turn their expertise into useful short workshops. At the beginning, she has an idea and relevant experience. She does not yet have evidence of demand, a successful product, or an automated company.

We will follow her questions, drafts, mistakes, and revisions. The same working documents will recur so that you can see how an early decision affects a later workflow. When an example uses customer conversations, delivery results, or financial figures, those details are invented for teaching unless a source is explicitly identified. They are not testimonials or evidence that this business would succeed in a particular market.

The case gives the book something specific to work on. It does not imply that your opportunity lies in education. Each arc includes adaptations for services, education, and software. A consultant might build a client-research brief; an educator might build a lesson and an assessment; a software builder might build a small feature and a reliable way to evaluate it. The shared requirement is that someone can inspect whether the work is useful.

Himura Inc. will not gain customers or revenue simply because a chapter needs an encouraging ending. A convincing exercise can lead to abandoning an idea, reducing scope, or keeping a task manual. These outcomes preserve resources and improve judgment. They belong in a practical blueprint as much as successful automation does.

Learn from the TFIS build experiments

Alongside the fictional case, the book follows selected experiments documented in the author’s TFIS build deck. These records give the discussion a factual starting point: a concrete question, a build, a reported problem, and a next step. They show work in development. An item labelled “Next” remains a plan, even when the idea is compelling. A screenshot of an interface establishes what the deck displays; it does not establish reliability or a commercial result.

One later experiment describes a division of responsibility in which agents gather evidence, humans judge its meaning, and scripts apply the resulting decision deterministically. The book will return to that division when it develops supervision and durable memory. It provides a useful design proposition to examine, not a claim that every part of an autonomous business has been solved. (The Future Is Solo, 2026, slide 33)

References identify the relevant slide so you can distinguish the experiment as reported from the practical extension proposed here. The book does not invent private conversations, emotions, or business outcomes to turn a build record into a dramatic story. The interesting narrative is already present in the work: a question becomes an attempt, an attempt exposes a limitation, and the limitation changes what the builder tries next.

Read, attempt, inspect, revise

Use each chapter in two passes. On the first pass, follow the argument and the worked example. On the second, perform the field assignment with your own project. You do not have to complete every optional extension. You do have to produce the primary artifact if you want to use it as evidence for the next stage.

Before asking an assistant to do an exercise, write a short account of what you think the task requires. It can be incomplete. Its purpose is to make your starting understanding visible. After working with the assistant, explain what changed and why. If you cannot explain a decision without rereading the answer, treat that as a signal to revisit the idea rather than a personal failure.

Research on practice testing and distributed practice supports making room for retrieval and revisiting material in learning, while leaving substantial room for differences between tasks and learners. The chapter exercises adapt those principles to project work; the research does not validate the book’s exact schedule or maturity checks. (Dunlosky et al., 2013)

Keep a correction log. Record the result you expected, what happened, what you changed, and what you will check next time. A log full of vague judgments such as “bad answer” is difficult to use. A note such as “the summary treated a proposed workshop as a completed trial; the next prompt must distinguish plans from observations” gives you something testable. Later chapters will turn this kind of correction into durable operating memory.

Set a stopping point for an investigation before you begin. You might need enough evidence to choose between two approaches, identify the next person to speak with, or reject a weak assumption. Without a stopping point, curiosity can consume the time meant for application. You can preserve the next question without pursuing it immediately.

What counts as evidence here

TFIS provides the book’s primary philosophical and developmental material. Academic research and frontier-lab publications support specific empirical or technical claims. The distinction matters. A statement about the life someone wants to lead is a normative choice. A measured difference between two groups is an empirical finding. A laboratory result does not prove a philosophy, and a philosophy does not establish a performance estimate.

References appear near the claims they support and in full at the end of each chapter. Where a paper is a preprint, it is identified as one. Where a source is a changing website, its retrieval date belongs in the reference. Worked examples and practical recommendations explain how the book applies evidence; they should not be read as additional findings from a cited study.

Read numbers with their conditions attached. A productivity result from a particular occupation, tool, or experiment may help you design a test. It does not tell you what improvement your own work will show. Your baseline and repeated trials remain necessary. When the source and your context differ, make the difference explicit in your record.

You are also allowed to revise the book’s procedures. Preserve what the procedure was trying to establish, explain your modification, and test whether the new version still provides that evidence. The goal is to develop judgment that travels beyond these pages.

Your first working folder

Create a folder called accumulated-curiosity-work. Inside it, create project, evidence, and practice. These names are conveniences, not a new taxonomy you have to adopt permanently. Put a short project description in the first folder. Put sources and observations in the second. Put your attempts and corrections in the third.

Write the project description in ordinary language: who might benefit, what task they need to perform, what you currently believe, and what you have not yet established. Date it. Do not polish it into a pitch. A record of uncertainty is more useful at this point than a confident story you will later struggle to question.

Then begin Chapter 1 with one task you currently perform yourself. The first change should be small enough to inspect. Over the course of the book, the artifacts will become more substantial. The habit starts here: do a piece of work, look at what it actually proves, and leave a record that makes the next piece of work better.

References

Dunlosky, J., Rawson, K. A., Marsh, E. J., Nathan, M. J., & Willingham, D. T. (2013). Improving students’ learning with effective learning techniques: Promising directions from cognitive and educational psychology. Psychological Science in the Public Interest, 14(1), 4–58. https://doi.org/10.1177/1529100612453266

The Future Is Solo. (n.d.-b). The future is solo. Retrieved September 10, 2026, from https://thefutureissolo.com/

The Future Is Solo. (2026). The Future Is Solo 20260910 [Google Slides presentation]. https://docs.google.com/presentation/d/1dvbBGs22QvtGogevZ6f5mf8YQE7WDAPBwYlclhTyctI/edit