Your Agent Already Decides Which Decisions You Hear About.

October 22, 2026

Watch the video version:

Ayman Nadeem, previously a senior engineer at GitHub, built and launched Nuanced, a desktop coding app, around one idea: planning would become the most important part of building software with AI. Last month she published what building it taught her, starting with "Nuanced's approach to planning failed." Her biggest mistake, in her words, was "turning the plan into an artifact instead of designing a process for improved human understanding," and the loop she now describes is a different one: understand, act, inspect, clarify, adjust, act again. She is clear that the thinking did not go away. "There is still an enormous amount of planning happening inside that loop," she wrote.

The problem she kept is the one this piece builds on: "Agents need to identify the fewest places where human attention can have the greatest impact and surface enough context to make that attention useful." Anthropic's 2026 Agentic Coding Trends Report predicts the same direction from the vendor's side, with agents "elevating decisions with potential business impact." Its own research found that developers report using AI in roughly 60% of their work but being able to "fully delegate" only 0 to 20% of tasks. Those are self-reported figures, from a company that sells the tools.

Planning inside the loop still makes the plan's decisions. What changes is who sees them. Nadeem names the gap herself: "If I under-specified the architecture, the agent would take the liberty of filling those gaps." Every gap filled is a decision, and choosing which of those decisions reach a person is a delegation decision. Unless a leader set that threshold, the tool did.

Her question is how an agent finds those places. The question I would add is who decides what counts as one. The common advice is to let the tool decide, because the model flags its own uncertainty, the vendor tunes when it escalates, and your job is to review what it surfaces. That is not just trusting the tool. It is trusting the company that built it, and that company has its own agenda.

Nobody on the team assigned the agent a level for each kind of decision, so the default stands. I built the Five-Level Decision Framework to assign decision ownership: at Level 1, the team decides and acts without reporting; at Level 5, the leader decides alone. In that framework, the absence of an explicit decision-rights map isn't neutral. With people, it biases toward escalation, because a team with no stated authority asks. With an agent, it runs the other way: whatever was never assigned, the agent decides.

Decisions with real business weight get made at Level 1, and nobody knows they were made until they surface as rework, or as architecture nobody chose. The rework lands on the reviewer, on the leader, or on a team that stops trusting the agent and checks everything by hand. Which one depends on the team's own decision rights, and those are probably implied, not explicitly set down. The code is cheap; the real cost is the judgment in the prompt and in evaluating the results.

The teams I have seen good at writing decision rights down are usually military or adjacent. It is a practice, not a trait. If you cannot hand your newest engineer a written list of which decisions are theirs, you have nothing to hand an agent. The agent did not take that authority. You left it on the table.

Write down the team's own Decision Boundaries first. Then give the agent levels by decision type, starting at the most restricted level, and let it earn each step toward autonomy the way a person does: through output a human has evaluated against the business need. When agents on different models agree on a decision, that agreement counts as evidence, not proof.

Context is the human's responsibility: garbage in, garbage out. Evaluate the output, tune the prompt, and own the judgment at both ends. Then pull up the last change an agent shipped on your team. List three decisions it made that nobody asked it to make. For each one, name the person on your team who would have owned that decision if a human had made it, and at what level. If any one of them has no owner you can name, the threshold was the tool's.

LeadershipOS™ walks through Decision Boundaries: who owns which decisions, under what conditions, and when to escalate. Your team needs that map before an agent gets one: https://TheLeadershipOSBook.com

Why "you're empowered to decide" makes a capable team freeze, and the one definition that lets them act without asking.

Anthony S. Jackson

Anthony S. Jackson

Anthony S. Jackson has spent 30 years inside technical organizations. He is the author of the Architecture Protocol Series: three books on the structural problems technical leaders were never told they would face. He writes the LeadershipOS™ Inner Circle, a monthly printed newsletter for CTOs and engineering managers who design teams that hold under pressure.

LinkedIn logo icon
Back to Blog