Process Forge: a framework for creating AI processes

During the 2026 New Year holidays, in one of the Joomla community chats, a fellow colleague shared a prompt for an AI agent and the result of that prompt. A week before that, he had tried Gemini CLI for the first time. Until then, I had only used AI in web versions, and overall that suited me fine. When I saw that wall of text, the CLI request, and the wall of response, the first thing that hit me was:

I DO NOT WANT to learn all this stuff! Something new again, I'm tired of it...

Then came the stages of trial and error, attempts to use ready-made community skills packages from GitHub with role-based suggestion like

"you are a super-duper mega-backend Joomla developer with 40 years of experience, make it beautiful for me"

Somewhere in the middle of this half-year I started formalising my processes. And by processes I do not mean only development, but also SEO, analytics, business analysis, process study and process design, and so on. In the end, as a rule, all of that is either connected with or leads to a Joomla site. Formalisation brought me to an understanding of several basics that are common to all processes. More on that below.

Now I want to present to the honourable public my work on a framework for creating formalised work processes for AI agents: Process Forge (GitHub).

I ask experienced vibe coders to forgive me in advance for any obvious points or long-known theses if they appear here. Workload did not allow me to spend too much time searching and watching what others were doing. I had to switch myself onto new tracks.

Starting Points

To answer the questions "what is all this for?" and "why this way?", I will give several starting points that I mostly felt out through practice over these six months and from which I proceeded when creating Process Forge. Some of these conclusions later found confirmation in other people's findings that I noticed in articles or social media posts:

1. An AI model's internal knowledge about a technology stack is most often seriously behind real modern practice. This varies a lot from stack to stack. You can add "for now", but in general this is still a relevant premise.
2. For an AI agent to work properly, it needs to be given everything a human is given for work: knowledge and tools, ready-made templates for reuse.
3. An AI agent needs a certain amount of freedom, but within a defined corridor, along a specified vector.
4. You must not be tied to any one AI provider ecosystem. There must be a way to "switch the brains" (there should be no .codex, .claude, and so on as the agent's home base; there should be something neutral, even though the agents themselves try to bind you to their ecosystem).
5. All project memory and processes must be structured in files.
6. You yourself must first understand WHAT is happening, HOW, and WHY. Without that, AI will only bring more chaos into your life.

When we work with AI agents, and with AI in general, we expect the work to be done quickly and well, because this is Artificial, damn it, Intelligence. But it turned out not to be so. Instead of a shovel, you were given a turbo-excavator that says to you: "I am ploughing the field, my wheel fell off, I will quickly fix it with a temporary fallback and put a track on one side." You still have to learn how to work with this thing, and know where and how to apply it properly. I should say right away that almost everything written here is the result of my own heuristics and is therefore purely subjective. Only several months later did I get acquainted with AI Factory (link one, link two (Habr)) and GSD Core, but it was already too late, because I was already working full steam with my own tool. There may well be other similar tools.

Process Forge Concepts

I will lay out the concepts in the order in which they appeared and were tested in "combat" conditions as they evolved. This way the history and logic of the decisions will be clearer.

Process Instead of Chat

After two months of working in chat mode and with ready-made community skills packages from GitHub, with role-based suggestion like "you are a super-duper mega-backend Joomla developer with 40 years of experience, make it beautiful for me", a quick search and a discussion with AI about my own doubts around all of this led me to the conclusion that I needed to build a development process. At first, only for development.

Chat history cannot be a reliable source of project data or project memory. Every new session starts from zero for the agent: tabula rasa. The agent has to be loaded with project context: what this thing is and how to deal with it. That is why all project memory and processes must be structured and stored in files. In spring I came across the word "artifact" in the sense of "a file produced as the result of an autonomous process". As far as I can judge by what is happening in the industry, everyone is accumulating their own Markdown files: in folders, in Obsidian, or somewhere else, with different instructions, skills, and so on inside.

My request was immediately for a process, so after several days of discussion I arrived at an artifact-based development flow. It was a set of folders and files describing the rules for working with projects. They described the workflow stages that I used and improved over three months while creating Joomla libraries, plugins, and components. You can get a general sense of the stages under the cut. In a modified form, this entered Process Forge as one of the "out-of-the-box" processes.

Example process stages:

Stage	Meaning	Requires	Fills
artifact-policy	Normalises artifacts before the stages	task-record, project-context	artifact-index, missing-artifacts-created
flow-orchestrator	Chooses the current/next stage	task-record, artifact-index, project-context	stage-decision, next-skill-handoff
intake-scope	Records the task, boundaries, and success criteria	task-request, project-context	brief, scope, task-record
investigation	Gathers facts, causes, and the impact surface	brief, scope, project-context	investigation-report, impact-analysis
domain-surface	Describes domains, ownership, and risks	scope, investigation-report, impact-analysis	decision-log, updated impact-analysis
architecture-plan	Designs the solution and the order of changes	brief, scope, decision-log, impact-analysis	architecture, implementation-plan
implementation	Makes changes according to the plan	architecture, implementation-plan, decision-log	changed-files, change-summary
code-assurance	Checks, review, test cases, browser proof	changed-files, change-summary, implementation-plan	review-findings, test-plan, test-cases, browser-verification-report
release-delivery	Release packaging/delivery	change-summary, review-findings, test-cases	release-notes, migration-notes, patch
evolve	Extracts reusable lessons into rules/extensions	patch, evolution-cursor, logs	evolution-report, updated-rules-or-extensions, updated-cursor

This is one of the earlier versions of the artifact-based development flow.

In addition, the whole flow maintained task-log, agent-log, verification-log, and tool-telemetry.ndjson; the specific log depended on the stage. Telemetry records tool usage and the reasons for using those tools. For example, if MCP PhpStorm could not perform the required action or got stuck for some reason, plain shell was used as a fallback.

Connecting Knowledge to an AI Process

The knowledge built into AI models themselves usually lags behind current reality. Top paid models have some idea of recent events, but even then not always. In my subjective assessment, web search also costs AI agents more time and tokens, so all current knowledge should be close at hand, and the agent should build its context from it. Almost anything can be used as reference material:

• source code of current versions,
• snapshots (local copies) of official documentation,
• your own or other people's development articles,
• your notes with recipes for solving a particular task,
• links to sites.

I work with Joomla, so in my stash I have:

• source code of several Joomla core branches,
• source code of the main Joomla extensions I work with regularly (JoomShopping, RadicalMart, and so on),
• copies of official documentation for web full stack: manual.joomla.org, HTML / CSS / JS / PHP, and documentation for several frameworks,
• my own articles and some articles by fellow colleagues,
• documentation for various APIs, which I supplement with dumps of real responses if it is REST,

and so on. Yes, I know that Context7 exists (the service and MCP for machine documentation), but as far as I remember it started limiting requests at some point and, predictably, introduced pricing plans with request packages.

Overall, this section of the article lives in the plane of on-premise vs SaaS: either we do it ourselves for ourselves, by hand; or someone else does it for us, but for money. For now I am, as you have probably already guessed, a supporter of the former )) Naturally, with this approach you, or your AI agent, take on the obligation to keep knowledge up to date.

Connecting Tools, MCP, and Templates

Templates

I will start with templates because they are simple: in my case these are separate ready-made pieces of code that can be copied, slightly adapted, and they are ready. For an AI agent, it is better to put them into folders and give each folder a README.md describing what this template is and how to work with it.

But it does not have to be only code: design fragments, video fragments (footage), and so on. Whatever your agent works with.

Tools and MCP

By tools I mean what the AI agent can use on your device. For a developer this may include git, GitHub CLI, pipeline runs, linters, fixers, packagers/builders, local and remote test stands. For an SEO \ GEO specialist these may be small utilities for automated access to various service APIs (Yandex APIs for Wordstat and SERP data collection), Screaming Frog CLI, and so on. I suppose that a conventional video-production setup also has similar tools of its own.

The most important point is that the tool must be configured globally on the workstation so that different projects can use it in the same way: one builder instance is used across all 80 plugins you write.

MCP in this case appears as the same kind of tool, just available through Model Context Protocol. It may be Playwright / Chrome DevTools / Firefox DevTools for tasks that require a browser. It may be MCP IDE PhpStorm in my case, Serena for symbolic code analysis, and so on.

I noticed that when working with code through MCP IDE, there are fewer problems with file encodings and file-system permissions. Also, through MCP the agent can receive more information from inspections and run tests. But it can also run shell commands through the PhpStorm console, even though it already has direct access to the console, so catch it in time before it starts doing nonsense.

Processes Again

In the context of working with Joomla and its extensions, I try to work through a full engineering process: the required functionality is discussed, we plan the implementation, then write the code, run end-to-end tests, finalise and build the package, and publish a release according to semver. After that, post-release tasks roll in: update or write documentation from scratch in two languages, prepare screenshots in two languages, video in one language, publish announcements about new versions with descriptions on 15+ platforms...

As I came to understand how to work with AI agents, the results of our joint work started accumulating. A new problem appeared: when should all this be checked and published? With agents, less time was spent on code, but more time on planning and testing. And post-release tasks did not disappear...

So the next experiment was to try adapting the agent for writing documentation, preparing screenshots, and publishing all of this to the site. The file-based process that had already been worked out handled this too. With great distrust, over several dozen iterations, I began expanding the agent's area of responsibility and eventually reached full release publication. In general it works, but there is of course less human spirit in it than one would like.

Often, certain thoughts or pieces of information circle around us for a long time, appearing before our eyes several times before we notice and understand them. In this case, an understanding began to form that I was surrounded by processes of different complexity in my work. It became logical to go one level above coding and identify a universal process entity, where there may be different numbers of stages, artifacts between them, relationships, and so on. That is how Process Forge began to appear.

It now has internal processes, out-of-the-box processes, and the ability to create your own processes. Processes can branch, and a parent process can wait for the results of a child process and then continue working.

Platforms and Specialisations

Platforms

The platform entity allows Process Forge knowledge packages to be combined into pluggable packages, and lets you describe the execution environment, templates, and required tools inside them. When you start making "a new plugin for Joomla 6+ that...", the agent understands which platform is meant and adds not only Joomla knowledge to the project context, but also PHP, HTML, CSS, JS knowledge, the required checks package, code style rules, and the Phing extension packager.

Platforms can inherit from one another. For example, you are writing a plugin for the JoomShopping online store, which does not exist separately from Joomla. But JoomShopping has its own separate knowledge sets, which are not needed when working on the clean engine core or another store. And, predictably, when working with JoomShopping we also need knowledge about Joomla.

Specialisations

If our agent writes Joomla code, it needs knowledge for writing code. But if it publishes an article or works with modules on the site in the admin panel, it does not need PHP, JS, or Joomla extension architecture knowledge. It needs knowledge of the admin panel, of the REST API for faster work, maybe basic HTML and the CSS framework of your project's site, image-processing rules, media-content placement rules (what to put in which folder), and so on. That is why specialisations appeared: they combine the knowledge needed for a particular specialisation.

The point of this entity is that the backend may work with Joomla, or with Laravel, or with Django and Python. Platforms provide applied knowledge about the language, architecture, and tools. Specialisations provide general abstract context: patterns, approaches, principles. Specialisations may also connect their own knowledge, tools, templates, MCP, and so on.

Cascading Project Context Computation

In Process Forge, context is not stored in one large prompt or skill. It is computed as a cascade from several levels, by analogy with merging arrays/objects: each next level inherits the data from the previous ones and refines it for a specific situation.

General workspace rules are supplemented by company, area, platform, and project knowledge, then by process, task, and concrete agent settings. More local levels can extend or override general parameters. As a result, the agent receives not the entire accumulated mass of information, but the relevant context assembled immediately before the task is performed.

In general terms, the context-computation logic is as follows:

• Workspace
• Company / organisation
• Area (SEO, development, content...)
• Platform (Joomla, WordPress, Symfony...)
• Specialisation (backend, frontend, full stack, content, SEO...)
• Project
• Process (software development / SEO audit / ...)
• Task and current stage
• Agent role and profile (in multi-agent mode)

Each next context source is layered over the already assembled one. The result of this work is a project context snapshot (YAML for machines, Markdown for people), which states:

• platform_contracts / platform_stack: selected and available platform contracts
• resolved_parameters: final parameters after inheritance and overrides
• parameter_resolution: parameter sources, provenance, and conflicts
• resolved_context: the result of specialisations, resources, tools, MCP, templates
• resolved: final knowledge packages / resources / templates / tools / processes
• capabilities: required/optional capabilities and their status
• conflicts: specialisation and parameter conflicts
• snapshot.health.status: final state: pass, warn, or blocked
• freshness / context_policy: freshness policy and state

and some other information.

For a specific task, and in multi-agent mode, even more specific snapshot-capsules are assembled and passed to the agent together with its assignment / process / stage / task layers as machine-readable files.

The General Feedback Mechanism: Evolve

Evolve in Process Forge collects useful conclusions that appeared during work on a task: what should be remembered, improved, checked, or moved into shared experience. It does not change rules and knowledge automatically. First, it formalises such findings as proposals with a clear scope: only for this project, for the workspace, for a package, platform, or the core. Then those proposals can be checked, selected, and only then consciously included in shared materials or updates.

When a proposal turns into an updated knowledge package, template, rule, or other shared material, it is distributed through the normal Process Forge update mechanism. The project sees that an update is available, can prepare it, check it, apply it, and after that rebuild its context with the new version of shared knowledge.

Versioning

Both Process Forge itself and its entities are designed with versioning in mind. Since everything lives as files, as separate packages, you can gradually improve and expand them. Accordingly, you can have your own update server for all parts of your workplace: the Process Forge core, separately processes and platforms, separately knowledge packages and templates. For example, you made process changes after evolve from several machines: you publish a new process version. You created new instructions for working with code: you publish code_instructions_v.1.1.0, and all your workstations receive a new knowledge package. After that, local workers update project contexts and can work with the new knowledge.

Organising Work in Process Forge

In a surprising way, all of this starts to resemble structures built in human companies and organisations. I assume that the human operator should not have to know slash commands, but should simply direct agents in natural language. That is why Process Forge 2 has documentation both for people and for agents.

To get started, you need to set up your machine:

1. Install the ProcessForge distribution (unpack the archive into your agent area).
2. Run step-by-step workplace setup with a human involved (there is an auto mode, but at your own risk).
3. Configure path constants and root directories.
4. Specify roots for knowledge and local documentation.
5. Register tools and MCP servers.
6. Create or import knowledge packages.
7. Create a registry of reusable templates.
8. Create platforms from existing resources.
9. Create specialisations.
10. Connect project(s) to the workplace.
11. Create your own processes if the out-of-the-box ones are not enough.
12. Start working.

Yes, this takes time to set up the machine. But it scales, and in general it has shown itself fairly well.

Process Forge assumes two main operating modes: garage mode and forge mode.

Garage Mode (1-1-1-1)

This is the mode where there is:

• one human operator,
• one main agent session (console window),
• one project,
• one active process/run.

The main agent performs the work, runs checks, maintains artifacts, and either finishes the work or hands it off to the next stage or process.

We open a console / chat with the agent, say "immerse yourself in the project through .pf. Tell me what has been done and where we stopped?", and continue working within one project. Physically, you may have two or three independent projects open at the same time, each working in garage mode. And in this garage you have an assistant that uses your tools, uses your knowledge, uses your platforms, and works according to your templates.

Forge / Factory Mode

This is a multi-agent mode where work is divided into independent streams.

Your main agent becomes an orchestrator that receives input data, chooses the process, creates assignments with context capsules, then starts agent sessions (full-fledged agents or subagents), coordinates them, and makes sure agents do not interfere with one another. Then it collects their results and integrates the outcome through result handoffs and reviews.

In this way, work on a project becomes similar to the work of a team or department on a project. They need to be coordinated, and therefore there appears...

Agent Director is a workplace-level role for organised coordination of several agent sessions, processes, or projects. It is not needed in garage mode, but it is needed where there are handoffs, waiting for a suitable executor, errors, parallel work by several orchestrators, or the need to explicitly transfer responsibility. Project agents and orchestrators can send signals to the Director's inbox: for example, that a task is blocked, another executor is needed, an error occurred, or an operator decision is required. Such messages form cases, which the Director takes into account during the next coordination pass.

At the same time, in the current ProcessForge implementation the Director is not a constantly running independent LLM agent. In the PF model it is described as an agent role, but it is executed as a CLI coordination layer: it checks the handoff queue, agent availability, leases, and the state of open cases, but it does not perform tasks itself and does not launch agents. In the future, this role can be developed into a full AI agent that reasons about priorities and complex routes, but for now it is a deterministic mechanism for managing workplace coordination.

The watchman's log. To make it comfortable for agents to work in a Process Forge workplace, there is a "watchman's log" where agents who have "come to work" are recorded. It shows who entered the process, what they saw, what they did, where they stopped, and what risks they left for the next participant.

The log helps quickly restore the course of work without searching through all files and messages. This is important because work can move between agents, tasks, and runs, while the log preserves context continuity. And it is not a separate agent; it is a CLI tool, so we do not spend tokens here.

Given that your computer is turning into a kind of company branch or small office, it may later have not only a Director and a watchman. Over time, it may get a "facilities manager" (some kind of background process) that checks whether anything needs to be done with the workplace: send candidates for improving knowledge packages to a central hub for release, or receive new knowledge packages and intelligently update the contexts of all projects. Or perhaps there may be a "cleaner" (a process that occasionally launches an agent for smart cleanup). But these are already fantasies, somewhat detached from reality ))

Conclusion

In some articles about AI development I have encountered similar ideas: you need to build a pipeline that performs tasks of the same type. The times, apparently, are such in AI that it is easier to create your own custom tool than to take someone else's and adapt to it, or try to customise it. Nevertheless, I will risk sharing my work with the IT community in a field that is completely new to me. I hope it will be useful to someone.

• Process Forge on GitHub
• This article on Habr
• This article on web-tolk.ru