WorkbenchProfiles and Policies

Profiles and Policies

Profiles define how an agent behaves end to end. They package model choice, tool access, permissions, guardrails, and harness selection into a reusable sidecar profile that the runtime enforces. This is how the workbench configures agent execution without hard-coding behavior into every task.

What A Profile Controls

  • Harness selection: OpenCode, Claude Code, Codex, AMP, Factory Droids, Kimi Code, OpenClaw, NanoClaw, Hermes, or CLI base when the product exposes them.
  • Model selection: primary and small model routing per profile.
  • Per-agent tuning: distinct configs for plan/build/explore (prompt, temperature, max steps).
  • Tool access: enable or disable individual tools.
  • Permissions: edit, bash, web access, and tool-server access (ask/allow/deny).
  • Command scoping: bash can be limited by command allowlists.
  • Tool servers: allowlisted local or remote servers with headers, env, and timeouts.
  • Plugins: allowlisted extensions that can be attached to the runtime.
  • Inheritance: extend a base profile and override only what changes.

Profiles make it possible to standardize agent behavior across teams while still allowing targeted customization when needed.

Guardrails And Validation

Profiles are validated before execution. Security policies can cap permissions (for example, “bash” at ask), block local tool servers, and require allowlisted plugins. Profiles that exceed policy are rejected so the runtime stays safe and predictable.

How It Shows Up In The Workbench

The workbench will progressively expose profile controls:

  • Base profiles for org-wide defaults.
  • Profile variants for team or project overrides.
  • Per-run overrides for experimentation and simulations.

If you want early access to advanced profile configuration, contact the team.

Under the hood, profiles can extend a base profile. The runtime merges overrides with the base profile, validates the final config, and applies the result to the sidecar session.

Example Profile (Conceptual)

{
  "name": "team-default",
  "extends": "tangle/base",
  "model": "provider/model-id",
  "small_model": "provider/model-small",
  "agent": {
    "plan": { "temperature": 0.2, "maxSteps": 8 },
    "build": { "temperature": 0.1, "tools": { "git": true, "bash": false } },
    "explore": { "temperature": 0.7 }
  },
  "permission": {
    "edit": "ask",
    "bash": "ask",
    "webfetch": "allow",
    "mcp": "ask"
  },
  "tools": {
    "git": true,
    "search": true,
    "bash": false
  },
  "mcp": {
    "internal-search": {
      "type": "remote",
      "url": "https://tools.example.com/mcp",
      "timeout": 10000
    }
  }
}

For a field-by-field reference, see Profile Schema. The schema is harness-aware; each backend maps the shared profile fields to its own config surface.

SimulationsProfile Schema