ICNLI vs Other AI Protocols and Frameworks — An Honest Comparison¶

Protocols, frameworks, and models occupy different layers of the stack. Comparing them apples-to-apples requires defining the comparison axis. This page does that — honestly.

1. The honest framing¶

Modern AI deployments are built on a stack of layers, and each layer in that stack solves a different problem. Foundation models from Anthropic, OpenAI, and Google are the brain — they reason, draft, summarize, and converse. Tool-boundary protocols like MCP (Model Context Protocol) and OpenAI Function Calling are the I/O layer — they standardize how a model invokes external capabilities. Agent frameworks like LangChain, AutoGPT, and CrewAI are the library layer — they orchestrate the brain and the I/O into multi-step behaviour, in code. Each of those layers is genuine engineering, and each has been advanced significantly by the people who work on it.

ICNLI is the Modular Proactive AI Cloud OS standard — three load-bearing words. Modular because the kernel is finite and extensions plug in. Proactive because the system watches the domain and surfaces concerns before being asked. AI Cloud OS because AI is the primary operational user of the system (the human remains the authorizing principal), not a feature inside an application. The standard sits at a different layer than the model, the tool boundary, or any particular framework. It defines the architectural class in which an AI system must live to be deployable in a real, regulated domain — context model, chain semantics, anti-fabrication contract, safety classifications, audit substrate, conformance levels — and defines them as normative MUSTs rather than engineering choices made differently in each library.

A fair comparison therefore is not "ICNLI versus X". It is "what layer does X occupy, and how does ICNLI compose with it". The sections below treat each of the most common counterparts in turn.

2. ICNLI vs MCP (Model Context Protocol)¶

What MCP does well. Anthropic's Model Context Protocol is genuinely good work. It standardizes how a foundation model calls tools and accesses resources across vendors — a problem that previously required bespoke integration code per provider and per tool. The MCP server ecosystem that has grown around it lets a model talk to filesystems, databases, code-search indexes, and a long tail of services through a single, well-defined interface. That is a real contribution at the model-tool boundary, and any compliant ICNLI implementation MAY use MCP at exactly that boundary.

What MCP does not define. MCP is, by design, focused on the model-tool boundary. It does not define a hierarchical context model with normative resolution semantics, multi-step chain orchestration with read-before-write topological ordering, an anti-fabrication contract with a verbatim cross-turn fact ledger, safety classifications and mandatory TWO-STEP confirmation, an audit substrate worthy of regulated work, channel neutrality, or formal conformance levels. None of those are deficiencies of MCP. They are simply outside its scope.

How ICNLI relates. ICNLI defines all of the above as protocol MUSTs at the appropriate conformance level. The two protocols sit at different scopes and compose cleanly. A compliant ICNLI implementation MAY use MCP at the model-tool boundary while ICNLI provides the surrounding OS — the context model that the tool sees, the chain orchestrator that sequences tool calls, the confirmation gate that runs before any state-changing call, the fact ledger that captures the tool's structured output, and the audit record that proves what happened. MCP is excellent at the boundary it occupies. ICNLI is the layer around it.

Cross-link: Modular Extension Contract.

3. ICNLI vs OpenAI Function Calling¶

What function calling does well. OpenAI Function Calling — and the equivalent capabilities now offered by every major foundation-model provider — gave the industry a clean, model-native way to let a language model invoke a structured function. The API is good. The schema is principled. The developer experience is the right shape for the problem it set out to solve. The pattern has become a load-bearing primitive across the field, and any compliant ICNLI implementation MAY use function calling as the mechanism by which the model expresses its tool-call intent to the kernel.

What function calling does not define. Function calling defines a request format. It does not define what context the model receives before it produces the call, how multi-step coordination composes across multiple calls in one turn, what happens if a call is state-changing, how the call's output is preserved verbatim across turns, what is logged, or what compliance means. Those questions are left to the application layer in every deployment that uses function calling directly.

How ICNLI relates. ICNLI defines the answers to those questions and treats function calling as one possible mechanism inside the protocol's broader contract. The context delivered to the model is structured by ICNLI's 9-Level Context Model. Multi-step coordination is governed by ICNLI's Chain Orchestration. State-changing calls trigger ICNLI's TWO-STEP confirmation. The call's output is preserved verbatim in ICNLI's fact ledger. The whole exchange is recorded in ICNLI's audit substrate. Function calling is a fine I/O primitive; ICNLI is the protocol that gives it operational meaning.

Cross-link: Interaction Protocol.

4. ICNLI vs Agent Frameworks (LangChain, AutoGPT, CrewAI)¶

What these frameworks do well. LangChain, AutoGPT, CrewAI, and the broader agent-framework ecosystem are excellent libraries. They lowered the cost of building agentic prototypes from weeks to hours. They have active communities, deep integrations, real production deployments, and engineers who have solved hard problems in tool routing, prompt assembly, retry semantics, and observability. The work is good, and the work matters.

The structural limitation. These frameworks are implementations, not standards. Each one re-invents safety, memory, multi-step semantics, confirmation, and audit differently — because each had to. There is no protocol underneath them that defines what compliance means. The result is predictable: agent code written for LangChain does not transfer to AutoGPT without rewriting; "safe", "auditable", and "compliant" mean whatever the chosen library happens to mean by them. That is not a criticism of the libraries — it is a consequence of the fact that there has been no standard for them to converge on.

How ICNLI relates. ICNLI defines those semantics once, at the protocol level, so any framework can implement them consistently and any compliant implementation can interoperate. Read-before-write multi-step ordering, verbatim step-output references, TWO-STEP confirmation, anti-fabrication grounding, channel neutrality, and audit completeness become protocol MUSTs rather than per-library design choices. A domain that adopts an ICNLI-compliant stack inherits the same structural guarantees regardless of which library is underneath. Libraries compete on engineering; standards define what compliance means.

Cross-link: Intent Routing and Chain Orchestration.

5. ICNLI vs Foundation Model APIs (Claude, GPT, Gemini)¶

This is not a competition. Anthropic, OpenAI, and Google are model providers. They make the brains. They do this exceptionally well, and the rate of capability improvement at the model layer has been the defining technical story of recent years. Constitutional AI, RLHF, refusal training, longer context windows, and safety filters have all advanced what the model can do and what it will refuse to do. Each of those reduces the probability of an undesired output inside the model.

Different layer, complementary by design. ICNLI is the nervous system you build around a brain. It is the protocol layer outside the model: context resolution, intent routing, chain orchestration, confirmation, fact ledger, narration grounding, audit. Any compliant ICNLI implementation MAY use any underlying foundation model — Anthropic Claude, OpenAI GPT, Google Gemini, an open-weights model, a future model that has not yet shipped. The model is a swappable component inside the protocol, not a competitor to it.

The layer where each kind of guarantee lives. A model-layer safety improvement reduces the probability of an undesired output. A protocol-layer structural mechanism either structurally prevents a class of undesired output (where the bytes the model emits never reach a consequential effect without an architectural gate) or contractually constrains it (where a normative MUST plus a runtime judge raises the bar dramatically). ICNLI's Anti-Fabrication Contract structurally prevents ungrounded fabrication at the provenance layer (the verbatim fact ledger the kernel maintains) and contractually constrains it at the narration layer (grounded-narration MUST plus runtime judges). ICNLI's TWO-STEP gate structurally prevents unauthorized state-changing execution because the kernel is what executes, not the model. Both layers have real value. They are not in opposition. Each is responsible for what it can guarantee at its own layer.

Cross-link: Anti-Fabrication Requirements.

6. ICNLI vs Traditional Control Panels¶

Click-driven interfaces — cPanel, Plesk, AWS Console, custom Grafana panels, ticketing systems — embed a pre-AI mental model. The user navigates, the user provides context by remembering or by clicking through a hierarchy, the user executes by clicking the right button. The system is the passive substrate; the human is the active participant. ICNLI inverts that. The user states intent in natural language; the system maintains structured context across the actor's entire domain; the system proposes the action with impact analysis; the user confirms. This is treated at length in the Whitepaper §2 — the short form is that a click-driven panel is a 1990s mental model wrapped around a 2026 capability, and ICNLI is what that capability looks like when the architecture is built for it from the start.

Cross-link: Core Principles.

7. ICNLI vs Kubernetes — same architectural category, different workload¶

Kubernetes is not normally listed among AI protocols, and it isn't one. The reason it belongs in this comparison is architectural precedent. ICNLI's "AI Cloud OS" framing rests on the same architectural pattern Kubernetes established: a finite, stable orchestration core that exposes OS-grade primitives one abstraction level above the underlying compute, to a specific class of workload, through a marketplace of pluggable extensions. Kubernetes is the operating system for containers; ICNLI is the operating system for AI agents.

What Kubernetes proved. That "operating system" is a category, not a Linux-kernel implementation. Kubernetes has no CPU scheduler — it schedules pods. It has no syscall ABI — it has the Kubernetes API. It has no process isolation in the Linux sense — it composes namespaces and cgroups at a higher level. The industry calls Kubernetes "the cloud operating system" because it owns the orchestration primitives at its abstraction level: workload scheduling, declarative state reconciliation, networking, storage, secrets, identity, and a CRD/Operator extension surface that lets new workload classes plug in without modifying the kernel. The OS framing is not a metaphor; it is the architectural category one abstraction level above the silicon.

What ICNLI does at the agent level. The same shape, one abstraction level up. A finite kernel exposes the agent-level analogs: context resolution, intent routing, chain orchestration with dependency-aware topological execution, the fact ledger, TWO-STEP confirmation, audit substrate, extension lifecycle. The marketplace surface — Python extension packages declared through the SDK and validated against the protocol contract before registration — is the agent-level analog of CRDs / Operators / Helm charts. The kernel's correctness is a one-time concern; every extension inherits the protocol's guarantees by construction.

Why this comparison matters defensively. When a backend-fluent reviewer reads "AI Cloud OS" and reaches for "but where is the CPU scheduler?", the answer is the same answer the Kubernetes community gave a decade ago: the OS abstraction operates at the orchestration layer, not the silicon layer. ICNLI is not claiming to be Linux. It is claiming to be the architectural category Kubernetes lives in, one level up for a different workload class. Same category, different abstraction level. The lineage is what makes the claim defensible.

Cross-link: Modular Composition Principle.

8. ICNLI vs AWS Bedrock AgentCore — closest structural competitor¶

AWS Bedrock AgentCore is the closest structural analog to ICNLI's deployed shape today. The two artifacts are doing similar things — and the differences are exactly the ones a serious adopter should weigh.

What AgentCore offers. A bundle of AWS-managed services for agentic systems: a managed memory store, a tool gateway, an identity layer, a browser tool, a code interpreter, and orchestration glue. The bundle composes into something that looks, from the application's perspective, like an agent runtime with OS-like primitives: persistent memory, tool access, identity, audit, structured execution. AgentCore is real engineering and a reasonable choice for teams already standardized on AWS.

What ICNLI offers that AgentCore does not. A series of structural differences, axis by axis:

Axis	AWS Bedrock AgentCore	ICNLI
Form	Bundle of AWS-managed services	Open published specification
Lock-in	AWS-only; primitives are AWS-proprietary	Vendor-neutral; any compliant engine on any infrastructure
Substrate	A stack of AWS services with a marketing umbrella	A normative protocol with conformance levels and audit semantics
Compliance posture	AWS Service Terms govern behaviour	RFC2119 MUSTs the implementation publishes against
Deployment topology	AWS regions, AWS account boundary	On-premises, air-gapped, multi-cloud, single-region — implementation-neutral
Audit substrate	CloudTrail + AgentCore audit events	Tamper-evident hash-chain at L2+, normative observability requirements
Anti-fabrication	Tool output is preserved; narration grounding is implementation-specific	Anti-Fabrication Contract is normative at L1; grounded-narration MUSTs published
TWO-STEP confirmation	Per-tool implementation pattern	Normative protocol primitive with safety classification L0–L4
Extension model	Lambda function action groups	Python extension packages with declared manifest contract, validated before registration
Channel neutrality	Application-layer concern	Normative MUST at L1; cross-channel continuity at L3

Where AgentCore is the right choice. A team already deeply AWS-resident, comfortable with AWS lock-in, and not requiring on-premises or multi-cloud deployment can ship faster on AgentCore than on a brand-new protocol. The trade is real and is the right trade for a real class of teams.

Where ICNLI is the right choice. Regulated domains that need on-premises or air-gapped deployment; organizations that need a normative spec their compliance team can audit against; teams that want to avoid single-vendor lock-in; deployments that need formal conformance levels rather than per-service Terms-of-Service promises.

The two can compose. A future AgentCore could implement the ICNLI specification on top of AWS services without changing AgentCore's user-facing surface — and at that point, ICNLI compliance would become an additional guarantee on top of the AWS bundle. The protocol is implementation-neutral by design.

Cross-link: Conformance Levels.

9. Why ICNLI Is Properly Called an Open Standard — Standards Category Argument¶

The most common technical critique of ICNLI is the claim that "it isn't really a standard yet" because it is vendor-authored with one implementation today. This claim uses a too-narrow definition of standard that, when applied consistently, would exclude HTTP 0.9, early TCP/IP, MCP today, Python before PyPy, POSIX before formal IEEE adoption, and every other successful standard during its anticipatory phase. The narrow definition is historically wrong. This section is the technical argument for why ICNLI is properly called an open standard, with prior art receipts.

Standards literature recognizes multiple specification categories¶

The IEEE, ISO/IEC, IETF, and the academic standards-engineering literature recognize multiple categories of standards and specifications. They are not interchangeable, and not all standards belong in the same category as TCP/IP.

Category	Definition	Examples
Wire-level standards / protocols	Byte-level message exchange between independent endpoints	TCP/IP (RFC 791/793), HTTP/1.1 (RFC 7230), MQTT (OASIS), MCP (Anthropic)
API standards	Message-level semantics over a wire transport	REST, GraphQL, JSON-RPC, gRPC
Behavioral specifications / standards	Semantic contracts and compliance criteria (no required wire format)	POSIX (IEEE Std 1003.1), OpenAPI Specification, ANSI SQL (ISO/IEC 9075), SOAP, WSDL, HIPAA Security Rule, PCI DSS, ICNLI
Architectural standards	Pattern + conformance criteria	12-Factor App, ISO/IEC 25010 (software quality model), C4 model

ICNLI sits in category 3: behavioral specification / standard. It defines:

Normative MUST clauses (RFC2119) for what a compliant implementation must do — context resolution, intent routing, chain orchestration, anti-fabrication, safety classification, audit substrate, observability.
Three conformance levels (L1/L2/L3) with measurable requirements per specification §13.
Safety classification taxonomy (L0–L4) with normative confirmation escalation per §8.2.
Audit substrate format requirements at L2+ (hash chain, SHA-256 or stronger, append-only) — these ARE byte-level normative requirements where they matter most, per §12.5.
Cross-extension behavioral contracts — Step-Output References with topological resolution semantics (§6.4).

POSIX is the closest categorical analog¶

POSIX (IEEE Std 1003.1, ISO/IEC 9945) is universally called a "standard" and a "protocol" despite having:

No byte-level wire format. POSIX specifies system call semantics, not transport.
Extensive "implementation-defined" clauses. Buffer sizes, scheduling policies, signal delivery details, locale behavior, file-system semantics — all marked implementation-defined or implementation-specific.
Implementation-specific dialects. GNU/Linux, FreeBSD, macOS, AIX, Solaris all have POSIX-conformant cores plus extensive non-portable extensions. Two POSIX-conformant systems do not necessarily run each other's programs without modification.
Self-attested conformance for many years before automated test suites. The Open Group's certification regime exists today; POSIX was a "standard" for years before that ship existed.

By the exact logic the critique applies to ICNLI ("no wire format", "implementation-specific clauses", "not freely interoperable"), POSIX would also "not be a protocol". This is obviously wrong. POSIX is a behavioral specification, and so is ICNLI — one abstraction level up, for a different workload class.

The same logic applies to OpenAPI (specifies API semantics, not byte-level transport — uses HTTP/JSON as transport-neutral substrate), ANSI SQL (every database vendor has a SQL dialect; ISO/IEC 9075 is still the standard), SOAP/WSDL (transport-independent behavioral contracts), and HIPAA Security Rule (regulatory standard with no message format whatsoever).

The "N=1 implementation" critique misreads standards evolution¶

The standards-engineering literature (Krechmer 1996/2005, "Open Standards Requirements"; Markus 2006, "Standards Evolution"; Egyedi & Blind 2008, "The Dynamics of Standards") recognizes three stages every successful standard moves through:

Stage	Definition	ICNLI today	Historical examples in same stage
1. Anticipatory standard	Written before broad adoption, by a single author or single organization	ICNLI v2.0 (May 2026) — first created 30 December 2025 (v1.0.0)	HTTP 0.9 (CERN, 1991, single-author Tim Berners-Lee); TCP/IP RFC 791/793 (DARPA contractors, small group, 1981); Python (CPython only, 1991–2008 — 17 years anticipatory phase); Kubernetes (Google internal, pre-2014); MCP (Anthropic, 2024–present, single organization)
2. De facto standard	Multiple independent implementations exist	(ICNLI roadmap target: end-2027 per §15)	Mature HTTP after Apache + Netscape + IIS implementations; mature TCP/IP across vendors; Python after PyPy + IronPython + Jython; mature Kubernetes after CNCF transfer with multi-vendor distributions
3. De jure standard	Formally adopted by a recognized standards body with multi-stakeholder governance	(ICNLI roadmap target: after stage 2 per §15)	ANSI SQL (ISO/IEC 9075), POSIX (IEEE Std 1003.1), HTTP/2 (IETF RFC 7540), ISO/IEC 42001 for AI Management Systems

The critique "ICNLI is not a standard because N=1 implementation" applies equally to HTTP/0.9 in 1991 (which had N=1 — CERN). It excludes MCP today (which is N=1 — Anthropic) from being called a protocol. It excludes Python before PyPy (17 years of N=1 — CPython) from being called a language standard. The critique is historically and definitionally inconsistent.

ICNLI is explicitly in stage 1 — and that's exactly what whitepaper §15 discloses, with dated milestones to reach stages 2 and 3:

Conformance test suite (target v2.1, late 2026)
At least three independent compliant implementations from unaffiliated organizations (target end-2027)
Governance transfer to a neutral foundation (target after milestones 1 and 2 are met)

This is exactly how every standard listed above moved through their stages.

What ICNLI is and is not — both halves of the disclosure¶

ICNLI is properly called, all four labels applying simultaneously:

An open standard — in the behavioral specification category (POSIX, OpenAPI, SOAP, SQL — same category, different problem domain).
An open standard — in the anticipatory phase, with explicit multi-vendor governance milestones.
A reference architecture — descriptive of the architectural class (Modular Proactive AI Cloud OS) that compliant implementations build.
A conformance framework — defining what compliance means at three levels (L1/L2/L3).

ICNLI is not, and does not claim to be, in equally clear terms published normatively:

A wire protocol in the TCP/IP / HTTP byte-level-format sense (no required wire format).
A foundational layer in the TCP/IP / HTTP architectural lineage (those frameworks earned that status over decades through multi-vendor adoption).
A multi-vendor de facto standard today (vendor-authored in stage 1; multi-vendor adoption is the roadmap target).
In the same earned-governance category as Kubernetes (which entered CNCF from inception under a Google CLA-grant — a different starting condition entirely).

The positive labels and the explicit non-claims together define ICNLI's honest position. Both halves are in the published normative documents — see §15 of the whitepaper and §13.5 of the specification. A reviewer who attacks ICNLI for claims it does not make is attacking a strawman.

Summary¶

The reviewer who claims "ICNLI is not a standard yet because vendor-authored / N=1 implementation / no test suite" must, to be consistent, also claim that HTTP 0.9 in 1991 was not a standard (one author Tim Berners-Lee, one implementation at CERN), MCP today is not a standard (one organization, Anthropic), Python before PyPy was not a language standard (CPython only for 17 years), and POSIX before formal IEEE adoption was not a standard. All of these are recognized as standards during their anticipatory phases. ICNLI is in their category — a behavioral specification with normative compliance semantics, currently in the anticipatory-standard phase that every successful standard begins in.

Cross-links: whitepaper §15 Open Standard Strategy · specification §13.5 Current state of conformance verification · specification §13 Conformance Levels.

10. Summary matrix¶

The comparison axis is scope at the artifact's own normative layer — what each protocol, framework, or model API defines in its published contract. Cells are not value judgements; they read as "in scope" or "out of scope" of the artifact itself. A partial or out of scope cell does NOT mean an implementation cannot achieve that capability — it means the artifact does not normatively define it. An application built on Claude with MCP and a custom safety layer can absolutely implement TWO-STEP confirmation; the comparison reflects that the Foundation Model API itself does not define a safety contract at the API surface, and the MCP spec itself does not define multi-step orchestration. The cells compare normative scope, not composed capability.

Capability	ICNLI	MCP	Function Calling	Agent Frameworks	Foundation Model APIs
Hierarchical context model	✅ defined (9 levels, normative)	❌ out of scope	❌ out of scope	partial (per-library)	❌ out of scope
Multi-step chain orchestration	✅ defined (read-before-write, topological)	❌ out of scope	❌ out of scope	partial (per-library)	❌ out of scope
Safety contract & confirmation	✅ defined (TWO-STEP, L0–L4 classifications)	❌ out of scope	❌ out of scope	partial (per-library)	partial (refusal training)
Audit substrate	✅ defined (per-step, conformance-bound)	❌ out of scope	❌ out of scope	partial (per-library)	❌ out of scope
Memory across sessions & channels	✅ defined (User Intelligence Profile)	❌ out of scope	❌ out of scope	partial (per-library)	partial (context window)
Anti-fabrication contract	✅ defined (fact ledger + grounded narration)	❌ out of scope	❌ out of scope	❌ out of scope	partial (RLHF, Constitutional AI)
Channel neutrality	✅ defined (chat, voice, alerts, API)	❌ out of scope	❌ out of scope	partial (per-library)	❌ out of scope
Vendor & model independence	✅ defined (any compliant model)	partial (model-side)	❌ vendor-specific	partial (per-library)	❌ vendor-specific

11. When to use what¶

These are not exclusive choices. They layer.

Use a foundation model API directly when what you need is raw intelligence — a single-turn generation, a classifier, a summarizer, a code-completion endpoint.

Use MCP when you need a standardized, model-vendor-neutral boundary between a foundation model and a set of tools or resources.

Use OpenAI Function Calling (or the equivalent native capability of your provider) when you want the model to invoke a small set of structured functions inside your own application, and you accept that the surrounding semantics — context, multi-step, safety, audit — are your responsibility to implement.

Use an agent framework when you want a library to scaffold an agentic prototype quickly and you do not yet need protocol-level interoperability or formal compliance.

Use ICNLI when you need to ship AI into a real operational domain with structural guarantees that survive a regulatory audit, a model swap, an extension marketplace, a multi-channel surface, or a hostile environment. ICNLI composes underneath with any model, any tool-boundary protocol, any extension language, and any orchestration runtime that can satisfy the contract.

These are not exclusive choices — they layer.

12. Next reading¶

Read the ICNLI Whitepaper for the full architectural argument. Read the ICNLI Specification v2.0 for the normative MUSTs that make every claim on this page auditable. Read the 5 AI Problems Bounded Structurally for the punch-list summary of what the protocol bounds and how. Each document is open under CC BY-SA 4.0.

About the Author¶

Valentin Scerbacov is the founder of Imperal, Inc. and the creator of ICNLI. This page positions the protocol against the most common adjacent artifacts in the AI stack — model APIs, tool-boundary protocols, and agent frameworks — and explains the layer at which each one operates. Imperal Cloud (imperal.io) is the first ICNLI AI Cloud OS — the world's first complete implementation of the ICNLI protocol — with Webbee as its reference agent; WebHostMost is imperal.io's first enterprise client, running an ICNLI-compliant deployment across multi-region hosting infrastructure.

License¶

This page is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). You are free to share and adapt this material for any purpose, including commercial, under the terms of attribution and share-alike.

Full license: https://creativecommons.org/licenses/by-sa/4.0/

ICNLI™ is a trademark of Imperal, Inc. The CC BY-SA 4.0 license applies to the content of this page but does not grant rights to use the ICNLI trademark for branding or commercial purposes without written permission. Webbee™ is a trademark of WebHostMost. MCP, Claude, and Constitutional AI are referenced under nominative fair use; their respective trademarks remain the property of Anthropic, PBC. GPT and Function Calling are referenced under nominative fair use; their respective trademarks remain the property of OpenAI, Inc. Gemini is referenced under nominative fair use; its trademark remains the property of Google LLC. LangChain, AutoGPT, and CrewAI are referenced under nominative fair use; their respective trademarks remain the property of their respective owners.

Creator: Valentin Scerbacov
Trademark Owner: Imperal, Inc.
Website: icnli.org
Trademark inquiries: license@icnli.org
Flagship implementation: imperal.io — the first ICNLI AI Cloud OS
Reference agent: Webbee
First enterprise production deployment: WebHostMost