Architecture

Documentation Index

Fetch the complete documentation index at: https://docs.foenix.ai/llms.txt

Use this file to discover all available pages before exploring further.

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 Worker plugin runs. It receives instructions from the Cloud, executes them on your server, and reports the result back. The plugin 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. 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.

​

Architect — the planner

Used for complex tasks. Researches the relevant context (themes, custom post types, existing plugins, ACF fields, taxonomies), decomposes the task into clear ordered steps, and prepares any assets the Coder will need.

​

Coder — the executor

Translates the plan into PHP and runs it on your WordPress server through the plugin. 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. 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.