Stacklok’s newly open sourced Mecatl project gives the cloud native community a concrete version of a question that has been building all year: what should an AI agent runtime look like when it leaves a developer’s laptop and becomes production infrastructure?
The CNCF blog post announcing the project describes Mecatl as a cloud-native harness, not just another terminal agent. That distinction is the point. A desktop coding agent can bundle the user interface, local filesystem, shell, credentials, sandbox, session log, model calls, and tool registry into one long-running process because one person is sitting in front of it. A hosted agent fleet cannot assume that shape. It has to survive worker replacement, support multiple clients, preserve session history, govern tools, separate execution from control, and give security teams a way to reason about identity and delegation.
Mecatl is early, and the project should be read as an architectural proposal as much as a finished platform. But the proposal is timely. As agents move from individual development workflows into platform, operations, security, and internal tooling use cases, the hard problems stop being prompt phrasing and start looking familiar to Kubernetes operators: state, leases, isolation, observability, rollout, identity, and policy.
The Lead Event
On September 28, the CNCF published a member post from Stacklok co-founder Craig McLuckie making the case for a cloud native agent harness. The post centers on Mecatl, Stacklok’s open source agent harness for running agents locally, remotely, or on Kubernetes. The project’s GitHub repository describes it as a provider-agnostic loop with tools, permissions, hooks, delegation, durable sessions, event logs, client APIs, and Kubernetes-oriented deployment components.
The project separates the agent loop from surrounding concerns. In Mecatl’s model, the engine owns reasoning, tool dispatch, permissions, hooks, and event emission. Clients, execution environments, tool catalogs, model providers, state stores, identity systems, and coordination services sit behind explicit interfaces. A terminal UI, HTTP/SSE API, gRPC API, TypeScript SDK, Kubernetes runtime, or embedded application can interact with the same underlying loop without owning the whole system.
That is a different stance from simply putting a desktop agent in a container. Containerization changes where a process runs. It does not by itself make session state durable, tools governable, credentials separable, clients interchangeable, or workers disposable. Mecatl’s argument is that the harness itself has to be decomposed around cloud native operating assumptions.
Why This Matters Now
Agent tooling is passing through the same transition many developer tools passed through before it. The first useful form is local and interactive because that is where experimentation happens fastest. The next useful form is shared and service-oriented because organizations eventually need governance, repeatability, and scale.
For agents, that transition is sharper than usual because the harness is not just an application shell. It is the place where a model receives context, chooses tools, takes actions, writes files, calls external systems, starts subagents, and leaves behind an audit trail. If that machinery remains fused to a local desktop process, every enterprise requirement becomes an add-on: centralized policy, remote access, multi-client collaboration, state recovery, identity propagation, credential boundaries, and fleet observability.
The cloud native community has vocabulary and machinery for these problems. It knows how to run replaceable workers, externalize state, issue leases, route traffic, isolate execution, collect telemetry, and roll out new versions. Mecatl’s significance is that it applies those patterns to the agent harness itself, instead of treating the agent runtime as a special snowflake beside the rest of the platform.
This also changes who can use agents. A desktop coding agent assumes the user has a repository, terminal, local tools, and enough technical comfort to supervise every step. A cloud-native harness can support clients that look nothing like a terminal: a web application, a Slack workflow, a mobile interface, an internal support console, a CI job, or a collaborative document editor. The agent loop becomes a service capability rather than a UI feature.
The Architecture Shift
The most important design choice in Mecatl is the split between the agent loop and everything around it. That split sounds abstract, but it maps directly to operational control.
If the loop is a versioned service component, operators can roll it out, observe it, and replace it like other production workloads. If sessions and event history live in durable storage, a worker crash or pod eviction does not necessarily destroy the conversation. If clients connect through APIs rather than owning the process, the same session can be started in one place and resumed from another. If tools are exposed through a catalog with permissions and audit records, a hosted agent does not need the same unrestricted shell assumptions that made early desktop agents powerful but risky.
The GitHub repository highlights several pieces that make that model practical: durable sessions and append-only event logs through pluggable stores, client integration through gRPC and HTTP/SSE, a TypeScript SDK, a terminal client, Kubernetes session leases, drain handling, Redis-backed state, disposable replicas, and optional per-session execution environments. The documentation also emphasizes provider-agnostic model integration and explicit ports for persistence, locks, permissions, and model backends.
Those are not just implementation details. They are the difference between an agent that is convenient for one developer and an agent runtime that an infrastructure team can own. A platform team can ask where state lives, how a session is assigned, what happens during drain, which tools are available, which action required approval, what identity was attached, and where traces went. Those questions are mundane, and that is exactly why they matter.
Identity Becomes A First-Class Problem
The CNCF post is especially interesting on identity. When an agent calls an external system, the receiving service needs to know who is acting: the human user, the agent, the session, an application, or a delegated subagent. Stacklok’s proposed direction is to make Mecatl its own SPIFFE trust domain and encode the delegation chain in a JWT, giving policy engines a kind of call stack for the action.
That framing is useful because agent identity is not a simple service account problem. A long-running agent may act on behalf of a person, under a workflow, through a specific session, using a tool with scoped permissions, and perhaps via a subagent. Flattening that into one token loses the context that security decisions need. Over-expanding it into broad credentials creates a different risk: an agent with more authority than the task requires.
Cloud native identity systems already deal with workload identity, service identity, and short-lived credentials. Agents add a delegation layer on top. The policy question is not only whether a workload may call an API. It is whether this session, operating for this user, through this agent path, with this packaged context, may call this tool against this resource now. That is where a cloud native harness starts to look less like a chatbot wrapper and more like a security-sensitive control plane.
Tools Need Better Data Paths
Mecatl’s design discussion also points beyond MCP as a universal tool pipe. MCP is useful because it gives agents a standard way to discover and call tools. But not every tool interaction should move large inputs and outputs through the model context. A PDF decoder, repository indexer, build step, or data transformation may need access to workspace resources without forcing the model to read every byte.
Stacklok’s post describes scoped resource grants and direct tool-to-service data paths as areas of exploration. The principle is sound: the model should orchestrate when appropriate, but it should not become the data plane for every operation. Cloud native systems learned this lesson in other forms. Control planes make decisions and coordinate state. Data planes move traffic or process payloads efficiently under policy.
For agent platforms, that distinction can reduce cost, latency, and exposure. It also creates clearer audit points. Instead of asking whether the model saw sensitive content, a platform can ask which tool received which scoped grant, for how long, and under what session identity. That is the kind of question compliance and security teams will ask before hosted agents get broad access to internal systems.
Observability Is Part Of The Runtime
Agent systems need conventional infrastructure observability and behavior-level observability. Mecatl’s site lists OpenTelemetry traces, a resilience decorator for LLM calls, a slow-turn ring buffer, and an MCP-accessible performance server among its runtime features. That is a sensible baseline because agent failures can hide in places normal service dashboards do not capture well.
A hosted agent can be healthy from a process perspective while producing bad outcomes. It can respond quickly but take the wrong action, burn excessive tokens, loop through tools, or degrade after a prompt or model change. Grafana’s recent writing on applying SLOs and error budgets to agent behavior reflects the same broader trend: agent quality has to become observable as behavior, not merely as latency and error rate.
The operational implication is that a cloud native harness should emit events at the level platform teams need: turns, tool calls, approvals, model calls, context changes, session recovery, execution-environment actions, and policy decisions. Without that event stream, teams cannot debug incidents, compare versions, or decide whether a new model or skill package improved the system.
Who Should Pay Attention
Mecatl is most relevant to platform teams, developer experience teams, security engineering groups, and internal tools teams that expect agents to run beyond a single user’s workstation. If an organization only needs an individual coding assistant, a cloud-native harness may feel like unnecessary machinery. If it needs agent sessions that outlive a tab, run on shared infrastructure, call governed tools, and support more than one client, the machinery becomes the product.
The project is also worth watching for vendors building agent features into existing platforms. The temptation is to embed a model loop inside each product and let every team reinvent state, tools, audit, and permissions. A harness abstraction offers another path: keep the loop and governance model consistent while allowing different clients and tools to attach.
There are still open questions. Mecatl is early. Some of the hardest identity, resource-grant, and context-attestation ideas are design directions rather than finished features. Kubernetes deployment alone does not guarantee safe agent behavior. A decomposed harness can still be misconfigured, over-permissioned, or poorly observed. But those are the right problems to expose early because they are the problems production agent platforms have to solve anyway.
The Bigger Takeaway
The cloud native lesson for agents is not simply “run it on Kubernetes.” It is to make the agent runtime decomposable, observable, recoverable, governable, and identity-aware from the beginning. Mecatl matters because it gives that idea a concrete open source shape.
If agents are going to become part of production workflows, the harness cannot remain an opaque desktop bundle. It has to become infrastructure that platform teams can reason about. Mecatl may or may not become the standard implementation, but the architecture it argues for is likely to stick: agent loops as services, tools as governed capabilities, execution as an isolated environment, state as durable infrastructure, and identity as a delegation chain rather than a single credential.
