Set up your own agentic workspace

A while back I wrote about how my agentic system actually works. That post is the why. This one is the how, plus a file you can download and use today.

The thing people get stuck on is not the idea. It is the blank page. You open the agent in an empty folder and you do not know what to put in front of it. So here is the smallest useful starting point, packaged up.

Download the kit

Download the starter kit (zip)

Inside the zip:

• CLAUDE.md is the file you actually use. It is the wrapper: a two-page description of your project and how the agent should work in it. This is the part that matters.
• README.md is the install guide and a page of hard-won notes.
• .claude/ shows the structure that grows around the wrapper: where slash commands live, an example command template, and a real safety hook that stops the agent from editing your secrets.
• .mcp.json.example shows the shape of connecting an external tool, with no keys in it.

The kit is deliberately generic. It is not my system. My system is six months of corrections layered on top of a file like this one. The point is to hand you the seed, not the tree.

Install it (about ten minutes)

1. Get an IDE with an agent. I use VS Code with Claude Code. Install Claude Code, sign in. Any editor with an agent integration works the same way.
2. Open a folder. A real project, or an empty one for something new.
3. Drop CLAUDE.md into the root. Copy the .claude/ folder too if you want the examples nearby.
4. Edit CLAUDE.md so it describes your actual project: what it is, the stack, the layout, the rules you care about. Keep it to two pages.
5. Point the agent at it. Open the folder in Claude Code and say: “Read CLAUDE.md, then propose a scaffold. Ask me what you need before you build.”
6. Critique what it does for the next half hour. Every correction becomes a new line in CLAUDE.md. That is the whole loop, and it is the only step that compounds.

If you want the agent to reach outside the repo (a database, an automation tool, an analytics product), that is what MCP is for. Copy .mcp.json.example to .mcp.json, fill in the real values, never commit it, and fully restart the IDE so the connection loads. Then run one small test before you build anything real on it.

What will break on day one (this is normal)

I have now watched someone set this up from zero, and the same small things tripped her up that trip everyone up. None of them mean you did it wrong. Knowing they are coming is half the battle.

• The connection is not live until you wire it. The agent cannot reach your external tool just because you mentioned it. You have to create the API key on that service, paste it into .mcp.json, and only then can the agent talk to it. Until you do, every attempt fails, and that failure is expected, not a bug.
• You have to fully restart the IDE. Not just the agent panel, the whole window. Commands and new connections load on startup. Half the “it is not working” moments are fixed by closing everything and opening it again.
• You will hit permission prompts. The agent asks before it edits files or runs commands, which is correct. Once you trust a project, there is a setting to loosen that so you are not clicking “yes” all day. Find it early; it changes how the work feels.
• It hands you homework it could do itself. The agent will tell you to go do a step it has the access to do on its own. The single most useful habit is to push back: “can you do that part yourself?” The honest answer is usually yes. The automation ceiling rises every time you ask.

The mindset that makes all of this bearable: it is a marathon, not a sprint. You are slow at the start because every tiny thing breaks and you have to learn what each break means. Then you are fast, because you have seen the breaks before and you know exactly where to look. The friction at the beginning is not the obstacle. It is the curriculum.

You do not need to read the code

The fear that stops most people is that they are not technical enough. Set it down.

You do not need to understand how the model works inside. You need to read what it produced and judge whether it is right, ask the next question, and point it in a direction. You are the fact-checker, the sanity-checker, the one who holds the context. That is a real job and it is not a coding job.

It is not a black box. It just needs a flashlight, and someone to show you where the switch is. After a week you will be surprised how much of the dark was just unlit.

Why the blank version does not work

You can open the agent in an empty folder and tell it to build. It will. The result looks reasonable and is subtly wrong, because the model has no idea what your work looks like. It is a contractor with no brief.

The wrapper is the brief. When my agent is good at something, the model did not get smarter. The CLAUDE.md got shaped by twenty sessions of getting it wrong. That is the difference between a vanilla agent and a system: the vanilla one guesses every time, the system remembers what you already decided.

A few notes from doing this daily

• Frontload, do not dribble. Give the agent the whole picture in one go. Output quality tracks input quality, and a long brief beats ten tiny prompts.
• Talk to it, do not just type. Spoken input is faster and carries more, and richer input produces better output. A dictation tool plus the agent is a real upgrade over typing.
• Give it positive feedback. When it nails something, say so. It sounds odd, but the same way you would steer a person, telling the agent “that was right, keep doing that” makes the next pass better.
• Push it to do more itself. Agents hand you work they could do. Ask “can you do that part yourself?” more than feels natural. The automation ceiling rises every time.
• You are the sanity checker. You do not need to know how the model works inside. You need to read what it produced and judge it. If you cannot read what it wrote, you do not own what it built.
• Checkpoint before the context fills. Letting it auto-compact silently drops detail. A short summary plus a friction log keeps the thread across sessions.
• Then fix the design, not just the bug. Every few checkpoints, ask whether the same kind of error keeps coming back because the design is wrong. Fixing that is what ends the loop.
• Sync to git constantly. The wrapper is the asset. Losing the folder is losing months.

The honest version of “ship faster with AI” is this: you spend the time you save building the system that lets you trust the speed. Fair trade. Not a free one.

The kit is the first hour of that trade, done for you. The rest is yours.