What the v0.1.0 bundle can claim
The v0.1.0 bundle can claim a specific set of things with confidence.
It controls agentic write impact by separating intent from materialization.
It creates a deterministic boundary before external effects exist.
It checks state and policy before admitted work becomes claimable.
It demonstrates the boundary flow in a local v0.1.0 runtime with Core inside the Adapter Host.
It makes external impact explicit, bounded, and inspectable as a sequence of request, decision path, claimable work, and outcome.
Those are meaningful claims. They are also narrower than the claims people sometimes expect from systems in this space.
What the v0.1.0 bundle cannot claim
The v0.1.0 bundle does not guarantee safety.
It does not prove semantic correctness.
It does not replace human review.
It does not solve AI safety.
It does not fully verify all agent behavior.
It does not provide a production-ready security layer.
It also does not claim durable queue guarantees, hosted identity, broad adapter trust, or complete operational controls for sensitive production systems.
These limitations do not make the project unhelpful. They tell you exactly what kind of help the project is trying to provide.
Why the limitations are intentional
A local v0.1.0 runtime should be honest about what it demonstrates. If the project tried to claim every hard property at once, the public docs would become less trustworthy, not more.
The current bundle is useful because it focuses on one concrete idea: agent writes should pass through a clear boundary before they become real external effects. That idea can be evaluated locally. It does not depend on first solving every production identity, persistence, observability, and hosting problem.
In practice, this means the v0.1.0 bundle can be small, explicit, and inspectable. It can show the pattern clearly before larger operational layers are added.
Local v0.1 versus production-grade
Local v0.1 and production-grade concerns are not the same thing.
Local v0.1 concerns
The v0.1.0 bundle is concerned with showing the control flow:
- intent submission;
- state check;
- policy candidate evaluation;
- Core validation;
- claimable admitted work;
- adapter materialization;
- outcome reporting.
These are architecture and contract questions. They are the reason the v0.1.0 bundle exists.
Production-grade concerns
Production work introduces a different class of problems:
- durable persistence across process restart;
- stronger identity and authorization models;
- adapter trust and registration models;
- review and escalation workflows;
- operational security and secret handling;
- monitoring, audit, and incident response;
- deployment, rollback, and recovery behavior.
Those concerns matter. They are just not the same thing as the core boundary pattern itself.
The difference between "bounded" and "safe"
The v0.1.0 bundle can honestly say that external impact is made more explicit, bounded, and inspectable. That does not mean it can honestly say that the system is safe in every relevant sense.
Bounded means the path is structured. The request is distinct from the decision. Work is distinct from the external effect. Outcome is distinct from the original promise.
Safe would imply much broader guarantees about hostile cases, operational resilience, target semantics, and deployment context. The v0.1.0 bundle does not make those claims.
That distinction is important because many systems sound stronger in prose than they are in engineering reality. This documentation should not do that.
Why human review still matters
The boundary does not replace human review. It can route, constrain, and structure the path to impact. It can make the write path more inspectable. But it does not eliminate the need for human judgment in sensitive cases.
Some actions are operationally risky because the business context matters more than the raw target state. Other actions may be structurally valid but still unwise. A local v0.1.0 runtime cannot claim to remove those categories of review.
That is why the project should be read as a control pattern, not as a final answer to judgment-heavy workflows.
The main production tracks
If a team wants to move beyond the local v0.1.0 runtime, the next concerns are not mysterious. They are separate engineering tracks that need their own design work.
Durable persistence
The v0.1.0 bundle uses process-local state. A production system would need stronger persistence for work state, claims, outcomes, and related operational history.
Hosted identity
The v0.1.0 bundle uses local tokens and connector callback tokens. A production system would need stronger identity and authorization boundaries.
Adapter trust
The v0.1.0 bundle shows how adapters fit into the model. It does not certify arbitrary adapters as trustworthy production components.
Stronger review workflows
Approval, escalation, and operational override paths need deeper design when actions are sensitive or organizationally complex.
Production deployment
A local binary or Docker v0.1 runner is not the same thing as a production deployment model. Real deployment adds concerns around scaling, recovery, rollout, and operational ownership.
Monitoring and audit
The v0.1.0 bundle can show trace-like behavior, but that is not the same as a durable audit system or a complete monitoring stack.
Operational security
A production environment needs stronger handling for credentials, incident response, target rollback expectations, and target-side observability.
How to read the v0.1.0 bundle correctly
The most productive way to use the v0.1.0 bundle is to ask: does this boundary model create a clearer and more controllable path from agent request to external effect?
That is the right question for the current artifact.
The wrong question is: does this local bundle already guarantee the full set of production properties we might eventually want? It does not, and the docs should not pretend otherwise.
Summary
The limitations in the v0.1.0 bundle are deliberate. The system can claim a controlled, deterministic boundary from intent to external impact, with state and policy checks before admitted work exists. It cannot claim guarantees of safety, semantic correctness, human-review replacement, or full verification of agent behavior. Production concerns such as durable persistence, hosted identity, adapter trust, stronger review workflows, production deployment, monitoring, audit, and operational security remain separate tracks. That narrower scope is what makes the current v0.1.0 bundle honest and useful.