What Claude Code needs to work with you

In Brief

• Claude Code is not just a tool for writing code. It is an AI agent that has to work inside a real environment.
• Daisy Hollman's main point is simple: the agent needs access, knowledge and tools.
• Access means the agent must be able to see the right files, folders, documents, systems and error messages.
• Knowledge means the agent must understand rules, routines, style, decisions and what the project is actually used for.
• Tools means the agent must be able to check, test, search, export and finish the work.
• The point is not to give the agent everything all the time, but to give the right information, the right method and the right limits at the right time.
• That is why good agent use is less about one perfect prompt and more about building a good system around the model.

Why this is about more than code

It is easy to think of Claude Code as a tool for programmers.

But what Daisy Hollman explains in Beyond the Basics with Claude Code is really about something much bigger than code.

It is about how an AI agent can work alongside you inside a real system.

That system could be:

• a codebase
• a folder of images
• an accounting system
• a spreadsheet
• a blog archive
• a project with PDFs, notes, appointments, design files and old decisions

Imagine giving someone access to your entire computer.

• They can open your documents.
• See your images.
• Read your notes.
• Browse through folders.
• Find spreadsheets, PDFs and old projects.

But that does not mean they understand your life.

• They do not know which documents are important.
• They do not know which images belong to which project.
• They do not know which spreadsheets are up to date.
• They do not know which files are old.
• They do not know which folders you actually use.
• They do not know which routines you follow.

They see the information, but they are missing the context.

The same is true for Claude Code.

Claude Code can read files, write code, edit text, run commands and help you with work. But code is just one type of file. In practice this is about something more fundamental:

An AI agent needs a work environment.

Some parts of this work environment are ordinary files. A project file can explain how the folder works. A skill can live in a SKILL.md. A specialized agent can be defined in its own agent file. Other parts are connections, settings or tools. The point is not the file type, but that the agent gets something concrete to work from.

Daisy Hollman sums this up in three simple needs:

"Access. Knowledge. Tools."

If one of these is missing, the agent becomes less useful.

Without access, it cannot see what it needs.

Without knowledge, it does not understand why things are the way they are.

Without tools, it cannot finish the job.

That is why the main point of the talk is not just that Claude Code is smarter than before.

"A good coding agent is not just about the model. It is also about the system the model works in."

That is the key.

Claude Code is not just a chatbot

When people hear about Claude Code, it is easy to picture a chatbot that can write code.

You type:

"Build this function."

Then Claude replies with code.

That is the simple version.

But Claude Code is closer to a colleague who gets access to a project.

A project often lives in a folder on your computer. It contains code, documentation, configuration files, tests, notes, images, design files, CSVs, PDFs, old drafts and small rules that only the project itself knows about.

When Claude Code gets access to such a folder, it can read files, understand the structure, suggest changes and do work.

For developers this often happens in the terminal, in a code editor or in an app.

But the principle is not only technical.

The same applies if you have a folder called:

• Finances 2026
• Blog posts
• Client projects
• Images
• Personal operating system
• Accounting
• Courses and talks
• Board work in the sports club
• Documents for the housing cooperative
• Family archive
• Receipts and warranties

If you ask an AI agent to help you with such a folder, it is not enough that it can just "see the files".

It has to understand what the files mean.

• What is old?
• What is active?
• What is finished?
• What is a draft?
• What can be deleted?
• What must never be deleted?
• Which files belong together?
• What is the source of truth?

This is what Hollman spends the talk on.

She is not primarily talking about better prompts.

She is talking about the work environment around the agent.

The problem is not just code. The problem is context.

If you hire a new developer and give the person access to one folder of code, that does not mean the person automatically understands the project.

• They do not know why the system was built.
• They do not know which decisions have already been made.
• They do not know which rules the team follows.
• They do not know which errors have come up before.
• They do not know how changes are tested before they go live.

Even though the person can read the code, a lot of the context is missing.

The same is true for Claude Code.

Code is just one part of reality.

Around the code there is documentation, decisions, workflows, routines, tools and experience that have built up over time.

And this applies just as much outside programming.

If you have a spreadsheet with personal finances, the numbers are not enough. The agent has to understand what the columns mean, which rules you use, which accounts are personal, which belong to the business, and what should be counted or not.

If you have an image archive, the file names are not enough. The agent has to understand which images are originals, which are exported, which were used in a campaign, and which are just old tests.

If you have a folder of blog posts, the text is not enough. The agent has to understand style, structure, publishing routine, sources, audience and what has already been written before.

If you have a personal operating system, often shortened to personal OS, it is not enough that the agent sees the folders. A personal OS can be notes, projects, files, routines and goals gathered in one place. Some people call parts of this a second brain or a personal knowledge system. Before, this was mostly something you organized yourself in folders and apps. The system did not understand the connections. With AI agents it can become more active: the agent can keep track, find the right information, connect things and give quick answers. But then it has to understand how you work.

This is why simple coding help is not enough when the project grows.

An agent can help with small things without much context.

• It can write a function.
• Fix a typo.
• Update a file.
• Create a simple test.
• Summarize a document.

But when the project gets bigger, it needs more.

It needs access. It needs knowledge. It needs tools.

The three things the agent needs

Hollman's simple model is really useful because it cuts through a lot of technical language.

Here it becomes a practical checklist:

1. Access

The agent has to be able to see what is relevant.

For a developer that could be GitHub, the terminal, test results, documentation, error messages, tasks or CI systems, meaning systems that automatically run tests and checks when code changes.

For a non-technical user it could be folders, documents, images, PDFs, spreadsheets, notes, contracts or project files.

If you ask the agent to tidy up your finances but it cannot see the spreadsheet, it is going to guess.

If you ask it to write a blog post but it cannot see earlier articles, it is going to miss the style.

If you ask it to find a bug in a project but it cannot read the error message, it is working blind.

Access does not mean the agent should have free access to everything.

It means it has to get the right information when it is working on a specific task.

If Claude cannot see what you see, and cannot use what you use, it cannot do the job fully alongside you either.

2. Knowledge

Access is not enough.

The agent also has to understand how things work.

The agent needs to understand why, not just what.

A spreadsheet is not just cells. It has rules.

A folder is not just files. It has structure.

An image archive is not just JPGs. It has versions, choices, export files and originals.

A codebase is not just code. It has architecture, dependencies, tests, history and decisions.

Knowledge can live in documentation, project instructions, README files, custom rules, style guides, checklists or small explanations in the project.

For Claude Code, files like CLAUDE.md are often used for this.

But the idea is simple even without code:

Make a file that explains how the project works.

For example:

• What this folder is used for
• Which files are important
• Which rules apply
• What must never be deleted
• How things are named
• How work should be checked before it counts as finished

This is not decoration.

This is working knowledge.

3. Tools

Finally, the agent needs tools.

Reading and writing text is not always enough.

Sometimes the agent has to be able to:

• run a test
• open a file
• check a CSV
• analyze a spreadsheet
• create a report
• export a file
• compare two versions
• read metadata
• check whether a link works
• find images in a folder
• run a command

For developers this could be terminal tools, tests, linters, type checkers, build systems and Git.

In ordinary projects the agent might need tools to read spreadsheets, find files, understand images, open PDFs, search, export, follow checklists and create reports.

Tools mean the agent does not just answer.

It can actually do the work.

Why the agent should not get everything at once

When a project gets big, a new problem appears.

The agent needs more information, but it cannot get everything all the time.

This is important.

Many people think the solution is to write one enormous instruction for the agent.

Everything goes in:

• Project history.
• Folder structure.
• Rules.
• Code philosophy.
• APIs.
• Test rules.
• Design principles.
• Past mistakes.
• Working methods.
• Personal preferences.
• Publishing routines.
• File names.
• Sources.
• Formats.

But that works badly as the project grows.

It is like handing someone the whole library before they answer a single question.

An AI model has a limited context window. That means it can only hold a certain amount of information active in its head at once.

So the solution is not to give the agent everything.

The solution is to organize the knowledge.

"The agent should not know everything all the time. It should be able to fetch the right knowledge, the right tool or the right workflow when it needs it."

That is a much better way to think about AI agents.

When you work yourself, you do this automatically.

If you need to find a receipt, you do not open your whole computer in your head. You go to the right folder.

If you are going to edit an image, you do not open all your images. You open the right file in the right program.

If you are going to write a blog post, you do not open everything you have ever written. You find relevant notes, sources and earlier articles.

If you are going to fix code, you do not necessarily read the whole codebase. You find the right file, the right test and the right error message.

The agent has to work the same way.

It has to be able to fetch the right information at the right time.

From chatbot to work system

This is where the term agentic harness comes in.

It sounds technical, but the idea is simple.

An agentic harness is the work system around the agent.

• Which files does it get to see?
• Which systems can it use?
• Which rules must it follow?
• Which tools does it have access to?
• What should it remember?
• What should it check?
• Where are the limits?

Think of an agent as a person walking into an office.

If the office is empty, the person has to guess.

If the office has the right folders, the right programs, clear rules, good checklists and access to the systems the work actually happens in, the person can do a much better job.

The same goes for Claude Code.

It is not enough that the model is smart.

It has to sit at the right desk.

A simple map of the system

Here is how you can read the system:

The point is not that everything has to be advanced.

The point is that the agent has to get a work environment.

MCP: the bridge between agent and systems

MCP stands for Model Context Protocol.

It can sound technical, but the idea is pretty simple.

MCP is a way to connect the AI agent to external systems.

That could be databases, documents, internal tools, GitHub, Slack, file systems, task systems or other services.

A good analogy is USB-C.

USB-C is not the hard drive, the screen, the charger or the camera itself.

It is the connector that lets things be connected together.

MCP works a bit the same way for AI agents.

MCP is not the knowledge itself. It is not the database itself. It is not the tool itself.

It is the connection.

If Claude Code only sees the code files in the project folder, it can help with what it finds there.

But if it can also pull information from other systems through MCP, it can understand more of the reality around the project.

For a developer it could mean the agent can see errors from the CI system, pull information from GitHub, read tasks from a project tool or look things up in internal documentation.

For an ordinary user the same principle could mean the agent can work with folders, notes, documents, spreadsheets, image files or other systems that belong to the project.

The point is not that the agent should have free access to everything.

The point is that it has to be able to use the right sources when the task requires it.

Every time you have to fetch information somewhere else, you have found something Claude Code is missing.

"MCP connects the agent to systems and data sources."

That is the short explanation.

MCP is the bridge.

Skills: abilities on demand

Where MCP is about connections, skills are about abilities.

A skill is a specialized ability the agent can use when a particular type of task comes up.

The Matrix analogy fits pretty well here.

In The Matrix, Neo sits in the chair, gets a plug connected to his neck, and suddenly he knows kung fu.

He has not spent years training the normal way. He gets an ability loaded in when he needs it.

You can think of skills the same way, just in a more down-to-earth version.

A skill can teach the agent how to do a particular type of work.

For example:

• Create a report
• Analyze a codebase
• Format a blog post
• Tidy up a spreadsheet
• Work with a specific file format
• Follow an internal style guide
• Create image prompts
• Summarize research
• Check an article that is ready to publish

The agent does not need to have all skills active all the time.

It needs to be able to fetch the right skill when the task fits.

If MCP is the USB-C cable, skills are ability packs.

MCP says:

"This is how you connect to this system."

Skills say:

"This is how you do this type of work."

That is an important difference.

Imagine you have a personal OS with folders for finances, projects, ideas, images and texts.

MCP can be how the agent gets access to the files.

A skill can be how the agent learns to tidy up the finance folder, create a weekly report, summarize project status or write a blog post in the right style.

One gives access.

The other gives method.

Hooks: automatic checkpoints

Hooks are small automatic checkpoints in the workflow.

They can be used to check, alert, log or stop something before it goes further.

For example, a hook could do this in a code project:

• Run tests after the agent has changed code
• Check formatting
• Stop if the agent tries to delete something dangerous
• Alert if a file is missing
• Remind the agent of a project rule

But hooks make just as much sense outside code.

In a private system, hooks can be small control points:

• Before you send an invoice, check that the amount, date and recipient are there
• Before you publish a blog post, check that the title, intro and sources are included
• Before you change an important file, make a copy
• Before you delete something, stop and ask
• Before you export images, check the right size and file format

Hooks mean the agent does not just work freely and blindly.

They build safety, routine and quality into the system.

What helps is usually not a smarter model, but a better feedback loop.

It is a bit like the railing on a bridge.

The railing does not make the trip for you.

But it stops you from falling off.

Subagents: specialized helpers

Subagents are specialized helpers.

In practice, such a helper can be defined in a small agent file with a role, instructions and an area of use.

Instead of the main agent doing everything itself, it can send a subtask to an agent that is better at that particular type of work.

In code it could be:

• A test agent
• A security agent
• A documentation agent
• A research agent
• A review agent

In a private or creative system it could be:

• A finance agent
• An image agent
• A writing agent
• A structure agent
• A publishing agent
• A planning agent

This is more like how people work in larger projects.

Even if you are one person, you can still divide the work into roles.

You can have one role that writes. One that checks. One that tidies up. One that publishes. One that thinks strategy.

With subagents, the agent system can start to look more like a small team, even if it is just you running it.

Plugins: ready-made extensions

Plugins are more like ready-made extensions.

They can add features, integrations or working methods without everything having to be built from scratch every time.

A plugin can give the agent a new ability or connection.

The important thing is not to mix all the words together.

In short:

Together they give Claude Code a better work environment.

Not just more information.

Better organized information.

Not just more tools.

The right tools in the right place.

Not just more automation.

Safer and more understandable automation.

Where this gets practical in everyday life

Let us take this out of the coding world.

Imagine you have a project called "Courses 2026".

The folder contains:

• old course notes
• images
• PDFs
• client lists
• ideas
• spreadsheets with prices
• presentations
• blog posts
• video scripts
• invoices
• old versions
• export files

If you ask an ordinary chatbot to help you, you have to explain a lot manually.

But if you build a better agent system around the work, the agent can do more.

It can know where the course material is. It can know which style you use. It can know which files are active. It can know which images are approved. It can know which spreadsheet controls prices. It can know which checklist applies before publishing. It can use a skill to create course modules. It can use a hook to check that sources and links are there. It can use a subagent to check the text. It can use a tool to export the right format.

Then the agent does not just answer questions.

It becomes part of the workflow.

A concrete example: spreadsheet

Let us say you have a spreadsheet with finances.

Bad agent use looks like this:

"Look at this spreadsheet and tell me what you think."

That can give an okay answer, but the agent has to guess a lot.

Better agent use is to give it context:

This spreadsheet is used for personal finances. Column A is date. Column B is description. Column C is amount. Column D is category. Everything with the category "business" should be separated out. Everything without a category should be suggested for categorization. Do not change the original file. Create a new report instead.

Then the agent gets both access, knowledge and rules.

It gets even better if this does not have to be explained every time.

Then the knowledge can live in a project file or skill.

The agent does not need to know everything all the time.

It needs to know where to fetch the right instruction.

A concrete example: images

Let us say you have a folder with 800 images for a creative project.

An agent that only sees the files knows little.

It does not know which images are references. It does not know which ones are exported. It does not know which ones are finished. It does not know which ones belong to the same character. It does not know which ones can be used publicly. It does not know which ones are just old tests.

A better system can have a simple explanation file:

This folder contains reference images for the character. originals contains untouched files. exports contains finished versions. archive contains old tests. Do not delete anything without confirmation. Only use images from approved when creating new prompts.

This is not advanced.

But it makes the agent much more useful.

Context is the difference between seeing files and understanding the project.

A concrete example: blog post

Let us say you want Claude Code to help you write blog posts.

Then the agent needs more than the topic.

It should know:

• which structure you use
• how the intro should be
• how simple the text should be
• which words you prefer
• which words you want to avoid
• how sources should be used
• how technical terms should be explained
• which audience the text is for
• how the finished article should be checked

Then you can have a skill called "write blog post".

That skill can say:

Start with a title. Write "In Brief". Use short paragraphs. Explain technical terms with everyday examples. Use code examples only when they actually help. Also use examples from folders, files, images and spreadsheets. End with a glossary and sources.

Then you do not have to explain everything all over again every time.

The agent gets a fixed way of working.

What this means for the future of work

What Daisy Hollman is pointing to is a shift.

We are going from using AI as a chatbot to using AI as a work agent: a kind of digital colleague.

A chatbot just needs a question.

A work agent needs a system.

That is a big difference.

If you ask:

"What is MCP?"

Then a chatbot can answer.

But if you say:

"Go through my project, find what is missing, update the documentation, check that the spreadsheet is correct, suggest next steps and create a report that is ready to publish."

Then the agent needs a lot more.

• It needs to see files.
• It needs to understand rules.
• It needs to use tools.
• It needs to know what is safe.
• It needs to know what is finished.
• It needs to know where to stop.

That is why modern agent work is not just about better models.

It is about better work environments for the models.

The most important misunderstanding

The most common misunderstanding is that more information is always better.

That is not true.

More information can make the agent better.

But only if the information is organized.

If you throw everything into one big prompt, you often get a mess.

But if you put the right knowledge in the right place, you get a system.

• Some of it should live in project instructions.
• Some of it should live in documentation.
• Some of it should live in separate files.
• Some of it should be fetched through tools.
• Some of it should be activated as skills.
• Some of it should be checked with hooks.
• Some of it should be sent to subagents.

This is the whole point:

"The agent should not get everything. It should get the right thing at the right time."

That is how people work.

And that is how good AI agents have to work too.

Give the agent access. Respect the context window. Choose solutions that still work when usage grows.

What you can do right now

You do not need to build an advanced agent system right away.

You can start simple.

Make one project folder.

Add a simple explanation file.

Write:

• What is this project?
• What is the goal?
• Which folders exist?
• Which files are important?
• What is old?
• What is active?
• Which rules apply?
• What should the agent never do without asking?
• How do we know a task is finished?

Just that can make an enormous difference.

For example:

• For a codebase this could be a CLAUDE.md.
• For a private project it could be README.md.
• For an image project it could be project-notes.md.
• For finances it could be rules.md.
• For a blog it could be styleguide.md.

The name is not the most important thing.

The point is that the agent gets a manual for the project.

A simple starting structure

You can think like this:

• Project folder
• README or project explanation
• Working files
• Sources
• Drafts
• Finished files
• Archive

In the README file you can gather:

• goals
• rules
• style
• checklist

This is enough to get started.

Not because the structure is perfect.

But because the agent gets something to orient itself by.

Conclusion

The most important thing in Hollman's point is not that Claude Code can write more code.

It is that AI agents get better when they get a good work environment around them.

A chatbot can answer a question. A work agent has to understand the task, find the right context and use the right tools.

That is why this is less about one smart model, and more about how we organize the work around the model.

When access, knowledge and tools come together, the agent becomes more than a place where you type in questions.

It becomes part of the workflow.

Glossary

Sources and resources