ProcessForge 1.2.0 Released: Performance Optimizations and Improved Reliability

ProcessForge 1.2.0, a new version of the open-source framework for organizing and running processes involving AI agents, was released on 18 October 2026. This release focuses primarily on optimizing PF's internal mechanisms, improving the reliability of long-running processes, and resolving issues encountered in practical work with multiple AI agents.

Optimizing Work with Large Volumes of Data

In Forge / Factory multi-agent mode, ProcessForge can launch separate, independent AI agent sessions (workers). Each worker receives its own assignment (Assignment), a context capsule (Capsule) containing the necessary knowledge and instructions, and a limited area of responsibility (Scope).

This allows several agents to work on different parts of a project in parallel without interfering with one another.

During extended work with workers launched through the command shell (shell workers), large volumes of logs, events, and task execution history began to accumulate. A problem emerged: some PF operations repeatedly read and parsed data that was not directly relevant to the current work. As the history grew, this created unnecessary overhead.

Version 1.2.0 reworks several mechanisms.

1. Moving Event Journals to SQLite

Previously, NDJSON journals were used to store project and hook events. When the history grew large, some operations required records to be read repeatedly.

Project events and raw hook events (raw hooks) are now stored in two local SQLite databases with indexes.

This makes it possible to find the required records quickly, check that events are unique, and process new data without repeatedly scanning the entire accumulated history.

PF does not require a separate database server to be installed. Shell worker output logs, telemetry, and session transcripts remain separate files.

2. Faster Selection of the Current Work

In PF, work is defined by a specific Run (a process run), Assignment, and associated context. Previously, even when the required assignment was specified explicitly, the system would sometimes scan the project's entire Run and Assignment history. Now, when the identifiers have been unambiguously verified, PF goes directly to the selected work without iterating over the other assignments.

On a synthetic project with 400 Runs and 800 Assignments, the number of reads required for this selection dropped from 1,202 to 4, while the operation time fell from approximately 3.2 seconds to 5–6 milliseconds.

3. Reusing Parsed YAML

ProcessForge uses YAML to describe processes, assignments, settings, and other structured data. Repeated reads of unchanged documents can now reuse an earlier parse stored in process memory. PF still checks the current file contents. If a document has changed, the system parses it again. Access control and context integrity checks remain enabled.

Improved Recovery After Worker Failures

In multi-agent mode, the Process Execution Inspector monitors tasks carried out by external workers. It tracks the state of launched processes, their activity signals (heartbeat), completion, and results. Once an assignment has been carried out, the Inspector gathers the required artifacts through the collect mechanism. During extended work, a worker may finish while result collection fails.

Previously, persistent automatic collection errors could cause an operation known to be failing to be repeated. PF now distinguishes between temporary errors, where a retry makes sense, and persistent failures that require a separate recovery step. Results that have already been collected remain in the history. Assignment execution state and Runtime health are displayed separately. This helps prevent the results of an agent's lengthy work from being lost because of a problem during result processing.

Safely Continuing Work in a New Session

Another feature of long-running AI processes is the need to continue work after an agent's session ends. ProcessForge provides a Continuation mechanism. It allows a specific Work to be resumed while retaining its association with the Run, Assignment, context capsule, and selected process. When work resumes, the system checks its state, permissions, and context freshness again. The new session does not gain the right to replace the assignment, expand the Scope, or choose another task on its own simply because the earlier conversation context is unavailable.

Expanded Capabilities of the ProcessForge MCP Server

Version 1.2.0 significantly expands the set of tools available to AI agents through MCP. Previously, the PF MCP server mainly provided access to project context, knowledge search, Work creation, and process stage management. Many operations, especially those involving the launch of other AI agents, required PF command-line tools. Additional Core capabilities are now available directly through MCP.

Managing Workers

In Forge / Factory multi-agent mode, the orchestrator distributes work among separate, independent AI agent sessions. Each worker receives a limited assignment (Assignment), a prepared input context, and its own area of responsibility (Scope).

Four tools have been added for managing workers through MCP:

• pf.worker.prepare — prepare the worker's input data, context, and constraints.
• pf.worker.start — launch the worker through the selected registered Runtime Driver. The launch is asynchronous: control returns to the orchestrator immediately.
• pf.worker.status — check execution status, with support for state reconciliation and collection of completed results.
• pf.worker.collect — collect the worker's results and verify the report, checksums, and execution attempt details.

During preparation and launch, you can also specify the model (model) and reasoning effort (reasoning_effort).

The orchestrator can therefore manage the worker lifecycle through MCP without manually invoking CLI commands.

PF's constraints still apply: a worker can only be launched through a registered agent driver, with a specific Assignment and a pinned context.

Continuing Work Across Sessions

The tools pf.continuation.status, pf.continuation.create, and pf.continuation.resume have been added. They allow previously started work to be found, a continuation point to be created, and work to be resumed in another AI agent session. The specific Run, Assignment, pinned process, and immutable context are preserved. The new session does not gain the right to choose a different assignment arbitrarily or expand its area of responsibility.

Searching for Knowledge Within a Work

The new pf.work.search and pf.work.resolve tools allow agents to search for and retrieve resources permitted for a specific assignment. Unlike the general pf.search, which works with project context resources, these tools also take into account the permissions pinned to the Work and the constraints of the current process stage.

Discovering Available Commands

The tools pf.actions.list and pf.actions.describe have been added. They allow an agent to find out which CLI commands and MCP tools are supported by the installed version of ProcessForge, which parameters they accept, and which parameters are required.

• pf.actions.list describes the actions available in the installed PF version, their names, and their purpose. The catalog can be filtered.
• pf.actions.describe describes the exact parameters of the selected action: required fields, types, permitted values, constraints, and declared side effects.

The tools pf.runtime_driver.list and pf.runtime_driver.describe have been added for working with drivers. They show which drivers are registered and available in PF without exposing their internal launch commands or environment variables. These tools help the orchestrating AI agent choose how to execute a Work. A driver defines how PF passes prepared work to a worker, removing the need to guess launch methods, paths, commands, or arguments. When this information was unavailable, an agent would often inspect the executable's source code to find those details. The workflow is now more convenient.

Session Management and Message Recording

The tool pf.session.heartbeat has been added to renew an existing session's registration in the Agent Ledger (the PF workplace's "gatekeeper's log"), along with pf.chat.record for recording an agent's message in its own session log. The new pf.work.cancel tool allows an agent's assignment to be cancelled. All tools that change state retain authorization checks. The relevant operations require an explicit apply: true.

Why Were These Changes Made?

The goal is to give AI agents a unified programmatic interface for working with ProcessForge. The orchestrator can now use MCP to obtain context, manage Work, launch workers, monitor their state, collect results, and continue work across sessions.

The workers themselves do not have to connect to the PF MCP server: they can work independently with a context that has already been computed and prepared, and return results through the defined contract. This reduces dependence on command-line tools and a particular runtime environment while preserving PF's control over processes, permissions, and results.

Clearer Instructions for Agents Entering a Project

The root AGENTS.md is now the main entry point into a project. It contains the mandatory contract for an agent's work with ProcessForge: how to obtain context, select or continue a Work, stay within its area of responsibility (Scope), and move through process stages. A problem arises during extended work: AI agents tend to append new rules, conclusions, and instructions to AGENTS.md. The file gradually grows, while different AI clients have their own limits on the amount of instructions they load. As a result, some rules may fall beyond the available limit and never reach the model's context.

PF 1.2.0 adds a mechanism for checking the size of startup instructions (Instruction Accounting).

The mandatory PF contract is limited to 4,096 bytes. The system can also check the size of the entire file and the chain of included instructions against explicitly configured limits for a particular AI client. If it detects a risk that mandatory instructions will be truncated, PF blocks the relevant change. If warning mode is configured, it reports that the limit has been exceeded.

PF does not automatically shorten or rewrite the user's instructions.

Separate diagnostic profiles are available for different AI clients. They help assess which files should be loaded and whether they fit within the known limits. Whether the instructions actually reach the model requires a separate check. The mechanism is intended to prevent accumulated instructions from causing an agent to miss the mandatory rules for working with the project. These checks run when the entry point is prepared, changed, or diagnosed; they do not continuously monitor the file in the background. The 4,096-byte limit applies to the PF-managed contract, rather than the whole of AGENTS.md.

Prepared workers can also begin work with instructions and a capsule that have already been supplied, without connecting to their own PF MCP server or creating the Work again. This reduces unnecessary context and preserves the division of responsibility between the orchestrator and workers.

Managing Temporary Files

Project temporary files should now be placed in .pf/tmp/, with separate directories allocated to workers. The optional PF app-server now supports configurable notifications about temporary files that have not been modified for a long time. PF does not delete them automatically: workers may still be using them.

What Does This Mean in Practice?

ProcessForge continues to evolve as a framework independent of any particular AI model or runtime environment. In the simple Garage mode (the 1-1-1-1 mode: one person, one project, one agent, one run), a single agent can work with a project without starting the PF app-server. The entire project history, including the history of decisions, is stored in the project's .pf directory.

In Forge / Factory mode, multiple workers can operate in parallel with separate contexts and assignments, controlled access to resources, result verification, and work handoffs between sessions. All of the "project bookkeeping" remains in the project's .pf directory, but a shared process, pf-app-server, is required to organize the workflow correctly. It is optional in Garage mode.

The changes in version 1.2.0 are primarily intended to keep this system responsive and manageable as the project, task count, and accumulated history grow.

Upgrade process: when upgrading from an earlier version, preserve the state of your projects and perform a separate migration of the old event journals (tell the agent to use the suggested migration tool).

ProcessForge — processes, knowledge, tools, and execution control for AI agents.