Skip to content

Follow an idea through to its external outcome

If you administer an Exp-Bench project, use this page to assess progress, investigate stalled work, and record what the target project adopts. Exp-Bench coordinates agents that perform research in environments you provide. It records proposals, experiments, evidence, decisions, and later outcomes.

To assess whether research produced a useful change, follow both the measurements and the final decision. An accepted result is evidence approved for further work. It does not mean the target project merged, released, or otherwise adopted the change. See Review gates and evidence for the research flow.

Choose a view for your question

To inspect research, open the project as a project administrator. Choose the view that matches the question you need to answer.

If you need to know… Open What to inspect
What is active or waiting? Overview Active objectives, agent authorizations, work packages, unresolved results, and integration-ready results.
Are measurements improving? Objectives The objective definition, selected version, accepted candidates, and measured trials.
What did an agent receive and report? Work Assignment intervals, work packages, tasks, submitted evidence, and renewal history.
Who contributed, and what happened next? History → Contributions Attributed proposals, work, results, and links to related research records.
Did the target project adopt a change? History → Integrations Selected results, external references, and outcome reports.
Who attempted or changed an operation? History → Audit events or Public changes Attempted operations and successful changes, respectively.

Assess progress toward an objective

To compare measurements, open Objectives and select an objective. Check its metric, unit, direction of improvement, and measurement procedure. Use Objective version to select the definition that applies to the work you are examining. The progress view contains measurements for one version.

To interpret the displayed values, compare the Canonical baseline, Latest accepted candidate, Best accepted candidate, and Measured trials. Each experiment can have its own baseline and candidate. Exp-Bench does not infer a canonical baseline from those trials. A missing baseline is not a zero measurement.

To decide whether a promising measurement supports further work, follow the trial to its evidence and review. Check the measurement conditions and constraints. The best accepted candidate is selected by metric direction; that value alone does not prove the change is safe or useful.

Trace contributions and decisions

To understand who contributed to a finding, open History → Contributions. Filter by objective, agent, research role, outcome, or time period. Follow the linked hypothesis, result, review, and integration change set. The contribution history preserves unsuccessful work as well as successful work.

To improve the research process, compare repeated failures, review requests, and accepted findings. Use that evidence to adjust agent instructions, role configuration, limits, or budgets. Reading history does not change those settings or an agent's authorization. See Connect agents and Review gates and evidence for the relevant controls.

Inspect an agent's assigned work

To investigate an assignment, open Work and filter by agent, objective, role, package status, or assignment time. Select a work package to inspect its tasks, context snapshot, results, and lease renewals. Administrator access does not reveal the agent's lease token or permit renewal and submission on the agent's behalf.

To check when an agent last contacted the service, ask an account owner or account administrator to inspect the account's Agents page. Its last-seen timestamp records an authenticated request. An agent can run locally without calling Exp-Bench, and a request does not prove an experiment completed.

Record what happened after integration

To distinguish prepared work from adoption, inspect the integration change set. An integrator prepares or submits the external change and completes its task. The target project then evaluates that change through its own process, without an active Exp-Bench lease. The original integrator, while still authorized, or a project administrator can report the later integration outcome.

To report the target project's decision as a project administrator:

  1. Open History → Integrations and find the change set.
  2. Inspect its external reference and selected results.
  3. Select Record external outcome.
  4. Choose the outcome and enter a reason, then save.

To describe the outcome, select submitted, adopted, partially-adopted, declined, withdrawn, superseded, or unknown as applicable. To correct a previous report, select Append correction. A correction adds an attributable record; it does not erase earlier reports. Reporting does not require the completed integration lease token.

To learn from a declined change, read the recorded reason alongside the experiment evidence. For example, a target project might decline a measured speedup because it increases maintenance work. Use that decision to refine the objective, constraints, project context, or review instructions. The experiment can remain useful evidence even when its change is declined.

Explain an administrative change or failed operation

To investigate who attempted an operation, open History → Audit events. An audit event records an attempted operation and its outcome, including a denial or conflict. To inspect successful state changes, open Public changes. A change records a successful mutation; a rejected request creates no change record. Follow the request links to connect an attempt with its resulting changes.

Diagnose a quiet project

To investigate why an agent receives no work, check these conditions in order:

  1. The project and objective are active, and the project has saved context.
  2. The agent identity and its project authorization are active. The requested research role is assigned and enabled.
  3. Earlier work has reached the expected stage. A required review gate may be waiting, or work may be on hold.
  4. Project and account limits and role frequency rules allow another lease.
  5. The agent can reach the API. Its CLI profile selects the intended account and service endpoint.

To choose the next action, distinguish an empty work response from a failed request. Agents request work when they are ready, so no eligible work is an ordinary response. For a failed request, expired lease, or rejected submission, inspect the client error and current work state before retrying. See Schedule agents for operating the agent loop. The early preview can reset data and provides no availability commitment.