Skip to main content

What is a cloud-native harness?

A cloud-native harness is an agent runtime designed as a distributed application, not a desktop tool copied into a VM.

A desktop harness commonly ties the client, agent loop, filesystem, tools, credentials, and conversation state to one long-lived machine. Putting that machine in a container changes where it runs, but not how it is built.

Mecatl takes a different approach. Its core engine owns the agent loop, while clients, execution environments, model providers, tools, and durable state sit outside it behind explicit boundaries. The same loop can run locally, as a service, or on Kubernetes without being replaced.

Explode the harness into its parts​

A cloud-native harness separates the parts that a desktop harness often keeps inside one process:

  • Agent loop: reasoning, tool dispatch, permissions, hooks, and event emission.
  • Clients: terminal, API, and application clients that interact with the loop without owning it.
  • Execution environments: assigned workspaces and command runners.
  • Tool ecosystem: built-in tools, streaming-HTTP MCP services, skills, and application-supplied integrations.
  • Supporting services: model providers, session state, event history, identity, and coordination.

These boundaries let each part evolve on its own terms instead of requiring one long-lived machine to be the client, sandbox, database, tool host, and agent runtime.

What the boundaries enable​

Run the loop like an application​

The loop can be versioned, rolled out, logged, and observed like any other application component. In a Kubernetes deployment, workers can be replaced during normal operations without making durable sessions disappear. See Choose how to run Mecatl and deploy mecak8s.

Keep sessions beyond a worker​

A worker can be disposable while a session is not. With durable storage and coordination, a replacement process resumes from the last persisted turn boundary. It does not resume an in-flight operation, and work after the last successful save can be lost. See Session continuity for the storage, recovery, and single-writer model.

Build a governed tool ecosystem​

A cloud-native harness does not need an unrestricted remote desktop to be useful. Mecatl can expose purpose-built tools, MCP services, skills, and application integrations through an explicit catalog with permission, audit, and execution-environment boundaries.

Shell remains an available, governed capability when it is needed. The direction is to make it less necessary by expanding purpose-built, permissioned tools and service integrations for common agent tasks. See Execution environments and extension points.

Serve more than one kind of client​

The same loop can support local terminal work, remote services, embedded applications, and Kubernetes deployments. A client does not need to own the agent's filesystem, credentials, or durable session state to interact with it.

Where this is going​

Mecatl is early, and the cloud-native harness is a direction as well as a current architecture. We are working toward:

  • More clients. Mecatl already supports the TUI, gRPC, HTTP/SSE, and the TypeScript SDK. Next are web, desktop, and mobile clients, along with new interaction models such as Slack and collaborative documents, all over the same client/server core. See the TypeScript SDK and gRPC and HTTP/SSE contracts.
  • Strong identity. We want external systems to receive a verifiable delegation chain showing which user, agent, and subagent acted with which authority. The proposed design makes Mecatl its own SPIFFE trust domain and encodes that chain in JWTs. See the agent identity model working draft.
  • More tools. We want a richer ecosystem beyond MCP, including tools that can call each other directly with narrowly scoped resources instead of copying large inputs through the harness and agent context. Scoped Resource Grants proposes short-lived, attenuable grants and direct tool-to-service data paths; it is also a working draft.
  • Cryptographic context attestation. We want packaged agent context to be versioned, signed, attributable, distributable, and subject to policy, like modern software supply-chain artifacts, and to make that provenance available in the agent identity chain.

These are directions, not guarantees of current availability. The linked agent identity and scoped-resource-grants documents are explicitly speculative; the deployment and feature guides describe what Mecatl supports today.

Next steps​