The boundary is moving

A laptop used to be an obvious endpoint. A server belonged to infrastructure. An identity belonged to an access system. Those categories still organize teams and budgets, but they are becoming less useful as boundaries for control.

Consider a team working with a private model. Its developers use local workstations, a server exposes the model to internal applications, and rented GPU capacity handles a training run. Sensitive data, credentials and model artifacts move through that whole environment. The management responsibility follows them, even when ownership passes from endpoint IT to infrastructure or a service provider.

Each team can have a perfectly reasonable tool for its part. The difficult work happens between those tools: deciding whose policy applies, making the permitted change on the right surface, and establishing whether the intended state actually holds.

That is the opportunity we see. Every compute surface is becoming an endpoint in the operational sense: something with an identity, an owner, a desired state and a need for continuing control. A model service is different from a laptop. Both still need an accountable path from policy to reality.

Where policy becomes reality

An access system can establish who may connect. A security product can identify a condition that needs attention. An orchestrator can decide what to do next. The remaining responsibility is specific: carry that decision through the execution boundary and establish what changed.

We call that the last mile. In Smplify, it brings together the caller and customer tenant, the native plan, the authority to execute it, and the evidence returned by the managed surface. It is where a requested outcome acquires consequences.

An accepted request is only the beginning of that responsibility. Delivery, application and verification describe different events. A later change can undo a previously verified result. The operating record has to preserve those distinctions so the next decision starts from what is known.

This is why we start with endpoints. Apple, Windows and Linux already make the problem concrete. They have different management channels, different constraints and different ways of reporting state. Smplify uses native Apple management, native Windows management and signed bundles through its Linux agent. The control plane keeps the policy, authority and evidence connected across those paths.

Our first two Field Notes examined the control plane and the intent it carries. The larger question is where that operating model can go as enterprise compute changes shape.

Reading Plate 002

The centre of Plate 002 is the last-mile control plane. The first sector identifies the customer boundary an operation must preserve. The second follows the work through execution and verification. The third opens toward the compute surfaces we intend to reach next.

SECT I · BOUNDARY

1. Caller identity
2. Customer tenant
3. Approval authority
4. Customer evidence

SECT II · CONTROL

1. Resolve the request
2. Authorize the native plan
3. Execute through the platform channel
4. Verify observed state
5. Reconcile drift under policy

SECT III · EXPANSION

1. Servers
2. AI workstations
3. GPU nodes
4. Model endpoints
5. Agents
6. Neocloud workloads

The dashed arcs describe the endpoint foundation being brought into production. The dotted expansion arcs describe our strategic direction; they do not indicate current support. The external dial represents the systems that reason over evidence and request work. A change still crosses the control plane's execution boundary.

One operating model, distinct customer boundaries

For a partner serving several enterprises, the last mile has another dimension. Each customer brings its own identities, policies, approvers and records. If each also requires another version of the integration, the partner takes on a new maintenance burden with every deployment.

Smplify's multi-tenancy is designed around that repetition. A partner can reuse the integration and operating model while each customer retains a separate authority boundary. The tenant accompanies the work into planning, approval, execution and evidence. It determines where the request belongs and whose decision permits it to proceed.

Consider a security provider offering a hardening workflow to two customers. The outcome may be the same. One customer may permit a routine change under an existing policy; another may require independent approval. The provider needs a consistent way to operate both environments, and each customer needs a result that can be explained on its own terms.

That is the practical value of multi-tenancy: the next customer can reuse the workflow without inheriting another customer's permissions or evidence. A common view remains useful precisely because the underlying customer boundaries remain distinct.

It also gives Smplify two routes into the enterprise. A partner can embed the control plane inside a product its customers already use. An enterprise team can use it directly across its own fleet. Both routes rely on the same last-mile responsibility, rather than asking the customer to adopt a particular front end before the control becomes available.

As compute expands, this matters further. A service provider managing a customer's workstations and infrastructure needs to carry that customer's authority through both. Merely adding another resource type to an inventory would leave that work unfinished.

Changing the AI should not change the control

AI makes it easier to propose changes across this environment. A customer might use Claude Code, Codex or an internal agent to investigate a problem and request an outcome. Over time, the preferred model and the software around it will change. The enterprise still needs a stable place to decide what those requests are allowed to do.

Deterministic control begins at the accepted request. Given the same canonical intent, parameters, target facts and versioned mappings, the control plane should produce the same native plan. The model's interpretation can vary before that point; the meaning of the accepted operation must be precise enough to inspect and govern.

That distinction has a concrete consequence. If a target, parameter or platform mapping changes, the resulting plan must expose the difference. An approval belongs to the work that was reviewed. It cannot quietly stretch to cover a new operation because an agent describes it as the same task.

Determinism also has to be honest about the world outside the planner. A reproducible plan cannot make an offline device respond or make an unsupported setting available. It can make those conditions explicit and preserve enough evidence for a person or another system to decide what happens next. Predictability comes from a defined contract and observable state, including when execution cannot finish.

This is the foundation for useful autonomy. An agent can investigate, propose and coordinate work across tools while the control plane retains the tenant boundary, execution rules and record. Customers can improve their reasoning systems without rebuilding the authority underneath them.

Start with endpoints, follow the compute

Our starting point is enterprise endpoints across Apple, Windows and Linux. The next expansion is servers and AI workstations, followed by GPU nodes, model endpoints, agents and neocloud workloads. This is a progression in the surfaces we intend to control, with a consistent responsibility at each step.

The progression will require surface-specific work. Managing a model endpoint includes the service and its runtime context. Governing an agent involves the identity, permissions and tools through which it acts. A GPU workload brings its own lifecycle and infrastructure dependencies. Calling them endpoints does not make their controls interchangeable.

What should carry forward is the operating contract: an identified surface, a customer boundary, an authorized desired state, an execution path and evidence that the state holds. Expanding that contract means adding the right native controls and verification for each surface while preserving the enterprise's authority over the work.

The measure of that expansion is operational. A customer should be able to add a new kind of compute and retain the same policy, posture and remediation discipline. A partner should be able to carry it into another customer environment without rebuilding the integration or weakening the boundary.

Smplify is building the last-mile control plane for the AI-era enterprise. Endpoints are our starting point. The work ahead is to carry the same responsibility wherever enterprise compute goes: deterministic control where policy becomes reality.