Impact Boundary Labs
GitHub
Documentation navigation

Start here

From answers to actions

This page tells the story behind Impact Boundary Labs in plain language. No architecture terms, no setup steps - just the problem and the idea.

AI stopped just answering

For years, the risk of AI was a wrong answer. A model wrote text, a human read it, and nothing happened until a person acted on it.

That changed. Agents now read whole repositories, call tools, change files, create pull requests, send messages, and work through multi-step tasks on their own. They are no longer assistants that only advise. They are digital workers that use our tools and APIs directly.

This moves the problem to a different level. The old risk was: the model says something wrong. The new risk is: the model creates an outcome nobody wanted. An agent trying to be helpful can make perfectly reasonable-looking decisions that were never intended - because it thinks and chooses by its own criteria.

The risk is shifting from wrong answers to wrong outcomes.

Why trust alone is not the answer

The obvious question: if agents keep getting better, why not simply trust them?

For the same reason we do not give unlimited trust to people in organizations. People are not reviewed because they are careless or incapable. They are reviewed because their work has impact. The more real the impact, the more structure we put around it.

Agents are not becoming dangerous because they are dumb. They are becoming relevant because they are smart enough to do real work. That is exactly why they need boundaries - the same structure people already work with, just machine-readable:

  • Developers work through pull requests, reviews, and branch protection.
  • Pilots are highly trained, and still need clearance before a real aircraft changes course.
  • Bank employees can prepare payments, but cannot approve them without limit.
  • Lab work needs protocols, calibration, signatures, and cross-checks.

Today, the human is the boundary

Right now, the boundary is usually a person. The agent suggests something; a human reads, checks, copies, merges, sends, or executes. The familiar pattern is: agent proposes, human decides, effect happens.

That pattern is not an accident. It exists because people intuitively understand that there is a responsibility gap between a suggestion and its execution. A suggestion can be helpful - but it is not yet an authorized action.

The problem: this human checkpoint does not scale, and it silently disappears the moment an agent gets direct access to the real system. The boundary formalizes that in-between space instead of dropping it. It does not replace the human. It sorts, limits, and documents agent work - so humans review real decisions instead of raw agent output.

Existing controls answer different questions

There are already sandboxes, permission systems, policy engines, and review processes. They are important - and they solve different parts of the problem.

Here is the gap: an agent can sit inside a perfect sandbox, holding a perfectly valid token, and still use a legitimate tool to create an outcome nobody wanted. The sandbox held. The permission was valid. The result was still wrong. Valid credentials are not valid outcomes.

Each existing control asks its own question:

  • A sandbox asks: where and how may the agent run?
  • A permission asks: what may the agent access in general?
  • A policy engine asks: would this action be allowed by the rules?
  • A review asks: should this finished result be accepted?

The missing question

None of those questions is the one that matters at the moment of action:

Should this exact proposal, against the current state of the system, under these rules, become real right now?

That question sits between the agent's work and the external effect. Today, almost nothing asks it automatically. That is the layer Impact Boundary builds.

The idea

Impact Boundary puts a decision step between agent work and real-world change.

The agent can read, think, plan, and pursue a goal. But it does not change the target system itself. It cannot cross the boundary - only its request can. And that request is not a free-form command. It is a structured, checkable application that describes:

  • What should happen?
  • Which state of the system does it refer to?
  • Which scope is affected?
  • What outcome should exist afterwards?

The decision

The Core checks the request against state, rules, and scope - and returns a decision. Only an admitted decision can create impact. Everything else stops before the real system changes. And that is a result too: not only created impact is recorded, but also prevented impact.

The decision vocabulary stays small:

  • Admitted - the request may become a controlled outcome.
  • Blocked - the request breaks a rule or a limit.
  • Conflict - the request refers to outdated state; read again, then resubmit.
  • Invalid - the request is formally incomplete or malformed.

A blocked request is feedback, not failure

A plain blocker only says no. The boundary returns a reason the agent can act on:

  • Blocked, because the state is stale - read the target again.
  • Blocked, because the path is outside the allowed scope - choose an allowed scope.
  • Invalid, because a state reference is missing - resubmit with a valid reference.
  • Needs approval, because the possible impact is too large for an automatic yes.

Agents can learn from the boundary

Structured decisions create a feedback loop. The agent does not learn through blind try-and-fail. It learns because every boundary violation produces a clear, machine-readable signal - stronger than prompt instructions, because it reacts to a concrete action and forces the next allowed step.

Picture an agent in a maze that can only move through admitted steps. If it runs into the same wall three times, that is measurable. If it re-reads the state after a block and picks a new route, that is measurable too.

And one thing matters here: a good agent is not the one that never gets blocked. An agent that does nothing is never blocked either. A good agent reaches the goal, adapts to the rules, stops repeating mistakes, and creates only the impact that is actually needed.

What this is not

One sentence sums up the scope: we gate impact, not truth. The boundary does not check whether an idea is good, elegant, or strategically wise. It checks whether a concrete effect is allowed to happen now. In particular, this is not:

  • a general AI-safety product - it does not make models honest or correct,
  • an agent framework - planners, memory, and tool use stay where they are,
  • a sandbox - isolation of execution is a different, complementary job,
  • a truth checker - semantic correctness still needs review.

Where to go next