When I was young I sold furniture. I didn't know anything about fabric, and I didn't care how many springs were in a cushion. I took the job because it forced me out of my comfort zone to learn a skill that would transfer with me.
What the floor taught me was that nobody walks in for a chair. They walk in because something changed. A new house. A room that finally needs to work. A back that won't take the old couch anymore. A chair is not the outcome. The outcome they were after included the chair. Once I learned to ask why they were there, selling the chair was the easy part.
I didn't know it then, but that was one of the most useful engineering lessons I've learned.
The promotion nobody announced
You've read about the superstar engineer who got promoted to manager and struggled. Brilliant with code, lost with people. We've all heard the stories, read the books written on the topic, and maybe even worked for this person. That used to happen to a few engineers.
Now it happens to every engineer the first time they hand work to an agent.
I'm an engineer, and I say this with love: we think in binary. It works or it doesn't. When it doesn't, something is broken, so we find the broken part and blame it. That instinct is a big part of why we're good with code, and it's the instinct that fails us with agents. Scroll your feed and you'll see it every day. Someone posts a bad output and the verdict is that the AI is bad.
Nobody blames JavaScript when the website looks wrong. They open the code and fix it. An agent deserves the same, except the fix looks a lot more like management.
Where the bug lives
Agents tend to be very literal. Where you told them exactly what you wanted, they do it, much like code. Where you didn't, they fill the gap the way a new hire would, with their best guess. Most bad output lives in those gaps.
So when one of my agents gets something wrong, I start where I would with a person. I don't start with the code it wrote. I look at what it believed when it did the work. What did it think the job was? What did it think good looked like?
That answer tells me where to go next:
- It keeps doing the wrong kind of thing, on every job. That's the role. I rewrite what the agent is for and how it should behave.
- It knows the rules and loses them as the work piles up. That's the environment. I change what reaches it and when, so the important rules arrive every time instead of once at the start.
- The same task keeps coming out wrong. That's the method. Recurring work belongs in a written skill, so it's done the same way every time.
- This one job came out wrong. That's the assignment. The ticket or the prompt didn't carry the outcome.
Role, environment, method, assignment. A manager will recognize every one of those, because it's the same list you'd work through with a person.
Too much, too little
Most of my own misses came down to giving an agent too much or too little.
Too little, and it doesn't understand the outcome, so what you get depends on how it interpreted the ask. Too much, and it becomes a jack of all trades: pretty good at a lot, great at none of it, leaving you with a lot of little cleanup items.
That second one surprises people, because more context feels safer. It isn't. Anthropic's own engineering guidance says accuracy drops as an agent's context fills up, and that the goal is "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome."
So I build agents the way I'd build a team. If I want a great developer, it gets the developer's context, the practices that define good work, and the tools a developer needs. A tester gets a tester's. An architect gets an architect's. Each one knows its job and only its job, and it does better work because of it. Specialists beat generalists, with agents just like with people.
Won't the models just figure it out?
The models will keep getting better, and agents will work toward an outcome more on their own, with less hand holding. That's good.
What doesn't move is the outcome itself. Why the work matters, what done looks like, and who it's for live with the person asking. They aren't in any data the agent can see. The better the agent gets at the work, the more of your job becomes describing the outcome.
Which is the job I learned on a furniture floor.
If your team is getting bad results from AI and you'd like a second set of eyes on how the work is being handed off, I'm glad to take a look.
When your agent gets it wrong, where do you look first?