# The Work We Want to Keep

*How Flow Jobs gives documents work to do while their owners keep the judgment.*

By Manav Sehgal · September 17, 2026

[Read online and explore the product examples](https://orionfold.com/essays/the-work-we-want-to-keep/).

A file called `Research.md` can contain a small fortune in attention.

The papers somebody read. The distinctions they learned to make. A promising idea that survived three objections. A table assembled slowly enough that its author remembers why two apparently similar numbers should never be compared.

Then the file waits.

When we return, we read it twice. Once for the content, again to recover the person who understood it. Which source had changed? Why did we exclude that alternative? Was the last paragraph a conclusion, or a thought wearing a conclusion's clothes?

The file saved the words. We still have to recover the work.

That gap interests me more than another impressive answer in a chat window. The work we care about rarely ends with the first answer. A research question becomes an argument. The argument needs a chart, the chart needs a definition, and the definition needs a source we can still inspect. Next month, somebody asks whether the recommendation still holds. Frequently, that somebody is us.

I call the effort of making yesterday's work usable today the **continuity tax**. Some of it belongs to thinking: rereading, reflecting, changing our minds. Some is reconstruction we have already paid for. Find the relevant material. Recover the question. Rebuild the process. Remember why the previous result was worth keeping.

Eventually, we stop returning to things. The subject we meant to understand. The essay we almost finished. The business idea whose research now requires another weekend to recover. We keep it in a folder, which is a wonderfully polite way to postpone ambition.

In [*Room for a Renaissance*](https://orionfold.com/essay/), I argued that the document could become a better home for personal intelligence. This is the next question: can a document carry a useful responsibility forward, while leaving its owner free to question the result?

## One brief, one new interview

Consider a research brief that you expect to reopen. You have spoken with eleven people about how they work. Your interview register assigns one primary need to each person. The brief contains a needs chart, a finding table and a question you want the next conversation to help answer.

Then interview twelve arrives.

In Flow's bundled Customer Research example, that person mentions portable files. The count for that need should move from three to four. Approval records still lead this small sample with five mentions. The arithmetic has changed; what to make of it remains open.

The responsibility is small enough to inspect. Read the interview register. Group the entries by need. Refresh the chart and finding table. Leave the interpretation for the person doing the research. Next week there may be a thirteenth interview, and the question will still belong to you.

Flow 1.7 keeps those saved Jobs in a Workbench beside the brief. The document holds the work you want to read; the Workbench holds the instructions, inputs and account of the run. You can inspect the assignment before asking it to proceed. Here, a saved calculation can do the counting without a model or a web service.

The attraction is modest and practical. You should not have to explain the same calculation to a new chat, copy numbers into two places and reconstruct the source of each change. The brief can retain that arrangement for the next interview. You still decide whether the sample is useful, whether a need was classified well and which question deserves asking next.

The same distinction matters when the task does need a model. Preparing a draft and accepting its conclusion are different responsibilities. A useful assistant can help with the first while giving the second a clear place to happen.

Start with the example below: inspect the saved Job, add interview I12 and run the refresh. Two document parts change. Each awaits a decision to keep or revert it. Reverting an output does not erase the interview you added. That separation between the source, the work performed and the decision afterward is the beginning of the larger idea.

[Explore: One new interview. A brief you can return to.](https://orionfold.com/essays/the-work-we-want-to-keep/#essay-first-job)

## A better starting point for the next decision

Four mentions are not a strategy. They may be a reason to ask which export or handover failed last time. They may reveal that we have grouped together people with very different problems. A correct count can help us think without settling what we should think.

That is why the document matters. The chart belongs beside the question, the finding table and the author's interpretation. Its purpose is to make a piece of work easier to understand and continue. A completed run earns attention; it does not deserve automatic agreement.

I think of this as **working knowledge**: material that retains enough of its purpose and process to become a useful starting point again. The inputs can be examined. The assignment can be changed. A correction can survive the moment in which somebody noticed it. We need not make every document active. A finished poem has no obligation to become a service. A brief that will face the same question next month has a different life.

Search helps us find what we saved. Chat helps us explore what we might mean. A document with a defined Job can help carry selected work between those moments. The promise is continuity, with the person still responsible for where the work goes.

## From document systems to a personal desk

My route to this question has been through documents, analytical systems and AI products.

In the late 1990s, at Xerox PARC, I worked on systems for storing and sharing documents across distance. At Daily Mail Group's RMS and AgRisk businesses, my work was in risk analytics and technology. From 2017 until June 2026, I worked across Amazon and AWS, including cloud architecture, innovation, artificial general intelligence and generative-AI products. I describe that route in [the founding story](https://orionfold.com/story/why-i-folded-orionfold/); my [professional history](https://www.linkedin.com/in/manavsehgal/) records the roles.

Across those settings, I became interested in a recurring distinction: information can be available without being ready for the next decision. Documents carry knowledge. Analytical systems organize evidence. Models offer ways to reason and express. Somebody still has to connect the intended outcome to the actual work.

An analytical result can be exact while the question around it is incomplete. A system can make material accessible while leaving its interpretation to whoever was present when the assumptions were chosen. Process and judgment are part of the work, even when the file contains little trace of them.

I do not mean I spent twenty-five years secretly preparing to build a Markdown application. Careers are more interesting, and less conveniently outlined, than that. Experience gives me reasons to investigate this problem. It does not exempt the product from proving useful.

I left Amazon in June 2026 to build Orionfold. One question was whether serious AI-native work could be organized around a personally controlled desk, without first recreating a traditional company in miniature. In July, I wrote about a sixty-day, one-person experiment spanning research, software, publishing, design and operations. The hypothesis was that context and responsibility could persist across transitions between kinds of work. [*Limitless, Without the Pill*](https://orionfold.com/story/limitless-without-the-pill/) is that founder's account, not a controlled productivity study.

Building on shoestring capital makes the question immediate. Hardware, subscriptions, model setup and review all cost something. I can use my own work to find confusing Jobs, lost context and results that are harder to inspect than to generate. Founder dogfood is a useful laboratory. Its participant knows the machinery unusually well.

## More room for the person

I want Flow to give a person more room to inquire, make, correct and begin again.

Many people are researchers on Monday, writers on Tuesday and builders whenever a question becomes impossible to leave alone. A capable assistant could help them carry those interests further. It could also quietly choose their sources, narrow their questions and pronounce their unfinished thinking complete.

Delegation always contains values. Which choices may the software make? Which should remain visible? When does interruption protect the person, and when does it simply consume their attention? I share the conviction that human agency and truth-seeking should shape the architecture of AI products. Those convictions become useful when they change what a person can do. [McCord and Mandel, *Dare to Found*](https://blog.cosmos-institute.org/p/dare-to-found) helped sharpen that question for me.

For the research brief, keeping judgment with the owner has concrete consequences. The Job names its input. The calculation has a defined purpose. The changed chart can be inspected in the document. The researcher can reject the update, reconsider the classification or decide that another interview would be more useful than another run.

This also requires restraint from the product. More generated prose is not necessarily more useful knowledge. A quiet check that finds nothing to update can be a good result. Some work should wait because the person has not decided what matters yet.

## Where we intend to begin

Our initial customer hypothesis is independent professionals who repeatedly return to research, client or product briefs: consultants, researchers and builders whose work combines changing inputs with accountable judgment.

The common need is more specific than wanting an AI assistant. They have a document worth reopening, a recurring part of its upkeep they can describe, and a reason to inspect the result. A client brief must remain explainable. A research summary must preserve its qualifications. A product recommendation must survive another round of evidence.

That is where I want Flow to earn its place first. Can a person who did not build the app give one document a useful Job, return later and continue with less reconstruction? Does the time spent setting it up and reviewing it repay itself over repeated use? Does the person choose to keep using it?

We do not yet have independent customer evidence establishing those outcomes. They are the tests that distinguish a promising personal arrangement from a useful product. Twenty-four starting Living Documents offer places to begin in Flow 1.7, but the important count is how many responsibilities become worth returning to.

For the Research Brief, the arrangement remains small enough to explain: the interview register is an input, the saved definition describes the calculation, and the outputs serve the table and chart. The map below makes those declared relationships visible. It gives the next visit somewhere to start.

[Explore: A clear route back to the source.](https://orionfold.com/essays/the-work-we-want-to-keep/#essay-jobs-map)

## A Job should be an understandable assignment

“Improve my research” is an ambition. It leaves almost every practical choice open. Which sources count? Which statements may change? What should happen when the evidence is missing? How will the person know whether the work helped?

“Read this interview register, refresh these two views and leave my interpretation alone” is an assignment somebody can inspect. Its limits make it useful. When a result is surprising, the owner can return to the input and the instruction rather than start another conversation about what the assistant might have meant.

In the Customer Research example, `Research Refresh.md` holds the saved definition. It reads `Interview Register.md` and prepares data used by the brief. The Jobs map shows that declared shape. A line between two items tells us what the Job is meant to read or produce; it does not establish that a run succeeded or that an interview supports a claim.

The difference matters as the work grows. A document may draw on local files, selected web material or a model's contribution. Those inputs carry different kinds of uncertainty. A calculation can correctly count a mistaken classification. A model can preserve a source's words and lose its qualification. A retrieved passage can be relevant without supporting the conclusion written beside it.

The practical response is to keep the assignment and its results close enough to question. We should be able to ask what was intended, what happened and which part now needs attention. A graph or a reassuring completion mark cannot answer all three on its own.

Flow's Workbench provides different views of this responsibility. You can inspect and edit the saved Jobs, run them deliberately and examine their declared relationships. The primary document remains in view. The arrangement is useful only if understanding it takes less effort than repeatedly recovering the work it is supposed to help.

## Permission should match the responsibility

Making a copy of a Living Document gives you local files to inspect and change. It does not enroll you in a schedule. Running a Job once does not authorize it to keep running.

This is especially important for work inherited from somebody else. Their useful template is a starting point. Their authority over their files is not authority over yours. You should be able to read the assignment, change its inputs and decide whether it deserves a first attempt.

A recurring Job is a further choice. Night Shift can run supported, authored work under standing permission within an owner-set window, when the Mac is available under its idle and power conditions. It leaves an account of the attempt and, for reviewable changes, a decision to make later. It cannot do useful work on a powered-off computer, and named web inputs still need a network connection.

Different actions also have different moments of approval. A daytime Agency transformation can present an exact proposal before **Approve & Save**. A manual Jobs run can apply reviewable changes that await **Keep** or **Revert** afterward. Permitted Night work has its own standing agreement. The owner needs to understand which arrangement they are choosing.

This is more useful than a general promise that an assistant “keeps you in control.” Control has to attach to an actual decision: what may be read, what may change, when work may proceed and what happens if it fails. A missing input should remain a visible gap. A failed local attempt should not quietly become permission to send the material elsewhere.

## The decision after the run

Return to interview twelve. The source now contains twelve entries. The Research Brief's needs chart and finding table have changed the portable-files count from three to four. Those changes are applied, and they await the owner's decision.

Selecting a changed part brings attention to the place being judged. You can inspect its previous and current values, keep it or revert it. **Later** leaves the remaining changes applied while postponing the decision. It does not silently reject them or pretend they have been approved.

Suppose you keep the chart and revert the finding table. The interview remains in the source. Reverting that output restores its earlier state; it does not remove inconvenient evidence from the study. A later run may refresh the output again. If the problem is the classification or the assignment, that is where the lasting correction belongs.

This distinction gives review a purpose beyond clicking through an approval screen. Was the input right? Did the Job do the intended work? Does the resulting presentation help the reader? Is the conclusion still proportionate to the evidence?

In our small example, approval records still lead with five mentions. The new portable-files count is worth noticing, but it does not establish a market preference. The next useful move might be to ask about a failed handover, revisit the sample or leave the recommendation unchanged. The chart can refresh without the software inventing a stronger conclusion.

Review itself costs attention. If every minor change demands an investigation, we have moved the continuity tax rather than reduced it. The aim is to make the meaningful change easy to locate and its source easy to question, so a person can spend judgment where it matters.

A receipt records what ran. A retained decision records what the person chose to keep. Neither certifies that the work is true. Together with the source and the document, they provide a practical route backward when a question arises. That route is part of what makes the work worth carrying forward.

[Explore: The numbers changed. The decision is yours.](https://orionfold.com/essays/the-work-we-want-to-keep/#essay-review-decision)

## A model should earn its part in the work

The research count needs arithmetic. Another Job might need to compare passages, prepare notes or help revise an argument. Giving each task a suitable tool is more useful than making every operation an audition for the largest model.

Personal computers are becoming more capable places for this work. Apple's recent hardware and model research point toward richer applications that combine device resources with other capabilities when needed. They do not eliminate the constraints of memory, energy, availability or review. A useful AI workshop still has to leave room for the person and the rest of their computer.

In our own September model curation, a smaller candidate handled a bounded daytime document task better than an alternative we tested. It did not pass the separate Night baseline. A larger candidate did. That distinction mattered more than a single ranking: a model can earn one assignment without earning every assignment.

We also observed that a larger thinking allowance could add time without consistently improving the result. These were small development studies on one Mac, not evidence of typical customer performance. The [research notes](https://orionfold.com/essays/the-work-we-want-to-keep/notes/) retain the exact models, test scope, resource measurements and their limits, alongside the external research informing this essay.

The product principle is simple: choose computation for the work. A deterministic operation, a qualified local model or a stronger hosted model may be appropriate. A person should be able to understand the choice and the boundary it crosses. Suitable local inference avoids a hosted token charge, but hardware, electricity and human attention still count.

Flow begins on the Mac, with readable files the owner controls. Configured daytime actions can use metered OpenRouter, OpenAI or Anthropic routes when the person chooses to run them. Night Shift model work stays local. Local inference does not make every activity offline, and locality alone does not establish safety or correctness.

I call this **opinionated optionality**: defaults we are willing to defend, with room for the owner to choose differently. Keep the document visible. Give a Job an understandable purpose. Fit the computation to the task. Make departures from the device explicit. Leave the work in a form the person can keep.

## The second visit is the test

The first successful run is encouraging. The next visit is more revealing.

Another interview has arrived. You changed a classification. You left the finding table unresolved because it needed thought. Ordinary life intervened. Can you now find the work, understand the changes and continue without rebuilding the assignment?

For the Research Brief, the meaningful test reaches beyond refreshing two numbers. We would need to observe the full cycle: setting up the Job, returning to the context, updating the inputs, inspecting the result and correcting mistakes. The question is whether that whole arrangement helps somebody produce work they are willing to stand behind.

Sometimes the right result is no change. Sometimes an input is unavailable and the honest result is an explanation. Sometimes the Job runs perfectly and the owner discovers that it answers a question no longer worth asking. A system that generates something impressive every time can make these ordinary outcomes harder to recognize.

Flow retains run information, receipts and revision history to make returning possible. Morning Briefing can orient an owner to standing work that needs review. Those mechanisms create the opportunity for continuity. They do not prove that the product has reduced the total effort of a recurring responsibility.

The next test should include people who did not build the software and cycles in which inputs change, remain unchanged or cannot be read. Count the setup and the correction, not just the quick run. Notice whether people understand the Job well enough to adapt it and whether they return by choice.

That is also how the product should improve. A useful correction might be a clearer instruction, a better source or a simpler control. It might be the removal of a Job that never repays the attention it requires. Accumulating more generated text is not the same as learning how to work better.

## What could accumulate

Orionfold's opportunity is to make these arrangements dependable and understandable across useful kinds of work. A local model alone is not that advantage. Neither is a folder of templates or a collection of approval buttons.

The hypothesis is that task-specific curation, document-aware execution and close attention to repeated use can improve together. Better Jobs make useful work easier to begin. Better review makes mistakes easier to diagnose. Those diagnoses can guide better defaults and more focused evaluations. Each part matters because it serves an actual responsibility somebody wants to carry forward.

Whether this becomes a lasting advantage for Orionfold depends on people whose work and patience differ from mine. The first evidence would be modest: someone understands the arrangement, gets a result worth keeping and finds a reason to return. Repeated usefulness would tell us more than a spectacular first demonstration.

## Own the page, keep the possibility

Markdown is a quiet foundation for this ambition. Readable text can hold an argument, links and structured Job declarations. Supporting files can sit beside it. Flow can present charts, tables, diagrams and images while leaving the underlying work accessible to other tools.

Another Markdown editor will not necessarily execute Flow's Jobs or reproduce its views. Ownership of the file and portability of execution are different promises. The important starting point is that leaving the application does not require surrendering the work itself.

A model can be replaced. A routine can be retired. An application can become unsuitable. The work should still offer its owner somewhere to stand: readable material, retained reasons, supporting files and a choice about what happens next.

The larger possibility is a working life with more continuity. Research can inform writing without another long reconstruction. A product decision can retain its reasons while the builder returns to making the product. A recurring responsibility can remain legible while its owner turns to business, family, curiosity or rest.

The [Living Documents Manifesto](https://orionfold.com/manifesto/) calls this rhythm FOLD: Frame the outcome, Organize the routine, Leave a receipt, Develop the practice. The document holds the question. A Job carries selected work forward. The person's judgment gives it a direction worth continuing.

Choose a document you already have reason to reopen. Give it a small responsibility and inputs you can explain. Run it once. Inspect the result. Keep what is useful. Then decide whether another cycle would help.

Future you has enough mysteries to solve. Yesterday's research need not be one of them.

[Research notes and evidence](https://orionfold.com/essays/the-work-we-want-to-keep/notes/).

[Download Flow](https://orionfold.com/flow/) and begin with one piece of working knowledge of your own.