Existing tests.
Flexible tools.
Clear evidence.

CARBON adds testing guidance, workflows and evidence discipline. Your agent provides code access, command execution, browser tools and model access. CARBON helps turn that environment into a more systematic testing workflow. See the testing workflow guide.

Often, no. An agent can use an available command-line tool, API, browser or code library to work with another system. Ask CARBON to use those capabilities rather than wait for a purpose-built connector. The route still needs to be available and authorized. A working API or browser session does not automatically grant permission to change data.

It can support a wide range of workflows, but the practical boundary is what your agent, model and environment can actually do. Unsupported protocols, missing credentials, unavailable dependencies, restricted networks and limited host tools can block execution. Start with a small end-to-end example before relying on a new workflow.

It does not have to be. Start by letting CARBON use the tests and conventions you already have. Add exploration, new coverage or a different output format when that helps. Migration is a choice, not a prerequisite.

Yes. CARBON can run existing pytest tests without requiring conversion. Give the agent the repository, the usual test command and the required environment. The Python version, packages, fixtures, secrets and services those tests normally need must still be available. Preserve the original suite unless you explicitly request edits.

Ask CARBON to use the project’s native test runner and conventions. The important check is whether the host can execute that stack and capture its results. A successful pytest pilot does not establish compatibility with every runner, plugin or proprietary harness. Validate a representative suite for your environment.

Yes. You can request conversion into another framework or an AI-first format, or keep the tests exactly as they are. Specify the target format and which behavior must remain equivalent. Review converted assertions, fixtures, setup and teardown before adopting the result.

Ask for original files to remain unchanged and for a mapping from each source test ID to any converted test or reported result. Retain native runner output alongside the CARBON report. Treat this as an explicit acceptance requirement, then verify the mapping; do not assume every format preserves identifiers in the same way.

You can ask the agent to create tests and help investigate maintenance failures. Dedicated test generation, repair and durable management workflows are also described in Pro. General agent-assisted work and packaged product workflows are different things; select the edition for the workflow you need.

Require a diagnosis before a repair. Compare the failure with the intended behavior, review the diff, and rerun the original case plus relevant neighboring checks. Do not silently weaken assertions, drop coverage or change expected results merely to obtain a green run.

By default, CARBON tries to use the available AI-first browser controls. You can instead tell it to use Selenium, Playwright or another browser framework or driver. The selected tools must be supported by the host environment, installed and able to reach the target.

Yes. State the framework, browser, version constraints and existing project conventions at the start. Ask the agent to report which driver actually ran. If it cannot use the requested setup, have it stop and explain the blocker rather than silently substitute a different browser or execution route.

Yes, when the environment performing the test can reach the application. A local browser or runner can test a local development server without making it public. A remote runner has a different network boundary. Confirm where the browser and application run, including containers, VPN access and required internal services.

The installation guide covers Claude Code, Claude Desktop through Cowork, Codex through CARBON Studio Lite, Cursor and Antigravity. Setup and available interfaces vary by host and edition. Ordinary Claude or ChatGPT web chat is not the same as installing the local coding-agent package.

Yes. CARBON also runs as an MCP server for compatible environments, including noncoding hosts. The host still needs model access and the tools required to perform the work. Supporting MCP alone does not guarantee that a client provides browser control, a shell or local project access.

Do not assume so. Clients differ in permissions, tool availability, sandboxing, model configuration and interface support. For a fair comparison, hold the target build, test data and requested scope constant, and record the actual tools used.

Yes, through a host or execution setup that supports your selected model. You can point the workflow at a local open-source model instead of a cloud model. Validate that the model can use the necessary tools and produce reliable results for your workload. Running the model yourself still consumes compute and operational resources.

Yes. CARBON can work with model access configured for the host, including Azure and other public or private cloud setups. Endpoint support, authentication, model capabilities and organization policies must be compatible with the chosen host. This is not a claim that every client can connect directly to every provider.

The documented default uses the coding agent’s configured model access. Eligible subscription allowance or API billing applies through that route. Optional services and direct-model checks can have their own costs. Check the active billing configuration before a large run.

CARBON and the separate Codex Studio Lite package are MIT open source; the installation page describes no CARBON signup requirement for the free offering. Pro is commercially licensed and CARBON Cloud is separate. Model, hosting and third-party service charges may still apply. Consult current plan details rather than assuming a free package makes the whole workflow free.

No. Local files and local execution are separate from model inference. A cloud-connected agent may send code, screenshots or other context to its model provider. Review the complete data path, including integrations, reports and telemetry settings. Local-only requirements need an appropriately configured and verified end-to-end setup.

Use synthetic or appropriately de-identified data for an initial pilot. Before using regulated or confidential data, have your organization approve the environment, providers, access and retention rules. CARBON’s testing capabilities are not a compliance certification or permission to send sensitive data to a model or third-party service.

You can ask CARBON to export results into JUnit XML, a pytest-compatible result format, or another format your team needs. Be specific about the consumer and schema. CARBON’s documented portable reports include HTML and JSON. A custom export is a workflow to validate, not a promise that every downstream system accepts it unchanged.

Name the exact artifact you need. For example, pytest can produce JUnit XML, while a team may use a particular plugin’s JSON schema or preserve the runner’s console output. Supply a sample or schema where possible. Avoid treating “pytest format” as one universal interchange standard.

Yes, you can ask for those workflows using capabilities available to the host, such as APIs, command-line tools or browser access. A dedicated CARBON connector is not necessarily required. Provide the authorized project or run, required fields and mapping rules. Verify a small sample before allowing bulk writes.

Check schema validity, test counts, stable IDs, names, timestamps, durations, status mapping and evidence links. Distinguish failed assertions from infrastructure errors, skipped tests and unexecuted work. Confirm that retries and parameterized cases are represented correctly for the receiving system.

A narrative summary alone is not enough. Retain runner output, exit status and available screenshots, traces or logs. Record the target build and environment. Clearly separate planned checks, generated tests, executed checks and findings supported by observation. Investigate discrepancies between the summary and underlying evidence.

The result should explain what could not run and why. A missing credential, inaccessible app, unavailable browser or failed setup is not a passing test. Preserve partial results and list the next action needed without inventing outcomes for the remaining scope.

Improve reproducibility by recording the application commit, test revision, data seed, configuration, model and host versions, browser and dependencies. Save prompts and evidence where policy permits. Repeat critical checks with deterministic assertions. Exploratory paths and model outputs may vary even when the starting conditions look similar.

Use confidence together with the tested scope, evidence freshness and important gaps. Passing checks do not establish that every user journey works or that the application is defect-free. Define your critical risks and acceptance criteria before the run, then compare the evidence with those criteria.

An automated workflow needs a runner that can execute the required tools without an interactive session, approved credentials, a reachable target and machine-readable outputs. Validate exit behavior, timeouts, artifact retention and failure handling. Start with a bounded job; do not infer unattended CI readiness from a successful interactive session.

Use least-privilege test accounts and approved secret handling. Define whether the agent may edit code, install dependencies, create issues or change external data. Keep human review for consequential actions, release decisions and changes to expected behavior. A testing instruction is not unlimited permission to modify production.