How my agentic system actually works

A client asked me today how my setup works.

She has a job to automate (bug intake from Sentry, triage with an LLM, ticket creation in Jira, notification in Slack) and she wanted to know how I would build it. We ended up spending an hour on the screen. I realized I was explaining the same thing I get asked about every week.

Here is the written version.

The three pieces

There are three components. None of them are clever on their own. The work is in how they sit next to each other.

An IDE. I use VS Code. Any editor with an agent integration works. The IDE is where files live, where edits happen, where the agent can actually do something instead of just talk about it.
An agent inside the IDE. I use Claude Code. The agent reads and writes files, runs commands, and talks to external systems through tooling. It is not a chatbot. It is a process with hands.
Orchestrators on the other end. N8N, Make, custom code on a server. The agent connects to these and configures them so the long-running automations run without me in the loop.

The pattern is always the same. You sit in the IDE. The agent reads your project, asks questions, edits files, calls APIs, and reports back. When you want something running on its own out in the world, the agent goes and wires it up in the orchestrator.

Why a blank workspace plus AI is not the system

This is the part most people miss when they first try it.

You can open Claude in a browser tab and ask it to build an automation. You can open Claude Code in an empty folder and tell it to scaffold a project. Both work in a small way and break quickly. The reason is that the model has no idea what your work looks like.

Half of what I do every day is improve the wrapper the agent sits inside. A description of how my projects are structured. Rules about what to do before asking me a question. Skills that load in specific situations. Memory that survives across sessions. Hard-coded checks that catch the kinds of mistakes the agent has made before.

When my agent is good at something, it is usually because that wrapper has been shaped by twenty sessions of getting it wrong. The model is the same model. The wrapper is what changed.

If you skip the wrapper and run the agent on raw vibes, you get the result you would get from any contractor working with no context. They will produce something. It will look reasonable. It will be subtly wrong in ways you do not notice until later.

How I actually start a new project

The short version: I drop a single markdown file into the new folder, point the agent at it, and let it scaffold the rest.

The file describes the shape of the project. What is it. What problem is it solving. What does the layout look like. What rules should the agent follow. What does “done” mean for a typical change. It is two pages, not ten.

The agent reads the file, asks the questions it has, and starts building the structure. I spend the next thirty minutes critiquing what it scaffolded. The criticism goes back into the markdown file as new rules. The next session is sharper because the previous session got written down.

After six months of doing this, I have a wrapper that knows my voice, my projects, my tools, my failure modes. The work I do on it compounds. The work I would have done correcting the same mistakes for the twentieth time does not.

The trap

The trap is running the agent on infrastructure you do not understand.

It will produce things. Files appear. Workflows get configured. APIs get called. If you cannot read what it wrote, you do not own what it built. The first time something breaks, you will have nothing to debug from. The audit trail is the wrapper plus the code plus your understanding of both. Remove any of the three and you are renting a result.

The honest version of “use AI to ship faster” is: you will spend the time you save on building the system that lets you trust the speed. That is a fair trade. It is not a free one.

A seed prompt you can paste

If you want to try this today, drop the following into a CLAUDE.md file at the root of an empty folder, then open it in Claude Code and tell the agent to read the file and propose a scaffold. Edit the file as you go. It is supposed to grow.

# Project

What this is: [one sentence]
Why it exists: [one sentence]
What done looks like: [one sentence per milestone]

## Stack

Language: [e.g. TypeScript / Python / Go]
Frameworks: [e.g. Astro, FastAPI, Hono]
Hosting: [e.g. Cloudflare Pages, Railway, Vercel]
External services: [e.g. Stripe, Supabase, Sentry, N8N]

## How I work with the agent

- Before asking me a question, try the obvious thing first.
- After two failed attempts at the same fix, stop and explain what is happening.
- Never run destructive commands without confirming.
- When you make a change, tell me which files changed and why.
- When you finish a task, summarize in one sentence.

## House rules

- No emojis in code or commits.
- No em-dashes in any prose output.
- Match the voice of existing files.
- If a pattern exists in the codebase, reuse it instead of inventing a new one.

That file is the seed. It is intentionally short. You add to it every time the agent does something you did not want, and every time it does something you do want and you want to keep doing.

The system is not the agent. It is what you write down about how you work, so the agent can stop guessing.

If you want more than the seed, I packaged a fuller version with an install guide and the structure that grows around this file. See set up your own agentic workspace for the walkthrough and the download.