Slate vs Conductor

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Conductor
   Slate✓fullprobed8/10

   A probe confirms Slate's docs site serves a valid llms.txt at the root with links to actual docs pages, directly satisfying the ability to point an agent at agent-oriented docs. Missing for 10: no independent/community confirmation that agents successfully consume this llms.txt in practice, and no broader agent-oriented doc format beyond the single file.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.randomlabs.ai/llms.txt # Slate ## Docs - [Introduction](https://docs.randomlabs.ai/en/getting-sta…”

   proof ↗⚑ flag

   Conductor✓fullprobed9/10

   Direct probe confirms llms.txt is live and served at https://www.conductor.build/llms.txt with agent-oriented summary, plus a full docs.md markdown mirror for agent consumption. missing for 10: no independent/community confirmation that external agents actually consume these files successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”
   • [probe] “PROBE docs-md: HTTP 200 at https://www.conductor.build/docs.md --- title: "Introduction" url: "/docs" description: "Learn what Conductor is …”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Conductor
   Slate—none0/10

   The docs describe Slate as an interactive terminal agent (onboarding, slash commands, hotkeys, subagent cards) with a permission-bypass flag (--dangerously-skip-permissions/--yolo), but there is no mention of a headless mode, non-interactive CLI flags, exit-code/scriptable output, or CI integration examples. Missing for 10: documented headless/non-interactive invocation, CI pipeline examples, scriptable output format, and any evidence of automation use outside the interactive TUI.

   • [claimed-docs] “We support `--dangerously-skip-permissions` (alias: `--yolo`) to bypass permission prompts.”
   • [claimed-docs] “npm i -g @randomlabs/slate”
   • [claimed-docs] “Use `/sessions` to switch between existing sessions”

   proof ↗⚑ flag

   Conductor~partialprobed6/10

   Conductor supports scheduled/CI-like automation via 'routines' that run on a schedule or GitHub Action, plus a programmatic API and hosted MCP server for managing cloud workspaces headlessly, and cloud agents can run builds/tests without confirmation. However, it is fundamentally a Mac GUI app, and there's no evidence of a standalone CLI or true headless binary for arbitrary CI pipelines outside GitHub Actions. missing for 10: dedicated CLI/headless binary for generic CI systems, independent evidence of routines/GitHub Action working reliably in production, clarity on full non-interactive operation outside the Mac app.

   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Slate—none0/10

   No evidence in the pack mentions MCP servers or integrating external tool providers into Slate; the docs cover skills, permissions, orchestration, and CLI usage but never MCP support. Missing for 10: any documentation or claim about connecting/plugging in MCP servers, configuring MCP tool sources, or using MCP-provided tools.

   ⚑ flag

   Conductor—none0/10

   Evidence only shows Conductor exposing its OWN hosted MCP server so external MCP clients (ChatGPT, Claude, Codex) can manage Conductor's cloud workspaces (conductor-docs-14, conductor-probe-4) — the reverse direction of what the story asks. There is no documentation or community mention of a user being able to add/configure external MCP servers inside Conductor so its hosted coding agents (Claude Code, Codex, Cursor, OpenCode) can consume their tools.

   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Slate
   Slate✓fullprobed8/10

   Slate is delivered as an official CLI (npm-installed, terminal-based) with rich first-party docs covering install, sessions, hotkeys, shell execution, and configuration — squarely matching the 'official CLI' story for an AI-native user. Missing for 10: independent/hands-on corroboration of the CLI experience itself (community evidence found only relates to unrelated porting-quality claims, not CLI usage).

   • [claimed-docs] “npm i -g @randomlabs/slate”
   • [claimed-docs] “Use `/sessions` to switch between existing sessions”
   • [claimed-docs] “Press Tab to queue the current message so it runs after the current turn finishes.”
   • [claimed-docs] “Execute shell commands directly with `!`”
   • [claimed-docs] “Ctrl+X then N New session”
   • [probe] “official CLI documented at https://docs.randomlabs.ai/en/getting-started/quickstart”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor is documented as a Mac GUI app with a programmatic API and hosted MCP server, but no evidence pack item describes an official Conductor CLI tool; the only CLI mention is a user leveraging their own 'local GitHub CLI auth', which is unrelated.

   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Conductor
   Slate—none0/10

   Slate is documented as a CLI/terminal agent with configuration, skills, and hotkeys, but there is no evidence of a documented public API for programmatic/agentic access—the OpenAPI probe returned 404 across all candidate paths and no SDK or REST/API docs are mentioned anywhere in the pack.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.randomlabs.ai/openapi.json, https://docs.randomlabs.ai/swagger.json, https://docs.rando…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.randomlabs.ai/llms.txt # Slate ## Docs - [Introduction](https://docs.randomlabs.ai/en/getting-sta…”

   proof ↗⚑ flag

   Conductor✓fullprobed7/10

   Conductor documents a public API for programmatically managing cloud workspaces (create workspaces, send prompts, read agent replies) plus a hosted MCP server for AI clients like ChatGPT/Claude/Codex to drive it. Missing for 10: a published OpenAPI/reference spec (probe found only 404s for schema files) and independent/hands-on developer corroboration of API usage.

   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Conductor
   Slate—none0/10

   Slate is a coding-agent CLI; its evidence only covers permission settings (allow/ask/deny) for tool actions, not issuance of scoped/least-privilege API credentials or tokens for agents. No mention of credential/token scoping, API key generation, or IAM-style access control.

   • [claimed-docs] “Each permission key maps to an action ("allow", "ask", or "deny"), or a pattern object for fine-grained control.”
   • [claimed-docs] “We support `--dangerously-skip-permissions` (alias: `--yolo`) to bypass permission prompts.”

   proof ↗⚑ flag

   Conductor~partialcommunity4/10

   Community threads document that Conductor originally required full read/write GitHub access with no fine-grained scoping, which users flagged as risky; the developers later added a GitHub App integration for fine-grained repo access (or use of local GitHub CLI auth) as a fix, showing partial progress toward least-privilege credentials but not a documented, general mechanism for issuing scoped API credentials for agents beyond GitHub repo access. Missing for 10: no documentation of scoped/least-privilege credentials for the Conductor API/MCP server itself, no explicit policy on token scoping for non-GitHub integrations, and no independent verification that the new GitHub App permissions are truly minimal in practice.

   • [community] “Any way to have it not require full write access to your entire GitHub account?”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
   • [community] “I was really excited to try this but this does NOT work the way I expected. I wanted a simple git worktree manager for my existing, already-…”
   • [community] “Right now the app uses GitHub's OAuth sign in which unfortunately doesn't allow for fine-grained permissions... We're switching our sign-in …”
   • [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”
   • [claimed-docs] “Bring your own subscriptions and keys”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Conductor
   Slate—none0/10

   The evidence pack covers Slate's CLI, skills, configuration, and orchestration features but contains no mention of an official SDK (Python/TypeScript/etc.) for building applications on top of Slate, and the OpenAPI probe returned 404s across all candidate paths. Missing for 10: any documented SDK package, API reference, or programmatic interface for building against Slate.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.randomlabs.ai/openapi.json, https://docs.randomlabs.ai/swagger.json, https://docs.rando…”
   • [claimed-docs] “npm i -g @randomlabs/slate”

   proof ↗⚑ flag

   Conductor~partialprobed5/10

   Conductor documents an official REST-style API for managing cloud workspaces and sending/reading agent prompts, plus a hosted MCP server for AI clients, which supports building AI-native integrations. However, no dedicated client SDK packages (e.g., npm/python libraries) are evidenced, and a probe for an OpenAPI spec returned 404s, suggesting the 'SDK' is really just a raw API/MCP interface rather than a polished, language-specific SDK. missing for 10: official language SDK packages, OpenAPI/schema-based codegen support, independent hands-on confirmation of SDK usage.

   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   Slate~partialcommunity4/10

   Slate is a coding-agent CLI whose evidence shows it can analyze a codebase and produce suggestions (e.g., generating an ARCH.md with improvement ideas), which maps loosely to 'AI-generated insights from data' but only in the narrow sense of source code, not general data analysis. Community evidence also raises skepticism about the real quality of generated output (e.g., criticism of a ported-code example as low quality/unverified). Missing for 10: evidence of insights/suggestions over non-code datasets, dashboards or analytics-style outputs, and independent validation of suggestion quality.

   • [claimed-docs] “Please review the architecture of my entire codebase creating an ARCH.md and then give me ways I can improve it.”
   • [community] “Blog post claimed porting a library with one sentence, but critic noted it was JS->TS (trivial rename) not Python->TS, excluded tests/exampl…”
   • [community] “"Why trumpet code that is so ready for the garbage that you wouldn't even bother to publish it" - skepticism about the quality/usefulness of…”

   proof ↗⚑ flag

   Conductor~partialclaimed4/10

   Conductor orchestrates third-party coding agents (Claude Code, Codex, Cursor) that analyze the codebase and produce diffs, suggested changes, and PR reviews, which can be seen as data-driven suggestions, but Conductor itself does not document any native analytics/insights engine — the 'insight' generation is delegated entirely to the underlying agents. Missing for 10: no first-party insight/analytics feature, no evidence of Conductor synthesizing patterns or trends from user data beyond agent chat/diff output, no independent corroboration of this specific capability.

   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
   • [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Conductor
   Slate~partialclaimed5/10

   Slate supports background subagents, parallel task orchestration, and built-in workflows like goal/deep-research that run while the user keeps interacting, which shows some autonomous background execution. However, this is task-level parallelism within an active session, not scheduled or trigger-based automations that run independently of user presence. missing for 10: evidence of scheduled/cron-like automations, persistent background jobs surviving session end, or trigger-based (event-driven) autonomous runs without an active user session.

   • [claimed-docs] “Those agents show up as a grid of inline subagent cards, one per agent.”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”
   • [claimed-docs] “`goal` and `deep-research` are built-in programs. They are user-visible workflows, not something you need to author before using Slate.”

   proof ↗⚑ flag

   Conductor✓fullclaimed7/10

   Conductor's "routines" feature explicitly lets users run agents on a schedule or via GitHub Action, and cloud workspaces continue running autonomously ("agents keep working after you close your laptop") without requiring step-by-step confirmation. This directly matches background, autonomous automation for an AI-native user. Missing for 10: independent/hands-on confirmation that routines work reliably in practice, and more detail on scheduling configuration options beyond the changelog mention.

   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Conductor
   Slate✓fullcommunity7/10

   Slate is a CLI-based AI assistant where users delegate whole tasks (e.g., 'review architecture and write ARCH.md') and it spins up parallel subagents, orchestration programs like goal/deep-research, and long multi-hour sessions per first-party docs. Community evidence (comm-1/2/3) raises skepticism about output quality/novelty but does not contradict the core delegation mechanism itself. Missing for 10: independent hands-on validation that delegated multi-agent tasks reliably complete as advertised.

   • [claimed-docs] “Parallelize working and orchestration of many tasks at once.”
   • [claimed-docs] “Please review the architecture of my entire codebase creating an ARCH.md and then give me ways I can improve it.”
   • [claimed-docs] “Those agents show up as a grid of inline subagent cards, one per agent.”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”
   • [claimed-docs] “`goal` and `deep-research` are built-in programs. They are user-visible workflows, not something you need to author before using Slate.”
   • [community] “"Why trumpet code that is so ready for the garbage that you wouldn't even bother to publish it" - skepticism about the quality/usefulness of…”

   proof ↗⚑ flag

   Conductor✓fullcommunity8/10

   Conductor lets users delegate coding tasks to agents (Claude Code, Codex, Cursor, OpenCode) that run inside its own workspaces, autonomously testing repos, running builds, and continuing work unattended, with checkpoints and review flow built into the product (conductor-docs-1, -17, -20, -29, -32). Community reports confirm the agent runs live inside the app during real use (conductor-comm-7, conductor-comm-15). Missing for 10: independent benchmarking of assistant quality/reliability beyond docs and mixed anecdotal UX feedback (conductor-comm-9).

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
   • [community] “I have been imagining something like this would be perfect for working with Claude Code... This feels like just a nice clean simple extensio…”
   • [community] “Your messages are just between you and Claude Code — it all runs on your local Claude Code installation via the SDK.”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Conductor
   Slate✓fullclaimed7/10

   Docs show Slate is driven primarily via natural-language prompts (e.g. the quickstart example 'Please review the architecture of my entire codebase...') alongside slash-commands, shell escapes, and file references, indicating natural-language is the core interaction mode for an AI-native agent CLI. Missing for 10: independent/hands-on confirmation that complex natural-language commands are reliably parsed and executed as intended (community evidence only discusses code-porting quality, not NL command usage itself).

   • [claimed-docs] “Please review the architecture of my entire codebase creating an ARCH.md and then give me ways I can improve it.”
   • [claimed-docs] “Execute shell commands directly with `!`”
   • [claimed-docs] “Use `@filename` references”
   • [claimed-docs] “Use `/sessions` to switch between existing sessions”
   • [claimed-docs] “`goal` and `deep-research` are built-in programs. They are user-visible workflows, not something you need to author before using Slate.”

   proof ↗⚑ flag

   Conductor✓fullprobed8/10

   Conductor's entire interaction model is natural-language chat with coding agents (Claude Code, Codex, Cursor, OpenCode) that can autonomously test, build, and edit without step confirmation, and it exposes a hosted MCP server so ChatGPT/Claude/Codex or other AI clients can manage workspaces via natural language, plus an API to send prompts and read agent replies. missing for 10: independent/hands-on validation of natural-language command reliability beyond vendor docs.

   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
   • [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”

   proof ↗⚑ flag

Api quality

1. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Slate—none0/10

   Slate's docs site was directly probed for an OpenAPI/swagger spec at standard locations and all returned 404, and no documentation anywhere mentions a machine-readable API spec for AI-native consumption.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.randomlabs.ai/openapi.json, https://docs.randomlabs.ai/swagger.json, https://docs.rando…”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor documents a REST-like API and an MCP server, but a direct probe for machine-readable OpenAPI/Swagger specs at standard locations returned 404 on all candidate paths, and no evidence pack item links to a downloadable spec file.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”

   proof ↗⚑ flag

2. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Slate—none0/10

   Slate is a CLI coding agent product; no evidence of any versioned public API, API reference, or deprecation policy documentation exists—openapi probes returned 404 and no docs mention API versioning or deprecation. Absence of evidence for this applicable axis (a product could plausibly document API stability) yields 'none'.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.randomlabs.ai/openapi.json, https://docs.randomlabs.ai/swagger.json, https://docs.rando…”

   proof ↗⚑ flag

   Conductor—none0/10

   There's an API and MCP server documented, but no evidence of API versioning scheme or a deprecation policy; probes show no OpenAPI spec found and no changelog/policy on version deprecation.

   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Conductor
   Slate~partialclaimed6/10

   Docs describe running many agents in parallel and orchestrating multiple tasks simultaneously (grid of subagent cards, spinning up more agents to parallelize work), which supports bulk-style operations across many items. However, there's no independent corroboration of this working at scale and no detail on failure handling, limits, or item-level bulk operations (e.g., bulk file edits/refactors) beyond task orchestration. Missing for 10: independent/hands-on verification of large-scale parallel task execution, concrete examples of bulk item processing (files/records), and failure/error handling details at scale.

   • [claimed-docs] “Parallelize working and orchestration of many tasks at once.”
   • [claimed-docs] “Those agents show up as a grid of inline subagent cards, one per agent.”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”
   • [claimed-docs] “`goal` and `deep-research` are built-in programs. They are user-visible workflows, not something you need to author before using Slate.”

   proof ↗⚑ flag

   Conductor~partialclaimed7/10

   Conductor supports running many coding agents in parallel across isolated workspaces, and exposes a programmatic API plus scheduled/CI-triggered 'routines' that can create workspaces and send prompts at scale — a reasonable basis for bulk, automation-driven operations across many items. However, there's no documented UI for batch-selecting and acting on many existing workspaces at once (e.g., bulk archive/merge), and no independent evidence of large-scale parallel runs in practice. Missing for 10: explicit multi-item batch actions in the UI, evidence of scale/limits on parallel agents, and third-party corroboration of bulk automation workflows via the API or routines.

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Run multiple agents in one workspace when the work belongs on the same branch and should share the same files and context.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Conductor
   Slate—none0/10

   Slate's docs describe agent rules for permissions/behavior ordering (docs-15, docs-20) and orchestration of parallel agents (docs-12, docs-13), but there is no evidence of user-defined rules that trigger actions automatically on external events (e.g., file changes, webhooks, schedule, git events). This is a plausible axis for a coding agent (many support hooks/triggers), so absence of evidence yields none rather than na.

   • [claimed-docs] “Slate by default respects agent rules in the following order”
   • [claimed-docs] “Each permission key maps to an action ("allow", "ask", or "deny"), or a pattern object for fine-grained control.”

   proof ↗⚑ flag

   Conductor~partialclaimed5/10

   Conductor's 'routines' feature lets agents run on a schedule or via GitHub Action trigger, which is a limited form of event-driven automation, but there's no evidence of a general rules engine supporting arbitrary event types (e.g., webhooks, file changes, custom conditions) or complex trigger-action definitions. Missing for 10: broader event-type support, custom rule/condition definitions, and hands-on evidence that routines fire reliably on GitHub events.

   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Conductor
   Slate—none0/10

   Slate is a coding-agent CLI with orchestration/parallel-agent features and sessions, but nothing in the evidence describes scheduling recurring jobs or workflows (e.g., cron-like triggers, timed recurring runs). Orchestration docs cover on-demand parallelization, not recurrence.

   • [claimed-docs] “Those agents show up as a grid of inline subagent cards, one per agent.”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”
   • [claimed-docs] “`goal` and `deep-research` are built-in programs. They are user-visible workflows, not something you need to author before using Slate.”

   proof ↗⚑ flag

   Conductor✓fullclaimed6/10

   Conductor's changelog explicitly introduces 'routines' that let agents run on a schedule or via GitHub Action, directly matching the recurring-jobs/workflows story. However, this is a single brief changelog mention with no dedicated documentation page, configuration details, or community corroboration of the feature in practice. Missing for 10: dedicated docs on routine/schedule configuration, independent/hands-on confirmation, details on failure handling or monitoring of scheduled runs.

   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Conductor
   Slate—none0/10

   Evidence shows session management (/sessions, /workspace) and built-in 'programs' like goal/deep-research, but nothing about versioning automations, reviewing history of changes, or rolling back to prior states of an automation/workflow. Missing for 10: any documentation of version history, diffing, or rollback mechanisms for automations/workflows.

   • [claimed-docs] “Use `/sessions` to switch between existing sessions”
   • [claimed-docs] “Use `/workspace` to open the workspace manager, where you can review and remove workspace directories.”
   • [claimed-docs] “`goal` and `deep-research` are built-in programs. They are user-visible workflows, not something you need to author before using Slate.”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   Conductor provides git-based versioning (separate branches/worktrees per workspace), diff review before merge/PR, and 'Checkpoints' to revert code and chat state to an earlier turn—covering version, review, and rollback at the workspace/agent-session level. However, the newer 'Routines' (scheduled/GitHub-Action automations) feature has no documented versioning, review, or rollback mechanism specific to the automation definitions themselves. Missing for 10: explicit version history/rollback for Routines/scheduled automations, independent hands-on confirmation of checkpoint reliability.

   • [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”

   proof ↗⚑ flag

Background execution

1. ai-native userHave a cloud agent build, test, and demo a feature end-to-end for my review

   weight 2 · round to Conductor
   Slate!disputedcontradicted4/10

   Slate's docs claim orchestration of parallel background subagents and being 'one of the few agents capable of performing integration tests manually,' suggesting it could build and test a feature autonomously, but no docs mention a 'demo' output or cloud-hosted execution environment. Community hands-on critique of an actual Slate-produced port directly contradicts the build/test claim: reviewers found the work excluded tests/examples and provided no verifiable repo, undermining confidence that Slate reliably builds+tests end-to-end for review. Missing for 10: evidence of cloud/remote execution infra, an explicit demo-generation feature, and independent confirmation that test suites are actually run and pass.

   • [claimed-docs] “Those agents show up as a grid of inline subagent cards, one per agent.”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”
   • [claimed-docs] “Slate is one of the few agents capable of performing integration tests manually.”
   • [community] “Blog post claimed porting a library with one sentence, but critic noted it was JS->TS (trivial rename) not Python->TS, excluded tests/exampl…”
   • [community] “"Why trumpet code that is so ready for the garbage that you wouldn't even bother to publish it" - skepticism about the quality/usefulness of…”

   proof ↗⚑ flag

   Conductor✓fullclaimed7/10

   Conductor's cloud agents can autonomously test repos, update setup scripts, and run builds without step-by-step confirmation (conductor-docs-17, conductor-docs-32), continue working after the laptop closes (conductor-docs-20), and then help the user review the diff, open a PR, and merge (conductor-docs-21) — covering build, test, and review end-to-end for a feature. Missing for 10: no explicit 'demo' artifact (e.g., preview links/screenshots) beyond diff/PR review, and no independent/hands-on account confirming a full autonomous build-test-review cycle worked as described.

   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”

   proof ↗⚑ flag

2. developerDelegate longer-running coding tasks to run in the background in an isolated cloud environment

   weight 3 · round to Conductor
   Slate—none0/10

   Slate's docs describe subagents running 'in the background' locally while you keep chatting and orchestration/parallelization of tasks, but there is no mention of an isolated cloud environment, remote execution sandbox, or delegation to a hosted service — everything described appears to run within the local CLI session. This axis is applicable to coding agent tools generally, but no evidence supports a cloud-isolated background execution capability for Slate.

   • [claimed-docs] “Those agents show up as a grid of inline subagent cards, one per agent.”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”
   • [claimed-docs] “Slate works with you across long, multi-hour sessions.”
   • [claimed-docs] “Parallelize working and orchestration of many tasks at once.”

   proof ↗⚑ flag

   Conductor~partialcommunity7/10

   Docs describe a dedicated 'cloud workspace' feature where agents run in isolated sandboxes that 'spin up in seconds' and 'keep working after you close your laptop,' can test repos/run builds unattended, and continue processing PR checks while 'asleep' (conductor-docs-20, conductor-docs-17, conductor-docs-11, conductor-docs-13). However, community reports describe the core product as creating an isolated git worktree locally rather than a cloud container, contrasting it with Codex's cloud sandbox (conductor-comm-17, conductor-comm-6), suggesting the cloud-isolation capability may be a newer/optional layer rather than the default experience. Missing for 10: independent hands-on verification that background cloud tasks are fully isolated/persistent, and clarity on whether cloud workspaces are the default vs. opt-in given local-worktree-first community accounts.

   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “PR comments and failing-check logs now load while a cloud workspace is asleep.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
   • [community] “I was really excited to try this but this does NOT work the way I expected. I wanted a simple git worktree manager for my existing, already-…”

   proof ↗⚑ flag

3. developerConfigure a reproducible cloud environment with the dependencies and setup steps my repository needs

   weight 2 · round to Conductor
   Slate—none0/10

   Slate's docs describe a local CLI agent (npm install, terminal sessions, permissions, skills, orchestration) but contain no mention of provisioning or configuring a reproducible cloud environment, dependency setup, or devcontainer-style configuration for a repository. This is a fair capability to ask of an autonomous coding agent, but no evidence shows Slate supports it.

   • [claimed-docs] “npm i -g @randomlabs/slate”
   • [claimed-docs] “Slate by default respects agent rules in the following order”
   • [claimed-docs] “Each permission key maps to an action ("allow", "ask", or "deny"), or a pattern object for fine-grained control.”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   Docs show Conductor's cloud workspaces spin up sandboxes, check for needed tools/credentials, and let agents edit install/setup scripts and run builds automatically, which supports configuring an environment with the right dependencies (conductor-docs-17, conductor-docs-20, conductor-docs-32, conductor-docs-33). However there's no explicit first-party description of a declarative, versioned environment-config file (e.g., a devcontainer-style spec) guaranteeing reproducibility across runs/teammates, and no independent confirmation that these setup scripts persist reliably across sessions. missing for 10: explicit reproducible-config artifact/spec, independent verification that environment setup is consistent across workspace recreations.

   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
   • [claimed-docs] “When you open Conductor, it checks for the tools and credentials it needs. If anything is missing, Conductor walks you through setup.”

   proof ↗⚑ flag

Parallel agents

1. ai-native userLaunch fleets of autonomous agents that work in parallel on different tasks for hours or days

   weight 2 · round to Conductor
   Slate~partialcommunity7/10

   Docs describe genuine parallel agent orchestration (grid of subagent cards, spinning up more agents while others run in background) and explicitly support multi-hour sessions, matching much of the story. However, evidence only confirms 'multi-hour' not multi-day autonomy, and community commentary raises skepticism about output quality/novelty without directly refuting the parallel-agent mechanics themselves. Missing for 10: confirmation of multi-day unattended runs, independent hands-on validation of fleet-scale parallel task completion.

   • [claimed-docs] “Slate works with you across long, multi-hour sessions.”
   • [claimed-docs] “Parallelize working and orchestration of many tasks at once.”
   • [claimed-docs] “Those agents show up as a grid of inline subagent cards, one per agent.”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”
   • [community] “Commenter compared the approach to 'Ralph as a service' referencing an existing agentic coding technique (ghuntley.com/ralph), suggesting Sl…”

   proof ↗⚑ flag

   Conductor✓fullclaimed7/10

   Docs show Conductor explicitly designed for running multiple agents (Claude Code, Codex, Cursor, OpenCode) in parallel across isolated workspaces/worktrees, with cloud workspaces that 'keep working after you close your laptop' and 'routines' to run agents on a schedule or via GitHub Action, supporting long-running autonomous fleets. Community feedback focuses on GitHub permission/privacy concerns rather than disputing the parallel-autonomy capability itself. Missing for 10: independent/hands-on confirmation of agents actually running unattended for multi-day spans and evidence of fleet scale (e.g., dozens of simultaneous agents).

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Run multiple agents in one workspace when the work belongs on the same branch and should share the same files and context.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”

   proof ↗⚑ flag

2. developerRun several task attempts in parallel and compare results before choosing one

   weight 1 · round to Conductor
   Slate~partialclaimed6/10

   Slate's orchestration docs show multiple subagents running in parallel as a grid of cards while the user keeps working, directly supporting parallel task execution (docs-12, docs-13). However, there's no explicit documentation of a compare/diff view or a 'choose winning attempt' workflow for reconciling multiple parallel results into one choice. Missing for 10: explicit comparison/selection UI or workflow for multiple attempts of the same task, and independent/hands-on confirmation of this specific use case.

   • [claimed-docs] “Those agents show up as a grid of inline subagent cards, one per agent.”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”
   • [claimed-docs] “`goal` and `deep-research` are built-in programs. They are user-visible workflows, not something you need to author before using Slate.”

   proof ↗⚑ flag

   Conductor✓fullprobed8/10

   Conductor's core design is running multiple coding agents in parallel, each in its own isolated workspace/git worktree with its own branch, files, and diff/review path, letting a developer inspect and choose before merging (docs-2, docs-27, docs-29, docs-21, probe-1). Community hands-on comments corroborate the git-worktree-based parallel workspace model (conductor-comm-1, conductor-comm-17). missing for 10: explicit first-party description of a side-by-side comparison UI across multiple simultaneous attempts (evidence shows parallel isolated workspaces and per-workspace diff/review, but not an explicit 'compare attempts' feature or independent review confirming the comparison workflow).

   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”
   • [community] “Oh cool, I was already doing this with git worktrees but a ui for it would be handy.”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”

   proof ↗⚑ flag

Scheduled automation

1. ai-native userSet up always-on agents that run on schedules or triggers to maintain and fix my software autonomously

   weight 2 · round to Conductor
   Slate—none0/10

   Slate's docs describe parallel subagent orchestration within a live session (background agents you keep talking to, spin up more agents to parallelize tasks) but there is no evidence of scheduling, event/webhook triggers, or persistent always-on agents that run autonomously outside an active session to maintain/fix software over time.

   • [claimed-docs] “Those agents show up as a grid of inline subagent cards, one per agent.”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”
   • [claimed-docs] “`goal` and `deep-research` are built-in programs. They are user-visible workflows, not something you need to author before using Slate.”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   Conductor documents 'routines' that run agents on a schedule or via GitHub Action, plus cloud agents that keep working after you close your laptop and can autonomously test, fix, and rebuild repos without step-by-step confirmation — directly supporting always-on autonomous maintenance. However, the routines feature is only briefly mentioned in a changelog entry with no deep documentation of trigger types, monitoring, or failure-handling, and no independent/hands-on evidence confirms long-running unattended reliability. Missing for 10: detailed docs on trigger configuration (webhooks, cron specifics), evidence of long-term unattended reliability, and community confirmation of the scheduling/autonomy feature working in practice.

   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”

   proof ↗⚑ flag

Debugging

1. developerDebug issues and troubleshoot using natural-language queries

   weight 2 · round drawn
   Slate~partialclaimed5/10

   Slate's docs show it operates via natural-language prompts, executes shell commands (`!`), references files (`@filename`), and can run integration tests and review codebase architecture in NL form, which implies it could be used for debugging and troubleshooting queries. However there is no explicit example, workflow, or documentation section dedicated to debugging/troubleshooting via natural language, and community evidence is skeptical/unrelated to this specific capability. Missing for 10: explicit debugging-focused examples or docs, independent verification that NL-based debugging works well, dedicated troubleshooting workflow beyond generic agent capabilities.

   • [claimed-docs] “Execute shell commands directly with `!`”
   • [claimed-docs] “Use `@filename` references”
   • [claimed-docs] “Slate is one of the few agents capable of performing integration tests manually.”
   • [claimed-docs] “Please review the architecture of my entire codebase creating an ARCH.md and then give me ways I can improve it.”

   proof ↗⚑ flag

   Conductor~partialclaimed5/10

   Conductor orchestrates coding agents (Claude Code, Codex, Cursor) that support natural-language chat, and each workspace has its own terminal, diff, and chat interface, implying a developer could ask an agent to debug/troubleshoot via NL queries. However, there's no Conductor-specific documentation describing a dedicated debugging/troubleshooting NL workflow, error-log analysis, or diagnostic features beyond generic agent chat and build/test execution. Missing for 10: explicit docs on NL-driven debugging workflows, log/error analysis features, or examples of troubleshooting via chat distinct from general coding tasks.

   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
   • [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”

   proof ↗⚑ flag

Feature implementation

1. developerTurn a tracked issue into a complete pull request end-to-end

   weight 3 · round to Conductor
   Slate—none0/10

   The evidence pack covers Slate's session management, orchestration, skills, and permissions but contains no mention of issue-tracker integration (e.g., GitHub issues) or automated pull-request creation/submission. Without evidence of ingesting a tracked issue and producing a PR end-to-end, this capability is unshown.

   ⚑ flag

   Conductor✓fullclaimed7/10

   Docs show workspaces can be created directly from a GitHub issue (conductor-docs-12), agents run autonomously to implement, test, and build (conductor-docs-17, conductor-docs-20), and Conductor then helps review the diff, open a PR, merge, and archive the workspace (conductor-docs-21) — covering the full issue-to-PR loop. Missing for 10: independent/hands-on confirmation of the complete issue→PR flow (community evidence covers worktree/permissions concerns but not this specific workflow), and no example of a merged PR originating from an issue.

   • [claimed-docs] “Use Command + Shift + N or the `...` button next to `New workspace` to create a workspace from a branch, pull request, GitHub issue, or Line…”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”

   proof ↗⚑ flag

2. developerDescribe a feature or bug in plain language and have the agent implement or fix it across multiple files

   weight 3 · round to Conductor
   Slate!disputedcontradicted5/10

   Docs imply broad multi-file code work (e.g. the quickstart example asks Slate to review an entire codebase and produce ARCH.md, plus orchestration features for parallelizing tasks across files/agents), suggesting Slate can act on plain-language requests across a codebase. However, independent community scrutiny of a specific real-world claim (a 'ported library' from one sentence) found it was actually a trivial JS->TS rename, excluded tests, lacked a verifiable repo, and drew explicit skepticism about the quality/usefulness of the generated code — concretely contradicting the marketed multi-file code-generation capability. Missing for 10: first-party documentation of a genuine multi-file bug-fix/feature-implementation workflow with verifiable before/after results, and independent hands-on confirmation that resolves the community dispute.

   • [claimed-docs] “Please review the architecture of my entire codebase creating an ARCH.md and then give me ways I can improve it.”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”
   • [claimed-docs] “Parallelize working and orchestration of many tasks at once.”
   • [community] “Blog post claimed porting a library with one sentence, but critic noted it was JS->TS (trivial rename) not Python->TS, excluded tests/exampl…”
   • [community] “"Why trumpet code that is so ready for the garbage that you wouldn't even bother to publish it" - skepticism about the quality/usefulness of…”

   proof ↗⚑ flag

   Conductor~partialcommunity6/10

   Conductor orchestrates underlying coding agents (Claude Code, Codex, Cursor, OpenCode) that implement plain-language feature requests across files, with workspaces, diffs, and PR flows supporting this, and community feedback confirms it works as a Claude Code-like workflow wrapper. However, the actual code-generation quality depends entirely on the underlying agent, not Conductor itself, and no hands-on example of a multi-file feature/bug fix is shown in the evidence. missing for 10: a concrete hands-on example of Conductor implementing a described feature/bug across multiple files, and clarity on Conductor's own contribution versus the wrapped agent's capability.

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [community] “I have been imagining something like this would be perfect for working with Claude Code... This feels like just a nice clean simple extensio…”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”

   proof ↗⚑ flag

Maintenance automation

1. developerHave the agent write tests, fix lint errors, resolve merge conflicts, and update dependencies for me

   weight 3 · round to Conductor
   Slate~partialcommunity3/10

   Slate is documented as a general-purpose coding agent with shell execution, file editing, permissioning, and orchestration of multiple sub-agents (random-labs-docs-9, random-labs-docs-13, random-labs-docs-16), which implies it could perform tasks like running tests or lint/dependency commands, but the evidence never explicitly documents test-writing, lint-fixing, merge-conflict resolution, or dependency updates as capabilities. Community commentary raises quality concerns about generated code but doesn't specifically address these tasks. Missing for 10: explicit documentation or examples of writing/fixing tests, resolving lint errors, resolving merge conflicts, and updating dependencies.

   • [claimed-docs] “Execute shell commands directly with `!`”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”
   • [claimed-docs] “Slate is one of the few agents capable of performing integration tests manually.”
   • [community] “"Why trumpet code that is so ready for the garbage that you wouldn't even bother to publish it" - skepticism about the quality/usefulness of…”

   proof ↗⚑ flag

   Conductor~partialclaimed5/10

   Docs confirm the underlying agents can test repositories, edit setup/install scripts, and run builds autonomously (conductor-docs-17, conductor-docs-32), which covers test-writing/fixing to some degree, but there is no explicit documentation or community evidence of lint-error fixing, merge-conflict resolution, or dependency updates as distinct capabilities. Missing for 10: explicit evidence of lint fixing, merge conflict resolution, and dependency-update automation.

   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”

   proof ↗⚑ flag

Codebase mapping

1. developerUnderstand how a codebase fits together to find where to start making changes

   weight 3 · round to Slate
   Slate~partialclaimed5/10

   The quickstart example explicitly shows Slate producing an ARCH.md architecture review of an entire codebase with improvement suggestions, directly supporting codebase-understanding use cases, and @filename references plus workspace management help navigate a repo. However there's no dedicated codebase-mapping/search feature (e.g., symbol index, dependency graph) documented beyond this one example, and no independent evidence confirming quality of such architecture summaries. missing for 10: dedicated code-navigation/search tooling, independent validation of architecture-summary accuracy, more than a single example of codebase-understanding workflow.

   • [claimed-docs] “Please review the architecture of my entire codebase creating an ARCH.md and then give me ways I can improve it.”
   • [claimed-docs] “Use `@filename` references”
   • [claimed-docs] “Use `/workspace` to open the workspace manager, where you can review and remove workspace directories.”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor's evidence focuses on orchestrating parallel coding agents, worktrees, and workspace management, not on codebase comprehension features; the only related item is a basic file-content search (⌘⇧F), which does not constitute understanding how a codebase fits together or where to start making changes.

   • [claimed-docs] “Search file contents in your current local project or cloud workspace with ⌘⇧F.”

   proof ↗⚑ flag

2. developerHave the agent map and explain an entire unfamiliar codebase without manually selecting context files

   weight 3 · round to Slate
   Slate~partialcommunity6/10

   Docs show Slate's quickstart example explicitly demonstrates asking it to 'review the architecture of my entire codebase' and generate an ARCH.md without manual file selection, and it has orchestration/subagent features for broad exploration. However there's no independent/hands-on verification that this codebase-mapping actually works well on large unfamiliar repos, and community evidence raises quality skepticism about other generated outputs. missing for 10: independent hands-on validation of full-codebase mapping accuracy, evidence of handling very large/unfamiliar codebases without manual curation, detail on how context is auto-selected under the hood.

   • [claimed-docs] “Please review the architecture of my entire codebase creating an ARCH.md and then give me ways I can improve it.”
   • [claimed-docs] “Those agents show up as a grid of inline subagent cards, one per agent.”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”
   • [community] “"Why trumpet code that is so ready for the garbage that you wouldn't even bother to publish it" - skepticism about the quality/usefulness of…”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor's evidence focuses on orchestrating parallel agent workspaces, worktrees, git branches, and collaboration—not on any built-in whole-codebase mapping or explanation capability. The closest feature is manual file-content search (⌘⇧F), which requires the developer to search rather than having the agent autonomously map/explain the codebase.

   • [claimed-docs] “Search file contents in your current local project or cloud workspace with ⌘⇧F.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”

   proof ↗⚑ flag

Context management

1. developerHave the agent build and recall memory automatically across sessions

   weight 2 · round drawn
   Slate—none0/10

   Docs describe session switching (/sessions), long multi-hour session support, and diagnostic context attachment, but there is no evidence of automatic cross-session memory building or recall — sessions appear to be manually selected/switched contexts, not an automatic memory system. Missing for higher verdict: any documentation of persistent memory storage, automatic recall of past codebase context, or memory summarization across sessions.

   • [claimed-docs] “Slate works with you across long, multi-hour sessions.”
   • [claimed-docs] “Use `/sessions` to switch between existing sessions”
   • [claimed-docs] “Slate automatically attaches relevant diagnostic information (OS, version, session context) to your report.”

   proof ↗⚑ flag

   Conductor—none0/10

   Evidence covers checkpoints (revert to earlier turn), static 'general preferences' for repo-wide instructions, and parallel workspace/session management, but nothing describes the agent automatically building or recalling memory across sessions (e.g., persistent knowledge base, learned context reuse). This is a fair axis for a coding-agent orchestration tool, so absence of evidence yields none.

   • [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”
   • [claimed-docs] “`General preferences` apply broad instructions to agents in a repository.”

   proof ↗⚑ flag

2. developerInclude multiple project directories in a single session for broader context

   weight 2 · round to Slate
   Slate~partialclaimed6/10

   Docs mention a `/workspace` manager for reviewing and removing 'workspace directories' (plural), implying support for multiple project directories in one session, but there's no detailed documentation on how directories are added or how context is merged across them, and no independent/hands-on confirmation. Missing for 10: explicit instructions/examples for adding multiple directories, and independent verification that broader multi-directory context actually works in practice.

   • [claimed-docs] “Use `/workspace` to open the workspace manager, where you can review and remove workspace directories.”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor's workspace model is built on git worktrees scoped to a single repository/branch per workspace (conductor-docs-27, conductor-docs-29), and there's no documentation of combining multiple project directories into one session. A community member explicitly requested multi-repo task support, implying it isn't currently available (conductor-comm-12).

   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [community] “I've been looking for a tool like this, that lets Claude operate on multiple repos... but all the tools for background/multiplexing are alwa…”

   proof ↗⚑ flag

3. developerAdd a project instructions file to set coding standards and conventions the agent follows

   weight 3 · round to Slate
   Slate~partialclaimed6/10

   Docs confirm Slate 'respects agent rules' in a defined precedence order and supports Skills (markdown instruction packages, including Claude Code-compatible `.claude/skills/` paths), which cover project-level conventions/instructions, but there's no explicit example of a single top-level 'instructions file' analogous to AGENTS.md/CLAUDE.md being demonstrated end-to-end. missing for 10: explicit naming/format of the project instructions file, a worked example showing the agent following custom conventions from it, and independent/community confirmation it works as documented.

   • [claimed-docs] “Slate by default respects agent rules in the following order”
   • [claimed-docs] “Skills are markdown instruction packages that give the agent domain-specific knowledge and behavior.”
   • [claimed-docs] “`.claude/skills/` | Claude Code compatibility”

   proof ↗⚑ flag

   Conductor~partialclaimed4/10

   Docs mention 'General preferences' that 'apply broad instructions to agents in a repository,' which is the closest match to a project instructions/conventions file, but there is no detail on file format, location, or how it maps to underlying agents' native instruction files (e.g., CLAUDE.md). Missing for 10: documentation of the actual file/config mechanism, examples of setting coding standards, and independent confirmation it works across all supported agents (Claude Code, Codex, Cursor, OpenCode).

   • [claimed-docs] “`General preferences` apply broad instructions to agents in a repository.”

   proof ↗⚑ flag

Issue diagnosis

1. developerReproduce issues, narrow down root causes, and verify fixes

   weight 3 · round to Conductor
   Slate~partialclaimed4/10

   Slate documents shell execution (`!`), file references, and being 'one of the few agents capable of performing integration tests manually,' which are plausible building blocks for debugging workflows, but there's no explicit documentation of a reproduce→diagnose→verify-fix workflow. Missing for 10: explicit debugging/root-cause-analysis workflow documentation, evidence of test-driven verification loops, and independent hands-on confirmation that Slate helps developers actually reproduce and fix bugs.

   • [claimed-docs] “Slate is one of the few agents capable of performing integration tests manually.”
   • [claimed-docs] “Execute shell commands directly with `!`”
   • [claimed-docs] “Use `@filename` references”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   Conductor provides isolated worktrees/workspaces where agents can run builds, tests, and setup scripts (conductor-docs-17, conductor-docs-32, conductor-docs-29), diff/PR review paths to verify fixes (conductor-docs-2, conductor-docs-21), and checkpoints to revert code/chat state when narrowing down a bad change (conductor-docs-18). These features support the reproduce→diagnose→verify loop, but the evidence is all first-party docs describing environment/orchestration features rather than direct debugging tooling (log inspection, stack traces, targeted bisection) or independent hands-on accounts of successfully reproducing/root-causing a bug. missing for 10: dedicated debugging/log-inspection features, independent user reports of using Conductor to isolate root causes or verify fixes end-to-end.

   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”
   • [claimed-docs] “Search file contents in your current local project or cloud workspace with ⌘⇧F.”

   proof ↗⚑ flag

Marketplace

1. developerEquip the agent with custom skills to perform specialized tasks

   weight 1 · round to Slate
   Slate✓fullclaimed7/10

   Slate has a documented Skills system: markdown instruction packages that give the agent domain-specific knowledge/behavior, with example skill definitions and compatibility with Claude Code's `.claude/skills/` format, letting developers equip the agent with custom specialized capabilities. Missing for 10: independent/hands-on verification that custom skills work as documented, and more detail on skill authoring/discovery beyond the single example.

   • [claimed-docs] “Skills are markdown instruction packages that give the agent domain-specific knowledge and behavior.”
   • [claimed-docs] “description: "Create distinctive, production-grade frontend interfaces."”
   • [claimed-docs] “`.claude/skills/` | Claude Code compatibility”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor orchestrates existing coding agents (Claude Code, Codex, Cursor, OpenCode) and offers 'general preferences' for broad instructions, but there's no evidence of a custom skills/plugin/tool system for equipping agents with specialized capabilities; a community request even notes the lack of 'custom tools' in its menu (conductor-comm-2).

   • [claimed-docs] “`General preferences` apply broad instructions to agents in a repository.”
   • [community] “It'd be great to change the default branch used for creating new workspaces. I'd like the ability to add custom tools to the 'Open in...' me…”

   proof ↗⚑ flag

2. engineering-leadIntegrate third-party partner-built agent apps into my workflows

   weight 1 · round to Conductor
   Slate—none0/10

   Slate is a coding CLI agent focused on subagents, skills, sessions, and model orchestration; there is no evidence of an ecosystem for integrating third-party partner-built agent apps (e.g., a marketplace, app store, or partner integration framework). Skills compatibility with Claude Code is mentioned but that is file-format compatibility, not partner app integration.

   • [claimed-docs] “Skills are markdown instruction packages that give the agent domain-specific knowledge and behavior.”
   • [claimed-docs] “`.claude/skills/` | Claude Code compatibility”

   proof ↗⚑ flag

   Conductor~partialcommunity7/10

   Conductor natively integrates several third-party agent apps (Claude Code, Codex, Cursor, OpenCode) into its parallel-workspace workflow, with per-org connection configuration and subscription/API-key support, and even exposes its own MCP server so other agent clients can manage workspaces. However, community feedback shows requests for additional partners (Gemini CLI, Amazon Q) that aren't yet supported, indicating a fixed rather than open/extensible partner ecosystem. Missing for 10: an open plugin/marketplace model for arbitrary partner agents, and independent confirmation of seamless integration beyond the listed agents.

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
   • [claimed-docs] “Sign in to your Cursor subscription for cloud workspaces.”
   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [community] “Love the design. does it build on electron? and will it support other code agents, like gemini cli, codex, opencode ext.”
   • [community] “Would be cool if I can use this with opencode, Amazon Q or whatever. I reckon the logic would be quite similar. Seen a few of these tools bu…”

   proof ↗⚑ flag

Team knowledge

1. engineering-leadCreate a shared workspace from my docs and repos as a common source of truth for the team

   weight 1 · round to Conductor
   Slate—none0/10

   Slate is a CLI coding agent focused on individual sessions, workspaces (local directories), skills, and orchestration of subagents—there is no evidence of a shared team workspace or collaborative source-of-truth feature built from docs and repos. The 'workspace' concept here refers to local directory management (/workspace), not a shared team hub.

   • [claimed-docs] “Use `/workspace` to open the workspace manager, where you can review and remove workspace directories.”
   • [claimed-docs] “Slate by default respects agent rules in the following order”
   • [claimed-docs] “Skills are markdown instruction packages that give the agent domain-specific knowledge and behavior.”

   proof ↗⚑ flag

   Conductor~partialclaimed4/10

   Conductor's cloud workspaces are shared with the whole organization and teammates can follow, reassign, or pick up the same workspace/chat, giving some sense of a shared team space tied to a repo (conductor-docs-24, conductor-docs-25, conductor-docs-16). However, there's no evidence of a workspace built from 'docs' (knowledge base, wiki, or design docs) alongside repos, or of any feature explicitly positioned as a team 'source of truth' beyond per-repo agent preferences. missing for 10: docs ingestion/aggregation into a workspace, explicit source-of-truth knowledge base feature, independent corroboration of team-wide shared-workspace usage.

   • [claimed-docs] “Workspaces and chats are shared with your organization, so a teammate can open the same workspace, follow the same conversation, and pick up…”
   • [claimed-docs] “browse everyone's work in **Home**, contribute to a teammate's chat, follow workspaces you care about, and hand work off with **Reassign to*…”
   • [claimed-docs] “Right-click the workspace and choose **Reassign to** to make a teammate responsible for it.”
   • [claimed-docs] “`General preferences` apply broad instructions to agents in a repository.”

   proof ↗⚑ flag

Tool integration

1. developerConnect the agent to workflow tools like Jira, Slack, and Google Drive to extend its context

   weight 3 · round drawn
   Slate—none0/10

   No evidence anywhere in the docs pack mentions integrations with Jira, Slack, Google Drive, or any workflow tools/MCP connectors; the docs focus on CLI usage, sessions, skills, and permissions with no mention of external tool connectivity.

   ⚑ flag

   Conductor—none0/10

   Evidence shows Conductor integrates with GitHub and Linear (issue/branch creation) and exposes an MCP server for managing cloud workspaces, but there is no mention of Jira, Slack, or Google Drive integrations anywhere in the docs or community evidence.

   ⚑ flag

2. developerKick off agent tasks directly from GitHub, GitLab, Linear, or Slack

   weight 2 · round to Conductor
   Slate—none0/10

   No evidence of any integration with GitHub, GitLab, Linear, or Slack for triggering agent tasks; Slate's documentation covers CLI usage, sessions, skills, and configuration but nothing about ecosystem/platform triggers.

   ⚑ flag

   Conductor~partialclaimed5/10

   Conductor lets you create a workspace (kick off an agent task) from a GitHub branch, pull request, GitHub issue, or Linear issue, and can trigger agent runs via GitHub Actions/scheduled routines, but there is no evidence of GitLab or Slack integration for starting tasks. missing for 10: GitLab task-kickoff support, Slack task-kickoff support, and independent confirmation of these triggers working in practice.

   • [claimed-docs] “Use Command + Shift + N or the `...` button next to `New workspace` to create a workspace from a branch, pull request, GitHub issue, or Line…”
   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”

   proof ↗⚑ flag

Cross device continuity

1. developerStart a task on one device and continue it later from another device or browser

   weight 2 · round to Conductor
   Slate—none0/10

   Docs show session management within Slate (e.g. `/sessions` to switch sessions, `Ctrl+X N` for new session) but only describe local session switching, not any cloud sync or cross-device/browser continuation mechanism. Slate appears to be a terminal-only CLI tool with no mention of a browser interface or account-based sync for resuming tasks elsewhere.

   • [claimed-docs] “Use `/sessions` to switch between existing sessions”
   • [claimed-docs] “Ctrl+X then N New session”
   • [claimed-docs] “npm i -g @randomlabs/slate”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   Cloud workspaces are shared with the organization and support handoff via 'Reassign to' and shared links, so a teammate (or the same developer on another device) can open a workspace and pick up where they left off, and cloud agents keep working after the laptop closes. However, evidence is framed around team collaboration/handoff rather than explicit single-user cross-device continuity, and local (non-cloud) workspaces are tied to the machine's worktree. missing for 10: explicit documentation of the same developer resuming a *local* task from a different device, confirmation of seamless single-user cross-browser/device session continuity, and independent hands-on confirmation of this specific workflow.

   • [claimed-docs] “Workspaces and chats are shared with your organization, so a teammate can open the same workspace, follow the same conversation, and pick up…”
   • [claimed-docs] “browse everyone's work in **Home**, contribute to a teammate's chat, follow workspaces you care about, and hand work off with **Reassign to*…”
   • [claimed-docs] “The link opens the workspace in Conductor for any member of the organization.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “Following is useful when someone else is assigned to the workspace but you want to keep it in your workflow.”

   proof ↗⚑ flag

Ide integration

1. developerChat with the coding assistant directly inside my IDE for contextual help

   weight 3 · round to Conductor
   Slate~partialclaimed6/10

   Slate is documented as a terminal-based coding agent with session management, `@filename` references, shell execution, and workspace context — providing contextual chat help that developers can run alongside their editor in a terminal. However, there is no evidence of a native IDE extension/panel (e.g., VS Code/JetBrains plugin) that embeds Slate directly inside the IDE UI itself. missing for 10: dedicated IDE extension/panel integration, evidence of in-editor chat UI beyond terminal, independent corroboration of IDE workflow usage.

   • [claimed-docs] “Use `/sessions` to switch between existing sessions”
   • [claimed-docs] “Execute shell commands directly with `!`”
   • [claimed-docs] “Use `@filename` references”
   • [claimed-docs] “Use `/workspace` to open the workspace manager, where you can review and remove workspace directories.”
   • [claimed-docs] “Ctrl+X then N New session”

   proof ↗⚑ flag

   Conductor✓fullcommunity7/10

   Conductor provides each task/workspace its own chat, terminal, diff and review path directly alongside the running coding agent (Claude Code, Codex, Cursor, OpenCode), letting a developer converse with the assistant in context of their code (conductor-docs-2, conductor-docs-27). Community reports confirm the chat works locally against Claude Code with no meaningful complaint about chat context/quality beyond stylistic preference (conductor-comm-9, conductor-comm-15). Missing for 10: no evidence of a native plugin embedding this chat inside third-party IDEs like VS Code/JetBrains (it's a separate Mac app), and no independent hands-on review of contextual-help quality beyond one HN thread.

   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [community] “There's a 'feel' to the way Claude Code outputs the text. And for input as well. Sadly, this is lost with conductor. I just don't feel as jo…”
   • [community] “Your messages are just between you and Claude Code — it all runs on your local Claude Code installation via the SDK.”

   proof ↗⚑ flag

Session management

1. developerReview diffs visually and run multiple sessions side by side in a desktop app

   weight 2 · round to Conductor
   Slate—none0/10

   Slate is documented as a terminal/CLI tool (npm install, terminal-background onboarding, hotkeys, `/sessions` switching, subagent grid) with no mention of a desktop GUI or visual diff review; session switching is terminal-based, not side-by-side desktop windows. Missing for 10: any evidence of a desktop application, a visual diff viewer, or GUI-based side-by-side session comparison.

   • [claimed-docs] “npm i -g @randomlabs/slate”
   • [claimed-docs] “Onboarding asks for your terminal background, multiline input preference, and model source: your ChatGPT/Codex subscription, SuperGrok subsc…”
   • [claimed-docs] “Use `/sessions` to switch between existing sessions”
   • [claimed-docs] “Those agents show up as a grid of inline subagent cards, one per agent.”
   • [claimed-docs] “Ctrl+X then N New session”

   proof ↗⚑ flag

   Conductor✓fullprobed8/10

   Conductor is a native desktop (Mac) app that runs multiple coding agents (Claude Code, Codex, Cursor, OpenCode) in parallel, each in its own workspace/branch/worktree with a dedicated diff and review path before opening a PR, and community users independently confirm the git-worktree-based parallel session model. Missing for 10: independent hands-on evaluation specifically praising the visual diff-review UI's quality/UX (only vendor docs describe the diff view) and no screenshots/video corroboration.

   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”
   • [community] “Oh cool, I was already doing this with git worktrees but a ui for it would be handy.”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”

   proof ↗⚑ flag

2. engineering-leadManage multiple agent-driven coding sessions from one unified workspace

   weight 2 · round drawn
   Slate✓fullclaimed8/10

   Docs describe first-class multi-session/multi-agent workspace features: `/sessions` to switch sessions, `/workspace` manager, new-session hotkey, and orchestration showing a grid of inline subagent cards while continuing to chat, queue tasks, or spin up more parallel agents — directly matching the engineering-lead's need to manage multiple concurrent agent sessions from one place. Missing for 10: independent/hands-on verification of this workspace at scale and any lead-specific team-management features beyond individual session switching.

   • [claimed-docs] “Use `/sessions` to switch between existing sessions”
   • [claimed-docs] “Use `/workspace` to open the workspace manager, where you can review and remove workspace directories.”
   • [claimed-docs] “Those agents show up as a grid of inline subagent cards, one per agent.”
   • [claimed-docs] “While one or more agents run in the background, you can keep talking with Slate: plan next steps, queue up additional tasks, or spin up more…”
   • [claimed-docs] “Ctrl+X then N New session”

   proof ↗⚑ flag

   Conductor✓fullcommunity8/10

   Conductor is explicitly built as a unified workspace for running multiple coding agents (Claude Code, Codex, Cursor, OpenCode) in parallel, each with its own workspace/branch/terminal/diff, plus team collaboration features (reassign, follow, shared workspaces) that support engineering-lead oversight. Community hands-on posts corroborate the parallel-agent workflow, though some raised concerns about permissions/data practices unrelated to the core multi-session management claim. missing for 10: independent lead-level testimony specifically on cross-team oversight at scale, and clearer evidence of a dashboard view aggregating all sessions' status for a lead.

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “Workspaces and chats are shared with your organization, so a teammate can open the same workspace, follow the same conversation, and pick up…”
   • [claimed-docs] “browse everyone's work in **Home**, contribute to a teammate's chat, follow workspaces you care about, and hand work off with **Reassign to*…”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [community] “I have been imagining something like this would be perfect for working with Claude Code... This feels like just a nice clean simple extensio…”
   • [community] “Oh cool, I was already doing this with git worktrees but a ui for it would be handy.”

   proof ↗⚑ flag

Terminal workflow

1. developerRun a coding agent locally from my terminal

   weight 3 · round to Slate
   Slate✓fullprobed8/10

   Slate ships as a global npm CLI (`npm i -g @randomlabs/slate`) that runs interactively in the terminal, with documented terminal-native features like hotkeys, shell command execution (`!`), file references (`@filename`), session management (`/sessions`), and configuration via `slate.json` — all consistent with a locally-run terminal coding agent. Missing for 10: independent hands-on confirmation of local terminal usage (community evidence only discusses porting-quality skepticism, not terminal operation itself) and no evidence of offline/non-terminal fallback limitations.

   • [claimed-docs] “npm i -g @randomlabs/slate”
   • [claimed-docs] “Onboarding asks for your terminal background, multiline input preference, and model source: your ChatGPT/Codex subscription, SuperGrok subsc…”
   • [claimed-docs] “Use `/sessions` to switch between existing sessions”
   • [claimed-docs] “Press Tab to queue the current message so it runs after the current turn finishes.”
   • [claimed-docs] “Execute shell commands directly with `!`”
   • [claimed-docs] “Use `@filename` references”
   • [claimed-docs] “Ctrl+X then N New session”
   • [probe] “official CLI documented at https://docs.randomlabs.ai/en/getting-started/quickstart”

   proof ↗⚑ flag

   Conductor~partialprobed7/10

   Conductor documents running local coding agents (Claude Code, Codex, Cursor, OpenCode) with per-task local git worktrees and a dedicated terminal per workspace, and community confirms it runs the agent locally via the local CLI/SDK install (conductor-comm-15, conductor-comm-17). However, hands-on reports show it isn't a pure lightweight local terminal wrapper—it requires GitHub OAuth/cloning rather than just running an existing local repo, and some users complain the local CLI 'feel' (e.g., Claude Code's native terminal UX) is lost inside Conductor's GUI (conductor-comm-6, conductor-comm-9). Missing for 10: independent confirmation that pure terminal-only (non-GUI) workflows are fully supported, and clearer first-party disclosure addressing the community concerns about local vs. cloud/GitHub dependency.

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [community] “Your messages are just between you and Claude Code — it all runs on your local Claude Code installation via the SDK.”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
   • [community] “I was really excited to try this but this does NOT work the way I expected. I wanted a simple git worktree manager for my existing, already-…”
   • [community] “There's a 'feel' to the way Claude Code outputs the text. And for input as well. Sadly, this is lost with conductor. I just don't feel as jo…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”

   proof ↗⚑ flag

2. developerRun the agent non-interactively in scripts for workflow automation

   weight 2 · round to Conductor
   Slate—none0/10

   The evidence shows Slate is a CLI-based interactive agent (npm install, onboarding, in-session commands like /sessions, !, @filename) but nowhere documents a non-interactive/headless mode, flags for scripted execution, or CI/automation usage; --dangerously-skip-permissions bypasses prompts but is not shown as enabling scripted/non-interactive invocation. Missing for 10: documentation of a non-interactive/print/exec mode, exit-code or piping behavior, or any CI/scripting examples.

   • [claimed-docs] “npm i -g @randomlabs/slate”
   • [claimed-docs] “We support `--dangerously-skip-permissions` (alias: `--yolo`) to bypass permission prompts.”
   • [probe] “official CLI documented at https://docs.randomlabs.ai/en/getting-started/quickstart”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   Conductor exposes a programmatic API to create workspaces, send prompts and read agent replies, and supports 'routines' to run agents on a schedule or via GitHub Action, which enables non-interactive, scripted automation of the agent outside the GUI. However, this is all first-party documentation with no independent/hands-on confirmation, and Conductor is fundamentally a GUI-first Mac app rather than a CLI tool built for scripting. Missing for 10: independent verification that the API/routines work reliably in real automation pipelines, and clearer CLI-style invocation/flags for non-interactive use.

   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Conductor
   Slate—none0/10

   No evidence of any public API for Slate — the openapi.json/swagger.json probes returned 404s and no docs reference programmatic endpoints; Slate is documented purely as a CLI/terminal agent with slash-commands, hotkeys, and config files, not an API-driven product with UI/API parity.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.randomlabs.ai/openapi.json, https://docs.randomlabs.ai/swagger.json, https://docs.rando…”
   • [probe] “official CLI documented at https://docs.randomlabs.ai/en/getting-started/quickstart”
   • [claimed-docs] “npm i -g @randomlabs/slate”

   proof ↗⚑ flag

   Conductor~partialprobed5/10

   Conductor documents a programmatic API and a hosted MCP server that let you create cloud workspaces, send prompts, and read agent replies, giving genuine API access to core agent workflows (conductor-docs-13, conductor-docs-14, conductor-docs-30, conductor-probe-4). However, the API is explicitly scoped to 'cloud workspaces' only, with no evidence it exposes local workspace/worktree management, collaboration features (reassign, follow, sharing), settings like port forwarding, or UI-specific conveniences (loadouts, sections, checkpoints) — and no OpenAPI spec is discoverable (conductor-probe-3), suggesting the API surface is narrower than the full UI. missing for 10: full parity coverage of local workspace/git-worktree operations via API, coverage of collaboration/organization features via API, and a public OpenAPI spec or independent confirmation of API completeness.

   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
   • [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
   • [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Slate—none0/10

   No evidence in the docs or elsewhere describes any data export functionality, open-format export, or data portability mechanism for Slate. Sessions, workspace history, and configurations appear stored locally but no documented export/leave path is mentioned. Missing for 10: any documentation of export commands, data format specifications, or account/data portability guarantees.

   ⚑ flag

   Conductor—none0/10

   Conductor stores workspace state, chat history, and cloud workspace data, but no evidence in the pack shows an explicit data-export feature or open-format export guarantee; while code lives in git worktrees (inherently portable), there's no documentation of exporting chats, settings, or cloud workspace metadata. Community threads even raise unresolved concerns about data practices and lack of transparency (conductor-comm-3, conductor-comm-5), reinforcing the absence of an export/leave story.

   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Slate—none0/10

   No evidence of an open-source license or public source repository for Slate; the CLI is distributed via npm install with no mention of source availability. missing for 10: open-source license declaration, public source repo link, license file/OSS registry evidence.

   ⚑ flag

   Conductor—none0/10

   There is no evidence Conductor's source is available under any open license; it is distributed as a compiled Mac app with docs/API only, and a community comment explicitly contrasts it with an open-source alternative ('Crystal... unlike Conductor is open source'), indicating Conductor's source is not open.

   • [community] “Crystal can do all of this and more, and unlike Conductor is open source.”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Slate—none0/10

   No evidence anywhere in the docs of Slate being open-source or offering a self-hosted deployment option; it's installed via npm as a CLI that connects to model subscriptions/credits, implying a hosted/service model rather than self-hostable core infrastructure. Missing for 10: any mention of self-hosting instructions, open-source repo, or on-prem deployment option.

   • [claimed-docs] “npm i -g @randomlabs/slate”
   • [claimed-docs] “Onboarding asks for your terminal background, multiline input preference, and model source: your ChatGPT/Codex subscription, SuperGrok subsc…”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor is a proprietary Mac app with a hosted cloud service and API/MCP server; there is no evidence of a self-hostable core product—no open-source repo, on-prem deployment option, or self-hosting docs are mentioned. Community even contrasts it unfavorably with 'Crystal,' which is explicitly noted as open source unlike Conductor, reinforcing that self-hosting isn't offered.

   • [community] “Crystal can do all of this and more, and unlike Conductor is open source.”
   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”

   proof ↗⚑ flag

Authentication

1. developerAuthenticate with an API key instead of an account login

   weight 2 · round to Conductor
   Slate—none0/10

   No evidence pack mentions API key authentication as an alternative to account login; onboarding docs only describe choosing a model source (ChatGPT/Codex, SuperGrok, or Slate credits subscription), not API-key auth. No mention of an API key mechanism anywhere, and the openapi probe returned 404s, giving no indication of an API-key based auth path.

   • [claimed-docs] “Onboarding asks for your terminal background, multiline input preference, and model source: your ChatGPT/Codex subscription, SuperGrok subsc…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.randomlabs.ai/openapi.json, https://docs.randomlabs.ai/swagger.json, https://docs.rando…”

   proof ↗⚑ flag

   Conductor✓fullclaimed7/10

   Conductor explicitly supports 'bring your own subscriptions and keys' and lets you configure Claude Code, Codex, and Cursor connections to use an API key instead of a subscription/account login per organization. This directly satisfies the developer's need to authenticate via API key rather than an account login flow. missing for 10: independent/hands-on confirmation that API-key auth works end-to-end without any account sign-in step, and detail on whether Conductor's own app access also supports API-key-only login (vs. GitHub OAuth).

   • [claimed-docs] “Bring your own subscriptions and keys”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”

   proof ↗⚑ flag

2. engineering-leadAuthenticate through an enterprise identity or cloud platform for compliance and scalability

   weight 2 · round drawn
   Slate—none0/10

   No evidence of SSO/SAML/OIDC enterprise identity integration or cloud-platform authentication for compliance; onboarding only mentions choosing a model source (ChatGPT/Codex, SuperGrok, or Slate credits), not enterprise identity federation.

   • [claimed-docs] “Onboarding asks for your terminal background, multiline input preference, and model source: your ChatGPT/Codex subscription, SuperGrok subsc…”

   proof ↗⚑ flag

   Conductor—none0/10

   Evidence shows only GitHub OAuth/GitHub App authentication and per-organization agent connection settings (conductor-comm-13, conductor-comm-14, conductor-docs-23); there is no mention of SSO, SAML, OIDC, or enterprise identity provider integration for compliance/scale. missing for 10: SSO/SAML/OIDC support, enterprise IdP integration, admin/compliance controls tied to identity.

   • [community] “Right now the app uses GitHub's OAuth sign in which unfortunately doesn't allow for fine-grained permissions... We're switching our sign-in …”
   • [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”

   proof ↗⚑ flag

3. developerSign in with my existing product subscription plan to use the coding agent

   weight 2 · round drawn
   Slate✓fullclaimed8/10

   Docs explicitly state onboarding lets you choose your model source as your existing ChatGPT/Codex subscription or SuperGrok subscription (in addition to Slate credits), directly matching the story of signing in with an existing subscription plan to use the agent. Missing for 10: independent/hands-on confirmation that subscription sign-in actually works end-to-end and any detail on limitations of that mode vs credits.

   • [claimed-docs] “Onboarding asks for your terminal background, multiline input preference, and model source: your ChatGPT/Codex subscription, SuperGrok subsc…”

   proof ↗⚑ flag

   Conductor✓fullclaimed8/10

   Docs explicitly state you can 'bring your own subscriptions and keys' and sign in with existing Cursor, Claude Code, or Codex subscriptions rather than requiring a separate Conductor-specific plan, with per-organization control over subscription vs API key. Missing for 10: independent hands-on confirmation that subscription sign-in works smoothly across all supported agents (only vendor changelog/docs evidence).

   • [claimed-docs] “Bring your own subscriptions and keys”
   • [claimed-docs] “Sign in to your Cursor subscription for cloud workspaces.”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”

   proof ↗⚑ flag

4. developerSign in with a personal account to get free-tier access without managing API keys

   weight 1 · round to Slate
   Slate~partialclaimed4/10

   Docs show onboarding lets users choose a model source including an existing ChatGPT/Codex or SuperGrok subscription instead of managing API keys, implying account-based auth is supported, but there's no explicit mention of a free tier or of signing in with a personal Slate account for free credits without a paid subscription. Missing for 10: explicit free-tier account sign-in flow, confirmation that 'Slate credits' option requires no payment, and any account-based (not subscription-based) login mechanism.

   • [claimed-docs] “Onboarding asks for your terminal background, multiline input preference, and model source: your ChatGPT/Codex subscription, SuperGrok subsc…”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor's docs describe a 'bring your own subscriptions and keys' model where users must sign in to their own Claude Code, Codex, or Cursor subscription or supply an API key (conductor-docs-19, conductor-docs-23, conductor-docs-7); there is no mention of a free tier accessible purely via personal account sign-in without managing credentials. Community discussion also focuses on GitHub OAuth/permissions issues, not a free-tier access model.

   • [claimed-docs] “Bring your own subscriptions and keys”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
   • [claimed-docs] “Sign in to your Cursor subscription for cloud workspaces.”

   proof ↗⚑ flag

Model choice

1. developerLet the tool automatically pick the best model for each task

   weight 1 · round to Slate
   Slate~partialclaimed6/10

   Docs explicitly claim Slate 'automatically selects the right model for the job' and also allow developers to set preferred default models per slot via `/models` or `slate.json`, suggesting a hybrid automatic+manual approach relevant to pricing/limits tradeoffs. However, there's no detail on the selection logic, cost-awareness, or independent verification that auto-selection actually optimizes for task/price. Missing for 10: independent hands-on confirmation of auto-selection quality, explanation of selection criteria (cost vs capability), and evidence of pricing-limit awareness in model choice.

   • [claimed-docs] “Slate automatically selects the right model for the job.”
   • [claimed-docs] “Set preferred default models for each slot with the `/models` dialog or `slate.json` under `models`.”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor documents manual model selection via 'loadouts' and keyboard shortcuts to switch between chosen models, but there is no evidence of an automatic mechanism that picks the best model per task based on cost/performance tradeoffs.

   • [claimed-docs] “Pick a loadout of your favorite models to quickly switch between. It’s keyboard accessible too: change models (⌃⌘ 1-5), effort (⌘⇧/), speed …”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”

   proof ↗⚑ flag

2. developerChoose which underlying AI model powers my session from multiple providers

   weight 2 · round to Conductor
   Slate~partialclaimed6/10

   Docs confirm model source can be chosen at onboarding (ChatGPT/Codex, SuperGrok, or Slate credits) and that default models per 'slot' can be set via `/models` or slate.json, showing multi-provider flexibility. However, this is framed around subscription/credit sources rather than a clear list of many independent model providers, and there's no independent/hands-on verification of switching providers mid-session. missing for 10: independent corroboration of provider switching, a full list of supported model providers, and confirmation this works reliably in practice.

   • [claimed-docs] “Onboarding asks for your terminal background, multiline input preference, and model source: your ChatGPT/Codex subscription, SuperGrok subsc…”
   • [claimed-docs] “Set preferred default models for each slot with the `/models` dialog or `slate.json` under `models`.”

   proof ↗⚑ flag

   Conductor✓fullcommunity8/10

   Conductor explicitly supports running Claude Code, Codex, Cursor, and OpenCode as interchangeable providers, with a 'loadout' UI and keyboard shortcuts to switch models per session, plus per-organization configuration of API key vs subscription for each provider. Community comments confirm interest in and some support for multi-agent/provider use, though no independent hands-on review specifically validates seamless mid-session switching. Missing for 10: independent/hands-on verification of the model-switching UX and confirmation across all listed providers beyond vendor docs.

   • [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
   • [claimed-docs] “Pick a loadout of your favorite models to quickly switch between. It’s keyboard accessible too: change models (⌃⌘ 1-5), effort (⌘⇧/), speed …”
   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
   • [community] “Love the design. does it build on electron? and will it support other code agents, like gemini cli, codex, opencode ext.”
   • [community] “Would be cool if I can use this with opencode, Amazon Q or whatever. I reckon the logic would be quite similar. Seen a few of these tools bu…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Slate—none0/10

   Slate is a CLI coding agent tool; the evidence pack contains no mention of data residency, region selection, or storage location controls. Missing for 10: any documentation of data residency options, regional storage configuration, or compliance controls.

   ⚑ flag

   Conductor—none0/10

   No evidence anywhere in the pack addresses data residency, region selection, or storage location controls for cloud workspaces; community comments even highlight lack of disclosure about where data is sent.

   • [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”

   proof ↗⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Slate—none0/10

   No evidence in the pack addresses data-training opt-out, privacy policy, or any control over model training use; the documentation covers CLI usage, orchestration, and skills but nothing about data privacy posture. Missing for 10: any privacy policy statement, opt-out settings, or data usage terms regarding AI training.

   ⚑ flag

   Conductor—none0/10

   No documentation or policy statement anywhere in the evidence pack addresses training-data opt-out or data-usage controls; in fact community reports explicitly note 'no way to find out if there's any data sent to your servers' and 'zero disclosure of data practices,' underscoring the absence of any such privacy control.

   • [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Slate—none0/10

   No evidence pack items mention data retention policies, deletion controls, or privacy settings for user data/sessions; docs cover workspace management and permissions but not data retention/deletion. Missing for 10: any documentation of data retention periods, deletion mechanisms, or export/erase controls.

   ⚑ flag

   Conductor—none0/10

   No documentation describes retention periods, data-deletion controls, or export/purge mechanisms for cloud workspace data; community feedback explicitly flags 'zero disclosure of data practices' and no way to verify what is sent to Conductor's servers.

   • [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
   • [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Slate—none0/10

   No evidence pack item mentions telemetry, usage tracking, analytics, or an opt-out setting anywhere in Slate's docs or community coverage; the closest item (diagnostic attachment on bug reports) doesn't address general telemetry opt-out. Missing for 10: any mention of telemetry collection, a privacy policy, or a documented opt-out flag/setting.

   • [claimed-docs] “Slate automatically attaches relevant diagnostic information (OS, version, session context) to your report.”

   proof ↗⚑ flag

   Conductor—none0/10

   No documentation or changelog entry describes any telemetry/usage-tracking settings or an opt-out mechanism; community commenters explicitly note there is 'no way to find out if there's any data sent to your servers' and 'zero disclosure of data practices,' confirming the absence of any documented privacy control for telemetry.

   • [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”

   proof ↗⚑ flag

Data governance

1. engineering-leadOpt out of having my code and prompts used for AI model training

   weight 1 · round drawn
   Slate—none0/10

   No evidence in the pack addresses data usage, training opt-out, or privacy policy for prompts/code submitted to Slate or its model providers.

   ⚑ flag

   Conductor—none0/10

   No evidence anywhere in the pack of a data-usage/training opt-out policy or setting; in fact community reports explicitly complain about 'zero disclosure of data practices' and no way to find out what is sent to Conductor's servers, reinforcing the absence of any documented opt-out mechanism.

   • [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”

   proof ↗⚑ flag

Pr review

1. developerHave the agent stage changes, write commit messages, create branches, and open pull requests

   weight 3 · round to Conductor
   Slate—none0/10

   No evidence in the pack mentions git operations like staging, committing, branching, or opening pull requests; documentation covers sessions, orchestration, skills, permissions, and CLI setup but not any git/PR workflow. Absence of evidence for this applicable capability means the verdict is none.

   ⚑ flag

   Conductor✓fullcommunity8/10

   Docs explicitly state each task gets its own branch/worktree, agents can be given autonomy to test/build without confirmation, and Conductor 'helps you review the diff, open a pull request, merge, and archive the workspace' — covering branch creation, staging/commits (implied by agent workflow), diffs, and PR creation. Community evidence corroborates git worktree branch isolation and GitHub integration for PR workflows. Missing for 10: explicit first-party mention of 'commit message writing' as a distinct feature and independent hands-on confirmation of the full stage→commit→branch→PR pipeline working end-to-end.

   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
   • [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
   • [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”

   proof ↗⚑ flag

2. developerInspect diffs and run checks to catch problems before merging

   weight 3 · round to Conductor
   Slate~partialclaimed3/10

   Slate's docs mention it can perform integration tests manually (random-labs-docs-16), implying some check-running capability, but there is no evidence of diff inspection, git diff review, PR-style change summaries, or pre-merge validation workflows. missing for 10: diff/change inspection UI or command, explicit pre-merge check/test running workflow, and any corroborating hands-on evidence of catching problems before merge.

   • [claimed-docs] “Slate is one of the few agents capable of performing integration tests manually.”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   Docs show each workspace has its own diff and review path, and Conductor explicitly helps you 'review the diff, open a pull request, merge' before finishing work, plus it surfaces PR comments and failing-check logs even while a cloud workspace sleeps, and agents can run builds/tests as part of setup. However, there's no detailed description of built-in linting/test-runner integration beyond agent-run builds, and no independent/hands-on confirmation that this catches real problems pre-merge. Missing for 10: dedicated CI/check-running feature docs, independent verification of diff/check accuracy, and coverage of how failing checks block or warn before merge.

   • [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
   • [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
   • [claimed-docs] “PR comments and failing-check logs now load while a cloud workspace is asleep.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”

   proof ↗⚑ flag

Safe execution

1. engineering-leadControl which external tools and integrations the agent is allowed to access

   weight 2 · round to Slate
   Slate~partialclaimed6/10

   Slate's configuration docs describe a permission system where each permission key maps to allow/ask/deny actions or fine-grained pattern objects, which supports controlling what tools/actions the agent can perform, and a `--yolo` flag exists to bypass these prompts entirely. However there's no explicit documentation of controlling specific external integrations (e.g., MCP servers, API connectors) or org/team-level lockdown for an engineering lead specifically. Missing for 10: explicit external-integration/MCP allowlist docs, engineering-lead/team-level enforcement (vs individual config), and independent verification that permission enforcement can't be trivially bypassed.

   • [claimed-docs] “Each permission key maps to an action ("allow", "ask", or "deny"), or a pattern object for fine-grained control.”
   • [claimed-docs] “We support `--dangerously-skip-permissions` (alias: `--yolo`) to bypass permission prompts.”

   proof ↗⚑ flag

   Conductor~partialcommunity5/10

   Conductor lets an org configure agent connections per organization (choosing API-key vs subscription per agent) and, after community pushback over full GitHub OAuth access, added fine-grained GitHub repository permissions or local GitHub CLI auth as an alternative [conductor-docs-23, conductor-comm-13, conductor-comm-14]. However there's no documented allow-list/deny-list for arbitrary external tools, MCP servers, or third-party integrations beyond GitHub scopes and model provider choice, and the initial full-write-access design (comm-4, comm-5, comm-6) shows the control was originally coarse and only partially remedied. missing for 10: granular per-tool/integration allow-listing beyond GitHub and model provider, admin-level policy enforcement across the org, and independent verification that fine-grained access covers all agent-invoked external services (e.g., MCP servers).

   • [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
   • [community] “Any way to have it not require full write access to your entire GitHub account?”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
   • [community] “Right now the app uses GitHub's OAuth sign in which unfortunately doesn't allow for fine-grained permissions... We're switching our sign-in …”
   • [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”

   proof ↗⚑ flag

2. engineering-leadHave the agent operate inside a sandbox when interacting with code, tools, and network resources

   weight 2 · round to Conductor
   Slate—none0/10

   The evidence shows a permission system (allow/ask/deny actions) and a --yolo flag to bypass prompts, but there is no mention of sandboxed execution, containerization, or network isolation for the agent's code/tool interactions. missing for 10: any documentation of sandbox/container execution, network isolation controls, or filesystem confinement mechanisms.

   • [claimed-docs] “Each permission key maps to an action ("allow", "ask", or "deny"), or a pattern object for fine-grained control.”
   • [claimed-docs] “We support `--dangerously-skip-permissions` (alias: `--yolo`) to bypass permission prompts.”

   proof ↗⚑ flag

   Conductor~partialcommunity5/10

   Conductor's cloud workspaces are explicitly described as spinning up in "sandboxes" and the agent can run builds/tests without step-by-step confirmation, suggesting isolated execution for cloud mode. However, the local mode (the primary use case per community feedback) uses plain git worktrees on the user's own machine with no described network/tool sandboxing, and early versions required full read-write GitHub account access with no disclosed data practices, which is the opposite of a hardened sandbox model (though later mitigated with fine-grained GitHub App permissions). Missing for 10: explicit sandbox isolation details (container/VM boundaries, network egress controls) for local workspaces, and independent confirmation that cloud sandboxes restrict network/tool access beyond marketing language.

   • [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
   • [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
   • [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
   • [community] “Any way to have it not require full write access to your entire GitHub account?”
   • [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
   • [community] “Right now the app uses GitHub's OAuth sign in which unfortunately doesn't allow for fine-grained permissions... We're switching our sign-in …”
   • [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”

   proof ↗⚑ flag

Security checks

1. engineering-leadSee license and public-code matching references for AI-suggested code

   weight 1 · round drawn
   Slate—none0/10

   No evidence anywhere in the pack mentions license compliance checks, public-code/OSS matching, or provenance references for AI-suggested code; the docs cover orchestration, skills, permissions, and CLI usage but nothing about code provenance/license scanning.

   ⚑ flag

   Conductor—none0/10

   No evidence anywhere in the pack of license compliance checks, public-code/plagiarism matching, or provenance references for AI-suggested code; Conductor's documentation focuses on orchestration, workspaces, and diffs/PRs but never mentions license or code-provenance scanning.

   ⚑ flag