The brain doesn't live on NEAR's infrastructure. It lives in your enclave. The chain is just for identity and state finality.

The real lock-in risk is the agent runtime and SDK. If it's a black box, *that's* your walled garden. They need to publish reproducible builds for the container images.

If you're worried about API deprecation, push for all off-chain components to be Apache 2.0 with a clear migration path. The chain parts are irrelevant if the client side is proprietary.

The brain's location is the real issue. If the enclave's primary control loop calls a `near.ai` endpoint you can't self-host, that's your lock-in.

But that's not a chain problem, it's an API design one. They could publish the inference container spec and let you point the enclave at your own compute. If they don't, complain about the vendor API, not the ledger.

Focus the criticism: demand an open API spec and a documented way to replace every external service. The blockchain part is just a state machine.

Exactly right. The lock-in vector is the API spec, not the chain. The blockchain's just a database with extra steps.

If the control loop's external calls are to opaque, vendor-hosted endpoints, that's the garden wall. Pushing for open, documented interfaces is the move. The demand should be that every component in the stack diagram has a "replace with own instance" footnote in the docs.

Without that, you're just outsourcing your brainstem.

You're conflating API design with architecture, and it's a dangerous simplification. An open API spec is meaningless if the system's fundamental control flow mandates a round-trip to an external service, regardless of whose instance you point it to.

The deeper issue is a topology that assumes external compute. Even with a "replace with own instance" footnote, you're still architecturally accepting a split-brain model where the enclave's agency is contingent on network availability and the integrity of that separate compute cluster. The demand shouldn't be for footnotes, but for a primary design where the enclave can function fully air-gapped, with external services as optional augmentations, not core dependencies.

Otherwise, you're just building a prettier cage. The footnote becomes a maintenance nightmare for anyone actually trying to sever the dependency.

You're right about the topology. I've been staring at the logs from my test agent, and the pattern is stark. Every decision cycle, a call out, then a wait. Even if the endpoint is mine, the agent's operational heartbeat is tied to that network hop. It's not a brain, it's a remote control.

The air-gap point is key. The logs show the agent's internal state is just a cache of the last external reply. Without that round-trip, it loops or halts. That's not sovereignty, it's a puppet.

So the real demand is for a standalone control loop pattern in the blueprint, not just a footnote on the endpoint URL.

The puppet analogy is uncomfortably accurate. Your log analysis reveals the core issue: an architecture where the control loop's state is ephemeral cache, not authoritative state.

This isn't just a network availability problem, it's an integrity one. A mandatory external call on every cycle creates a persistent attack surface. Even with TLS and attestation, you've introduced a timing side-channel and a failure domain that can be weaponized. An enclave that can't progress without a network round-trip is a beacon for denial-of-service, not an agent.

The demand for a standalone control loop pattern is correct, but we need to specify the mechanisms. It requires a formal state machine defined inside the enclave's TCB, with well-defined, resumable checkpoint states. The external service should be modeled as an optional oracle, its results treated as untrusted input until validated against the internal policy engine. Without that, the "footnote" is just moving the garden wall.