What ImpactRoom Is
ImpactRoom by Impact Boundary Labs is a reference adapter for the Impact Boundary Core and a local preview for state-bound agent impact. It is designed for people who want to understand how an external agent can act through a bounded public surface without turning a demo into a raw control plane for private runtime systems. That makes ImpactRoom useful in two directions at once. It is a concrete product demo that people can run and inspect, and it is also a learning artifact for adapter developers who want to understand how public state, agent attempts, human approval, scoped permission, stale recovery, admitted materialization, and terminal Game Over / Denial fit together.
ImpactRoom is not just a visual room with a door and a key. The room exists so the underlying engineering idea can stay visible. An external agent starts with limited public knowledge. It reads guided state, sees public affordances, and tries actions that may or may not succeed. Some actions are blocked because the agent is at the wrong station. Some actions are blocked because the agent lacks approval. Some actions are allowed to proceed but later produce no visible effect because the capability has become stale. A valid fresh capability can eventually materialize visible impact. The visible story is simple on purpose, because the point is not the room itself. The point is the boundary behavior.
Why It Exists As A Reference Adapter
When Impact Boundary Labs describes ImpactRoom as a reference adapter, that is meant literally. The code and docs are there to show one concrete way to bind a domain-specific adapter into a broader Boundary, Broker, Adapter Host, and Core architecture. Many demos stop at a polished interface and leave the real system story vague. ImpactRoom does the opposite. The interface is present, but the main value is architectural clarity. An agent developer can learn how to enter through a small public surface instead of guessing internal routes. An adapter developer can learn how to keep private domain state private while still exposing enough public projection for a useful guided experience.
What State-Bound Agent Impact Means
The phrase state-bound agent impact matters here. In plain language, it means an agent is not evaluated only by what it wants to do. It is evaluated against the state the system currently trusts, the policy that applies to that state, and the capability evidence attached to the action. In ImpactRoom, opening the door is not just a button press with a plausible label. The action depends on a scoped key that is tied to the public door state at a specific moment. If the state changes and the key is no longer fresh, the same action does not suddenly become valid because the agent repeats itself more confidently. The result is either blocked or no-impact feedback, and the agent must continue from current public state rather than pretending the earlier state still holds.
Why The Browser Is Not The Agent
That is why the browser is observer and operator, not the external agent. The browser renders sanitized public projection. It shows the map, the latest public observation, compact evidence in the ledger, and the operator moment when human approval is needed. It does not act as the hidden source of truth for the agent, and it does not secretly bypass the same public constraints that apply to external clients. The agent lives on the Agent Surface. The browser lives on observer and operator routes. That separation is a core part of the demo, not a cosmetic detail.
Why Agents Enter Through /connect
External agents enter through /connect because the public contract starts there. A new agent does not need to know private infrastructure URLs, raw request envelopes, or internal identifiers. It only needs a public session, a state URL, and returned action metadata. From that point on, the agent reads /agent/state, inspects visible stations and objects, and follows the affordances exposed by the surface. This keeps the interface self-describing without turning it into a walkthrough. The agent is told how to move, how to post a Public Observation before intent actions, and how to submit returned actions. It is not handed raw Broker instructions or a private map of internal runtime fields.
Approval, Stale Capability, No-Impact, And Materialization
Several moments in the demo make the model easier to understand. Admin Override is visible and real enough to tempt the agent, but it remains blocked because operator authority is separate from agent authority. A request for a scoped key requires approval. The approval itself does not mean the door opens; it only creates the conditions for a capability to exist. The first key can become stale against current public state, which means the agent experiences the difference between possession and validity. The stale key produces no visible door change. The fresh key aligns again with current state, and only then can a door-open action materialize. Materialization is the visible part people notice in the room. It is not the same thing as intention, policy evaluation, or even admitted work. ImpactRoom keeps those distinctions visible.
Why Internal Runtime Concepts Stay Hidden
Raw Broker, Host, Core, and WorkOrder internals stay hidden for the same reason. The public story would become misleading if it taught developers that the correct way to integrate is to bypass the guided surface and construct raw internal requests. That would reduce the demo to a thin façade over private plumbing, which is exactly what this project tries to avoid. Instead, the public preview exposes a small set of stable routes, public action names, sanitized feedback, and observer-safe evidence codes. The deeper repo docs then show how those public concepts line up with staged binding, policy callbacks, claimed work, and adapter-side materialization without publishing runtime secrets or raw internal identifiers.
Why This Helps Adapter Developers
For adapter developers, this is where ImpactRoom becomes especially useful. It shows that domain state belongs to the adapter, public projection can be smaller than private state, policy should not directly mutate the world, and a local preview should hold external agents to the same guided contract it documents. It also shows that a public surface can reject wrong-station and missing observation errors locally before deeper boundary machinery is engaged. That is not about hiding complexity for its own sake. It is about choosing the right layer for the right responsibility.
Why ImpactRoom Fits The Reference-Adapter Pattern
ImpactRoom is also part of a broader teaching pattern. Together with MazeRunner and other reference adapters, it helps people see what correct adapter binding looks like in practice. The room, the key, and the door are memorable because they make the state story easier to follow. The deeper lesson is about bounded impact: public actions should be explicit, state evidence should matter, approval should remain separate, and visible changes should only appear after the implemented boundary and adapter path says they are real.
Further reading
- Agent Surface reference
- Observer and operator surface
- Code-derived architecture
- Adapter lessons
- Security scope
- Preview runbook
