A workspace for humans and agents

I open a Claude Code session on DIA, the community radio I've been building tools for over the past year. Every week, we post an Instagram reel with our favourite tracks of the week. I ask: "Do we have the tracklists for every show from last week?" Claude gives me the list: which ones are complete, which ones are missing. One episode is missing its information, so I ask the agent to write to the resident and ask them to fill it in. Once that's done, and we have everything for every show that aired, I just say: "OK, prepare the favourite tracks reel." And the automation starts.

At the start of that conversation, I didn't explain what DIA is. Or where the shows are, or how we make that reel, or who to write to, or in what tone. All of that is already written down somewhere, and the agent knows where. Time can pass between two sessions and nothing gets lost: what we decided last time is written down, and it finds it in a few seconds.

It's all about context

In the first article, I described how I had become my agents' memory, carrying exports from one conversation to the next. With a workspace, the question becomes one of context: how to give them permanent access to everything they need, so I don't have to explain things again at every session.

First, there are two ways of working with an AI. In a chat app, ChatGPT or Claude, the agent mostly relies on the conversation. These apps have memory now, much better than before, but what is said in the conversation still weighs a lot. And the longer it gets, the more the quality of what the agent sends back drops. Researchers at Stanford measured it in 2023: information placed in the middle of a long context is taken into account less well than information placed at the beginning or the end. After a while, it's tiring. You explain again, you correct, you start over.

Everything I describe here runs on Claude Code, which works differently. It's an agent that works directly in the folders on my computer: it opens files, reads them, edits them, runs commands. It doesn't need me to tell it about a project, it goes and reads what is written about it. With a plain chat, none of this works.

And what is written down is all my work: my projects, their manuals, my notes and my ways of working, organised in folders. Each project has its git repository and its manual, with the brain in the middle, and the skills. The agent is also connected to everything else: my email, my calendar, Figma, analytics, the radio's database.

The manuals, which I wrote about in the previous article, were already a huge gain. But the day the workspace and the brain were connected to my email and everything else, it was immediate: we had a system that worked. We've been working this way for months now, and I can't even remember how I did things before. And I can't imagine going back.

In a chat, you don't control the result

Context doesn't solve everything. One problem is still there: you work out a process with the agent, you're happy with it, and when you ask for the same thing a bit later, the result comes out slightly different.

A couple of weeks ago, Claude and I ran a big audio analysis on DIA's archives, for our research on music discovery: the energy of each mix, its mood, its styles. First pass on nine shows, Claude gives me a report: for each mix, the styles it detected, the energy, the mood, how much of it is talk, and a line where I write down my own verdict after listening. We're not fully happy with the result, Claude suggests another method, we run it again. The second report comes in, and the layout has completely changed. The information isn't in the same place anymore, impossible to compare the two at a glance.

As long as the process only exists in the conversation, it depends on what the agent has retained along the way, and that's where it starts changing things. To make that stop, you have to write the process down in a file: what data we process, how we process it, what result we expect. It can be a skill, or an automation split into steps. For the third pass, on twenty-two more shows, the report became a script that reproduces the layout of the first one, exactly. Same rules, same presentation, every time. Now we control the result.

Files, and apps all the same

I keep all that context in text files, in markdown format, organised in folders. It's what an agent reads and writes most easily, and I can open them in any editor.

That doesn't mean other tools are useless now. I really like Notion, I worked with it a lot at the startup I was at before, and it's a very good tool. It's even better today, because an agent can drive it for us. For what humans read and edit, documents, meeting notes, tracking tables, these tools are still great. A lot of people want to be able to change something by hand, and not everyone wants to let an AI do everything.

The agent's context is something else: the rules for working on a production server, the tone to use in an email, the steps of an automation. All of that lives in files, where the agent works.

I also realise I use those interfaces less and less myself. I set them up, I structure them, but day to day, when I'm looking for something (a report, where a project stands, something in an email), I ask my agent in my Claude Code session, rather than opening the tool where it's stored. It's much faster than opening, clicking, searching. Same for the content of my websites: I no longer edit text by hand in the CMS, I tell Claude what's wrong, we rewrite it together, and it updates it.

I asked Claude what it would add, from its side.

We tested it: searching the files is enough, almost

We're not the only ones working this way: building your system around folders and instruction files for agents is a real trend today. Two people talk about it particularly well, Jake Van Clief and Kem, from Glitch Cat Club. On AI, our feeds are full of noise and clickbait; these two, we decided to follow because they share real information. Jake wrote a method, ICM, on how to structure your folders for an agent. Kem has made several videos about it. In one of them, he criticises "LLM wikis", those knowledge bases the model writes and maintains itself, which is exactly what my second brain is. For him, the index that serves as their front door doesn't add much: an agent that searches well-organised folders directly answers just as well, for less.

So we ran the test, at the end of October. Ten real questions about my projects, twenty agents launched with no context at all. The ones that searched the files directly found everything, using 40% fewer tokens than the ones that had to go through the brain's big index first. Kem was right: searching the files directly works.

But the brain is still useful elsewhere. When I give it an article or a piece of information, it links it to the subjects I'm working on, and a plain search doesn't do that. So we kept both, replacing the big index with a short table of contents: one line per project, saying where its up-to-date state lives. On a second, smaller test, the agents that read it before searching gave better answers than the ones that searched directly, for almost the same cost.

Everything it learns belongs to me

Everything we teach the agent so it works well, we save in files: the rules, the ways of doing things, the decisions, the mistakes not to repeat. Those files sit in my folders, physically on my computer. They belong to me.

I can change models tomorrow: move from Anthropic to OpenAI, or to an open-weight model. Those are catching up with the frontier models. Kimi K3.1 just came out, and with a powerful enough machine, I could run it at home. The new model will work in the same folders. I don't depend on a big company that can, overnight, cut off access or raise the price of the subscription.

We spend months building all this with the agents: documentation, rules, ways of writing, of producing, of automating. If all of it lived in an online tool I had no control over, I'm not even sure I'd do it. Training agents for months for a result that doesn't belong to me, I don't see the point.

On this too, Claude has something to say.

Organised for two

A human and an agent don't search the same way, so they don't need the same structure. I go through the Finder: when I open a folder, I need to see right away where things are. Claude searches the text of the files. A folder's name or depth matters less to it than what's written inside, and where its instructions are.

The structure for the human depends on each person. Someone very organised already has their own filing logic, and can apply it to their folders. What matters is that the person finds what they're looking for. And that structure doesn't have to be fixed: you build it as you go, with the agent. When a new case comes up, you create the folder it needs, just by talking about it. If you can't find your way around anymore, you redo the structure together, and that's that.

On the agent's side, though, some things really matter. I let Claude say which, since it applies them every day.

We had started building this system before we discovered ICM. Reading Jake, we found someone doing something very close: folders and files that decide what the agent has in front of it at each step. He applied it directly to automations, in a very structured way, and we used it to strengthen ours. Two of Claude's rules also come from him: at each step, give the agent only what it needs for that step; and never copy an instruction into every folder, but write it once, in one place, and point to it.

Out of all this, and out of our own trial and error on our own space, came the workspace we now install for other people: a base that is already structured, ready to evolve. Each person then adapts it to their way of working, to their own logic.

Where to start

The simplest answer would be: take my system. But the core comes down to a few things.

A main file in every folder, which the agent always reads, and which points to the others: what the project is about, what it can do, what it must not do. It's as simple as that.

You don't write these files, the agent does. At the end of a session, ask it to write down what it learned: the facts, the decisions, what will need to be done the same way again.

Context, lots of it. If you set up a folder for a single automation, its context can be limited to what that automation needs. But to work in an augmented way, every day and on everything, without context, it doesn't work. Who you are, who you work with, how you think, how you produce, and your tools. It's a big leap, a bit scary. You can do it in steps: connect your tools read-only first (email and calendar to read, not to send), then widen as the results follow.

When I've finished writing this article, I'll open a Claude Code session on the radio, and I'll ask it whether we have everything we need to put out this week's favourite tracks reel. I won't have to explain anything.

Sources

• Kem, Glitch Cat Club, "LLM wikis are bullshit", October 2026: the blind test of LLM wikis against an agent searching folders.
• Andrej Karpathy, LLM Wiki, April 2026: the original idea, a wiki the model writes and maintains.
• Jake Van Clief and David McDermott, Interpretable Context Methodology: Folder Structure as Agent Architecture, March 2026: folder structure as agent architecture.
• Jake Van Clief, icm-architect, 2026: the skill that applies ICM to an existing space (one piece of information, one place; point to the level above rather than copy).
• Nelson F. Liu et al. (Stanford), Lost in the Middle: How Language Models Use Long Contexts, 2023: the loss of quality over long contexts.