There's a way most people think about asking a computer to build something: you describe what you want, it hands you a finished thing, and you're done. That's how you'd order from a vending machine. Working with an agent is not that. It's working with a partner — and like any good partnership, the real work happens in the back-and-forth.
We set out to build a small tool that would look at a person's home network, figure out what's connected, and build a custom health check for that person's specific setup. The first version came out quickly. It worked — it found the devices, and it built the check. But when I actually ran it, something was off. A great many of my own devices just showed up as "network device," which is a polite way of saying the tool didn't really know what it was looking at. It had done the job, technically, but it hadn't done it well.
It is very important to understand that working with an agent is a process. Your agent is an extremely capable partner, but it cannot read your mind. You need to learn to explain as clearly as possible and in plain English what it is you want your agent to do. Often, you won't know what's missing until you see the results. It is rare to get everything right on the first iteration — very rare. Working with an agent is like coding with your voice, but without having to use any programming language. However, the rules of logic still apply, and just as with any programming project, you should expect to go through testing and debugging. An agent can only do what a human programmer can do, but it can often do it a lot better and faster. It may seem like magic at times, but it isn't.
The true value of working with an agent is that if you learn how to work with it, it will do the programming for you. Occasionally, you will have a fully formed idea for a project. But more often, "you will know it when you see it" and that is fine. It is what makes working with an agent so dynamic (and frankly speaking — fun). In our example of building this tool, we talked about what was wrong, why it was wrong, and what "right" would actually look like. Together we landed on a plan — identify each device by combining several available clues instead of simply relying upon one. But it took several iterations. After each iteration, my agent (Phrankie) rebuilt the tool and I tested it. Using this process, Phrankie brought me a version that actually recognized my router, my printer, my computers, and my smart-home gadgets. Even then, there were a few devices that could not be easily identified. They were devices that a human analyst would have equally found difficult to identify.
That loop — build, test, find the problem, discuss, improve, rebuild — is the process. It's not a one-shot order; it's iteration. And the reason it works is that there are two of us bringing different strengths to the table. The agent is tireless, fast, and knows how to write code. I bring judgment — I know my own network, I know what "good enough" means for the people I'm building for, and I'm not shy about saying "this isn't right yet." Neither of us could have gotten to the polished result alone.
This is what I want you to take from the whole project. Agentic AI isn't "build me this, slave." It's "let's work together to develop an idea into a working system." You are the one who decides what good looks like. The agent is the one who can turn that judgment into something real, iterate with you, and get it right. When you work with your own agent, expect the back-and-forth. Bring your own standards. And don't settle for "network device" when you know in your gut that it can do better. I am not going to lie. There are times that your agent will "push back" and insist it is doing something correctly when it is obvious (to you) that it isn't. It is easy to get frustrated — don't. Remember that you can cut and paste output, show it to your agent and explain in black and white why you are correct. And, by the way, don't be surprised to find that some of the time, it is you who are missing something.
