September 19, 2026
Agents Need Raw Access to the Runtime
Why Elixir, Erlang, and Kubernetes give agents the raw runtime access they need, and why that is part of our secret sauce for moving fast at Tuist.
I was reading the other day about Shopify's move to native and their approach of shipping a headless version of the app, where agents can test business logic without the UI. It made me appreciate even more our decision to build Tuist with Elixir and Erlang.
When you debug code written by an agent or investigate an issue in production, access to the runtime is essential: the most granular information possible, access to the code's symbols, and the ability to call them. Without it, the alternative during development is adding extra telemetry to validate assumptions. In production it's even worse, because you may have to deploy a new version of your software just to validate those assumptions before work on a fix can even begin.
Erlang is uniquely positioned here. You (and your agent) can open a console against a running instance and not only access symbols and call them, but also use an API to inspect process trees and see exactly how memory and CPU usage are distributed across them. The first time I saw something like this was with Ruby at Shopify, and similar tooling exists in languages like Python and PHP. But their runtimes don't reach this level of granularity, and more importantly, they don't have a scheduler that lets you do this even when a bug in your code is keeping every CPU busy. Erlang's scheduler does.
There are other ways to meet this need in languages that lack powerful runtime inspection, but having it makes a massive productivity difference because it eliminates a lot of back and forth. Imagine a patient arriving at the emergency room in critical condition, and instead of examining them to understand what happened and treating them, you have to send them away to collect more metrics first. That can be the difference between life and death. For production systems, it's the difference between keeping and losing a customer.
Go one level lower, to servers and ingress proxies, and you find the same story. We switched to Kubernetes because it gives agents a runtime API to understand the system and, when the situation calls for it, change it on the fly. We rely less and less on Grafana dashboards. The two features we use most from that stack are durable storage and alerts. From alert to solution, we give agents access to the cluster, and they consistently deliver a PR on the other end. Our usage of Grafana has become headless too.
This is part of our secret sauce for moving fast. You move fast when an agent doesn't need to tap into a browser to figure out client-side state, doesn't need to trace that state through a gRPC API to find the business logic behind it, and doesn't need to rely on assumptions about production resource usage because a PaaS abstracted them away. Agents thrive with the rawest possible access to systems at runtime. Sadly, most runtimes never invested in this, and many platform-as-a-service abstractions actively prevent it, getting in the way with packaging conveniences we no longer need. It's time to peel them away.