Get started
Reason
AgentsQuoxMindAgentic TeamsMirrorQuoxLensRemember
QuoxMemoryBrain2CompoundingQuoxPlanCodebase MirrorAct
QuoxFlowQuoxEngineQuoxAgentQuoxChatAutonomyRun
EnterpriseOrganisationsPowers & ToolsmithQlusterQuoxBastionInterfaces
QuoxMCPQuoxCLIQuoxTerminalQuox ConsoleQuoxBoxGovern
HITL ApprovalsQuox SecurityAgent HonestyQuoxVaultAI GovernanceAgentic AIProve
For AuditorsVerifiable AI OpsLoggingEU AI ActCompliance SuiteChannels
Matrix RoomsDiscord ProTelegram ProQuoxSignalCoreCommsAll products A-ZBuild
QuoxProofDeveloper KitPlugin SDKBring your tool to QuoxQuoxpertQuoxSkillsQlarityShip and sell
Build and sellBrowse MarketplaceDownloadsProtocolsDev Suite
Dev ServersQuoxBuildQuoxSlotsShared Skills + RulesDev workflow
RepoBrainGripeTriageFixLoopProofLoopDoneEngineAll products A-ZGet started
OverviewArchitectureProtocols
AEEAOCLVOLTWARDReference
GlossaryAPI ReferencePlugin SDKDockerAll products A-ZPlugins that just add UI panels are not particularly interesting. Plugins that bring their own specialist agents, with their own tools, their own policies, and their own audit trails, are a different proposition entirely.
Most plugin systems are essentially UI injection. A plugin adds a tab, renders some data, maybe exposes a settings panel. The platform does the thinking. The plugin is decoration.
That model breaks down when plugins need to do real work. A GitHub integration that only shows issues is not much better than a bookmark. A system maintenance view that displays backup status but cannot actually run a restore is a dashboard, not a tool.
The question we kept running into: what if a plugin could bring its own agent? Not a wrapper around the platform's AI. A specialist, with domain-specific tools, registered in the sidebar, governed by AOCL policy, and auditable through the same envelope system as everything else.
FORGE is the specialist agent inside the GitHub Operations plugin. It shipped on 17 March with the full plugin, from skeleton to production, in a single day.
The plugin itself has six phases of functionality: a GitHub API client, an issues board, a feedback tab, the FORGE agent, a release management view, and a close-the-loop feed with AOCL policy gates. But FORGE is the part that makes it more than a GitHub mirror.
FORGE MCP tools:
These tools are registered through the Model Context Protocol, the same way every other QuoxCORE tool is exposed. FORGE does not get special treatment. It uses the same tool registration, the same credential vault, the same audit envelope system. The difference is that FORGE knows what to do with them.
Ask FORGE to triage open issues and it will pull the list, categorise by label, and flag anything that has been open without a response for more than 48 hours. Ask it to prepare a release summary and it will walk the commit history, cross-reference merged PRs, and draft notes. These are not prompt tricks. They are structured tool chains that FORGE executes through MCP, with every step logged.
The first version of the GitHub plugin shipped on 17 March. By the morning of 18 March, it had been audited and substantially reworked. Nine rounds of fixes across two days.
| Round | Area | What changed |
|---|---|---|
| R1 | Security | All GitHub API calls now proxy through the collector. No direct browser-to-GitHub requests. Tokens never leave the server. |
| R2-R3 | Integration | Organisation mapping, vault integration for credential storage, and UI fixes for the setup wizard. |
| R4-R5 | Policy | Server-side policy enforcement. Feedback pipeline hardening. Every update operation now writes an audit log entry. |
| R6 | Auth options | GitHub App OAuth, device flow, and personal access token. Three authentication paths so the setup works for individuals, teams, and organisations. |
The lesson here is not that we shipped fast. It is that the plugin architecture supported this kind of rapid iteration. Each round touched only the GitHub plugin's code. Nothing in the core platform changed. The agent registry, the sidebar, the credential vault, the audit system: all of those are stable interfaces that the plugin builds against.
One detail worth calling out: the feedback pipeline. Users submit feedback through the dashboard. That feedback now flows directly into GitHub as issues, tagged, categorised, and linked back to the original submission. When the issue is resolved, the user gets notified.
This is the close-the-loop feed, built in Phase 5 and gated by AOCL policy in Phase 6. The policy gates mean that issue creation, label changes, and status transitions all pass through the orchestration control layer. Not because GitHub needs governance, but because the actions happen on behalf of the organisation and should be traceable.
Every feedback-to-issue conversion generates an AEE envelope. The intent, the action, the outcome, and the agent that performed it are all recorded. If someone asks "who created that issue and why," the answer is in the audit trail, not in someone's memory.
KEEPER is the second specialist agent to ship in the same week. Where FORGE is outward-facing (GitHub, issues, code), KEEPER is inward-facing. Its domain is system continuity: backups, restores, updates, and the operational health of the platform itself.
KEEPER lives inside the System Maintenance plugin, which was simultaneously redesigned from a scattered collection of views into a single unified interface with four tabs: backups, restores, updates, and a release management checklist.
What KEEPER does:
KEEPER is not an assistant that tells you what to do about backups. It is an agent that handles backups. The distinction matters. When KEEPER runs a backup, it uses the same MCP tool interface as any other agent, the operation is logged through AEE, and the policy layer determines what KEEPER is permitted to do without human approval.
FORGE and KEEPER are the first two examples of a pattern that we expect to become the default: plugins that ship with their own specialist agents.
The architecture makes this straightforward. A plugin declares its agent in the manifest. The agent registers in the sidebar. It gets its own tool set via MCP. It is governed by AOCL policy like any other agent. Its actions are recorded via AEE like any other operation. The plugin does not need to understand the governance system. It just builds against the interfaces.
{
"id": "github-operations",
"agent": {
"id": "FORGE",
"role": "GitHub operations specialist",
"tools": ["github:*"],
"sidebar": { "icon": "github", "section": "organisation" }
}
}This is what a platform plugin system should look like. Not UI injection. Agent injection. The plugin brings capability, not just interface.
Between 17 and 18 March, the following went from plan to production:
Two specialist agents. Two plugins. One pattern. Every action governed, every operation auditable, every tool exposed through a standard protocol. This is what it looks like when the plugin system stops being a feature list and starts being an architecture.
Quox (quox.ai) builds trust infrastructure for AI agent operations. Its open protocols, AEE for standardised agent messaging, AOCL for orchestration control and observability, and VOLT for cryptographic evidence chains, provide the accountability architecture that autonomous systems require. Four open protocol specifications. Building in the UK.
AI agent orchestration with built-in governance. Docker Compose up and running in under five minutes.