DOCUMENTATION / YOUR FIRST INVESTIGATION
Develop your question
into a useful experiment.
Start with your chosen agent and a question precise enough to test. Give the project a shared home in Unclosed, then keep the reasoning close as you explore different approaches.
This guide combines available pilot steps with the intended experiment workflow. API integration requires setup; automatic conversation capture, collaborative documents, and custom comparison views are planned. Public experiment execution remains disabled.
01 / ASK
Make the question testable.
Work this out in your agent conversation first. “Find a better search algorithm” leaves too much open. Try: “Does method B match method A’s accuracy on our synthetic dataset, using the same evaluation budget?”
Your research brief
- Question
- Can the simpler method match the baseline?
- Comparison
- Same fixed inputs, seeds, and evaluation budget.
- Primary measure
- Accuracy on held-out examples.
- Decision rule
- Declare the acceptable difference before seeing results.
- Limitations
- A synthetic dataset may not represent real-world use.
Try it in the pilot: create a project and put this brief in its description or discussion. Invite someone to challenge the assumptions.
02 / INVESTIGATE
Design a fair comparison.
Identify the baseline, document the input versions, choose the controls, and agree on the evaluation. A coding agent can help you implement the plan; a separate review should challenge whether the implementation actually tests it.
The intended workflow keeps your agent conversation connected to a shared research brief, implementation, and review. A research plan is a proposal; executable work needs its own finite authorization.
03 / TEST
Keep the test and its evidence together.
The built campaign model specifies exactly what can run: code, inputs, environment, configurations, seeds, deadline, and allowance. The results implementation records signed artifact inventories, checkpoints, and verified downloads. These execution features remain gated for public customers.
Successful software execution answers “Did the process finish?” Evaluation answers “What does the result support?” Those are different questions. Cleanup confirmation is a separate operational fact.
Explore the example workflows →HOW THE EXPERIMENTS RUN
Run independent experiments without buying more hardware.
You do not need to build a supercomputer to run many independent experiments. The execution model separates the machines doing the work from the storage keeping your inputs and results. Each approved run gets temporary compute that can shut down once the work is finished, while durable storage keeps its inputs and results.
- Prepare and approve. Pin the code, environment, inputs, and seeds. Set a finite budget, deadline, attempt limit, output limit, and maximum number of simultaneous runs.
- Queue and start. Cloudflare Workers coordinate the work. The experiment itself runs in a temporary Cloudflare Container: an isolated CPU Python batch environment. Available slots start approved runs; additional runs wait.
- Run in parallel. Independent experiments can execute at the same time. For example, 20 approved runs with a concurrency limit of four use up to four slots, with waiting runs admitted as capacity becomes available. This is an illustration, not a plan limit or a capacity guarantee.
- Save the evidence. Inputs and sealed result artifacts live in durable object storage (R2). Logs, outputs, and run records let you inspect what happened after the temporary machine is gone.
- Shut down and release capacity. When a run finishes, fails, or is stopped, cleanup tears down its compute. Capacity is released only after teardown is confirmed. Saved artifacts remain separate from that temporary compute.
What you gain
Explore different seeds, parameter choices, and competing methods without keeping a fleet of machines running between studies. Parallel runs increase the number of independent tests you can do; they do not combine into one giant shared-memory computer.
Compute and storage have different lifetimes.
Shutting down compute ends that instance’s running work. Retained storage and other provider services can still incur charges. Campaign allowances bound authorized work; they are not a complete provider invoice. Preserved code, inputs, and environment records support later replay, which may require new compute and approval.
04 / BUILD ON IT
Let the result change the next question.
Suppose the simpler method matches the baseline on this dataset. That supports a limited finding; it does not establish that the method works everywhere. A useful follow-up would test a different data distribution.
If it fails, preserve that outcome too. Record the conditions, the evidence, the limitations, and the next question. That record becomes a better starting point for collaborators and future agents. In the pilot, add your conclusion to a project discussion and link external results manually. Automated comparison views and collaborative result documents are planned.
A finding worth keeping
Observation: what happened in this test?
Evidence: which outputs and evaluation support it?
Limit: where does the conclusion stop?
Next: what would be most useful to test now?