Impact Boundary Labs

Core docs

Impact Boundary overview

Impact Boundary is a control layer between an agent's intent and a real external effect. An agent can decide what it wants to do, but it should not write directly into the target system. Instead, it submits a structured intent. The system checks the current state, evaluates policy, validates the decision path inside Core, and only then exposes admitted work to an adapter that can perform the target-specific change.

Impact Boundary Labs builds around a simple distinction that is easy to miss when people talk about agents in abstract terms. Reading context and writing impact are not the same operation. An agent may need broad context to reason well. A write, however, changes a repository, a ticket, a room, an account, a cloud resource, or some other external system that has consequences outside the model. Those two paths should not be treated as equivalent.

Docs homeCore docs
Back to Core docs

The problem in plain terms

Agents are increasingly connected to tools that can perform real actions. That connection is useful, but it also makes the action path harder to reason about. If a model decides to open a pull request, update a ticket, move a user between rooms, or change a cloud resource, several questions immediately matter:

  • What exactly did the agent ask to do?
  • What was the current state when that request was evaluated?
  • Which policy allowed it?
  • Was the request formally admitted before any worker touched the target?
  • What was actually materialized in the external system?
  • What result came back afterward?

Without a boundary, those questions can collapse into one vague idea of "the agent did something." That is too weak for systems that need to inspect, constrain, or reason about external impact.

The core distinction

Impact Boundary treats the write path as a separate discipline. The model or client can still read context directly in whatever way the surrounding product allows. But writes go through a narrower path:

  • the agent submits intent;
  • the system checks target state;
  • policy evaluates whether the request should proceed;
  • Core validates the decision path;
  • only admitted work becomes available to an adapter;
  • the adapter materializes the effect;
  • the adapter reports an outcome.

That sequence matters because it makes external impact explicit. It also means that a successful tool call, a policy response, and a final effect are not all treated as the same thing.

The product idea

At a product level, Impact Boundary is not trying to be an agent framework. It does not replace the model layer, the orchestration layer, or the target-specific worker. It focuses on one problem: controlling the path from intent to external impact.

The public v0.1.0 bundle shows this with two concrete pieces:

  • Impact Boundary Core v0.1, compiled into the runtime bundle
  • an Adapter Host that exposes HTTP routes, talks to external state and policy connectors, and hands admitted work to adapter workers

The important design move is that the host does not materialize external impact directly from a submitted intent. It coordinates the path. It asks for state. It asks policy for a candidate decision. It relies on Core to validate the decision path. Only after that can work exist for an adapter.

What the boundary checks

The boundary is easier to understand if you think in terms of checkpoints rather than brand names.

Current state

Before deciding whether a write should exist, the system checks the current state of the target. That state may be a governed summary, a limited view, or another bounded representation, but it is still a system-side check. This is stronger than relying on "the agent already looked at it" because the state read is part of the decision path.

Policy

Policy evaluates the request against the state and context. In this model, policy returns a candidate decision. That detail matters. Policy does not directly equal impact. A policy result still has to fit the contract enforced by Core.

Core validation

Core validates the decision path. It checks that the state and policy output fit the expected shape and consistency rules. It validates the decision envelope and the combination of status, reason, and next action. The point is not to claim that Core proves semantic correctness in the target system. The point is that Core is the gate before admitted work exists.

Admitted work

If the decision path is admitted, the runtime can create work for an adapter. That work is a bounded handoff object, not a raw client request and not a free-form tool call. This is where the boundary turns an allowed request into something a target-specific worker can claim.

Adapter outcome

After a worker claims admitted work and performs the target-specific action, it reports an outcome. The outcome is the system's way to say what actually happened after materialization. That keeps the effect visible as something separate from the original request.

Mental model

Read directly. Write through the boundary.

That is the shortest useful way to understand the project. Reading may be broad and product-specific. Writing should be explicit, bounded, and inspected through a decision path before it reaches a target adapter.

Where this applies

This pattern is relevant anywhere agents are connected to systems that matter operationally. Typical examples include:

  • repositories and pull request workflows;
  • issue and ticket systems;
  • rooms, spaces, or workflow boards;
  • account and entitlement actions;
  • cloud resources and infrastructure controls;
  • internal tools that expose update or mutation endpoints.

The common thread is not the specific product category. The common thread is that the agent is no longer only generating text. It is participating in a path that can change a live system.

What this is not

Impact Boundary is easy to over-read if all you see is the phrase "security" or "control layer." The public v0.1.0 bundle is not making those claims.

It is not:

  • an agent framework;
  • a semantic correctness proof for model output;
  • a replacement for human review;
  • a statement that policy output is sufficient by itself;
  • a statement that every admitted request is wise or correct in a business sense.

It is a structured gate between intent and effect. That is narrower than a full trust or safety claim, and that narrower claim is the one the current v0.1.0 bundle actually supports.

What the v0.1.0 bundle shows

The public bundle demonstrates the model end to end in a local environment. A visitor can submit intent, see the system check state, see policy return a candidate, see Core admit or block the path, see admitted work become claimable, and then see an adapter report the outcome of materialization.

The included minimal adapter is a local fixture. It exists so that people can understand the pattern without first wiring a valuable real system into the loop. That makes the v0.1.0 bundle useful for architecture evaluation, adapter design, and early security review.

Why this framing matters

Many discussions about agents jump too quickly from model capability to automated action. Impact Boundary slows that jump down in a useful way. It makes the transition from "the agent wants to do this" to "the external system changed" into a series of inspectable steps. That improves clarity even before you talk about stronger production controls.

The result is not a promise that the model is right. It is a way to keep the write path understandable, bounded, and explicit.

Summary

Impact Boundary is a boundary between agent intent and real external impact. It separates reading from writing, treats policy as candidate input rather than direct authority, and requires admitted work before an adapter can materialize an effect. The local v0.1.0 bundle demonstrates that flow with Core inside the Adapter Host and a minimal fixture adapter. The value of the system is not that it proves correctness. The value is that it gives external impact a clear path, a visible gate, and a concrete handoff.

Related

How it worksTerminology