15.FAQ

Content can overlap heavily; standing differs entirely. A system prompt is unowned speech: composed per session or per app, with no version history, no review process, no inheritance, no audit trail, and no answer to "which rules governed March's output?" A Frame is a governed organizational document with an accountable author, versioning, defined scope, an inheritance chain, and selective sharing controls. The paper's formulation: a Frame is "an organizational artifact governed by the organization that owns it" (§4.3). If your instructions file acquired an owner, a changelog, scoped inheritance across your whole company, and a review process, it would be most of the way to a Frame; the protocol standardizing the format is the rest.

By deliberate unbundling. "Agent" typically bundles a worker, its tools, its coordination loop, and its autonomy into one word. The architecture splits them: a Cog is the bounded worker (model, Frames, tools, governance parameters), and it is not normally an end-to-end autonomous loop, though the paper allows simple standalone use; sequencing, retries, goal-seeking, and human oversight live at the Op layer. That separation is what lets governance attach at the right altitude, and it is aimed squarely at the deployment data: only 1 in 5 organizations has mature agent governance (Deloitte 2026), which is why "agentic" pilots stall at the compliance office.

The components are familiar, deliberately so; the claim is not novel parts but standardized units. RAG is a technique inside Cog context assembly. Agent frameworks provide orchestration libraries. What neither provides, and what the paper argues is missing, is the standard unit: a packaged, versioned, Frame-adapted, validation-declaring artifact that can be installed into any compliant deployment and audited afterward. The difference between a technique and a unit is the difference between knowing how to load cargo and having the shipping container. Whether that unit wins adoption is a fair question (see 5); that it is different in kind from a library is, we think, established by Sections 5–6.

They can build features that overlap; the paper's structural argument (§9) is that each is configured against building this. Model providers monetize vendor-side aggregation of usage and context; customer-side sovereignty inverts their economics. Cloud platforms monetize single-cloud lock-in; a portable standard dissolves it. Enterprise SaaS embeds AI in vertical silos. The realistic threat is not an incumbent adopting the open standard but an incumbent's good-enough closed bundle soaking up demand before the standard matures, which this guide lists as a brake on the flywheel (§11). The paper does not dwell on that scenario; we consider it the strongest competitive risk.

Then the marketplace never forms, and the paper's Layer 3 remains a diagram. This is the failure mode of every standards play. Two mitigations are real: the artifacts are useful at n=1 (a company gets internal-alignment value from Frames and reliability value from validated Ops with zero network), so adoption does not require faith in the network to start; and open-source distribution has seeded exactly this kind of registry before. Section 12 lists observable indicators. Watch them rather than the press releases.

The free circulation of Frames is the design, not a leak: coordination goods gain value by adoption (§10). Money concentrates elsewhere: Ops sold under subscription, usage, or outcome pricing; commercial Cogs; specialist Guard libraries; and, for OpenTeams specifically, enterprise services (assembling and maintaining Hubs), marketplace fees, and its own published artifacts. That is the Red Hat/Anaconda position: steward the free layer, sell assembly, assurance, and distribution above it. The paper states this plainly (§8.1); no reading between lines is required.

The paper's taxonomy answers part of this: the strongest Guards are algorithmic and deterministic (code runs, totals reconcile, schemas match), and they anchor the stack. Probabilistic Guards are layered, not trusted alone: consensus across independent Cogs, expert sampling, and Gates that escalate to humans on low confidence or disagreement. Two further points: Guard quality itself needs regression testing (the paper's drift category applies to Guards too), and community-vetted open Guard libraries are the proposed mechanism for Guards earning trust the way open test frameworks did. The recursion never terminates in pure automation; it terminates in humans at Gates, which is the design's actual claim.

The paper does not resolve liability. What the architecture changes is the evidence: a Track records which version ran, under which Frames, checked by which Guards, approved by which humans, which is the difference between a liability inquiry with facts and one with shrugs. Regulators are actively clarifying responsibility for AI acting with limited oversight (Dataversity, 2026), and EU AI Act obligations attach to deployers as well as providers. A reasonable reading: the architecture doesn't answer "who pays?", it makes the answer determinable. Legal allocation between Op author, Guard publisher, and deploying organization remains open territory.

They absorb part of the mechanics and none of the custody. A million-token context window (the bounded amount of text a model can consider at once) still has to be filled with something, and vendor memory features store your organizational context on vendor infrastructure, which is Section 1's problem restated as a feature. The durable claims here are governance claims: who owns the context, who versions it, who audits its application, who can take it and leave. Model progress makes context cheaper to use; it does not decide where context lives. That said, if frontier vendors ever offered genuinely portable, customer-owned, standards-based context and memory, the architecture's differentiation would narrow; nothing in their current economics points that way, but it is a scenario worth watching.

Partly, use: a wiki nobody reads rots invisibly, while a Frame that orients every Cog conversation and Op run produces visible drift the moment it goes stale, and the Desktop Application routes feedback and suggested changes back to the accountable author. Partly, validation: regression Guards can flag when a Frame change degrades output. And partly, nothing: the paper assumes organizations will do context curation, and that assumption is real labor that some organizations will fail at. This guide lists it among the load-bearing assumptions; Frames lower the cost of maintaining context, they do not abolish the work.

Yes, definitionally, in the way that package registries are, and the analogy carries both ways: npm and PyPI created enormous value and real attack surface, managed with pinning, auditing, signing, and scanning. The architecture's equivalents: Nebi pins and logs every installation; Ops declare their tools, data access, and Guards up front, so a workflow that wants more than it declared is detectable; policy and safety Guards run against installed artifacts; and Tracks make post-incident forensics tractable. Prompt injection tops the OWASP LLM Top 10, and the paper's proposed response is community test harnesses and Guards. Fair summary: the risk is real, the mitigations are the software supply chain's playbook applied earlier and more explicitly, and buying workflows from strangers will always deserve the scrutiny that phrase implies.

The paper does not address MCP or comparable protocols directly, so this answer is the guide's inference. Tool-connection protocols standardize how a model reaches tools and data at runtime; they are complementary plumbing at the Cog layer (a Cog's declared tools could well be reached over such a protocol). What they do not attempt is what the Frame/Op/Nebi stack targets: governed organizational context with inheritance and custody, packaged installable workflows with declared validation, and marketplace distribution. Competition would arise only if tool-protocol ecosystems grew upward into context governance and workflow packaging. Layered coexistence is the more natural reading today.

It means the system reproduces, not the sentence. Nebi reproduces environments: model versions, dependencies, configurations, Frames, pinned and logged, so the Op you install is verifiably the Op that was published, and the one that ran in March can be reconstituted. Outputs remain stochastic, which the paper concedes in its own caveat, "within generative AI limits" (§3.2). Trust in outputs comes from the validation layer instead: Guards, Gates, and Tracks verify each run rather than pretending runs are identical. Determinism where it is achievable, verification where it is not: that division of labor is the actual claim.

Regulated industries are the beachhead, because they feel the audit and sovereignty pain first and McKinsey projects up to 40% of AI workloads heading to sovereign environments on their demand. But the architecture explicitly scales down: Organizational Memory can be a version-controlled folder of Frame files ("many will find this sufficient indefinitely," §3.4), Nebari components are usable à la carte, and a small firm's first meaningful step is authoring a Company Frame, which costs an afternoon and a strong opinion about how the company talks. The paper's continuum framing is credible here; the enterprise sales motion and the architectural minimum are different things.

From the paper (July 2026): Nebari exists as an open-source project (rearchitected as a modular stack since mid-2025, nebari.dev); the Frame protocol, Nebi packaging standard, first Ops/Cogs/Frames, and the Desktop Application are described as near-term deliverables; the public marketplace and vertical ecosystems are later phases. In other words: the infrastructure layer is real and inspectable now, the execution standards are hardening, and the economy is a forecast. This guide has tried to keep those three tenses distinct throughout, and readers evaluating the project should too: judge the shipped layer as software, the standards by their openness and early adoption, and the economy by Section 12's indicators.