Tools
Tools are explicit capabilities exposed to the runtime.
In Decubed, a tool is not just a model hint. It has a durable description, a live registration, permission requirements, and an execution result that must be normalized back into the thread.
Two Layers
Decubed keeps tool behavior split across two layers:
- the durable definition that the model can see
- the live executable registration that actually performs the action
That split makes it possible to expose tools clearly without confusing prompt-visible description with executable privilege.
Permission And Approval Flow
Tool execution follows a canonical order:
- the tool is requested
- the runtime resolves required permissions
- policy is evaluated
- approval is requested when needed
- the tool runs only if allowed
- output is normalized into the thread
Approval is not the same thing as permission. Both surfaces matter and both should stay visible.
Durable Policy
Durable tool policy lives in the environment, not in a hidden provider session.
That lets the product answer concrete questions like:
- which tools are enabled in this workspace
- which tools are available to this agent
- which actions require approval
- which permissions are currently denied
Why This Matters
AI products often collapse tools into invisible side effects.
Decubed keeps them visible so the workspace can show:
- what the model tried to do
- why it was allowed or blocked
- how long it ran
- what came back
Examples
The tool surface can include:
- file inspection
- browser tasks
- calendar reads
- reminders
- contacts
- local shell or runtime actions
Different tools may have different policy and approval requirements, but they still pass through the same runtime shape.