Architecture

Foenix is built as a multi-agent system (MAS) - four specialised agents work together, each with a narrow role. This is what makes Foenix able to run autonomously without losing control of the outcome.

​

The two environments

Foenix has two parts that talk to each other over HTTPS: Foenix Cloud - where the agents live. They reason about your request, plan steps, generate code, and verify results. Your WordPress site - where the Foenix Connector plugin runs. It receives instructions from the Cloud, executes them on your server, and reports the result back. The Connector has admin-level access to WordPress but only acts on signed instructions from your account.

​

The four agents

Every request goes through up to four agents. Simple requests use one or two; complex ones use all four with multiple iterations.

​

Orchestrator - the lead

Receives your message, decides which execution path to take, and coordinates the other agents. It picks between paths depending on the request: a quick read-only answer, a single-step edit, a multi-step generation, an autonomous run, and so on. On a heavy, long task the Orchestrator decomposes the request: it splits the task into parts and calls a dedicated Worker sub-agent for each one. The Orchestrator is also responsible for the retry loop: if the Verifier returns a failure, the Orchestrator decides whether to try again with a new strategy or report the problem.

​

Worker - the sub-agent

Used for heavy tasks. Every Worker gets its own slice of the job, researches the context it needs (theme structure, custom post types, existing plugins, ACF fields, taxonomies), and hands the Coder a precise, scoped instruction. Because each part is handled by its own Worker, a ten-step task no longer depends on a single plan staying valid from step one to step ten. The result is noticeably higher accuracy and consistency on multi-step jobs.

​

Coder - the executor

Translates the instruction into PHP and runs it on your WordPress server through the Connector. The Coder doesn’t make decisions about what to do - only how to do it. This separation is deliberate: the agent that decides isn’t the agent that executes. The Coder reads freely but writes carefully. Every modification is wrapped in a transaction, logged before execution, and screened by the Safety Mode validator before it runs (see Safety Mode).

​

Verifier - the checker

Read-only access to your site. After the Coder runs, the Verifier checks whether the result actually matches the original request - does the page render? does the plugin activate without errors? did the meta description get added? It returns a structured pass/fail verdict. The Verifier checks whether the task was actually completed, not just whether the code ran. A plugin that activates but does nothing, or a page that renders but is missing the requested section, fails verification. If it fails, the Orchestrator gets the verdict and retries with a corrected plan.

​

How a request flows

​

Why multi-agent

A single LLM doing everything has two failure modes that matter at scale. It can’t reliably check itself. The same model that wrote the code is biased toward seeing it as correct. It can’t recover from errors during long autonomous runs. If a 10-step task fails on step 4, a single-agent system tends to either crash or hallucinate completion. Splitting roles solves both. The Verifier doesn’t share the Coder’s blind spots. The Orchestrator can detect a failed verdict and decide what to do next without needing the original context that produced the error. And because heavy tasks are split across Workers, a failure in one part is isolated: the Orchestrator retries that part, not the whole task.