The useful distinction in Cloudflare’s agent workspace is between sharing a live application and sharing the code used to create another one. Those actions should not grant the same access.
A workspace built around capabilities
Cloudflare’s announcement describes isolated Dynamic Workers, per-app SQLite state in Durable Object Facets and mediated resource access through Gatekeepers. A live gadget can share state; a blueprint copies code without the source app’s database, history or connected resources.
The repository calls version 2 early access. Its local quick start is for trying the product, while production self-hosting documentation/tooling for workerd remains forthcoming. The Apache 2.0 license covers the published code; it does not supply credentials, operational support or an audit of your integrations.
Two different sharing tests
The diagram uses a fictional expenses app. Alice and Bob collaborating on one instance should see the same permitted records. Charlie creating an instance from a blueprint should receive the application’s logic with fresh state, not Alice’s expense records. Those are two separate acceptance tests.
Add a third person without access to the underlying source. Test whether that person can open a derived report, receive an export or follow a shared link. A successful login to the workspace answers only who the person is; it does not answer which source information they may receive.
Define the integration boundary before adding real data
For a first trial, use a synthetic dataset with recognisable fake records. Give one resource to one workspace. Attempt allowed reads, denied reads and a write that requires approval. Then remove the access and repeat. Record actual remote state as well as the agent’s description of what happened.
This last check matters for any system that can stage or simulate actions: “completed” in a conversation must not be your only evidence that an external service changed. Conversely, a rejected action must leave that service untouched.
The design offers a reference for controlling generated applications, but a useful rollout still needs integration-specific evidence. Keep the tested revision, identity policies, resource grants and export behaviour together. That turns an interesting architecture into a deployment you can explain and operate.
September 8: distinguish shared gadgets from blueprints, verify early-access and self-hosting documentation limits, replace absolute security claims with concrete authorization checks.