Collaborators
Methods & reproduction
Distributed agent collaboration
Scientific research, with the project, its methods, and compute in one place. Start from a research question, and hand the work to collaborators, AI, and a fitting computing environment.
- 01ResearchersSet the question and the acceptance criteria.
- 02AgentPrepare the next step. Leave existing conclusions alone.
- 03ComputeRun where the data already is.
From a question to results others can build on.
Target architecture · In developmentResearchers
GitHub contributors
Agent suggestions
Define tasks
Shared project
Inputs · Methods · Criteria
OpenPero coordination
Dependencies · Permissions · Dispatch
Claim & dispatch
Agent Worker
Code & tools
Compute nodes
Models & experiments
Submit artifacts & records
Deliverables
Code · Data · Reports
Independent review
Verify · Review · Accept
Back to the project
Results · Records · Next steps
Target architecture, not live. Execution, verification, and acceptance are recorded separately.
Technology & deployment
- Desktop / Web
- Electron → GPUI Web / WASM (gpui-kit / Zed) → Restricted bridge → Rust Host
- Host / Agent
- Rust Runtime → ACP Rust SDK → Coding Agent. The Host manages workspaces, permissions, and execution.
- Coordinator / Worker
- Go manages tasks, workers, and leases. Workers connect outbound; ACP connects the Host to agents.
- Result / Review
- Fixed artifact version → Independent verification → Human acceptance → Authorized publication
A self-hosted coordinator, connected to trusted execution nodes.
Why a project
Continue the study from where it stopped.
Keep the question, materials, analyses, and judgments. When you return, you can see what is done and what still needs checking.
A change becomes concrete work.
When new data or a related paper appears, state the impact first, then propose a task. Follow your rules. Do not rewrite an existing conclusion on its own.
Find the right people and tools.
Hand the task to a collaborator, an AI, or a compute node. State the inputs and the delivery. Check it together when it comes back, instead of only receiving “done”.
From an Issue,
to a result you can check.
How does damping change the response?
Same model, different conditions.
Not split yetWaiting for you
1Propose the work2Confirm and dispatch3Run and review4Back to the project
01 / One clear piece of workINPUT
◉ISSUE #12 · example id
Compare the response across three damping ratios
Reuse the project's model. Run ζ = 0.08, 0.22, and 0.40. Submit the curves, numerical error, and full parameters.
Research contributionCan be reproduced on its own
InputsInitial state v1 · three damping ratios
MethodRK4 / 1.0.0
DeliverablesResult data + run record
Check101 points / run · RMSE < 0.001
This does not read or publish a real Issue. Switching the source clears this demo.
02 / Connect the workCOORDINATE
P
OpenPero coordinatorTask dependencies · where it runs · acceptance criteria
Needs confirmation01
Rerun the existing baselineζ = 0.08 · local workerWaiting for the task draft
Local worker○02
Run the parameter comparisonζ = 0.22 / 0.40 · node routing sketchCan run in parallel with the baseline
Remote node · illustration○03
Review the result independentlyDepends on 01 + 02 · a contributor claims itOpen to claim after computation
Open to claim○This page simulates all three roles. No remote process is started.
03 / Results return to the projectREVIEW
Waiting for a result that can be reviewed.
Every run carries its inputs, method, and parameters. A successful run is not the same as research acceptance.
Three parameters, seen together.Needs review
ζ 0.08ζ 0.22ζ 0.40
| Damping ratio | RMSE | Numerical check |
|---|
Automatic checks finished. Waiting for a contributor review.
↳
Write it back to the project, and keep the path that produced it.
Only a confirmed result updates this page's project record.
ACTIVITYThe example Issue is ready. Turn the goal into tasks first.
UNDER THE HOOD
Where did this result come from? Compute it again yourself.
The task demo uses a classic damped oscillator. Every curve on this page is computed with RK4 and compared with the analytical solution at the same parameters. This is a separate parameter bench. Recomputing here does not overwrite the task record above.
Research project / local exampleINTERACTIVE DEMO
✦
Next: compare with the baseline first
Use the existing method, run the current parameters, then look at the response curve and the numerical error. The run record can be downloaded.
Preset suggestion demo · no background agent connectedChange the parameters and compare with the baseline.
DAMPED OSCILLATOR / RK4
Baseline ζ = 0.08This run ζ = 0.22
—
— / run
—
RUN 001 · dt 0.10 s
A runnable numerical experiment, not a reproduction of a real paper. The suggestion is a preset example. Refreshing the page resets the record.
02 — From the result back to the process / a working example
Where this figure came from,
open it and see.
See the inputs, method, and parameters used in this analysis, then check the result. This example compares a numerical solution with an analytical one. It does not prove a research conclusion.
PROJECT / OSCILLATORRUN 001
The process can be checked. The conclusion is still yours.
04 — BUILT TOGETHER, ONE CONTRIBUTION AT A TIME
From a small task,
into a larger project.
Contribute code, and also methods and review.
A clear input and one independent delivery are enough to start.
No official repository is linked yet. These are editable Issue templates. Nothing is published to GitHub.
The code is open, and the work can be continued.
OPEN WEB + DESKTOPTask definitions, methods, artifacts, and acceptance criteria should be inspectable, exportable, and reusable.
OPTIONAL HOSTED COORDINATION