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, a review process, and declared Output Guards that must pass on its results, it would be most of the way to a Frame; the protocol standardizing the format is the rest.

A Cog is one of the three things "agent" is usually short for. Revision 9 splits the word deliberately (§4.2): the capability is a Cog, installable and auditable before it runs; the engagement is an Op, carrying the goal, the autonomy budget, the checkpoints, and the validation strategy; and the continuing actor, meaning identity, credentials, memory, and history, belongs to the Hub rather than to either artifact. The compressed form is "a Cog engaged through an Op, given identity and memory by the Hub." The reason to keep them apart is stated as a commercial one as much as an architectural one: fused, the three "are how vendors capture instance state and why governance cannot be tailored." It is also aimed 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, harnesses in the vocabulary Revision 9 adopts, provide orchestration libraries. What neither provides is the standard unit: a packaged, versioned, Frame-adapted, validation-declaring artifact that can be installed into any compliant deployment and audited afterward. Earlier editions of this guide had to infer that position; the paper now states it outright, calling a harness "a capability a Cog builder uses, not a competitor to the Cog" (§4.4) and repeating it in its landscape chapter. 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); the thing to watch is narrower than it used to be, namely whether Cogs built on different harnesses really do compose in one Op without the Op caring.

Revision 9 stopped arguing that they cannot. Its landscape chapter (§9) presents foundation model providers, cloud AI platforms, agent frameworks, and enterprise software vendors as legitimate choices with real strengths — several of them "components an owned Hub will use" rather than rivals to be defeated — and narrows the claim to this: open standards, portable context, and accountability rarely arrive together, and an ecosystem is better placed than any one vendor to supply the combination. The abandoned claim was that no incumbent is structurally configured to fill the category; a reader who found that argument convincing should note that its author no longer makes it.

The realistic threat is now named rather than described. A large vendor ships the whole shape (workspace, policy gatekeepers, app platform) free on rented compute, and organizations take the landlord for the convenience; Cloudflare OS gets its own row in the landscape table as the working instance. Earlier editions of this guide listed that scenario as its own brake on the flywheel (§11) and noted the paper did not dwell on it. It dwells on it now, and calls it "the brake most likely to bite." Agreement is not mitigation: we still consider this the strongest competitive risk to everything in Part IV. What is left to watch is the paper's answer, which is that ownership has to be made easier than renting. That is a product claim, and no amount of being right about the architecture will settle it.

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 in four places. Ops sold under subscription, usage, or outcome pricing, with the horizontal-becomes-vertical mechanism doing the work a consulting engagement used to. Commercial Cogs and specialist Guard libraries, whose value Revision 9 attributes to provenance rather than to code: "a HIPAA Privacy Guard is valuable because of who stands behind it." The products and services around the Hub, which the revision promotes into an economy of its own (§7.1) and which is where most of the revenue in a mature version of this market would sit. And assembly: selecting, integrating, hardening, and maintaining Hubs, now framed as a non-exclusive role that integrators and consultancies fill alongside the standard's steward. On OpenTeams specifically the paper is still plain, saying it "captures some of the value of those network effects through enterprise services, marketplace fees, and direct ecosystem participation with our own Cogs and Ops" (§8.1), which is the Red Hat/Anaconda position: steward the free layer, sell assembly, assurance, and distribution above it. Note which of these revenue lines the paper's own ledger supports today. Assembly does. Priced Ops depend on Ops as first-class installable objects, which the ledger files under active development, and marketplace fees on a marketplace filed under thesis. Commercial Cogs and Guard libraries sit between: the ledger places "the first Guard libraries" under active development, and the products economy has one shipped worked example, the Desktop/Web Application, with the rest forecast (Section 12). Today the only revenue this map describes as live is services.

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/Web 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 accountability plane 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 start as a version-controlled folder of Frame files, the simple end of the paper's continuum (§3.4), though the paper expects most organizations to outgrow it ("most will not find this sufficient"). 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.

Earlier editions of this guide had to reconstruct that answer from a roadmap. Revision 9 (August 2026) supplies it directly, in a three-row ledger reproduced in full in Section 12. Its own summary: existing today are Nebari (nebari.dev) and NIC, which the paper names without ever expanding, Nebi packaging (on the pixi and conda lineage), owned Intelligence Hubs in production, Frames as governed artifacts, a Desktop/Web Application, and owned model serving on open weights. In active development are Cogs and Ops as first-class installable objects, the Op manifest with a declared validation strategy, multi-organization Hubs, and the first Guard libraries. Filed as thesis are the accountability plane running at scale, the marketplace across many independent Hubs, and the distributed AI economy itself.

Two things follow. The first is that the three tenses this guide has kept apart (shipped software, hardening standards, forecast economy) now have a source in the document rather than only in the reading, and the mapping is close: infrastructure real, execution standards mid-flight, economy forecast. The second is that a self-graded ledger still needs reading with care, and Section 12 does that reading: "owned Intelligence Hubs in production" is unquantified, "Frames as governed artifacts" describes a product surface no outside reader can inspect while the Frame protocol's publication is still a roadmap milestone, and the application listed as existing today is also listed as a Phase 1 release and a Phase 2 general-availability milestone. Judge the shipped layer as software, the standards by their openness and early adoption, and the economy by Section 12's indicators.