What we built that nobody else has

Twenty platform-and-agent surfaces with zero precedent — what falls out of "the AI runs inside the kernel, the agent is cloud-modular, the agent is proactive by design"

This page lists twenty distinct platform-and-agent surfaces the AI industry currently hands back to extension authors — and that Imperal Cloud + Webbee solve at the contract level. Every claim cites the public doc that proves it.

If you find a platform that owns any of them at the same depth, file an issue — we'll update.

The pattern that makes everything below possible

We didn't invent twenty features. We made three architectural commitments:

The AI runs inside the kernel, not on top of it. Every action passes through a federal contract; the OS is the trusted boundary.
The agent is cloud-modular. Webbee gains capabilities at runtime from federally-contracted extension packages — like an OS gains apps from an app store.
The agent is proactive by design. Webbee speaks first when something changes — through skeletons, schedules, webhooks, and a platform-owned chat-injection contract.

The twenty surfaces below are what falls out of those three commitments when you do them rigorously.

And there's a fourth foundational thing

Imperal Cloud is the first complete implementation of ICNLI — Infrastructure Contextual Natural Language Interface, the open protocol we authored and published under CC BY-SA 4.0. Anyone can implement ICNLI. We are the first who shipped it as a deployed multi-tenant cloud OS.

Part I — AI Cloud OS surfaces (#1–#15)

1. Federal Extension Contract — 11 ERROR-severity validators block publish

Every extension that ships passes 11 ERROR-severity validators at publish time: manifest schema v3 conformance, module-scope Pydantic params, AST-scanned handler internals, icon validity, action-type closure, function description quality, first-party flag enforcement. A failing extension does not reach the marketplace. No author opt-out, no admin override at the contract level.

Most AI platforms either have no manifest contract (LangChain, LangGraph) or have a manifest schema with no severity gating. Reference: Validators reference.

2. Federal action ledger — bypass-proof audit chokepoint

Every action lands in the action-ledger row at the gateway boundary with retention_class, tenant_id, actor_kind, PII redaction. The chokepoint is upstream of your extension code — you cannot opt out, you cannot disable, you cannot bypass.

Microsoft has Purview; AWS AgentCore has Gateway logs. Neither makes the audit unbypassable by the author. Reference: Federal contract — runtime invariants.

3. Federal anti-hallucination layer — runtime invariants, not prompt engineering

Six federal I-AH-* invariants enforce at runtime: fabricated-id rejection, narration grounding-ratio 30%, classifier hint enum-closure, narrator factual-claim backing, manifest-grounded capability answers, user-installed-only capability surface. Runtime detection + structured rejection + critical audit row. Not "ask the LLM nicely."

Reference: Federal contract — anti-hallucination.

4. Federal credentials API — KMS-backed, plaintext-never-logged

@ext.secret + ctx.secrets.get/set/delete/is_set/list. Plaintext lives only inside the handler call stack, encrypted at rest by platform KMS (AES-256-GCM, non-exportable key), audit-trail-visible only by value_length + sha256_prefix8 — never the value. Seven federal invariants. KMS-fail-closed when endpoint unavailable.

Other platforms hand you a secrets-manager SaaS link and tell you to integrate. Reference: Secrets concept · @ext.secret reference.

5. Triple-gate authorization — fires before your code runs

Before any side-effect: (a) RBAC scopes from the manifest; (b) tenant scope — acted-on resource belongs to acting user's tenant; (c) action-type confirmation gate — write (when user has confirmations enabled), destructive (unconditional). If any gate fails, your handler never runs.

Reference: Architecture · Confirmations.

6. Byte-identical confirmation — args user agreed to = args dispatched

Federal I-CONFIRMATION-EXECUTES-WHAT-USER-SAW enforces byte-identical args on accept. The args the user agreed to in the confirmation card are byte-for-byte the args dispatched into your handler. No other platform makes this guarantee.

Reference: Confirmations.

7. Multi-step typed chain orchestration with `depends_on`

The intent classifier emits not a single tool call but action_plans[] with depends_on edges. The web-kernel applies Kahn's topological sort before iteration (I-CHAIN-READ-BEFORE-WRITE-DEPENDENCIES). Outputs flow as typed structured prior_step_results into the next step (I-CHAIN-PRIOR-RESULTS-STRUCTURED) — verbatim ActionResult.data, not placeholders.

LangGraph requires the author to write the graph. Here the classifier writes the graph from one user message. Reference: Chain dispatch.

8. Per-extension Python module isolation

Every extension's modules load in an isolated namespace (I-EXT-MODULE-ISOLATION v4). You can name modules app.py, handlers.py, config.py, models.py freely — no cross-extension collision in the same worker process.

Every multi-tenant Python platform has this problem; nobody else solves it without sub-interpreters (Python 3.13+). We solved it on 3.11 via per-async-task module ContextVar. Reference: Federal invariants.

9. Pydantic feedback loop — bounded LLM retry with structured prose

When the LLM emits tool_use args that fail Pydantic validation, the SDK gives the LLM a structured second chance — re-prompts with the specific field error in natural-language prose, bounded at 2 retries (I-PYDANTIC-RETRY-BUDGET). Catches ~80% of validation failures that would otherwise surface as user-visible errors.

No other AI platform has this — they fail the call and emit VALIDATION_MISSING_FIELD. Reference: Pydantic feedback loop.

10. Declarative long-running operations — `@chat.function(background=True)`

Decorator flag and the platform handles the rest: the LLM receives an immediate task_id ack, your handler runs detached, the platform auto-delivers your returned ActionResult as a fresh bot turn when work completes. Five federal invariants gate the surface.

Other AI platforms require you to wire your own job queue + webhook callback for chat delivery. Reference: Long-running operations.

11. Six uniform decorator families, one `ctx` injection

@chat.function · @ext.skeleton · @ext.panel · @ext.schedule · @ext.webhook · @ext.secret — all receive the same ctx object with the same protocols (store, cache, http, ai, secrets, notify, progress, background_task, deliver_chat_message, ...). No surface-specific context shape; no broken contract between surfaces.

Reference: Decorators reference.

12. Federal cache + store contracts — typed Pydantic, kernel-authoritative

@ext.cache_model registers typed Pydantic models; ctx.cache.get/set uses kernel-authoritative app_id (not the drift-prone Python Extension("X") value) — closes the class of bugs where Extension("spotify-extension") while the folder is spotify would 401 the entire cache surface. ctx.store is the same federal pattern for durable state.

Reference: Cache vs Store.

13. Agency multi-tenancy — hierarchical isolation for white-label

ctx.agency_id injected alongside tenant_id for hierarchical multi-org deployments. Agencies own tenants; tenants own users. Hierarchical data isolation, white-label theming, per-agency LLM configs. No other AI platform has this.

Reference: Kernel context (ctx).

14. Federal admin-as-extension — even admin features pass the same contract

The platform's own admin/billing/automations/developer features are regular extensions that pass the same federal contract as third-party authors. No privileged escape hatch; no admin functionality that escapes audit, isolation, or anti-hallucination invariants. Eat your own dog food at the contract level.

Reference: System Apps.

15. 100+ named federal runtime invariants — grep-able engineering contract

The federal contract is a registry of 100+ named runtime invariants with stable IDs (I-AH-*, I-CHAIN-*, I-PYDANTIC-*, I-SECRETS-*, I-LONGRUN-*, I-CONFIRMATION-*, …) — each citing the enforcement site, each blockable by a CI gate. Drift between docs and code triggers test failure.

This turns marketing claims into testable engineering facts. Reference: Federal invariants.

Part II — Webbee agent surfaces (#16–#20)

16. Cloud-modular AI agent

Webbee gains its powers from extensions at runtime — not at training time, not at compile time, not in a vendor-curated app store run by one company. Every other AI agent on the market today is a closed monolith with a bolted-on plugin surface.

Agent	Capability model
ChatGPT	Closed model + vendor-curated GPT/Apps marketplace
Claude	Closed model + Claude Skills (vendor-curated)
Gemini	Closed model + Gemini Extensions (Google-curated)
Webbee	Open extension ecosystem governed only by the federal contract

Capabilities install per-user with one click; uninstall removes the capability. Same agent, different superpowers per user. Reference: Why Webbee is different.

17. Proactive AI agent by design — four proactive primitives

Every other AI agent in production is reactive (waits for user message, replies). Webbee is the first where proactive behavior is structural:

Primitive	What it does
`@ext.skeleton`	Ambient awareness — the agent knows your state before you type
`@ext.skeleton(alert=True)` + alert tool	When state changes, the agent speaks first in chat
`@ext.schedule`	Time-driven proactive work (daily digest, weekly cleanup)
`@ext.webhook` + `ctx.deliver_chat_message`	Event-driven proactive responses to third-party signals

No polling loops authors have to write. No webhook fan-out plumbing. The platform owns the proactive surface as federal contract. Reference: Why Webbee is different.

18. BYOLLM — LLM-provider-agnostic, configurable per-tenant

Tenant operators choose the brain: Anthropic Claude, OpenAI GPT-5, Google Gemini, local Ollama models. Per-purpose routing (different model for routing vs execution vs navigation vs judge), failover policies, per-purpose AI param cascade (temperature, top_p, max_tokens). When the user supplies their own API key, platform fee → zero at every deduct site (I-BYOLLM-PLATFORM-FEE-ZERO).

Other agent platforms tie you to one vendor's brain. Webbee runs on whoever you point it at. Reference: BYOLLM guide.

19. Federal capability grounding — "what can you do?" is manifest-truthed

When a user asks Webbee "what can you do?", the answer is paraphrased verbatim from your installed extensions' display_name + description — never invented from training data (I-CAPABILITY-LIST-MUST-BE-GROUNDED). It also surfaces only your installed apps, never the platform-wide catalogue (I-CAPABILITIES-USER-INSTALLED-ONLY — anti-leak privacy contract).

Every other AI agent will hallucinate capabilities they don't have. Webbee structurally cannot. Reference: Federal contract.

20. Persistent across surfaces — one agent, every place

Webbee isn't a chat tab — it's the same agent across chat, panels, tray icons, scheduled alerts, webhook replies, and OAuth callback acknowledgements. The user has one agent following them through their entire work day, with one memory, one capability set, one audit history — not a fragmented collection of chatbots per app.

The only comparable cross-surface continuity exists in walled-garden OS assistants (Siri, Alexa); none of those is cloud-modular, federally-contracted, or extensible by third-party authors. Reference: Architecture.

How to test the claim

Pick any of the 20. Read the cited doc. Then look at the closest equivalent on:

OpenAI Apps SDK — developers.openai.com/apps-sdk
Anthropic MCP — modelcontextprotocol.io
Google Vertex AI Agent Builder — cloud.google.com/products/agent-builder
Microsoft Copilot Studio — learn.microsoft.com/copilot-studio
AWS Bedrock AgentCore — aws.amazon.com/bedrock/agentcore
LangGraph Platform — langchain.com/langgraph-platform
Salesforce Agentforce — salesforce.com/agentforce

We don't claim those platforms are bad. We claim they don't own these twenty surfaces at the platform-contract level — and that we do.

Why this matters for builders

A typical @chat.function handler on Imperal Cloud is 5–30 lines of code. The auth, audit, isolation, retry, tenant, schema-validation, chain-orchestration, anti-hallucination, multi-tenant, multi-LLM, proactive-delivery code that would balloon that handler to 800+ lines on a platform without a federal contract — lives in the OS, not in your codebase.

The same way Linux developers don't write their own filesystem driver, you don't write your own AI-safety layer. We did. Once. For everyone.