Who Owns the Harness?

The model can be replaceable while the system around it is not.

An organization may have a choice of model providers and still depend on one supplier for prompts, memory, tool connections, agent identities, routing rules, approvals, audit records, and operating knowledge.

That surrounding system is the harness.

It converts a model into an application that can participate in work. It also becomes the place where technical and organizational dependency accumulates.

If the harness cannot move, a model dropdown does not provide meaningful portability.

BAMS infrastructure and inference fleet. All displayed data is simulated.

What the Harness Contains

The term is useful because it makes an invisible boundary visible.

For an enterprise agent workflow, the harness commonly includes:

• the application interface and work objects
• the orchestration that sequences tasks and tools
• the identities and permissions assigned to agents
• the organizational memory and retrieval policy
• the provider and model routing rules
• the integration adapters and credentials
• the approval and escalation state machine
• the budgets, quotas, and operational limits
• the evidence, audit, and recovery records
• the procedures used by operators and implementation staff

The model receives a prepared request from this system. Its output returns into this system. The harness decides what the output is allowed to affect.

That is why a model can be swapped in a demonstration while a production deployment remains difficult to move.

The valuable dependency is not only the API call. It is the accumulated configuration and operating context around the API call.

Seven Ownership Rights

Ownership is more useful when expressed as rights that an operator can exercise.

1. The right to run

The organization can run the application and required services in an environment it controls or has selected under its own infrastructure policy.

This includes the ability to start, stop, monitor, back up, and recover the deployment.

2. The right to route

The organization can choose which model providers and model classes serve each workload. It can inspect the rule, change it, and disable a provider.

3. The right to govern context

The organization controls which sources enter memory, which identities can retrieve them, how context is retained, and how it is exported or deleted.

4. The right to control authority

The organization can define agent permissions, approval boundaries, budgets, and stop conditions without asking the supplier to interpret the change.

5. The right to inspect evidence

The organization can see the operational record required to explain a run, investigate an exception, and satisfy its own review process.

6. The right to change

The organization can replace a provider, integration, workflow rule, or operating owner without reconstructing the complete system.

7. The right to leave

The organization can export the required state, retain its knowledge, recover its procedures, revoke supplier access, and continue the workflow in an agreed form.

These rights are stronger than a sentence that says the client owns its data. Data ownership matters, but a database export does not transfer the harness that made the data useful.

BAMS Separates the Operating Layers

BAMS is designed as a set of separable layers rather than a single model service.

The current reference architecture includes a web operator interface, an application and API layer, agent orchestration, a memory layer, local and external inference paths, persistent storage, and security controls for identity, access, audit, sanitization, quality, and task governance.

The product interface exposes the operational consequences of those layers. Operators can see work, approval state, agent identity, provider health, route bindings, budget, memory, governance activity, circuit breakers, and infrastructure state.

Separation does not guarantee portability by itself. It gives us a structure that can be packaged, documented, tested, and handed over.

For a client-owned deployment, the target state is clear:

1. The client selects and controls the deployment environment.
2. BAMS runs as the governed operating layer inside that environment.
3. The client selects permitted model routes, including local routes where required.
4. Approved organizational sources connect under client access rules.
5. Agent identities receive explicit permissions and budgets.
6. Operators receive runbooks for routine control and failure states.
7. Exit tests are defined before production acceptance.

This is the practical meaning of owning the harness.

Hosting Is One Part of Ownership

Self-hosting can become another vague promise.

A supplier may install software into a client environment while retaining exclusive knowledge of configuration, upgrades, recovery, and policy changes. The servers belong to the client. The capability still belongs to the supplier.

Infrastructure ownership must be paired with operational transfer.

The handover needs deployment manifests, dependency inventory, configuration references, backup and recovery procedures, provider and connector inventory, identity and access maps, monitoring expectations, update procedures, and known limitations.

It also needs a named client operator who performs the procedures during acceptance.

A runbook that has only been used by its author is a draft. Handover becomes evidence when another operator can use it.

The Connector Trap

Integrations are a common source of harness dependency.

An adapter can contain more than an endpoint. It may include field mappings, credential handling, approval rules, retry behaviour, error interpretation, and assumptions about the source system.

If these details exist only in supplier code or supplier memory, the organization cannot operate the connection safely.

BAMS represents integrations with explicit health and configuration state. The reference implementation contains a mixture of working, degraded, disabled, and deployment-specific adapters.

We present that state directly. We do not claim that every external system is ready to connect.

For a client deployment, a connector is included only when its source, permissions, credential path, failure behaviour, and acceptance test are named in scope.

This is slower than placing logos on a slide. It is faster than discovering in production that a promised connector has no safe operating path.

Commercial Beta Boundary

BAMS runs as an internal reference implementation today. We are productizing a repeatable commercial beta appliance for client-controlled environments.

The architecture supports the ownership direction. The productization work includes repeatable packaging, customer-safe workspace isolation, connector hardening, and buyer evidence exports.

We will not call that work complete before it passes deployment and handover acceptance.

This distinction is important for buyers. The proposition is not "everything is already packaged." It is "the operating system exists, the ownership model is explicit, and the commercial beta engagement completes a bounded deployment with the client."

Questions for the Supplier

When reviewing an enterprise AI system, ask the supplier to demonstrate ownership as an operator action:

1. Show where the application runs.
2. Show who can stop and recover it.
3. Show the model-routing rule and change it.
4. Disable one provider.
5. Show an agent's identity and revoke one permission.
6. Show where organizational context is stored and how access is applied.
7. Export a decision record.
8. Identify every external connector in the workflow.
9. Hand the recovery runbook to a client operator.
10. Explain what remains if the supplier account is removed.

These are not hostile questions. They are basic architecture questions for a system that may become part of daily operations.

No Strings Attached

The phrase is credible only when the client can exercise the rights behind it.

Own the environment. Control the model layer. Govern the context. Define the identities. Inspect the evidence. Operate the system. Test the exit.

BAMS is built around those rights.

The Forward Deployed Engineer helps put them into one production workflow and transfers the operating knowledge required to use them.

The goal is not a permanent BlackUnicorn layer between the organization and its AI system.

The goal is a governed system the organization can run, change, and leave with.

Build a Harness Inventory

Ownership begins with knowing what the workflow depends on.

A harness inventory should record:

• BAMS component and version
• deployment location and operational owner
• model providers and local inference services
• organizational sources and memory domains
• agent identities and human owners
• external tools and connectors
• credentials and secret-management path
• route, budget, approval, and access policies
• persistent stores and backup responsibilities
• evidence and export formats
• runbooks and client operators
• licence and continuing-use constraints

The inventory should link each component to the workflow it supports. This prevents a broad platform list from obscuring which dependencies are material to the accepted production path.

It also reveals shared components. Disabling one connector or route may affect several workflows. The client needs to know the blast radius before exercising the control.

Configuration Is Part of the Asset

Software and data receive attention during ownership reviews. Configuration is often left behind.

The route bindings, access rules, approval states, connector mappings, budgets, lifecycle settings, and failure behaviour express the organization's operating decisions. They are part of the harness asset.

The handover needs a way to document and, where agreed, export or reproduce them. It should also distinguish client policy from BlackUnicorn product defaults.

This distinction matters during upgrades. A product change should not silently overwrite an accepted client rule. A client policy change should not be mistaken for a product modification.

Test the Rights Separately

The seven ownership rights can fail independently.

The client may have the right to run the software but lack a usable context export. It may control the model route but rely on a supplier-owned connector credential. It may possess every configuration file while no operator has used the recovery procedure.

Acceptance should record each right separately:

1. Run and recover.
2. Inspect and change routes.
3. Govern and export context.
4. Change and revoke authority.
5. Reconstruct evidence.
6. Replace named dependencies.
7. Remove supplier access and continue the agreed workflow.

This produces a more accurate ownership position than a single yes or no statement.

Ownership After an Update

Dependencies change after deployment.

A new model can alter route assumptions. A connector update can change permission scope. A storage migration can affect evidence export. A new agent tool can expand authority.

Material changes should update the harness inventory and rerun the relevant acceptance tests.

Ownership is not transferred once and then assumed forever. It remains operational when the organization can understand and govern how the harness changes.

BAMS provides the shared control surfaces for that work. The handover gives the client the procedures and authority to keep using them.

The Supplier Account Test

One final test exposes hidden ownership.

Assume the supplier's people and accounts lose access tonight. Do not remove the licensed product or agreed support rights. Remove only the informal dependency on supplier-operated credentials, private notes, and personal knowledge.

Can the client still start the system, inspect health, process the accepted workflow, change a route, resolve an approval, correct context, pause an identity, recover a failure, and retrieve the required evidence?

If not, identify the missing asset.

It may be a credential that should be client-owned, a configuration that was never documented, a connector only the FDE can repair, an export that lacks metadata, or a runbook no client operator has used.

The test does not demand that the client perform every future product upgrade alone. It asks whether the accepted operating capability belongs to the client in practice.

For BAMS, this is the intended outcome of the commercial beta engagement. The product supplies the governed harness. The FDE maps it to the organization and transfers the operating packet. The acceptance test determines whether the client can exercise the rights it was promised.

Ownership becomes credible when the supplier account is no longer part of the normal control path.

<!-- Editorial evidence: E04 and E11 in series/bams-no-strings-attached/EVIDENCE-LEDGER.md -->