Agents are not mostly a reasoning problem.
They are a permission problem.
A lot of the public conversation still treats agents as smarter chatbots with tools.
Can the model plan well enough. Can it call tools reliably. Can it hold context. Can it recover from a bad intermediate step.
Those questions matter.
They are just not the first ones that decide whether an agent is safe or useful in real work.
The real question is simpler and more operational:
What is this thing allowed to do without asking?
That is the boundary that turns a neat demo into a production tool, or into an incident with better UX.
The wrong mental model is "smarter model, better agent"
People keep trying to improve agents by starting at the model layer.
More context. Better reasoning. Better prompts. Better planning. Better memory.
Some of that helps.
But once a system can take actions, the limiting factor stops being whether it can produce plausible next steps. The limiting factor becomes whether those steps are bounded, reviewable, reversible, and appropriate for the level of trust you gave it.
A read-only agent that searches docs, summarizes diffs, and drafts a plan is one product.
A write-capable agent that edits code, opens pull requests, changes Terraform, or merges a migration is a completely different product.
Same model, different permissions.
That difference matters more than most benchmark deltas ever will.
The moment an agent can act, you are no longer designing a prompt. You are designing a permission system.
Capability is not the same as authorization
This is where a lot of teams get sloppy.
They ask whether the agent can do the task.
They do not ask whether the agent should be allowed to do the task unattended.
Those are not the same question.
A model may be capable of generating a schema migration.
That does not mean it should be allowed to apply one.
It may be capable of diagnosing a flaky deploy.
That does not mean it should be allowed to restart things until the graphs look better.
It may be capable of answering a customer question.
That does not mean it should be allowed to issue a refund, modify an account, or promise a behavior your product does not actually guarantee.
We already understand this distinction everywhere else.
A junior engineer may be capable of editing production configuration. That does not mean they have the right level of access to do it alone on a Friday night.
A script may be capable of deleting data. That does not mean you wire it to a button with no confirmation and no audit trail.
Agents deserve the same seriousness.
Most agent failures are authority failures wearing a reasoning costume
When an agent goes wrong, people love to say the model hallucinated.
Sometimes it did.
But a lot of the expensive failures are not fundamentally "the model reasoned badly." They are "we let a probabilistic system take an action whose blast radius did not match our confidence."
That is an authority design failure.
If an agent can read twenty files and propose a refactor, a wrong guess is cheap. You reject it.
If an agent can push directly to the default branch, the exact same wrong guess is suddenly expensive.
If an agent can collect context, draft a migration plan, and ask for approval, that is a manageable workflow.
If the same agent can run the migration because "it passed tests," you quietly moved from assistance to delegated operational authority.
The intelligence may not have changed at all.
The risk absolutely did.
The practical split is read, propose, act
Senior ICs need a simple frame here.
Do not evaluate agents as one category.
Evaluate them by the level of authority they hold.
1. Read
The agent can inspect state.
It can search code, read docs, summarize logs, collect evidence, compare options, and explain what it found.
This is the safest class, and it is already useful.
The main risks are privacy, data exposure, and false confidence in the summary. Those matter, but the side-effect profile is still low.
2. Propose
The agent can prepare changes but not commit them alone.
It can draft code, open a pull request, assemble an incident summary, prepare a migration plan, generate a runbook patch, or line up a sequence of tool calls for approval.
This is where a lot of real leverage lives.
The system is not passive anymore, but it still has a human gate at the moment that matters.
3. Act
The agent can take side effects in a live environment.
It can merge, deploy, restart, modify records, send messages, change configs, or spend money.
This is the class where most teams stop talking clearly.
They still describe the system as an "assistant" even though it now holds authority that used to belong to an operator.
That is the wrong label. Call it what it is.
If it can act, it is part of your operational control plane.
Operator guidance starts with authority budgets
The practical question is not "should we use agents."
It is "how much authority does this workflow justify."
That answer should be proportional to two things:
- how expensive a wrong action is
- how easy it is to detect and reverse the mistake
That gives you a usable rule set.
Low-cost, easy-to-reverse workflows can tolerate more automation.
High-cost, hard-to-reverse workflows need tighter bounds, more approvals, and better evidence before action.
This sounds obvious. Teams still skip it because demos flatten the distinction.
A beautiful demo makes read, propose, and act feel like one continuous product.
Operationally they are not.
The design questions that matter are boring and decisive
If you are the senior IC in the room, these are the questions that matter more than whether the model got 7% better on a benchmark.
What can it do without asking?
Be explicit.
Not "it helps with deployments."
Which exact actions. In which environments. Under which preconditions. With what rate limits. Against which resources.
If you cannot write that down, you do not understand the agent yet.
What evidence must it show before action?
"Trust me" is not a production interface.
Before an agent changes something, it should be able to show the inputs, the relevant context, the intended action, and the expected result in a form a human can inspect quickly.
If the evidence is too noisy to review, the agent is not ready for authority.
What requires human approval?
Approval should be tied to blast radius, not vibes.
Editing a docs file and rotating a production secret should not live behind the same gate.
Neither should opening a draft pull request and sending a customer-facing message.
What is the undo path?
Every meaningful side effect needs a recovery story.
Rollback. Revert. Idempotent retry. Dry run. Staging lane. Limited scope.
If the answer is "we would notice and fix it," that is not an undo path. That is hope with extra steps.
What gets logged?
Audit trails are not compliance garnish.
They are how you debug authority.
When the agent took an action, what did it see, what tool did it call, what arguments did it send, what came back, and who approved it if approval was required.
Without that, you are not operating an agent. You are sponsoring a mystery.
Good agent design looks conservative in exactly the right places
A mature agent system usually looks more constrained than the marketing version.
That is a good sign.
The useful patterns are not glamorous:
- read far more than you write
- propose more than you execute
- require structured plans before high-impact actions
- narrow tool interfaces instead of exposing raw power
- make side effects idempotent where possible
- keep risky actions small, staged, and attributable
This is the same reason good production systems often look less magical than the demo. Real operators optimize for damage containment, not applause.
Why this is broader than a systems problem
It is easy to hear "authority" and reduce this to infrastructure.
That is too narrow.
Authority shows up anywhere an agent crosses from suggestion to consequence.
In product:
- can it message a customer
- can it change a recommendation
- can it trigger a refund
In internal tooling:
- can it mutate a ticket
- can it approve a change
- can it close an incident
In engineering:
- can it merge code
- can it run a migration
- can it alter production configuration
In every case, the same truth holds.
The hard part is not getting a plausible answer.
The hard part is deciding what level of consequence a plausible answer is allowed to carry.
The reframe
The useful question for an agent is not:
"How smart is it?"
The more useful question is:
"What authority can it safely hold?"
That shift sounds smaller than it is.
It moves the conversation away from model theater and toward operational design. It forces teams to think in scopes, approval boundaries, proof, blast radius, and recovery. It makes the real engineering work visible again.
Because once an agent can take action, intelligence is only half the system.
The rest is governance disguised as product design.
The one-line version
The hard part of agents is not getting them to sound capable. It is deciding what they are allowed to do, what they must prove before doing it, and how you recover when they are wrong.