MindForge: Agentic Learning Systems and Frameworks

Updated 16 August 2026

MindForge is a name shared by distinct agentic-learning systems that use structured interaction, persistent experience, and executable environments for embodied cultural learning, source-free software engineering, or model–harness improvement.
The Minecraft system combines theory of mind, communication, and episodic, semantic, and procedural memory, raising task completion from weak-agent baselines as low as 5–7% to as high as 87% in instructive learning experiments.
The software-engineering and Macaron-V1 systems show complementary paths to improvement: trajectory distillation raises Qwen3.6-27B’s ProgramBench score from 37.98% to 49.51%, while versioned harness search achieves 122/122 task coverage without changing model weights.

MindForge is a name used by several distinct research systems: an embodied-agent framework for theory-of-mind-mediated cultural learning in Minecraft (Lică et al., 2024); a source-free program-synthesis pipeline for teaching small LLMs whole-life-cycle software engineering (Chen et al., 29 Jul 2026); and an agentic reinforcement-learning control plane for recursive model–harness improvement in Macaron-V1 (Lab et al., 10 Aug 2026). These systems share an emphasis on extended interaction, structured experience, and persistent improvement, but they differ substantially in domain, architecture, learning mechanism, and empirical claims. The name is also related to FlowForge, a visual design environment for multi-agent workflows (Hao et al., 21 Jul 2025), and AgentForge, an immersive platform for learning agentic software engineering (Fang et al., 4 Aug 2026).

1. Scope and disambiguation

The three MindForge systems address different meanings of agentic learning. The Minecraft system concerns social cognition and cultural transmission between embodied agents. The software-engineering system constructs source-free environments and distills complete program-reconstruction trajectories into a smaller LLM. The Macaron-V1 system coordinates task discovery, executable rollouts, evaluation, harness search, adapter training, versioning, and deployment lineage.

System	Primary domain	Central mechanism
MindForge (Lică et al., 2024)	Embodied agents in Minecraft	Structured theory of mind, communication, and memory
MindForge (Chen et al., 29 Jul 2026)	From-scratch software engineering	Source-free environments and trajectory distillation
MindForge (Lab et al., 10 Aug 2026)	Continual agentic learning	Model–harness co-design and recursive self-improvement

Despite the shared name, these systems should not be treated as versions of one unified framework. Their commonality is conceptual rather than genealogical: each treats agent performance as dependent on more than isolated next-token prediction. The relevant additional structures are, respectively, partner models and cultural memory; complete software-engineering workflows; and versioned runtime configurations coupled to model adapters.

2. MindForge for embodied cultural learning

The first MindForge extends the Voyager open-ended Minecraft agent with explicit perspective taking and social learning (Lică et al., 2024). Voyager combines an automatic curriculum generator, a reusable skill library, and iterative prompting that generates Mineflayer JavaScript, executes it, observes environmental feedback, and refines the program. MindForge retains these components while addressing two weaknesses identified for open-weight Voyager agents: isolated learning and dependence on a highly capable proprietary LLM.

MindForge defines lifelong cultural learning as a process in which an agent performs tasks in an open-ended environment, interacts with other agents, acquires task and environment knowledge, stores that knowledge in long-term memory, retrieves it later without necessarily communicating again, and generalizes it to related or novel tasks. The experiments distinguish instructive learning, in which an expert teaches a weaker agent, from collaborative learning, in which agents with similar capabilities learn together.

The architecture contains four principal mechanisms:

an explicit structured Theory-of-Mind representation;
perspective taking;
natural-language communication;
multiple memory systems.

Its conceptual information flow is:

$\text{Perception}+\text{Task state}+\text{Interaction history} \longrightarrow \text{Beliefs} \longrightarrow \text{Planning/code generation} \longrightarrow \text{Action}.$

The system represents percepts, beliefs, desires, intentions, and actions using a causal structure inspired by the Belief–Desire–Intention model and the BigToM causal template. Percepts may originate from sensory input, the Minecraft API, or a partner’s report. Beliefs describe the world, the task, the agent’s own situation, or another agent’s situation. Desires are objectives supplied by the automatic curriculum or collaborative exchange. Intentions are concrete plans, and actions are executable Mineflayer programs.

Each agent maintains a self-model containing task beliefs, interaction beliefs, perception beliefs, and partner-perspective beliefs. For every collaborator, it maintains a separate BigToM-style model of presumed perceptions, beliefs, desires, intentions, and actions. This corresponds conceptually to nested beliefs such as $B_i(B_j(s))$ , or agent $i$ ’s belief about agent $j$ ’s belief concerning state $s$ .

Perspective taking is implemented through prompting. Before generating a message, the agent is instructed to construct a mental model of the partner, ask targeted questions, resolve contradictions against its own world model, and provide advice once sufficient information is available. The Interaction LLM converts free-form chat into structured beliefs, with at most five concise beliefs and at least one belief relevant to task completion.

Communication uses Minecraft’s asynchronous text chat through Mineflayer. A dedicated Interaction LLM interprets messages but does not directly control environmental actions. Communication is turn-based, with each agent allowed at most three messages per round. In the current system, agents are forced to converse before acting because communication initiation is not reliably autonomous; the weak agent is hard-coded to send the first message.

MindForge includes episodic, semantic, and procedural memory. Episodic memory records task attempts, failures, error messages, social interactions, partner-specific information, and collaborator behavior. Semantic memory stores generalized task and environment knowledge, such as mining prerequisites, tool requirements, technology-tree relationships, and strategies abstracted from successful interactions. Procedural memory stores reusable Mineflayer programs for mining, crafting, smelting, placing blocks, killing mobs, and exploration.

The intended learning cycle is:

$\text{Conversation episode} \longrightarrow \text{Episodic record} \longrightarrow \text{Generalized semantic belief} \longrightarrow \text{Improved future plan}.$

The principal evaluation uses Minecraft, MineDojo, Mineflayer, LangChain, and built-in chat. The primary metric is task completion rate over 24 independent trials, focusing mainly on collecting one block of dirt and one block of wood. Open-weight Voyager baselines perform poorly: Mistral-7B achieves 7% on dirt and 5% on wood, Mixtral-8×7B achieves 27% on both, and GPT-4 achieves 100% on both. MindForge without interaction increases Mistral-7B performance to 37.5% on dirt and 33.3% on wood, while Mixtral-8×7B reaches 29.15% on dirt and 50% on wood.

Instructive learning produces larger gains. With a human expert and a Mixtral-based weak agent, dirt completion reaches 87%. With GPT-4 as expert, Mistral-7B reaches 54.16% on dirt and 45.85% on wood, while Mixtral-8×7B reaches 66.66% and 70.8%, respectively. The expert corrects false beliefs, such as confusing grass blocks with dirt or assuming that tools are required to mine dirt, and diagnoses code errors such as invalid direction variables.

Collaboration between equally weak agents is not uniformly beneficial. Two Mistral-7B agents achieve 33.3% on dirt and 20.8% on wood; two Mixtral-8×7B agents achieve 29.15% and 45.85%. These results can be equal to or worse than non-interactive MindForge because agents may reinforce correlated errors. The reported evidence therefore supports informative, perspective-guided teaching rather than communication as an intrinsically beneficial operation.

Post-collaboration results indicate limited persistence and transfer. For Mixtral-8×7B, dirt completion increases from 29.15% without collaboration to 41.66% after collaboration, while wood completion increases from 50% to 58.33% in an out-of-distribution post-collaboration condition. The study provides evidence for a restricted form of cultural transfer, but its evaluation covers only two simple tasks and does not establish full lifelong accumulation across the Minecraft technology tree.

3. MindForge for source-free software engineering

The second MindForge constructs training environments for complete program synthesis from scratch (Chen et al., 29 Jul 2026). It targets a setting in which an agent must recreate a command-line program without access to the original implementation. The agent receives only a compiled reference executable serving as a behavioral oracle and sanitized public documentation such as a README or manual page.

This setting differs from conventional software-engineering benchmarks that expose an existing repository and ask an agent to fix a bug, implement a feature, or resolve an issue. The source-free agent must infer the specification, probe the executable, design an architecture, create source and build files, compile the replacement, test it, diagnose behavioral mismatches, refine the implementation, and submit a final build.

The targeted life cycle consists of:

specification exploration;
architecture and design;
implementation;
verification;
bug localization;
bug fixing;
refinement;
final submission.

The pipeline begins with 2,235 candidate repositories drawn from curated “awesome CLI” collections. Repositories are pinned to identifiable commits and screened offline. The explorer agent checks for a clear primary executable, useful local behavior, an observable interface, absence of mandatory public internet access, feasible cleanroom packaging, and assertable behavior. After screening, 1,206 programs remain.

A build agent constructs a reproducible mindforge_build.sh script that builds the reference executable, preferably builds an instrumented coverage executable, places artifacts at fixed paths, and works from a clean checkout. The host performs a fresh replay in a new sandbox. For each behavioral check, the fresh build must match the original build in exit code, standard output, and standard error. The reference executable is also inspected for source leakage before it is placed in a Docker cleanroom containing only the compiled executable, sanitized documentation, and runtime scaffolding.

Of the 1,206 screened programs, 1,002 survive build discovery and packaging across 15 languages. Teacher rollouts use Mini-SWE-Agent and GLM-5.2 on 562 unique programs in six compiled languages: Go, Rust, C, C++, Swift, and TypeScript. The teacher must inspect documentation, probe the reference, implement a replacement, compile it, test it, diagnose failures, refine the implementation, and issue the explicit completion command.

A complete trajectory is retained when the teacher issues the completion command, avoids crash, timeout, or context exhaustion, and produces an executable through its emitted compile.sh. The resulting corpus contains 1,001 complete trajectories, with a mean of 181.6 turns and 177K tokens. A 256K-token training-length filter leaves 973 trajectories for supervised fine-tuning.

The trajectories cover the full engineering process. Specification exploration appears in 99.1% of trajectories, design in 87.1%, implementation in 99.7%, verification in 83.7%, bug localization in 59.4%, bug fixing in 62.6%, and refinement in 64.2%. The conditional coverage of bug localization and bug fixing is 80.8% and 85.2%, respectively, among trajectories with a failure opportunity; refinement reaches 79.5% among trajectories with a successful-check opportunity.

MindForge refines trajectories through infrastructure-noise recovery and local reasoning rewrite. Infrastructure-noise recovery replays completed tool calls in a fresh cleanroom and resumes generation from the first unfinished turn. Local reasoning rewrite removes malformed tool-call events while preserving tool calls, arguments, environment responses, and later actions byte-for-byte; only affected reasoning text may be rewritten, and a safety checker verifies consistency.

The refined trajectories are used to fine-tune Qwen3.6-27B. All language-model weights are updated, unused vision components are frozen, and training and inference use bfloat16. The configuration uses MS-Swift with the Megatron backend, sequence packing, a micro-batch size of 1, a global batch size of 96, eight epochs, AdamW, peak learning rate $4\times10^{-5}$ , linear warm-up over 10% of steps, cosine decay to $4\times10^{-6}$ , gradient clipping at norm 1.0, and random seed 1105. Loss is applied only to assistant reasoning, natural-language responses, and tool-call tokens.

On ProgramBench, fine-tuning raises Qwen3.6-27B from a 37.98% average pass rate to 49.51%, an absolute gain of 11.53 percentage points and a relative improvement of 30.4%. MindForge-27B outperforms the base model on 152 of 200 instances, underperforms on 43, and ties on 5. On seven unseen software-engineering benchmarks, it improves by 31.00 percentage points on RepoZero-C2Rust, 14.16 on DeepSWE, 10.70 and 4.56 on NL2Repo-Bench with and without tests, 5.04 on SWE-bench Verified, 5.93 on SWE-bench Pro, 5.22 on SWE-bench Multilingual, and 4.94 on FeatBench.

Behavioral analysis indicates that fine-tuning produces longer and more persistent workflows. Mean turns increase from 344.0 for the base model to 735.7 for MindForge-27B, while mean tool calls increase from 174.4 to 373.0. Total token use increases by 5.7×, and command failure rate decreases from 10.98% to 9.35%. The fine-tuned model also more often converts reasoning into implementation edits: editing follows reasoning in 50.1% of cases, compared with 27.8% for the base model, and follows failure recovery in 48.8% of cases, compared with 31.8%.

Reference-behavior coverage increases from 49.34% mean and 52.14% median for the base model to 58.39% mean and 66.47% median for MindForge-27B. Coverage is higher on 154 of 200 tasks, and the number of tasks reaching at least 50% coverage increases from 104 to 131.

The evidence supports transfer from complete, tool-mediated engineering trajectories to multiple benchmarks. However, the paper does not isolate the effects of source-free environments, long trajectories, teacher quality, trajectory refinement, filtering, or language diversity. It also does not demonstrate multi-generation compounding, and trajectory acceptance is based primarily on completion and buildability rather than a universal hidden behavioral-success threshold.

4. MindForge as a recursive model–harness control plane

The third MindForge is the agentic reinforcement-learning control plane of Macaron-V1 (Lab et al., 10 Aug 2026). It orchestrates recursive self-improvement by treating the trainable system as a versioned model–harness pair rather than as model weights alone. Its responsibilities include problem-bank construction, executable rollouts, trajectory evaluation, harness and configuration search, trajectory selection, LoRA adapter training, model and harness versioning, evaluation, and deployment lineage.

The central lineage is:

$(\text{problem bank},\text{model},\text{HCP}) \longrightarrow \text{evaluated trajectories} \longrightarrow (\text{dataset},\text{next model},\text{next HCP}).$

Here, HCP denotes the Harness Context Protocol, a versioned TOML contract that records model and provider selection, working directory, backend, context and generation limits, tool allowlists, MCP servers, prompts, skills, hooks, session snapshots, workspace resources, environment variables, secret references, and visibility policies.

MindForge is not the model, adapter router, tool substrate, benchmark evaluator, optimizer implementation, or serving engine. It is the lifecycle and provenance layer connecting these components. Compute-heavy operations are delegated to pluggable benchmark and training backends. A model checkpoint without its problem-bank version, selected data, runtime configuration, and evaluation evidence is treated as an incomplete experiment record.

The agent policy is represented as:

$\pi_{\phi}(a_t\mid o_{\leq t};\theta,c),$

where $B_i(B_j(s))$ 0 denotes frozen base-model parameters, $B_i(B_j(s))$ 1 denotes trainable LoRA parameters, $B_i(B_j(s))$ 2 denotes a versioned harness configuration, $B_i(B_j(s))$ 3 denotes observations and conversation history, and $B_i(B_j(s))$ 4 denotes a model-visible action. An episode is recorded as:

$B_i(B_j(s))$ 5

where $B_i(B_j(s))$ 6 contains task-level outcomes and process-level judgments. Actions may be natural-language messages, clarifications, discrete tool calls, or expressions executed in a stateful REPL. Adapter selection is handled separately by the MoL Proxy and is not itself a tool call in the model’s action space.

MindForge operates against production-like harnesses. UI4A is a component-native generative-UI harness with imports, components, state, and actions. Each UI action has origin, state, execution, and visibility fields, including NoAI fields hidden from the model. The REPL agent harness provides executable composition, validated reuse through save_tool and promote_tool, and ToolProxy wrappers for external services. A stateful action substrate determines whether intermediate values remain resident in executable state or are returned to the model as text.

The recursive self-improvement loop has three stages:

Discovery: generate harder tasks by lifting constraints, introducing hidden preferences, chaining subgoals, or embedding contradictions; retain tasks with verifiable answers or evaluation rubrics that provide learning value.
Expansion: execute accepted tasks under a fixed model–HCP pair, evaluate task and process behavior, and audit failures for model-, task-, or harness-level causes.
Update: filter invalid and duplicate trajectories, retain validated and informative examples, train LoRA specialists, register the accepted HCP, and link all artifacts to the parent generation.

MindForge supports improvement in both configuration space and parameter space. AutoResearch changes prompts, skills, scaffolds, tool-use policy, tool exposure, hooks, and other HCP resources. LoRA training transfers selected trajectory behavior into adapter parameters. The paper calls this transfer “context learning,” while distinguishing it from ordinary in-context learning.

The training backend uses GRPO to update LoRA adapters while keeping the base model frozen. The paper provides the policy and trajectory definitions but does not specify a complete GRPO objective, reward function, group size, advantage estimator, clipping threshold, KL term, optimizer-update schedule, or exact task-mixture weights. Reward and evaluation are benchmark-dependent and may include task success, exact match, tool-use correctness, need fulfillment, process quality, safety-relevant behavior, UI compilation, rendering, interaction, or terminal completion.

The most direct MindForge experiment isolates Expansion. Starting with a frozen GLM-5.2-FP8 base that failed all 122 selected tasks, adaptive HCP and skill search eventually reaches 122/122 unique task coverage without changing model weights. The final phase with stop-gate hooks obtains 65 passes from 80 attempts, compared with 49 passes from 76 attempts during skill and HCP search. This result demonstrates configuration-search reach, not weight improvement, generalization, or recursive learning across generations.

Macaron-V1 uses Mixture-of-LoRA to maintain separately versioned specialists over a frozen base. Venti contains Chat, Agent, Coding, and GenUI adapters; MindForge can update one specialist without modifying the base or necessarily changing other adapters. The MoL Proxy routes user turns to specialists and records routing metadata, but MindForge itself does not perform per-turn routing.

The system’s principal unresolved issue is causal attribution. The reported end-to-end results do not determine whether gains arise from LoRA specialization, MoL routing, UI4A, REPL composition, HCP search, trajectory selection, GRPO, MinT, LongStraw, or interactions among them. The release also does not demonstrate multi-generation compounding, broad transfer from self-generated tasks, or collective intelligence from independently owned adapters.

FlowForge provides a complementary design perspective by treating multi-agent workflow construction as human-guided exploration of a hierarchical design space (Hao et al., 21 Jul 2025). It organizes workflow development into task planning, agent assignment, and agent optimization. Its Design Space View presents candidate hierarchies and scatter-plot comparisons, while its Canvas View provides editable node-link workflow representations, design-pattern cards, execution results, runtime, and user ratings.

FlowForge supports breadth-first exploration through “Try Another One” and depth-first refinement through “Looks Good, Continue.” Its pattern catalog includes Sequential, Parallel, Reflection, Redundant, Supervision, Discussion, and Single Agent. Recommendations are generated heuristically by GPT-4o and connected to workflow patterns and metrics, but they are not empirically calibrated performance models.

The framework is relevant to MindForge because it preserves alternative designs, separates high-level decomposition from local configuration, and links architectural decisions to observed metrics. Its limitations are equally relevant: it does not provide formal workflow optimization, automatic Pareto-front computation, dynamic topology modification during execution, reproducible metric definitions, or robust runtime adaptation. These limitations are especially consequential for embodied or long-running environments such as those considered by the Minecraft and Macaron-V1 systems.

AgentForge addresses a different but related problem: teaching humans to participate in agentic software-engineering workflows (Fang et al., 4 Aug 2026). Learners assume one of four roles—Task Planner, Patch Author, Code Reviewer, or Test Runner—while AI agents perform the remaining roles. The workflow is:

$B_i(B_j(s))$ 7

Its design exposes handoffs, transcripts, files, status, routing decisions, prompts, plans, patches, review notes, and test evidence. The system uses workflow pauses, role-specific briefings, decision points, and an editable AI Coach to support metacognition.

In a study with 37 novice developers, task completion reached 100% for Task Planner, 100% for Patch Author, 80.6% for Code Reviewer, and 93.5% for Test Runner. Code Reviewer required approximately two human turns, six AI turns, two reroutes, five minutes of active response time, and seven minutes of completion time, making it the most demanding role. Self-reported workflow understanding increased from 3.8 to 4.3, understanding of the value of multiple AI agents from 3.3 to 4.3, and preparedness to participate in software-repair workflows from 3.4 to 4.0.

AgentForge also exposes a limitation of scaffolding: among 130 human turns submitted after an AI Coach request, 85.4% exactly reproduced the Coach draft and 88.5% were at least 95% text-identical. Completion and conceptual learning therefore do not establish independent critical evaluation. For MindForge, the relevant design implications are explicit human decision points, visible intermediate artifacts, role-based participation, adaptive difficulty, and eventual fading of assistance.

6. Comparative significance and limitations

The three MindForge systems collectively frame agent improvement as a process involving structured environments, persistent artifacts, and long-horizon interaction. The embodied system emphasizes socially mediated learning: agents improve by representing partners’ beliefs and transferring knowledge through communication and memory. The software-engineering system emphasizes trajectory-level procedural supervision: models learn complete cycles of specification discovery, implementation, verification, debugging, and refinement. The Macaron-V1 system emphasizes versioned model–harness evolution: task distributions, runtime configurations, rollouts, adapters, evaluations, and deployments form a linked recursive process.

Their evaluation limitations differ. The Minecraft study covers only two simple tasks, uses hard-coded communication initiation, depends on GPT-4 as an expert, and does not directly benchmark theory-of-mind accuracy. The source-free software-engineering study uses a restricted pool of offline command-line programs, accepts buildable trajectories without a universal behavioral-success threshold, and does not isolate the causal contribution of its pipeline components. The Macaron-V1 report lacks full multi-generation evidence, a complete RL specification, causal ablations, and a held-out generalization interpretation for its adaptive configuration-search experiment.

Several common misconceptions should be avoided. MindForge for Minecraft does not establish human-like Theory of Mind; improved task completion is evidence consistent with useful perspective taking, not a direct measurement of mental-state inference. MindForge for software engineering does not merely train isolated code generation; its distinctive supervision consists of long, tool-mediated workflows, but its performance gains do not prove that every trajectory component is causally necessary. MindForge in Macaron-V1 is not itself a new RL objective or an autonomous self-improvement engine; it is a provenance-preserving orchestration and control plane whose demonstrated capabilities include configuration search and artifact linkage, while multi-generation compounding remains unestablished.

A unifying interpretation is that the MindForge name denotes systems that move beyond static model checkpoints toward structured experience. In one case, experience is encoded as beliefs, memories, and partner models. In another, it is encoded as source-free reconstruction trajectories. In the third, it is encoded as versioned problem banks, harness configurations, evaluated rollouts, LoRA revisions, and deployment lineage. This suggests a broad research direction in which capability depends jointly on model parameters, interaction protocols, executable tools, memory or state substrates, evaluation contracts, and the mechanisms used to preserve and transfer experience.