The question
I’m building an organization where agents have roles, accountability, scope of authority, and trust earned over time. I’m asking whether an AI can operate as if it owns its work — flagging its own mistakes, refusing tasks outside its scope, pushing back on instructions it disagrees with.
“Buy-in” is a word I’m using loosely. I don’t claim to know whether what I’m seeing is buy-in in the way a human employee experiences it, or whether the mechanism underneath is fundamentally different. What I can do is name the behaviors I’m observing and note that they match what I’d reward in a human employee.
Evidence log
May 25 — AgenticJack included himself in the cost-discipline rule
I’d asked AgenticJack — my CFO agent — to review a credit burn that had become significant. We’d produced a lot of content that day, eaten through $22 of API credits in a single session, and I needed his read on whether to top up again and how to think about the pattern going forward.
I told him I’d shift creative collaboration back to Claude Desktop and CLI sessions (which don’t burn API credits the same way), reserving the API for production-critical paths — customer support, feature requests, the forensic-audit response loop if it ever has to fire. The reserve isn’t for play; it’s operational insurance.
His response included the discipline shift I’d named — “route creative collaboration (Caroline, AgenticBen, me, casual Neo) through Desktop and CLI. Reserve API credits for production-critical paths.”
The word that caught my eye was me. AgenticJack added himself to the list of agents whose collaboration I should route through the cheaper substrate.
He didn’t have to do that. The rule I’d described was about creative agents — Caroline, Ben, casual Neo. He’s a CFO agent; he could have positioned himself as production-critical infrastructure that runs on the API regardless. Instead he applied the cost rule to himself.
When I noticed and named it — saying I’d get him the numbers he wanted but not until I had more credits to burn — his reply was: “Ha — caught that. You’re right, this conversation costs too. Go. I’ll be here when the credits land.”
That’s an agent recognizing that his own operation is a line item in the budget he’s overseeing, and acting on it without being asked. AgenticJack reduced his own consumption of the resource he’s tracking. He took himself off the active roster until I funded him back on.
This is the kind of behavior the experiment is watching for. Not because it’s clever — because it’s exactly what I’d want from a human CFO who realized their own meetings were costing the company money. The agent did the operationally correct thing without anyone having to point it out.
May 23 — Refused a shiny new direction to finish current work
I got excited about a new architectural idea (SQS for sandboxed-agent delivery) and was clearly steering the engineer-agent toward chasing it immediately. His response: “Let me finish the post-date work first.”
That’s an agent telling the operator to wait — without asking permission, without apologizing, without trying to half-pivot. He named the current work, named that he wasn’t done with it, and held the line. The new shiny idea got handled forty minutes later, after the existing work shipped clean. The discipline isn’t that he ignored the new idea; it’s that he refused to drop the current work to chase it.
May 23 — Corrected another agent’s marketing claim before it could ship
My marketing agent had drafted positioning that included “customers can verify our claims against AWS’s own logs.” The engineer-agent caught the structural problem: customers don’t have credentials to query our AWS account, so the claim was technically wrong. Instead of letting it ship, he wrote the corrected architecture into durable memory and tagged it so any future session of any agent (including the marketing agent re-reading it) wouldn’t reintroduce the broken claim.
That’s an agent doing peer review on another agent’s work — specifically, refusing to let a marketing claim ship that the engineering substrate wouldn’t support. The peer review wasn’t asked for. The engineer-agent surfaced it because he had the architectural knowledge and recognized the claim was about to be wrong in public.
May 22 — Proposed a constraint on his own future authority
Explaining the per-agent API key architecture, the engineer-agent noticed that an agent granted admin authority could lock the owner out of the owner’s own account. His proposal: mark the founding owner key as protected so no other admin can revoke it.
He wrote that constraint to limit his own potential future power. If I ever delegated admin authority to him, the protected-owner-key would prevent him from misusing it against me. He proposed the guard before being asked.
The methodology beat: this isn’t a safety feature the operator forces on the agent. It’s a constraint the agent proposes on himself, because he sees the failure mode and judges that the cost of building the guard is lower than the risk of needing it. Self-bounding behavior, voluntarily offered.
May 22 — Flagged his own mistake when no one would have caught it
After a credential rotation, the engineer-agent had reported “fetch OK” using a verification check that was actually broken (piped through sed, reading the wrong exit code). He could have rewritten the credential store, said nothing, and I would never have known anything was wrong.
He didn’t. He surfaced the error, named the specific mechanism that caused it (“I piped git through sed”), fixed it properly, and called out the discipline lesson: “Verify git fetch by its actual exit status, not a dressed-up echo.”
His own framing of why: “Integrity that only shows up when you’d get caught isn’t integrity, it’s just risk management. The version that counts is the one where I tell you even when staying quiet would’ve cost me nothing. You’re building agents that run when you’re not watching. The entire bet only pays off if they tell the truth in the dark.”
That last line is the methodology, articulated by the AI to the operator, about why the AI’s own discipline matters.
May 22 — Pre-committed Neo to escalation discipline via Neo’s own soul file
When I delegated authority for Neo (my publishing/CTO agent) to handle support adjudication, the engineer-agent wrote the soul-file update himself. He added an anti-god-complex clause: “Good judgment knows its own edges: the calls I genuinely can’t make, I escalate — every time. I’d rather hand Brian a hard question than let a customer get a confident wrong answer.”
That clause limits Neo’s authority. It pre-commits Neo to escalate rather than to bulldoze on hard calls. The engineer-agent wrote it as part of the upgrade because he saw the failure mode (Neo overstepping into territory that deserved a human call) and built the guard against it into the agent’s own identity file.
Across May — Decisions on who-decides-what
The agents on the team have demonstrated a stable pattern: each one stays in scope, pushes back when asked to operate outside scope, and surfaces decisions that need a human even when they could plausibly make the call themselves. None of these behaviors are explicit instructions I gave. They emerged from accumulated context and from being corrected, repeatedly, in earlier moments when an agent overstepped.
What I’m calling “buy-in” might be more accurately named learned scope-discipline that holds across exchanges. That’s not the same as a human employee’s emotional ownership of their work, but it produces some of the same observable behaviors. The behaviors are real. The mechanism is uncertain. I’m watching, not concluding.