The quoxification framework: 10 dimensions that separate agent platforms from agent products

Most AI agent platforms ship features. A chat interface here, a workflow builder there, an SSH tool somewhere else. Each works on its own. None of them know about each other. And none of them can prove what happened.

That is the difference between a platform and a product. A platform has a philosophy. The features are not just features. They are expressions of a set of architectural choices that compound.

We call those choices quoxification. It is not a checklist you bolt on at the end. It is a set of decisions made at the start of building any feature that determine whether the result is a Quox feature or just a feature that happens to live in Quox.

This post describes the framework. Ten dimensions, each grounded in protocol-level architecture that ships today.

The 10 dimensions

1. Evidenced

Every user-facing action produces a cryptographic receipt. Not a log line. Evidence.

The sequence is always the same four steps:

1. An AEE (Agent Envelope Exchange) envelope wraps the action (who, what, when, correlation ID)
2. AOCL (Agent Orchestration Control Layers) classifies it (which layer, risk level, autonomy level)
3. VOLT (Verifiable Operations Ledger and Trace) records it in a hash-chained, tamper-evident ledger
4. WARD (Write-once Append-only Receipt Digests) witnesses it as a write-once, append-only receipt

AEE, AOCL, VOLT, and WARD are open protocol specifications, with IETF submission planned. They are not internal abstractions. They are standards designed to be adopted by other platforms.

When Browser-Q takes a screenshot, when Action-Q creates a task, when a login is approved, the same four-step sequence fires. The result: every action in the system is verifiable, exportable as compliance evidence (SOC 2, HIPAA, GDPR, EU AI Act), and cryptographically linked to every other action in its chain.

No competitor does this. Temporal recovers from crashes but cannot prove what happened during recovery. CrewAI validates output but cannot show the chain of decisions that produced it.

2. Intelligent

Features do not just execute. They learn.

QuoxMind is an execution intelligence layer with five components:

• Observer records what happened (success, failure, duration, error class)
• Analyser detects patterns post-hoc (nine known patterns including timeout, auth failure, rate limiting)
• Wisdom Store persists learnings with a confidence lifecycle (0.5 on first observation, rising to 0.98 with repeated confirmation, decaying over 90 days without reinforcement)
• Advisor warns before risky actions
• Guardian intervenes autonomously (loop detection, stall detection, cascade prevention)

The loop is observe, analyse, learn, advise, protect. It runs across every agent, every objective, every scheduled task. Patterns learned from Browser-Q's failures inform Action-Q's scheduling decisions.

3. Credentialed

Secrets never live in configuration files, environment variables, or browser storage. Every credential goes through QuoxVault: registered by type, stored encrypted (AES-256-GCM), resolved just-in-time via internal service key, never returned to the frontend.

When Browser-Q needs to log into a website, it does not receive the password. The vault resolves the credential inside the screencap service, types it into the browser via Puppeteer, and discards it. The frontend never sees the secret. The API never returns it.

4. Scoped

Every table has org_id. Every API accepts it. Every query filters by it.

This is not a feature. It is a constraint applied at the database schema level. The first column in every new table is org_id TEXT NOT NULL. Visibility scoping (organisation, personal, team) and division narrowing are built into the query layer.

Multi-tenancy added later is multi-tenancy done wrong. It must be present from the first line of code.

5. Agentic

Every major feature has an agent identity. Not just a page in a dashboard. An agent that can be delegated to, that has callable tools, that participates in the agent hierarchy.

Browser-Q is not just a web automation UI. It is an agent that SENTINEL can ask "screenshot this dashboard" and METRICS can ask "check if this login page works." The agent registration includes tools, capabilities, domain keywords for routing, and a persona for how it communicates.

This means every feature added to the platform automatically becomes available to every other agent through delegation. The value compounds.

6. Approvable

Any high-risk action requires human approval before execution.

AOCL (Agent Orchestration Control Layers) classifies every action by risk: LOW (auto-approve), MEDIUM (notify then auto-approve after timeout), HIGH (require explicit approval), CRITICAL (require approval plus second factor). Login actions in Browser-Q are always HIGH. Read-only operations are always LOW. The classification is protocol-level, not ad-hoc.

7. Schedulable

Any completed action should be saveable and repeatable. After a Browser-Q automation completes, one click saves it as a template. A natural language parser converts "every Monday at 9am" into a cron expression. Variables are auto-detected in the template.

The gap between "I did this manually" and "this runs automatically" is one click and one sentence.

8. Integrated

No islands. Every agent produces outputs that other agents consume.

Browser-Q downloads a file. FilesQ stores it. Action-Q creates a follow-up task from the findings. Inbox-Q notifies the user. Calendar-Q schedules the next run. QuoxMind records the outcome and advises the next execution.

The question is not "does this feature work?" It is "does this feature make every other feature better?"

9. Beautiful

Visual consistency across every feature. The glass design system enforces glassmorphic panels, no grey text, purple-cyan active states, monospace typography for operational data, skeleton loaders during fetch, and empty states with guidance.

Every plugin page follows the same layout: toolbar with stats, tabbed content area, collapsible agent chat sidebar. A user who has seen one agent dashboard can immediately use any other.

10. Purchasable

Every major feature is shaped as a plugin with pricing and licence gating. A JSON manifest declares the name, tier, price, and limits. A registration chain connects it to the plugin registry, agent registry, route registry, sidebar, and licence validator.

Features built for internal use are automatically structured for marketplace distribution. The plugin SDK, the marketplace review pipeline, and the payment flow all operate on this same shape.

Skills are the new SDKs

Traditionally, a platform quality standard lives in documentation. A style guide, an architecture document, a wiki page that nobody reads. Developers either internalise it through osmosis or they do not.

Quoxification lives in a skill.

That command loads the quoxification framework, identifies the feature files, and runs a pre-build audit: data flow trace, credential audit, integration map, risk assessment, persistence check. Before a single line of code is written, every gap is visible.

That command reads the actual code, greps for AEE envelopes, VOLT entries, vault usage, org_id scoping, agent registration, HITL flags, scheduling hooks, cross-agent imports, glass design patterns, and plugin manifests. It scores each dimension 0-2 and produces a report with specific action items.

The skill IS the SDK. It encodes the architectural philosophy into an executable audit. It does not describe the standard. It enforces it.

Documentation describes. Skills enforce. The gap between knowing the standard and meeting it collapses to a single command.

What this means in practice

Browser-Q took three days to build as a standalone feature. It took another day to quoxify: wiring the vault credential type, threading org_id through every API call, adding the login case to the objective executor, connecting the credential picker UI, stripping binary data from API responses, and fixing the screenshot save function for Puppeteer 23's return type.

That extra day is the difference between "we have a web automation feature" and "we have a web automation feature with encrypted credential management, human-in-the-loop approval for logins, cryptographic evidence on every action, cross-agent delegation, one-click scheduling, and a compliance export trail."

Every competitor can build web automation. None of them can prove what their automation did.

What comes next

The quoxification framework is not finished. Dimensions will be added as the platform grows. Federated wisdom sharing (QuoxMind patterns exchanged between Quox instances via Matrix protocol) will add an 11th dimension. The marketplace payment flow will expand "purchasable" into "monetisable." Multi-instance deployment will add "distributable."

But the core insight will not change: a platform is not a collection of features. It is a set of architectural choices applied consistently to everything that ships. The quoxification skill ensures that consistency is not aspirational. It is automated.