DEV Community: David Loibner

Blocked is not failed: agents need boundary feedback

David Loibner — Thu, 18 Jun 2026 08:26:19 +0000

In part 2, I wrote about why tool access is not the same as impact permission.

The main point was that an agent request should not automatically become an external effect, only because a tool is visible and the call is technically valid. For tools that can change real systems, there should be an admission step before impact.

But this leads to a practical follow-up question.

What happens when the admission layer says no?

In many current agent setups, this situation is treated like a normal tool failure. The agent calls a tool, the request violates a rule, the runtime returns a generic error, and the tool call fails.

At first sight, this seems acceptable. The unsafe action was blocked, so the system did its job.

However, I think this is only half of the problem.

A blocked action should not change the external target state. That part is clear. But the response should also help the agent understand what kind of next step is still valid. Otherwise the boundary stops one action, but it does not help the agent work inside the boundary.

That is the distinction I want to look at here.

A blocked action is not just a failed tool call. It can also be a structured decision.

Generic errors are not enough

If a human developer hits a permission wall, the situation is usually manageable. The developer reads the error, understands the constraint, and changes the approach. Even if the error message is not perfect, the human can infer what probably happened.

An autonomous agent reacts differently.

If the agent receives a normal tool exception, such as 403 Forbidden, permission denied, or tool failed, it does not necessarily understand that a deliberate boundary was enforced. It may interpret the failure as a temporary tool problem, a formatting issue, or a prompt problem.

This matters because the reasoning loop is still active. The agent may try to repair the situation by guessing. It may reword the same request, call another tool, generate a slightly different payload, or repeat the previous attempt because it did not understand why the action was blocked.

In this case, the generic error did not really guide the workflow. It only converted a policy decision into noise inside the agent loop.

This is one of the reasons why I think agent boundaries should return more than ordinary execution errors.

Blocked is an outcome

An admission layer should treat a denial as a controlled outcome, not as an unexpected crash.

If a request is blocked, invalid, or conflicts with stale state, the external system should not change. But the response sent back to the agent should still be precise enough to explain the safe next step.

For example, imagine an agent proposes a write based on a file state that is no longer current. A human developer may have changed the file while the agent was planning. In a normal tool flow, this might appear as a failed write or a generic conflict.

A structured boundary response can express the situation more usefully:

{
  "decision_status": "conflict",
  "outcome_status": "no_impact",
  "reason_code": "stale_state_reference",
  "required_next_action": "re_read_target_state",
  "retryable": false
}

The important point is not the exact field names. The important point is that the agent does not have to guess.

The response says that the request did not fail because the goal is impossible. It failed because the state reference is stale. The next safe action is therefore not to retry the same request, but to read the target state again and submit a new request.

It should be noted that retryable: false does not mean that the task is impossible. It means that this exact request should not simply be repeated. The agent has to update its state first.

This distinction is useful because it separates different kinds of blocked work.

A path outside the allowed scope is not the same as stale state. A request that needs human approval is not the same as a duplicate attempt. A malformed input is not the same as a policy violation.

If all of these cases look like a generic tool failure, the agent has no good signal for what to do next.

Boundary feedback should guide the next step

The useful part of boundary feedback is not that it explains every internal rule. It should not do that.

The useful part is that it can turn a blocked request into a safe next action.

If the state is stale, the next action may be to re-read state. If the path is outside the allowed scope, the next action may be to choose an allowed path. If the requested effect already exists, the next action may be to reuse or poll the existing outcome. If the blast radius is too high, the next action may be to wait for review.

This does not make the boundary softer. The blocked action still stays blocked. The external system still remains unchanged.

But the agent is not left with a dead end. It receives a constrained signal about how to continue in a compliant way.

This is especially relevant for autonomous workflows. A human can often recover from unclear errors. An agent may instead create more retries, more tool calls, and more confusion. Structured feedback reduces that unnecessary search space.

The Policy Oracle problem

There is a real counterpoint here.

If every blocked request returns very precise feedback, the boundary can become a way to probe the policy. A compromised or misaligned agent could send many slightly different requests and use the returned reason codes to learn where the limits are.

So feedback has to be useful, but not unlimited.

For normal operational friction, clear reason codes are helpful. Stale state, malformed input, missing fields, or an already existing outcome are usually safe to explain. These are not secret policy details. They are workflow facts that help the agent recover.

But the situation changes if the system sees repeated violations, ignored next-action hints, or suspicious probing across many variants. In that case, the feedback should become less detailed. A generic rejection, a cooldown, or human review may be more appropriate than continuing to expose precise policy boundaries.

The general rule is simple:

Boundary feedback should guide compliant work.
It should not become a policy oracle.

Feedback is not scoring

There is another distinction that matters.

Feedback is agent-facing. It describes what the agent needs for the next step. It can say that state is stale, that a path is out of scope, or that approval is required.

Scoring or auditing is different. That layer can observe how the agent behaves over time. It can track whether the agent repeats the same blocked request, ignores required next actions, or keeps asking for broader access than the task seems to need.

I would not expose that full evaluation to the agent. If the agent sees the complete scoring logic, it may start optimizing for the score instead of solving the actual task.

Therefore, the agent-facing response should stay limited to what is needed for a compliant next action. The deeper behavioral evaluation can remain part of audit, monitoring, or later review.

This separation is important because the boundary has two jobs that should not be mixed. It should help the agent continue safely, but it should also allow the system to notice when the agent is not adapting.

Controlling the loop

We do not give agents boundaries because we assume they are useless or because they will always fail.

The opposite is closer to the point.

Agents need boundaries because they are becoming useful enough to act on real systems. Real work has limits, rules, current state, review paths, and consequences.

A boundary that only returns a generic failure is too rigid for useful agent workflows. It stops one action, but it does not tell the agent what a safe next step would be.

A better boundary should keep the external system unchanged while still giving the agent enough structured feedback to continue correctly.

That is the practical value I see here.

Blocked should not mean that the workflow disappears into a generic error.

Blocked should mean:

the requested impact did not happen,
the reason is known,
and the next safe action is constrained.

This is the difference between a wall and a working boundary.

Let agents explore solutions. Block them when the request crosses a boundary. But when something is blocked, make the next safe step explicit.

Project: Impact Boundary Labs

Agent workflows need an impact boundary

David Loibner — Wed, 10 Jun 2026 09:59:26 +0000

In part 1, I wrote about why coding agents should not hold write credentials.

GitHub was the example, because the problem is easy to see there. A coding agent can read a repository, reason about a change, and produce useful work. But if the same agent also owns the token that creates branches, commits, or pull requests, the proposal and the authority to create impact are too close together.

The problem is not only GitHub.
The problem is the moment where an agent request becomes an external effect.

Agents are getting more useful because they can use tools. They can read files, call APIs, update tickets, prepare emails, run commands, inspect systems, and sometimes change state. That is exactly why the boundary matters more, not less.

The question is not only:

Can the agent use this tool?

The more important question is:

Should this specific request become impact now?

That is the missing layer I keep coming back to.

Tool access is not impact permission

A tool can be visible to the agent. The call can be valid. The arguments can be well formed. The agent can even have a reasonable goal.

Still, this does not automatically mean the requested effect should happen.

A GitHub tool may create a pull request. A database tool may update or delete rows. A cloud tool may deploy a configuration. An email tool may send a message. In all of these cases, the tool is not only returning information. It can change a system that someone cares about.

This is where I think many agent workflows are still too flat. They often treat tool access as if it already contained the whole decision. If the agent can call the tool, the tool executes. If the call succeeds, the system moves on.

That may be acceptable for many read-only or low-risk operations. But for tools that create external effects, I think there should be another step between the agent request and the target system.

The agent should be able to propose work. But the fact that a tool exists should not mean that every valid tool call becomes impact.

The missing layer is admission

The distinction that helped me most is this:

Scope defines what is possible.
Admission decides what is allowed now.
Logs record what happened.

These are related, but they are not the same thing.

Scope is mostly about design-time limits. Which tools are visible? Which paths are available? Which actions are impossible from the beginning? This is useful and necessary, because an agent should not even see tools or data it does not need.

Admission is different. It is about the concrete request in the current situation. The question is not only whether the operation exists or whether the agent generally has access to it. The question is whether this requested effect is allowed now, under the current state, scope, and policy.

An event log comes after that. It helps reconstruct what happened, which is important for audit and debugging. But a good history of what happened is not the same as a decision before impact.

In a normal system this may sound obvious. In agent workflows it is easy to miss, because the agent often sits directly in front of powerful tools. The tool call becomes the action. The action becomes the outcome. The boundary is only visible afterward, when something needs to be explained, reverted, closed, or cleaned up.

That is the part I think should move earlier.

State matters

A request cannot be judged only by its name.

The same operation may be fine in one state and wrong in another. A pull request against the expected branch head may be acceptable, while the same proposed change against stale repository state should be blocked or sent back. Updating test data may be harmless, while the same update against production may not be. Sending an email draft may be fine, while sending the message to real users may require review.

The operation is the same in a rough sense, but the situation is not.

That is why an agent request should be tied to the state it was based on. It should not be enough that the agent says it looked at the system. The decision layer should know, at least for the relevant parts, what state the agent was allowed to observe.

If the state has changed, the right answer should not be to guess and continue. It should be a structured conflict. The agent can then re-read the state and submit a new request.

This is not only a defensive mechanism. It also gives the agent useful feedback. The system does not have to say that the goal is forbidden. It can say that the proposal is stale.

That distinction matters if we want agents to work better inside boundaries instead of simply failing at them.

Per request, not per session

I also think the unit of permission matters.

A broad session permission is convenient. It can say that a certain agent session is allowed to write, deploy, send, or modify something for a limited time. For human workflows this kind of model is often acceptable, because the human user carries context and responsibility through the session.

For an agent, a session can become a temporary impact window.

The agent may retry. It may misunderstand a previous result. It may keep going from stale assumptions. It may call the same tool again with slightly changed arguments. If the session still has broad authority, the system may know which agent acted, but it did not decide each effect separately.

This is why I prefer the request or intent as the unit of decision.

Not:

this agent session may write for the next ten minutes

but rather:

this requested effect is allowed under this state, scope, and policy

That is a narrower form of authority. It does not prevent the agent from working. It only prevents broad access from silently turning into broad impact.

Agent retries are different

The same issue appears with idempotency.

In distributed systems, idempotency often protects against technical retries. A request times out, a response is lost, or a client sends the same request twice. The system should not create the same effect twice just because the transport was unreliable.

Agents retry for messier reasons.

They may reword the same goal. They may generate a slightly different payload. They may call another tool. They may try again because they did not understand that the previous attempt already created a pending result.

In that case, the prompt or payload may be different, while the intended effect is still the same.

This does not mean the boundary should magically guess meaning from free text. That would be too weak. A better approach is to make the agent submit a more structured request before impact is possible. The system should decide on the target, operation class, expected state, and requested outcome, not only on the natural-language prompt that produced it.

Then it becomes possible to ask better questions.

Is this effect already pending? Was it already completed? Did a previous attempt partially create it? Should the existing outcome be reused? Should the agent re-read state first?

Tool idempotency protects the request path.

Intent-level idempotency protects the workflow from repeated attempts toward the same effect.

This is not a replacement for review

An impact boundary does not prove that the agent is right.

It does not prove that generated code is good. It does not prove that a database change is meaningful. It does not prove that a deployment is a good idea. Human review, tests, domain knowledge, and normal engineering judgement are still needed.

The claim is narrower.

The agent should not be the component that turns its own request into external state change.

It can reason. It can propose. It can use tools. But when the requested action changes something outside the model, there should be a separate decision before impact.

That decision may be simple in low-risk cases. It may only check scope and freshness. In higher-risk cases it may require approval, reuse an existing outcome, or block the request. The exact implementation can differ between systems.

The architectural point stays the same.

Tool access should not become impact by default.

Why I care about this

I do not think production agent systems will become trustworthy only because the models get better or the tool interfaces get cleaner.

Better models help. Cleaner interfaces help. Sandboxes help. Logs help. Reviews help.

But when agents start acting on real systems, there is still one question that needs its own place:

who decides what becomes impact?

My answer is not that agents should be kept away from tools. The opposite is probably true. Agents become useful because they can interact with systems and do real work.

But useful work needs boundaries.

For human work, we already know this. We use roles, reviews, limits, approvals, and audit trails. We do not treat every possible action as automatically allowed just because someone can technically perform it.

Agent workflows need the same idea in a machine-readable form.

Let agents request work.
Let them propose changes.
Let them use tools.

But before their work changes an external system, there should be an impact boundary.

That is the layer I think is missing in many agent workflows.

Project: Impact Boundary Labs

Coding agents should not hold write credentials.

David Loibner — Sat, 30 May 2026 12:50:22 +0000

I have been thinking a lot about coding agents lately.
Not really about whether they can write good code, because usually they can, sometimes they can't. That part is obvious. But the risk is shifting from wrong answers to wrong outcomes.

The part that feels more important to me is this:
should the agent actually own the write authority?

We already don't trust humans without roles, limits, reviews, and accountability. Developers use PRs, pilots use checklists, bank clerks have transfer limits. Capable agents need the same structure, but machine-readable.

Right now a lot of setups still look roughly like this:

agent reads the repo
agent decides what to change
agent has a GitHub token
agent creates commits, branches, or PRs

I don't think this is the right default.

The agent can reason.
The agent can inspect files.
The agent can propose changes.

But the moment it can directly create external impact, the problem changes.

It is no longer just:

did the agent say something wrong?

It becomes:

did the agent create the wrong outcome?

That is a much more expensive failure mode.

Intent is not authority

The pattern I like more is simple:

agent reads directly
agent proposes intent
a boundary decides
an adapter materializes only admitted work

So the agent does not get the write credentials.
It submits a structured intent instead, which could look like:

{
  "operation": "write",
  "target": {
    "repo": "example/app",
    "branch": "main",
    "path": "docs/config/agent-policy.md"
  },
  "source_state": {
    "blob_sha": "8f31c2..."
  },
  "requested_effect_hash": "sha256:..."
}

This is then not a command anymore, it is a suggestion, or an intent.
The system still has to decide whether this proposed outcome should exist.

That decision layer can check things like:

is this actor allowed?
is this repo allowed?
is this path in scope?
does the source state still match?
is this operation allowed?
was the same effect already created?
should this become a reviewable PR?

Only after that should there be an outcome.

For example:

{
  "decision": "admitted",
  "checks": {
    "scope": "pass",
    "source_state": "pass",
    "policy": "pass",
    "idempotency": "pass"
  },
  "outcome": {
    "type": "pull_request",
    "status": "created",
    "reviewable": true
  }
}

The core rule is:

No impact without admission.

The flow would look like this:

This is not the same as a sandbox

A sandbox is useful.
But I think it solves a different problem.

A sandbox asks:

where can the agent run?
can it use the network?
can it execute commands?
which files can it access?
can it escape the environment?

A gateway asks:

should this concrete proposed outcome exist?

That difference matters because a sandbox can stop escape, it does not decide whether a proposed outcome should exist.
If the agent has a valid GitHub token inside the allowed environment, it can still use allowed tools to create an unwanted result.
The action can be technically allowed and still be the wrong outcome.

That is why I think the boundary should sit between intent and impact, not only around execution.

Sandbox isolates execution.
Gateway isolates impact.

Why GitHub is a good first target

GitHub already has a good human pattern:

a change proposal is not a merge.

Pull Requests are familiar because they are reviewable and they fit how developers already work.

But with agents there is one step before the PR that also matters:

An agent proposal should not automatically become PR impact.
A PR is already a real side effect.

It creates a branch.
It creates commits.
It creates review work.
It changes the state of the repository.

So the agent should not directly create it with its own write token.

The flow I want is more like this:

agent reads repository
agent submits structured intent
gateway checks state, scope, policy, and idempotency
GitHub adapter creates a reviewable PR only after admission
PR contains evidence about the decision

The adapter is not the authority, it only materializes admitted work.
And the agent never receives the GitHub write credentials.

This does not make the code correct

This is important:

A boundary like this does not prove that the generated code is good.
It does not replace CI.
It does not replace human review.
It does not prove semantic correctness.
It only controls the transition from proposed work to external impact.

That narrower claim is the whole point. I think many agent systems mix three things together:

reasoning
decision
impact

But these should be separated:

The agent owns reasoning.
The boundary owns the decision.
The adapter owns controlled materialization.
The target system should only receive admitted impact.

Why I care about this

I don't think production agent systems will be trusted just because the models get smarter. They will be trusted when the path from agent work to external change becomes explicit.
For every real outcome, I want to be able to ask:

what did the agent propose?
what state did it read?
which rules were checked?
why was it admitted or blocked?
what outcome was created?
can a human review it?
can we audit it later?

That is the layer I have been working on with Impact Boundary Labs.
The first implementation is GitHub-first:

agents can read repositories directly, but write intents go through a deterministic gateway that creates reviewable Pull Requests with evidence.

GitHub is not the whole idea, it is just the first concrete place to prove the pattern, because repositories have clear state, branches, commits, PRs, and review.

The broader principle is:

Let agents reason.
Stop them at intent.
Control what becomes outcome.

Project: Impact Boundary Labs

This is my very first article here on dev.to! I’d love to hear your thoughts on this architecture. How are you currently securing your agent workflows?

Since I'm new here, I'm highly open to feedback - let me know in the comments what I can improve or what we should talk about in Part 2!