Workflow and agentic loop

I've developed a repeating process. From the moment I tell Claude what I want, to the moment it's done and verified. It's not chaos. It's a sequence of steps I know work.

It starts with research. I tell Claude what I want. He looks first to see if something similar already exists. He checks existing solutions, libraries, approaches. Then he creates a plan—a real plan, not just intuition. Then he starts building. He keeps verifying it works. When it's done, I test it myself.

One thing matters: Claude's brain doesn't keep anything after a conversation ends. That's how it works. But he writes down insights, decisions, and results himself. In each new conversation, he reads those notes and picks up where we left off. That's what I call the agentic loop. Claude reads his own notes and adjusts how he works.

Planning

Before building anything, thinking comes first. I ask Claude to work out a plan. I don't want him to just start writing. I want to know the steps, what could go wrong, what the options are.

The plan says: do this first, then that, then test and verify. I see all the weak points ahead. When I see Claude's plan, I can tell him: no, not that step, try this instead. Or: this is critical, focus more on it. Plan-first means prep takes longer, but then it goes faster and fewer things break.

Agent teams

When the work is bigger, I'm not alone with one Claude. I ask him to hire a team. It's like a project: one person doesn't do everything. You have someone watching code, someone testing, someone writing docs.

Each team member gets their piece. One handles structure, one handles content, one handles security. They work side by side. One then reviews the other's work and says: I see a problem here. That's useful. When two agents disagree, one finds a bug. Teams speed things up. Details one agent might miss, a team catches.

I use them mainly for bigger things. Auditing web content, testing security, building several modules at once. Small things don't need a team, but when it goes somewhere with more options or more risks, I say: please, five of you on it.

Context and memory

Claude has one big weakness: he forgets the past. A conversation ends and everything is gone. Like someone with amnesia. After each conversation, memory is wiped. That would be catastrophic if I didn't handle it.

So I keep a notebook next to him. A real notebook. I write what we did, what worked, what didn't, what decisions we made. They're simple text records, nothing fancy. When I start a new conversation with Claude, he reads the notebook and knows where we left off. It's not hallucination or guessing. It's concrete writing: on day X we did Y. The result was Z.

I keep two notebooks. One is Notion—fast, available everywhere. I write important decisions and project status there. The other is Obsidian—deeper. There live session notes, research findings, an archive of what works. Those are notes on my computer, linked and searchable. When I ask Claude: how much does that hosting cost?, he finds the answer in Obsidian himself. I don't have to ask him anything.

At the start of each conversation, Claude's team reads everything important. All instructions, all old findings. On Windows I built a special script I call session-bootstrap. A special routine that runs at the start and says: here's your memory. Here's where we were. Here's your team. Here's what you need to do. Since I started using it, everything is simpler. Nothing gets lost.

My rules

When something works, or when something breaks, you learn. I learned a few things the hard way. Now I've fixed them as rules. I tell them to Claude and he watches for them.

Rule one: always one change at a time. Don't do three things in one commit. Do one, test it, then the next. When something breaks, you know where. If you did everything at once and it collapsed, you're throwing dice. You don't know the cause.

Rule two: never push the button without backup. Before I change something important, I make a copy. Takes ten seconds. If it breaks, I have something to go back to. It's basic, but it really helps. I wrote a script that automates it.

Rule three: never claim something works if you haven't tested it. Don't say: it's fine. Test it. Click on it. Run it. Check if it does what it should. I do things through Claude Code—that's an app on my computer, a text window where I write to Claude. His code runs on my machine, and I see what happens. So I always see if it works or breaks.

Rule four: find the root problem, not the symptom. Someone tells me: this is slow. I don't say: let's try speeding it up here and here. I ask: what's making it slow? Is it CSS animation? Is it the database? Is it the network? I find it first. Then I fix it. Without that, I'd just guess blindly and go nowhere.

Rule five: verify concretely, not by feel. I don't say: it looks good in the browser. I open Chrome Developer Tools. I look at the numbers. I test on my phone. I measure FPS. A concrete number is always better than a feeling.

These rules are detailed in Watch Out For. They're there because they really help me. You can teach them to Claude too.

Verification and debugging

When something's done, I don't trust it right away. I test it. All the parts. Starts, ends, error messages. How it behaves when something breaks. How it behaves with bad input. How it behaves when I try to break it.

Debugging is finding what broke. I have steps for it. First I see where it smells. Then I make a guess: I think it's here. Then I test it. Often I'm wrong, so I change my guess and try again. That's better than blindly guessing and just fixing symptoms.

Claude's team does this too. When they write code, they test it right away. Not just: no syntax errors. But: does it really do what it should? Does it really play well with the rest of the code? When they test and find a bug, they tell me. Then we fix it together. Example: I had a web project I was building through agents. For a while it kept changing. Then I asked: wait, what does it really look like? I opened Chrome DevTools and measured performance. FPS was around 11. Why? I looked under the hood. I found animations that kept redrawing. I deleted the animation and performance went back to 26 FPS. Without measuring, I wouldn't have seen it.

How I find news

Things change fast in this field. For a month nothing changes, then suddenly there are five new things. So I need to know what's happening. I don't want to work with a three-month-old model and think it's new.

I have ways. First: I read articles and research papers. I have a command I call deep-research. I say: find me articles about how agents solve problem X. Claude's team finds them, reads them, makes a summary. It saves me hours of reading.

Second: YouTube. A lot happens there. People play with new models before others know about them. I find their videos and often have them transcribed so Claude's team can analyze them. I use NotebookLM for it—a Google tool that takes a video or article and says what's most important.

Third: I follow creators. Faborský, Oborník and others. They're always a step ahead. When I see what they do, I see where everything moves. I don't do it to be influenced. I do it to know what's happening.

Fourth: Claude's team watches for changes too. When Anthropic changes something in the model, I see it. When something big changes in how agents work, Claude's team alerts me. That's faster than waiting for an article about it. It's like having a personal research assistant sitting next to you telling you what's happening.

This process isn't final. It evolves. I changed it several times this year. But the basics—plan, team, memory, rules, verification—those stay. It's not a technique I borrowed from someone. It's something I tailored to myself and what works for me.