Who Owns the Model? Sierra, Decagon and Writer vs Enterprise AI Vendors With Their Own Model Stack (2026)

Enterprise AI vendors that own their model may train or maintain models, but that does not mean your enterprise owns the weights. In 2026, Sierra, Decagon, Writer, and NuPlay AI show different combinations of model development, routing, self-hosting, and external-provider use. Procurement should test provenance, inference location, portability, and change approval separately.

Disclosure: NuPlay AI builds a competing enterprise AI platform. We reviewed public product documentation and technical posts for this comparison; we did not conduct hands-on tests.

Andreessen Horowitz surveyed 100 verified vice president (VP)- and C-level respondents at Global 2000 companies. The survey found that 81% used three or more model families in testing or production. It was non-random and self-reported, and focused on large enterprises already active in artificial intelligence deployment, so it is not representative of the whole market. It does support one procurement conclusion: buyers often need to evaluate a stack rather than select one “owner” label. Source: Andreessen Horowitz, January 30, 2026

What are enterprise AI vendors that own their model?

Enterprise AI vendors that own their model are vendors that train, maintain, or post-train named models instead of relying only on external model providers. That label does not establish that the customer owns the weights, can export them, or can run the full system outside the vendor’s environment.

Model ownership is best evaluated as four separate questions:

These claims are not interchangeable. A vendor can develop a model while still using external models for some tasks. A platform can offer customer VPC deployment without giving the customer ownership of model weights. A vendor can also orchestrate several providers without claiming to own a foundation model.

Vendor ownership is therefore not automatically better. Sierra’s published multi-model architecture shows why some buyers may value task fit and provider redundancy, while NuPlay AI’s Astra page presents self-hosting and no third-party model dependencies as priorities. Sierra’s model architecture · NuPlay AI Astra

Compare the public evidence

The table separates what each vendor publicly documents from claims that require contractual validation.

Sierra: multi-model orchestration

Documented: Sierra’s December 3, 2025 post says its agents use “15+ frontier, open-weight, and proprietary models.” It says the models are selected for specific tasks and that Sierra invests in fine-tuned models when off-the-shelf options do not meet its constraints. Source: Sierra

Documented: Sierra’s February 13, 2026 technical post describes a Multi-Model Router that follows task-level model ordering. When a primary model is constrained, it can select a pre-validated alternative when fallback is permitted. Source: Sierra

Not publicly verifiable: The reviewed materials do not identify a Sierra-developed foundation model. They also do not establish who owns the weights behind Sierra’s proprietary models, whether customers can export them, or which deployment rights are available.

Decagon: specialized models alongside external providers

Vendor claim: Decagon says that “over 80% of all model traffic at Decagon runs on models we trained ourselves.” This is a statement from Decagon, not independently verified market evidence. The same post describes specialized models for functions such as identifying the end of user speech, executing workflows, and detecting hallucinations. Source: Decagon, March 24, 2026

Documented: Decagon’s July 2025 evaluation post says its agents use models from OpenAI, Anthropic, Gemini, and other providers alongside Decagon’s fine-tuned versions of open-source and commercial models. Source: Decagon

Not publicly verifiable: The reviewed sources do not establish whether Decagon’s internally trained models began from scratch, were post-trained from open models, or were derived from commercial models. They also do not establish customer rights to weights, export, or customer-controlled deployment.

Writer: named Palmyra models plus external options

Documented: An AWS-hosted customer case study says Writer develops and maintains the Palmyra family, including general-purpose and domain-specific models. Because this is a hosted customer case study, it should be treated as documented product information rather than independent market analysis. Source: AWS

Documented: Writer’s model documentation lists Palmyra models and external models available through AWS Bedrock and OpenRouter. It describes these as options that can be used alongside Palmyra models in Writer’s agent-building tools. Source: Writer documentation

Documented: Writer’s August 12, 2026 Palmyra X6 technical report says the model was post-trained on GLM-5.2 and that fine-tuning updated the base model’s weights. Source: Palmyra X6 technical report

Not publicly verifiable: The reviewed material does not establish customer ownership of Palmyra-derived weights, export rights, or a customer-controlled deployment model for every Writer surface.

NuPlay AI: self-hosted Astra model layer

Vendor claim: NuPlay AI’s Astra page identifies Astra LLM as a 31B-parameter self-hosted model and Astra SLM as a 9B-parameter self-hosted specialist model. The page says Astra SLM can be deployed inside a customer VPC and that Astra has zero third-party model dependencies. Source: NuPlay AI Astra

Vendor claim: The Astra page also presents the models as tuned on customer production data and states that the model layer is 100% self-hosted on the customer’s infrastructure. These are product claims from NuPlay AI, not the result of an independent technical audit.

Not publicly verifiable: The page does not establish that customers own Astra weights or can continue operating them if the vendor relationship ends. Buyers should request the applicable licensing, portability, and deployment terms.

A four-question procurement test

The a16z survey’s finding that most large enterprises use multiple model families is a useful reason to evaluate the full stack, not just a vendor’s model label. Source: Andreessen Horowitz

1. Who created each production model?

Ask the vendor to identify:

• The model name used for each production task
• The base-model lineage
• Whether the vendor pre-trained, post-trained, or fine-tuned it
• Which parts of the model stack are vendor-owned
• Which third-party models or APIs remain in the production path
• Whether model versions can change without customer approval

A claim that a vendor “trained its own models” is not enough to answer all six questions. Decagon’s public material, for example, describes both internally trained models and models from external providers. Writer’s documentation likewise presents Palmyra and external models as available options.

2. Where does inference run?

Request an architecture diagram that identifies:

• Vendor-hosted inference
• Customer VPC components
• On-premises components
• External model-provider calls
• Retrieval and knowledge services
• Logging, evaluation, and observability services
• Data flows for prompts, responses, traces, and fine-tuning material

Ask whether the architecture changes by product surface, model, region, or workload. A vendor may offer self-hosting for one model or deployment pattern while using external services elsewhere.

3. What survives a vendor or provider change?

Ask whether you can export and reuse:

• Prompts and system instructions
• Workflow logic and tool definitions
• Evaluation sets and results
• Knowledge sources and retrieval configuration
• Fine-tuned weights or adapters
• Run traces and audit records
• Version history and rollback information

Customer rights are contractual questions. A vendor’s ownership of a model does not establish that the customer owns tuned weights or can operate the model independently.

4. Who approves production changes?

Require a documented process for:

• Testing model, prompt, retrieval, and workflow changes
• Comparing changes against past production runs
• Setting release thresholds
• Recording an approval decision
• Versioning releases
• Rolling back a change
• Identifying which person or team can promote it

This question applies even when the vendor controls the model layer. Model ownership does not replace change governance.

Hypothetical worked example: a regulated insurer

Assume a regulated insurer has two requirements:

1. No undisclosed external inference calls in a production workflow
2. Tested workflow behavior must be preserved after a model-provider outage

The insurer should not mark a requirement “passed” because a vendor uses proprietary models. It should classify each requirement as Documented, Contractually confirmed, or Unverified. No contract terms were reviewed for this article, so none of the cells below is contractually confirmed.

The insurer should then request architecture diagrams, contractual language, failure-mode tests, and evidence from a representative workflow. If the vendor cannot answer, the requirement remains unverified.

The operational trade-off: model diversity versus a controlled model layer

Model ownership is only one architecture criterion. Sierra’s public materials describe task-specific model selection, redundancy across providers, and controlled fallback when a provider is constrained. That approach may suit buyers who prioritize model diversity and provider resilience. Source: Sierra

The trade-off is that a multi-provider design can introduce more dependencies to document and govern. Buyers need to know which models process which tasks, how provider changes are controlled, and what happens when a preferred model is unavailable.

Decagon presents a different form of proprietary investment. Its public material describes specialized models embedded in a CX architecture, while its evaluation post also describes external models and fine-tuned versions of open-source and commercial models. This indicates a mixed model stack, not an exclusive one. Source: Decagon · Source: Decagon

Writer publishes named Palmyra foundation models while also documenting external model access through AWS Bedrock and OpenRouter. This gives buyers a model choice inside the platform, but the available deployment and ownership rights still require verification for the specific product surface. Source: Writer

NuPlay AI is an option for buyers prioritizing an in-house, self-hosted model layer. Its Astra page states that Astra LLM and Astra SLM are self-hosted, and that Astra SLM is deployable in a customer VPC. Those claims should be evaluated against the customer’s required architecture and contract terms.

NuPlay AI runs enterprise workflows in production and improves them after every run through NuLoop, with agents, the systems they operate, and the context they draw on under one platform.

Vendor claim: NuPlay AI’s public NuLoop page says the system records and replays runs, surfaces recurring patterns, turns each pattern into a targeted change, tests changes against real and simulated runs, and versions releases for rollback. It specifically documents a “Propose only” configuration in which a person approves or rejects changes. The public material describes more than one approval configuration, so buyers should verify the approval boundary that applies to their deployment. NuLoop

How to choose among these model-stack approaches

Choose based on the controls your workload requires, not on the phrase “owns its model.”

• Prioritize multi-model routing when task-specific model selection and provider redundancy matter more than using one vendor-controlled model layer. Ask for provider maps, fallback rules, and change controls.
• Prioritize specialized vendor-trained models when the vendor’s own training work maps closely to your workflow. Verify base-model lineage, external dependencies, and customer rights.
• Prioritize a named foundation-model family with external options when you want a vendor-developed model but also need access to other providers. Confirm which product surfaces support each model and where inference runs.
• Prioritize a self-hosted model layer when reducing third-party model dependencies and supporting customer-controlled infrastructure are procurement requirements. Confirm whether self-hosting applies to every required model and whether the customer receives any weight or portability rights.
• Treat governed change as a separate requirement regardless of model ownership. Require testing, approval, versioning, and rollback evidence for the production workflow.

Request a NuPlay walkthrough to assess model-layer ownership, VPC deployment, and governed workflow improvement.