Human-Agent-Society has published Reef, open-source infrastructure that links agent inference, interaction feedback, learning and versioned delivery. For developers, the immediate consequence is that one system can manage updates to model weights or to an agent harness—including its prompts, rules and skills—rather than leaving learning and deployment as separate pipelines (Reef repository).
One loop, two update surfaces
Reef divides a learning cycle into four stages. Serve handles requests and records interactions; Observe matches later feedback to those records; Grow produces updates from eligible records; and Commit applies a configured selection policy before publishing accepted versions. The repository maps those stages to its service, storage, training, evaluation, artifact-history and delivery modules (Reef architecture).
A deployment recipe determines what changes. Weight-oriented recipes can train model parameters through Slime and SGLang, while harness-oriented recipes can modify prompts, rules and skills using a model endpoint rather than local training GPUs (Reef learning surfaces).
For weight training, Reef documents OpenAI- and Anthropic-compatible inference endpoints. Each response carries an interaction record ID that a later report can reference; reports may include a numeric score plus textual or structured feedback. The project says that once a recipe has sufficient eligible feedback, it can run a training step and synchronize updated weights to the serving runtime without restarting Reef (Reef usage guide).
The documented harness-evolve path uses a model API instead of a local GPU training stack. In its coding tutorial, a failed report can trigger a candidate skill update; Reef compares that candidate with the current harness on three coding tasks and publishes it only if it wins (harness-evolve example).
Different infrastructure, shared release gate
The two paths impose different prerequisites. Model-weight training needs a trainable model, feedback usable by the selected recipe and a supported GPU stack. Harness optimization needs a model endpoint, representative tasks and an evaluator, but no local training GPUs (Reef requirements).
Both paths converge on the Commit stage. Reef applies the configured selection policy there and publishes accepted updates through its version-management and artifact-delivery components; the project also lists remaining live during updates as a built-in capability (Reef workflow).
Analysis: Evaluation becomes the release gate
Analysis: Reef’s consequential design choice is the separation of update generation from publication. A completed training step or harness edit does not automatically become the delivered version; candidate evaluation and selection intervene first. That makes the system more controlled than a loop that applies every generated change, although the control is only as useful as the policy and evaluator configured for it (Reef Commit stage).
The unresolved trade-off is between automating more of the improvement cycle and retaining confidence in what gets accepted. Reef can standardize interaction records, update jobs, version history and delivery, but harness operators must still supply representative tasks and an evaluator. A narrow evaluation can therefore become a narrow release gate: the infrastructure enforces the decision, while the recipe operator determines what evidence counts (Reef harness requirements).
Top comments (0)