Environment
The environment is the durable workspace layer around model execution.
It is the place where Decubed stores configuration that should outlive a single prompt, a single provider, or a single run.
What It Owns
The environment state is the canonical configuration snapshot for the workspace.
It owns fields such as:
- workspaces
- folders
- agents
- auth profiles
- permission profiles
- tool catalog policy
- skills
- metadata
It does not own transient execution state, live tool registrations, or raw secrets.
Why It Matters
Most AI products treat the prompt window as the product and attach everything else to the current model session.
Decubed does the opposite:
- the environment is durable
- the model path is interchangeable
- the user can inspect and update the workspace without tearing down the rest of the system
That split is what makes a local-first AI workspace practical.
Workspaces And Folders
Workspaces group related threads, profiles, and settings.
Folders add structure inside a workspace without rewriting history. A folder move changes organization, not the underlying record of what happened.
Agents And Profiles
An agent profile can bind together:
- a model reference
- a prompt
- a permission profile
- an auth profile
- selected tools
- selected skills
- a memory policy
That makes the agent an operational profile, not just a name on a tab.
Permissions And Tool Policy
Tool enablement lives in the environment because it should stay durable and inspectable.
Live execution can still change from run to run, but the workspace needs a stable place to record which tools are visible, enabled, or blocked by policy.
What The Environment Enables
Because the environment is explicit, Decubed can:
- open the same workspace on a different platform
- swap providers without discarding user structure
- preserve approval and policy decisions as part of the product state
- keep secrets out of the durable workspace snapshot