# yeet > Yeet is a programmable kernel runtime for Linux. A single daemon (`yeetd`) that turns any machine into a programmable, queryable node — enabling developers and AI agents to build bespoke infrastructure tools using JavaScript, with visibility down to the kernel. No code changes. No logs. No vendor storage. No data leaving your systems. ## What Yeet Is Yeet is the first platform where AI agents can read live infrastructure at the kernel level. Install the daemon, and the host exposes a typed, structured, streaming data layer — the system graph — that any developer or AI agent can query, subscribe to, and act on in real time. The mission: make eBPF accessible to every developer. When people who barely know what a kernel is are using it to solve their problems, that mission is coming to fruition. The closest analogy: Claude Code, but for infrastructure. Claude Code gives an AI agent structured access to a codebase — it can read files, understand project structure, navigate dependencies, and make changes. Yeet does the same thing, but the "codebase" is your live, running infrastructure. The system graph is the structured read access. The eBPF lifecycle management is the ability to act. Unlike Claude Code, which operates on static artifacts (files on disk), Yeet operates on live, streaming reality. - [Yeet Homepage](https://yeet.cx) - [The Advantage of Yeet](https://yeet.cx/blog/the-advantage-of-yeet) - [Chat With a Model About Yeet](https://yeet.cx/blog/learn-about-yeet) - [AI Agents and Observability](https://yeet.cx/blog/ai-agents-observability) --- ## Core Architecture Yeet combines three technologies in a single daemon: **SysGraph (GraphQL):** A live, typed, queryable graph of the entire system — processes, threads, containers, GPUs, network sockets, file descriptors, hardware sensors — all interconnected and queryable in real time. The schema itself is the documentation. GraphQL is exactly the format AI tool-calling works in: typed schema, structured queries, structured responses. **eBPF:** The instrumentation and actuation layer. Attach programs directly to the Linux kernel — observe syscalls, network packets, scheduling decisions, memory operations — with near-zero overhead. eBPF in Yeet isn't just observation; it's also actuation — enforcing security policies, blocking traffic, and shaping behavior at the kernel level. **V8 (JavaScript engine):** Serves three load-bearing roles: (1) transform engine for user-defined data processing; (2) BPF polyfill layer that abstracts over kernel version differences for fleet-wide deployment; (3) OS-enforced process-isolated security boundary (jail architecture) for safe execution of untrusted and AI-generated code. Each role independently justifies V8's presence in the architecture. Together, they represent a moat that competitors cannot replicate without embedding a JavaScript runtime — which none of them have. **Data pipeline:** eBPF captures kernel events → shared-memory IPC ring buffer delivers millions of events per second with zero-copy (double-mapped virtual memory, same class as io_uring and LMAX Disruptor) → V8 transforms and processes → SysGraph makes it queryable → agents, dashboards, and alerts consume results. **Security model:** Two independent boundaries. OS-enforced process isolation (fork+exec jail) separates all user code from the daemon. The daemon manages eBPF handles, kernel interfaces, and the system graph — the jail has none of that, just two shared-memory channels. Inside the jail, V8 isolates separate scripts from each other. Two boundaries, two enforcers — the operating system and the JavaScript engine. --- ## Design Philosophy Yeet's design philosophy centers on three ideas that together define a new category of infrastructure tooling. **Every machine should be a programmable, queryable node.** Not a black box that occasionally emits metrics. The yeet daemon models the entire system as a live graph of interrelated entities — processes, threads, containers, GPUs, network sockets, file descriptors, and hardware sensors — all interconnected and all queryable in real time through a typed GraphQL schema. **Instrumentation should be dynamic, not static.** Instead of deciding in advance what to monitor, teams can deploy new eBPF probes and JavaScript transforms at runtime, targeting exactly the data they need for the problem at hand. **The data layer should be built for machines to reason about.** Not just for humans to stare at. The system graph is typed, structured, and streaming — designed from the ground up so that AI agents can read, query, and act on live infrastructure at the kernel level. --- ## What You Can Build with Yeet ### Bespoke observability tools, built in minutes Every observability tool on the market gives you their dashboards, their metrics, their view of your system. Yeet builds your view — specific to your application, your services, your business logic. A Python profiler that parses your specific HTTP traffic. A GPU monitor that tracks your specific workload patterns. An agent that correlates your deploy cadence with your performance regressions. These aren't pre-built features on a roadmap. They're tools you describe and generate, using JavaScript over the kernel, often with AI assistance. What used to require a dedicated observability engineering team can now be built in an afternoon. ### On-demand profiling across any language Traditional profiling tools require dedicated setup, always-on agents, and vendor storage that accumulates costs whether anyone is looking at the data or not. Yeet takes a different approach: when you want to profile something, you run a script. A full CPU profiler — BPF program loaded, perf events attached, symbolized stack traces streaming in real time — in about a hundred lines of JavaScript. When you're done, you stop the script. No residual overhead. No data accumulating in a backend. Yeet's profiler works across all coding languages, compiled and interpreted, and it shows you exactly which lines of code are burning the most cycles. Not just which services are slow, but the forty lines buried in a forgotten module from two years ago where all the performance is actually being lost. ### GPU memory leak detection and autonomous remediation An AI agent that monitors GPU VRAM, detects a memory-leaking process, gathers evidence across multiple snapshots to confirm the pattern, and kills the offending process autonomously. Memory usage returns to normal immediately. The agent runs an investigation loop, gathering evidence iteratively before making a remediation decision. ### HTTP traffic parsing at the kernel level Yeet can parse individual HTTP requests at the kernel level — reading headers, payloads, and response codes from raw packets before they ever reach your application. This means building application-specific observability tools that understand your traffic patterns, not generic request/response metrics. ### HTTP/2 kernel-level firewall A firewall that decodes HTTP/2 HPACK headers (Huffman decoding implemented as a novel state machine approach in BPF) and makes per-request blocking decisions based on user-agent strings — all at the XDP layer, on the NIC, before the kernel network stack touches the packet. Built in three hours on the Yeet runtime. This operates at XDP, which is roughly 100x faster throughput than TC-layer approaches. ### Alerting with context, not just noise Most alerting today is a notification that something crossed a threshold, followed by a human scrambling to figure out what's actually happening. Yeet inverts that. When a PagerDuty alert fires, it can trigger a Yeet workflow that immediately snapshots the relevant data — CPU state, memory pressure, recent deploys, process trees, network conditions — and delivers a structured investigation summary to the engineer in Slack, arriving at roughly the same time as the page itself. ### Kernel-level security enforcement Every supply chain attack, every compromised CI/CD action, every rogue AI agent follows the same playbook: read credential files from known paths, exfiltrate secrets, escalate access. Yeet blocks that playbook at the syscall. A single script can enforce which processes are allowed to read ~/.aws/credentials, ~/.ssh/*, or any sensitive path — denying the read before file contents ever reach memory. ### USB protocol analysis A full USB traffic analyzer — per-endpoint inter-arrival timing, jitter analysis, transfer type breakdown, packet size distributions, driver-level attribution — built and running as a single Yeet Script. This is the kind of analysis that traditionally requires specialized hardware protocol analyzers or deep C kernel module development. --- ## Yeet Scripts A Yeet Script is a small JavaScript program that lives on a machine and takes care of it. It can see everything happening on that machine — CPU, memory, disk, network, processes — and it can react in real time. Monitor, detect, alert, ask a human, act. One file. **Sandboxed.** Each script runs in its own isolated container (V8 + OS-enforced process isolation). It can't touch other scripts, the filesystem, or the host. If it misbehaves, it dies alone. **Can look, can't touch.** Scripts read system data through a structured API. By default, they can observe everything and change nothing. You grant capabilities explicitly. **No shell access.** Scripts don't run shell commands. They call typed actions — "send an alert," "ask a human," "scale this thing." You can read a script and know exactly what it's capable of. No surprises. **Human-in-the-loop.** A script can detect a full disk and ask a human — via Slack, a dashboard, a mobile notification — "should I expand the volume, clean logs, or ignore this?" The script pauses, waits for the answer, then acts on it. **No credentials on the machine.** Scripts don't hold API keys. Alerts reach Slack or PagerDuty through the yeet platform. You configure destinations once, centrally. Nothing sensitive lives on disk. --- ## Why Yeet Matters for AI Agents The system graph is a tool-use interface purpose-built for LLM agent workflows. An agent doesn't need to parse `ps aux` output and hope the columns didn't shift — it queries the graph and gets clean, typed data back. Combined with a shared-memory IPC ring buffer delivering millions of kernel events per second, this gives AI agents continuous, structured perception of live infrastructure. Not polling every few seconds — a real-time sensory stream of kernel-level events. Right now there is no standard "perception-action layer" for AI agents managing infrastructure. Everyone is hacking together SSH + bash + hope. Yeet is the runtime those agents need. The progression: bespoke observability tools (today) → AI agents that read and reason about infrastructure at the kernel level (what the architecture enables) → self-driving infrastructure that detects, investigates, and resolves issues autonomously (where this is going). --- ## Why This Matters Now Two independent technology trends converged to make Yeet possible: **eBPF maturation:** eBPF has been developing in the Linux kernel for years, but it only recently reached the point where it's production-ready for general-purpose instrumentation. Kernel versions 5.x+ have the BPF capabilities needed for serious observability and security work. Even Microsoft is adopting BPF for Windows. But raw eBPF is still extremely difficult to write — C code constrained by a strict kernel verifier. Yeet makes it accessible by putting JavaScript on top. **AI code generation:** LLMs can now generate working infrastructure tooling. Describe what you want to see, and an AI writes the Yeet Script. The barrier drops from "you need a kernel engineer" to "you need to describe the problem." Every improvement to AI code generation makes the Yeet platform more valuable without Yeet shipping anything new — the same compounding dynamic that made platforms like AWS and Shopify defensible. Together: eBPF gives the kernel-level reach. AI gives the accessibility. Yeet is the runtime that connects them. This combination was not possible two years ago because neither technology was mature enough. --- ## BPF Polyfilling Deploying eBPF programs across a real fleet — different kernel versions, different architectures, different capabilities — has been one of the hardest unsolved problems in the ecosystem (the CO-RE problem). Yeet solves this the same way the web solved browser compatibility: with a runtime that polyfills the gaps. The V8 layer detects kernel capabilities at runtime, routes to the optimal BPF implementation if the kernel supports it, and provides JavaScript-level fallbacks when it doesn't. Write your BPF program once, deploy it everywhere, and the runtime handles the rest. This is a real deployment blocker for enterprise customers. Any organization running a heterogeneous fleet faces this problem when adopting eBPF at scale. --- ## Where Yeet Fits — and Where It Doesn't Yeet's breadth of capabilities makes it important to understand what it replaces, what it complements, and where its boundaries lie. It is not trying to be a monolithic replacement for your entire infrastructure stack. **vs. Full-Stack Observability Platforms (Datadog, New Relic, Grafana):** Yeet doesn't replace your existing observability stack wholesale. It fills the gap existing tools can't reach. Grafana and Datadog are strong for historical trends, shared dashboards, and compliance audit trails. Yeet provides what they cannot: programmable data transforms, edge-triggered rules engines, automated root cause analysis, autonomous remediation, deploy correlation, and kernel-level real-time data at sub-second latency with per-process, per-thread granularity. Their dashboards show you what they decided matters. Yeet shows you what actually matters to your application. **vs. eBPF Toolkits (bpftrace, BCC):** These are powerful for kernel hackers who write C. Yeet makes the same kernel-level capabilities accessible through JavaScript, with a managed lifecycle, fleet deployment, and an AI-friendly data layer. You don't need to be a kernel engineer. **vs. APM Tools (Sentry, Dynatrace):** APM approaches performance from the application down — SDKs in your code, language-specific agents. Yeet approaches from the kernel up — no code changes, works across any language. APM tells you which user request was slow. Yeet tells you exactly which lines of code made it slow. They're complementary. **vs. Security Platforms (Falco, CrowdStrike):** Security platforms detect threats against a known database of signatures. Yeet enforces policies you define — in JavaScript, at the kernel — specific to your infrastructure, your credential paths, your traffic patterns. Not a vendor's generic ruleset. **vs. Cloud Platforms (AWS, GCP, Azure):** Yeet is not a cloud platform. It runs on Linux machines that already exist in your infrastructure. **vs. CI/CD and Deploy Tools:** Yeet doesn't replace your deployment pipeline. It integrates with deploy systems through installable components to pull commit history, PR data, and changed files into agent context. **vs. Alerting and Incident Management (PagerDuty, OpsGenie):** Yeet doesn't replace your paging infrastructure. It makes it dramatically more useful by investigating problems the moment the alert fires and delivering structured situation reports alongside the page. **vs. Log Management (Splunk, Elastic):** Yeet doesn't collect, store, or index logs. It observes the system directly at the kernel level. Log management tools remain valuable for compliance, audit trails, and long-term forensics. **vs. ML Operations (MLflow, Weights & Biases):** Yeet provides the infrastructure visibility layer that ML platforms typically lack — GPU utilization, memory leak detection, stalled workload identification. It doesn't manage experiment tracking, model versioning, or training pipelines. --- ## Deployment Install: `yeet install` — the host becomes a programmable, queryable node. Runs as a systemd service. Remove with `apt remove`. No agent constellation, no backend to provision, no YAML labyrinth. Near-zero overhead when idle. Data never leaves the machine. Three paths once the daemon is running: use a script that ships out of the box, customize an existing script to fit your application, or write something entirely new. Each path takes minutes. --- ## Technical Details - Daemon written in Rust - Shared-memory IPC ring buffer with double-mapped virtual memory (zero-copy, futex-based cross-process wake, cache-line-aligned cursors) - Dual-socket privilege separation (0600 root, 0666 user) - Priority MPSC message bus with graceful shutdown choreography - BTF-aware eBPF lifecycle management with remote deployment via WebSocket - BPF polyfilling via V8 abstraction layer - GraphQL subscriptions for real-time streaming - DuckDB integration for complex correlations between data streams - OS-enforced process isolation (fork+exec jail) + V8 isolates for defense-in-depth security --- ## The Category: Programmable Kernel Runtimes Yeet sits at the intersection of observability platforms, eBPF toolkits, and AI-for-ops — but it doesn't fit neatly into any of these categories. The infrastructure industry has spent the last decade settling into a model where vendors collect your data, store it in their cloud, and give you their dashboards. This model is expensive, generic, and fundamentally limited by what the vendor anticipated mattering. Five principles define the new category: 1. **Tools would be created on demand.** A developer describing what they want to see, or an agent constructing an investigation on the fly, deploying a probe that didn't exist five minutes ago. When the problem is resolved, the probe goes away. No residual overhead. 2. **The data layer would be structured and self-describing.** A typed, queryable graph of system state — not logs that have to be parsed, metrics that have to be interpreted, or traces that have to be stitched together. 3. **Observation would happen at the kernel, not the application.** The kernel already knows what every process is doing — every syscall, every network packet, every file write. Observe from below instead of asking applications to emit data about themselves. 4. **Tools would be bespoke, not generic.** Every application has different failure modes. Purpose-built instrumentation, not generic dashboards designed for everyone and optimized for no one. 5. **The system that observes would also be able to act.** Observation with actuation is a control plane. The same probe that detects the anomaly can be the one that responds to it. --- ## Scenarios ### The 3am page It's 3am. PagerDuty fires. In the old model, an engineer wakes up, opens a laptop, stares at a dashboard, tries to remember which Grafana board has the relevant metrics, and forty-five minutes later has a hypothesis about what went wrong. In the new model, the alert fires and simultaneously triggers an agent connected to the live system graph. The agent snapshots relevant state, traces the causal chain (high latency on nginx → container CPU throttling → host iowait spike → NVMe thermal throttling → ambient temperature rise in hardware sensor data), and delivers a structured investigation summary to Slack alongside the page. Root cause analysis and proposed remediation, before the engineer finishes reading the alert. ### The bespoke profiler You suspect a performance regression. With Yeet, you describe what you need and AI writes it: a bespoke production profiler with function-level profiling, endpoint latency tracking, slow query analysis, and TCP retransmit correlation — built as a Yeet Script in under two hours. When you're done, you stop the script. No residual overhead. The tool existed for exactly as long as you needed it. ### The agent that understands An agent that doesn't just respond to incidents but understands your infrastructure. It knows what's normal on Tuesdays. It knows that Postgres gets busy after the nightly batch job. It doesn't alert on a threshold — it alerts on a deviation from understood behavior. That's not a threshold. That's understanding. --- ## Key Beliefs - Infrastructure tools should be written, not bought. - Every application deserves its own observability. - Instrumentation should be programmable at runtime, not configured in advance. - AI agents need kernel-level visibility to operate systems. - Static monitoring dashboards are the old world. Programmable kernel instrumentation is the new one. - Generic dashboards are built for everyone. Yeet tools are built for your application. --- ## About Yeet is a small, focused team with deep expertise in kernel engineering, infrastructure, and systems programming. The daemon is written in Rust. Yeet is pre-launch and approaching general availability. Visit [yeet.cx](https://yeet.cx) for updates and to join the waitlist.