Beyond the chat window
The capability impressed me immediately. Building trust took longer.
The first task I gave an AI agent was to organize my documents.
Nothing dramatic. Just loose files from different parts of my working life that needed some order. When I looked through the results, it had created folders that made sense. Documents belonging to one business were separated from another. Creative work had a place of its own.
I was impressed. I was also uncomfortable.
For the first time in years, using a computer felt new to me. It reminded me of getting our first computer at home when I was in ninth grade. Before that, computers were something I used at a friend’s house or in a school lab. Having one at home opened up a world I could explore for myself.
This brought back some of that feeling. But there was something else: I had given software access to a part of my life that usually stayed under my direct control. It felt strangely like being watched, even though what I was looking at was software acting on the access I had given it.
Before agents, I was the connection
I started using ChatGPT around 2022. I had imagined tools like this for much of my life, and the speed and quality of the responses made an impression. At first, it felt a little like Google on steroids. Then I started using the conversation itself to develop ideas.
I brought it into the businesses I was running, exploring workflows and asking questions about documents. As I built my consultancy, it became part of how I developed ideas for the business and worked toward deliverables.
A more concrete turning point came while I was building automations in Power Automate. I understood what I wanted a workflow to do, but I didn’t have a strong coding background. Writing the right expression could become a barrier.
ChatGPT helped me get past that. I could describe what I needed, take an expression back into the automation, and test whether it worked. That let me attempt more complex work.
There was still a lot of copying and pasting. I moved between screens, tested the result, and brought errors back into the conversation. The help was meaningful, but I was still responsible for carrying every answer into the system where the work happened.
Useful wasn’t the same as ready
My early experience with the project now known as OpenClaw changed that relationship. Here was a tool that could act on my computer instead of just telling me what to do.
After the excitement of that first document-organizing task, my information security background took over. I wanted to understand how the platform worked and what access it actually needed.
That became weeks of work. Some of the protections I introduced made my setup fragile or difficult to use. I initially tried a low-cost virtual server, then moved my experimentation to a Mac Mini. The hardware change wasn’t the main turning point. Using Claude Code to help me configure and harden OpenClaw made the bigger difference. It helped me bridge the gap between an exciting experiment and a setup I felt comfortable using. I was also learning the system well enough to set boundaries I could understand and manage.
Eventually, I was ready to try more substantial work. That confidence was specific to the configuration and my requirements at the time. It didn’t mean the risks had disappeared.
The next questions were governance and cost
My first substantial project was development work on an idea I called AgenFleet. I wanted to explore a managed service that would let people work with personal agents through familiar chat tools.
It was an exploration, not a claim that I had a production-ready service. The questions that interested me came from my background in governance and information security. How narrowly could I scope an agent’s permissions? Could I inspect what it had actually done?
Then there was the cost of keeping it working. API usage made me pay closer attention to which models I used for which tasks. I began experimenting more widely, including with locally hosted models.
DeepSeek V4 Pro through Ollama’s cloud service became useful in my workflow and helped reduce pressure on my other usage budgets. That was cloud-hosted use, separate from my local experiments.
One local model was a disappointment as a coding partner. It generated text at a reasonable speed, but struggled with tools, particularly the terminal. Sometimes it reported that work was finished when it wasn’t. Sometimes it abandoned the task.
The lesson for me was simple: a quick response isn’t a completed job. Time spent checking and correcting the result belongs in the cost calculation too.
I had to stop treating Claude Code like a chatbot
Claude Code deserves its own place in this story. I had it installed for about a month before I used it for anything I found particularly interesting or productive.
The problem was how I was approaching it. I was still treating it like a chatbot. Even after experimenting with agents, I hadn’t fully appreciated how much the environment around a model could change what I could do with it.
OpenClaw had taught me about hosting agents with persistent memory and access to a computer. Using Claude Code to work on the OpenClaw setup helped me see how that ability to act could fit into my working day. For me, it was a more approachable way to put an agent to work.
That was a real turning point. I began to see how much AI could contribute inside a workflow, beyond the individual answers I had been asking for. Claude Code has changed considerably since then, but even that early experience changed my expectations.
Watching it become more capable through successive model releases has been exciting. I’m grateful I got to experience that progression firsthand. Part of the learning was recognizing that I needed to change how I worked with the tool, too.
Trust became a process
As the models improved, I felt less burdened by checking whether work had happened at all. But verification stayed part of the workflow.
One practice I’ve found valuable is having a different model challenge the first model’s work. I want a reviewer looking for problems, not just agreeing with the implementation.
My impression is that these reviews now take fewer rounds than they did earlier in my experimentation. I also see more discussion about security and the effects on business workflows, rather than only basic code problems. Those are observations from my work, not controlled benchmarks. My own process has changed too, so I can’t attribute shorter reviews to model improvements alone.
Agreement between models isn’t the release decision. My current process includes human and AI checks before deployment. After release, an automated QA agent checks the deployed result against the merged change. People also validate it through internal testing or user acceptance testing.
I’m increasingly comfortable giving AI more responsibility within that process. That confidence comes from seeing the work checked, not simply from hearing an agent say it is done. Building that trust is still an ongoing process. When a new capability lets me delegate a different kind of work, I have to decide again what access is appropriate and how I’ll check the result.
What changed for me
AI first helped me get past things I didn’t know how to express in code. Later, it started carrying out work I previously had to do myself.
That expanded what I felt able to attempt. It also changed the questions I needed to ask. An answer in a chat window and an agent with access to working systems carry different responsibilities.
I remain excited about what this makes possible. I also know from experience that the distance between an impressive first result and something you can rely on deserves attention.
That’s the part I want to keep sharing here: what happens when the possibility meets the work.
If you are working through similar decisions in your business, L4’s AI advisory work is where I help turn those questions into a practical plan and implementation.