The first agent I put into production, I treated like a new hire. Clear brief, checked its first handful of outputs, saw they were clean, and started trusting it. About two weeks in it confidently pushed a config change that broke a downstream job. No error. No flag. It just went quiet and moved to the next task.
That was the day I figured out the advice everyone's repeating right now is only half true.
Ethan Mollick published "The Twilight of the Chatbots" yesterday and told 500,000-plus readers the best way to use agents is to think of yourself as a manager. He's right about the shift. Work moved from chatting with a model to handing tasks to one that runs for weeks on its own. But "think like a manager" quietly smuggles in an assumption: that the moves you'd use on a person carry over. Most of them don't.
Here are the four that broke for me, and what I do now instead.
Move 1: The trust curve runs backwards
With a person, trust compounds. A junior dev earns a code review, then a lighter review, then eventually you stop looking because they've proven it a hundred times. Competence banks.
An agent re-earns trust every single run. Yesterday's clean output tells you almost nothing about today's, because the same prompt against a slightly different input can wander somewhere you didn't test. There's no "proven it a hundred times" that carries forward. You never get to graduate an agent to "I don't need to look."
The mental adjustment that helped: I stopped thinking of review as a phase the agent grows out of and started treating it as a permanent property of the system. I treat it the way I'd treat rate limits or a flaky network, a fixed constraint of the tool rather than a comment on any teammate.
Move 2: Silence is not progress
Managing people, silence usually means things are fine. A good report pings you when they hit something they can't resolve. Absence of a question is a weak signal that the work is on track.
Agents invert this too. Mine sailed straight past the point a human would have stopped to ask, and did it with total confidence. "No error thrown" got read by me as "did the thing correctly," and those are not the same claim. The failure wasn't a crash. It was a plausible-looking wrong answer delivered without hesitation.
So I stopped waiting for the agent to surface problems and started instrumenting the moments where I most wanted a human to look up. A cheap version:
# check-in tripwire, not a full test suite
tripwires:
- when: "files_changed > 5"
action: pause_for_review
- when: "touches: [migrations/, infra/, auth/]"
action: pause_for_review
- when: "external_api_write == true"
action: pause_for_review
None of that is clever. The point is I decide when I look up front, instead of hoping the agent tells me. It won't.
Move 3: You re-scope every task, not once
You onboard a person one time. They absorb how the team works, what "good" looks like here, which shortcuts are fine and which will get someone paged. That context rides along on every future task for free.
An agent carries none of that between tasks unless you build the memory yourself. Each assignment starts closer to cold than you expect. Early on I kept writing terse tickets the way I would for someone who already knew our conventions, and the agent kept filling the gaps with reasonable-sounding guesses that were wrong for us specifically.
Now scoping is per-task until the shared context is actually encoded somewhere durable. More words up front, fewer surprises at the end.
Move 4: Corrections have to be written down, not remembered
This is the one that cost me the most rework. Tell a person "we never do X" once and they adapt. The correction lives in their head from then on.
Tell an agent, watch it fix the thing in that run, then watch it make the identical mistake on the next run. The feedback didn't stick because there was nowhere for it to stick. A correction only survives if it lives in the prompt or a guardrail the next run actually reads:
# AGENTS.md
## Hard rules (read every run)
- Never edit files under generated/. They are build output.
- Config changes to prod/ require an explicit human approval line.
- "Done" means the check passed AND the diff is under review, not just committed.
If a correction isn't in a file the next run loads, you didn't correct anything. You just watched it behave once.
The three moves that make the mindset operational
Mollick handed a huge audience the mindset. The part he left open is the method, so here's the version that's working for me.
First, check-in tripwires, from Move 2. Decide the moments you look before the work starts, not at the end.
Second, treat effort as a management call. Anthropic shipped adjustable effort levels on Sonnet 5 yesterday, and the interesting question isn't the setting, it's which class of task deserves the expensive, careful pass. That's a scoping decision, the same kind you'd make deciding whether a task needs your senior engineer or can go to anyone.
Third, define "done" and "escalate" before you assign, not after. A person can infer both from context. An agent can infer neither. If you can't write down what finished looks like and what should make it stop and come find you, the task isn't ready to hand off.
One thing making all of this easier: tools are starting to ship auditable artifacts, work products with a built-in trail of what the agent actually did. When you can read back the path instead of just the result, managing the thing gets a lot less like guesswork.
And this is about to stop being a specialist skill. Copilot became a permanent SKU baked into M365 tiers as of today, which means whole orgs are getting an agent to manage whether they asked for one or not. "How do you actually manage one of these" is turning into a question everybody has to answer, not just the people who opted in early.
I'll leave you with the one I want to argue about: of these four, which bit you first? Mine was the confident silence, and I still don't fully trust that I've fixed it.
Tags: #AIAgents
Top comments (3)
Great insight. AI agents require system-level management, not people management. Guardrails, clear escalation rules, persistent instructions, and continuous validation are essential for building reliable autonomous workflows.
The confident silence thing hit me too. Spent way too long thinking "no news = all good" with agents. The tripwires pattern is the fix I didn't know I needed — stealing that one🤣
yeah, "no news = all good" is the trap because it feels like trust when it's really just blindness. the tripwires only work if you set them before the first surprise, not after - that's the part that took me a while to internalize.