Preserve the power
- speed
- persistence
- file access
- tool use
- reusable artifacts
- visible work logs
- low-friction iteration
- workspace compounding
Thesis
Living context.
Claude Code is meant for working in software repos. Cowork is meant for bounded projects. ChatGPT and Claude web are meant for chat assistance.
Users are researching. Writing. Planning. Cleaning spreadsheets. Building tiny one-off tools. Pulling data from APIs. Summarizing PDFs. Making dashboards. Drafting emails. Running scripts they barely understand. Asking the agent to remember how they like things done.
Non-coders do not need a coding agent. They need a place where their work can accumulate.
Observation
Power users are bending coding agents into workspaces.
Power users are building worlds within their folder. Inside it they put notes, PDFs, CSVs, drafts, scripts, API keys, research outputs, little utilities, reusable procedures, and half-built tools that solve one annoying problem.
Over time, the agent learns the terrain. It knows where things live. It can reuse old scripts. It can turn yesterday's research into today's brief. It can take a messy spreadsheet and produce a clean artifact. It can make a local webpage because the user needs to see something, not because anyone is shipping a product.
Users are delegating work inside an accumulating environment rather than one-off prompts. That is much closer to a place where work lives than a chat app.
But it's a mess.
The work repo for a non-coder
Scattered context gets a durable home.
Click a source to see what kind of context it contributes to the workspace.
Inbox
open asks and active tasks
Files
source documents and datasets
Notes
rough thinking and summaries
Artifacts
durable outputs and templates
Tools
scripts and generated interfaces
Memory
preferences and reusable context
Work log
what happened and why
Permissions
read, write, send, delete boundaries
PDFs contributes
Research packets, citations, policies, and evidence trails.
Software has repos. Knowledge work needs a workspace that plays the same role.
Terminal
The Claude Code terminal is both the problem and the magic.
The terminal scares people. It exposes too much. It asks the user to trust a surface they do not understand. Permissions feel abstract. Files feel fragile. Commands look like equations from a class they never took.
But the terminal also gives the agent what web chat lacks: speed, persistence, file access, tool use, reusable artifacts, visible work logs, and a workspace that compounds.
In a software project, the repo is the context. That is why coding agents work so well. The agent can inspect the files, edit them, run tests, check the result, and leave the workspace better than it found it.
Knowledge work needs the same primitive, but its context is messier. A knowledge worker's "repo" is scattered across email, docs, browser tabs, PDFs, spreadsheets, Slack threads, calendar events, and memory. The work is real, but it does not arrive in a neat folder with tests.
So users improvise. They make a local monorepo for their life and work. That sounds ridiculous until you experience it. Then web chat starts to feel thin.
Chat
Web chat stops feeling like enough.
Once a user has a work homebase with files, scripts, and procedures, normal chat begins to feel oddly amnesiac. You have to upload the same files again. Explain the same context again. Copy things out. Paste things in. Rebuild the state of the work over and over.
Every copy-paste step is a small confession that the product is not really where the work lives.
A persistent workspace changes the math. The user can say, "Use the last research export," or "Run the script we made for this," or "Turn those notes into the same format as before." The system has a past. That past gives the user leverage without making them feel like they are starting from zero.
This is tacit knowledge for LLMs. Skills are part of it, but the deeper asset is the whole accumulated environment: procedures, prior outputs, local data, connectors, scripts, naming habits, user preferences, and review patterns.
The more the user works there, the more the system becomes theirs.
Shape
Cowork is project-shaped. The need is work-shaped.
Cowork is close because it recognizes that non-engineers need a friendlier agent surface. But the shape still feels too much like "start a project, complete a project, leave the project."
A person's work life is full of recurring fragments: the same weekly report, the same vendor analysis, the same messy spreadsheet cleanup, the same research process, the same "make it presentable," and the same personal preferences about tone, format, and depth.
The missing product is persistent, cross-context, and accumulative. It should feel like one place where your work history, tools, context, and agents can grow together.
That is why the "single folder" idea matters. It is primitive, even crude. But it has the right soul.
One workspace where everything goes, where everything can be reused, where everything keeps getting better.
How work becomes reusable
Intent becomes reusable work.
Memory returns to the next request, so every finished task becomes starter context.
01 Intent
Work Request Parser
Turns a messy ask into fields, assumptions, and a success shape.
Output: Parsed brief
02 Context
One Workspace
Pulls files, prior outputs, notes, and preferences into the task.
Output: Warm context
03 Boundary
Permission and Delegation Layer
Sets what the agent can read, edit, run, share, or ask about.
Output: Safe scope
04 Execution
Dynamic Tools
Creates the temporary surface, script, or workflow the work needs.
Output: Live tool
05 Inspection
Verification Loop
Shows sources, diffs, assumptions, and risks before approval.
Output: Reviewable result
06 Reuse
Accumulating Artifacts
Saves the output, procedure, and corrections as reusable material.
Output: Starter context
Memory return
The context gets richer.
Procedures, preferences, artifacts, and review patterns flow back into the next ask.
Prior outputsSaved procedureUser preferenceReview pattern
Every completed task should make the next task easier.
Delegation
The real user is delegating, not coding.
Most people do not want to code. But many people do want what coding agents accidentally provide: small tools on demand, automation for annoying tasks, work across files, reuse from previous work, and a computer that does the tedious parts.
The user does not think, "I need a Python script."
They think, "Can you clean this spreadsheet and make the weird columns usable?"
The agent may write Python. The user does not care. The code is an implementation detail. The artifact matters.
This is why the current category language is so limiting. "Coding agent" describes the tool's method, not the user's desire.
The desire is system-level delegation. The user wants to hand intent to the computer and watch the work happen.
Mainstream Surface
The average user does not want a raw terminal.
Power users like the roughness. They enjoy tuning their setup. They install MCPs, write skills, tweak instructions, and slowly assemble a private machine around themselves.
Most people want the system to work like iOS or macOS. They want power without ceremony. They want the machine to adapt without making them become the administrator of a tiny software company.
Non-technical users can learn powerful tools. In fact, many prefer them once trained. But they need a surface that does not punish them for lacking technical background.
The goal should be a product that preserves the compounding power of Claude Code while removing the fear tax.
The product should not bury the user in a heavy GUI. Heavy GUIs freeze assumptions too early. This space is changing too quickly. But the raw terminal is too hostile for mainstream use.
So the right question is sharper: what is the terminal-like thing for non-engineers?
Remove the fear tax
- clearer permissions
- friendlier file handling
- safe defaults
- visible memory
- simple recovery
- built-in teaching
- useful previews
- dynamic interfaces
Loop
The interface should feel like a game for work.
Claude Code is fun in a way most work software is not. The terminal gives immediate feedback. Text streams. Colors change. The system asks for permission. You press enter. It acts. You redirect. It tries again. A session has rhythm. It feels closer to a game loop than a productivity app.
People learn complex systems through play. They explore. They try things. They see what breaks. They build intuition. The best onboarding may feel more like a tutorial level than a help center.
There are already game-like concepts hiding in the category: MCPs feel like expansion packs, permission modes feel like difficulty levels, usage caps feel like paywalls, and faster models feel like power-ups.
The space of "video game for work" is underexplored. Most enterprise tools still perform seriousness through slowness. Agent products should do the opposite. They should make serious work feel alive.
Speed is central. Long web chat threads get sluggish. Terminal sessions stay quick. That speed changes behavior because the user is more willing to iterate. A fast agent feels like an extension of thought.
Adoption
Onboarding is the bottleneck.
The models are already strong enough to create compounding value. People need to learn what to delegate, how to scope a task, how to judge an output, when to give access, how to recover from a bad turn, how to build reusable workflows, and how to notice the magic moment.
Humans learn action tasks by watching and by doing. A one-on-one demo beats documentation. A Loom beats a feature page. A cohort where someone brings a real task beats a generic webinar.
AI-powered education is one of the most obvious uses of AI. The same models that can do the work can teach the user how to delegate the work. The product should watch for confusion, slow down, explain, and create practice loops.
Hard Parts
This is hard.
The product is difficult because knowledge work lacks the clean structure that software has. Software work has repositories, tests, build commands, diffs, and relatively clear pass-fail loops. Knowledge work has partial context, subjective judgment, fragile trust, and fuzzy completion.
Context
Software context often lives in the repo. Knowledge work context lives everywhere: email, docs, websites, spreadsheets, old notes, chat threads, PDFs, calendar events, and the user's own memory. The agent's usefulness rises with the amount of relevant context it can safely access.
Verification
Software can often be tested. Knowledge work is usually verified by a human. The user has to decide whether the memo is right, the analysis is sane, the plan is usable, or the recommendation matches the situation. The product needs better human verification loops: previews, citations, comparisons, source views, reversible changes, and clear uncertainty.
Integrations
Agents need access. But access creates fear. The user wants the agent to work across email, docs, browsers, spreadsheets, and business apps. The same user may hesitate to give real credentials to an immature product. This is why permission design is central. Trust cannot be bolted on later.
Product Shape
The winning product probably starts with a few simple primitives.
One workspace
The user should have a global place where work accumulates. Projects can exist inside it, but the workspace should outlive any single project. This is the user's professional memory, toolbench, and work history.
Accumulating artifacts
The system should naturally save useful things: notes, outputs, scripts, procedures, research packs, data files, and generated tools. The user should not need to think like a developer. The system should decide what is worth keeping, ask when needed, and make reuse feel natural.
Dynamic tools
Many tasks only need temporary interfaces. The agent should be able to create these surfaces as needed. Ephemeral software becomes a core part of work.
Visible memory
Users need to know what the system remembers. Memory that cannot be inspected becomes untrustworthy. The product should show what it knows, where it learned it, when it last used it, and how to delete or change it.
Permission layers
Permissions should be understandable in human terms. The user should know what the agent can read, write, send, buy, delete, publish, or share. The product needs a permission model that feels closer to delegation than system administration.
Built-in teaching
The product should teach as it works. When the user gets stuck, the system should switch modes: demo, collaborate, then hand control back. The agent should help the user become more powerful without forcing them to read docs.
Risk
What will hobble these products.
A product that makes every new capability wait on bespoke interface work will move too slowly. A product that gives the agent simple primitives, file access, tool access, and dynamic UI generation can evolve faster.
This is why terminal-forward development has an advantage right now. The category is uncertain. Simple primitives beat polished rigidity. But the mainstream product has to carry the power forward into a friendlier surface.
Strategic Bet
The future computer may look less like a desktop and more like a living workspace.
A place where files, memory, tools, agents, permissions, and interfaces are native parts of the same system. A place where the user can say what they want, watch work unfold, inspect the result, correct the system, and know that the correction will matter next time.
A place where every completed task increases the value of the next one.
The less technical user does not need a weaker tool. They need a stronger system.
Build the work homebase. Build the game loop for serious work. Build the computer where agency, rather than navigation, is the core primitive.
That is living context.