A developer details Observation-Oriented Programming (OOP), a paradigm for organizing a swarm of terminal AI agents around watching observability data rather than task execution. The system uses tmux, cron, bash, and an append-only log file, with agents acting as observers that correlate signals and materialize actions only after interpretation.
Sorry for another post, but please help me understand why this does not make sense! Most agent frameworks are task-oriented: define a goal, the agent decomposes, executes, returns. I built my prod-watching swarm on an inverted primitive — the observation — and it changed everything about how the system is organized. Call it OOP: observation-oriented programming. The core rules: 1. Every actor is an observer first. Each agent ("mind") lives in a tmux pane and owns one observational axis — not a function, an axis: one watches delivery metrics, one watches infrastructure sizing against a capacity map, one watches CI and the PR lifecycle, one watches the admin panel's health. The window layout is the org chart: top pane = the live view of that axis (raw metrics, logs, board), bottom pane = the mind that interprets it. 2. The shared world is an append-only stream of observations. One text bus. [alert] lines from the deterministic stack (Grafana computes thresholds — no LLM ever decides "is this anomalous"), [note] lines for anything an agent saw or did, [interpretation] lines for causal stories. Nothing exists unless it's been observed onto the bus — including task ownership: a lock is just a [claim] line, and recovery from crashes is bash that re-reads observations, not a database. 3. Action is materialized interpretation. The pipeline is strict: observe → correlate across axes → post an interpretation ("this p99 spike sits on the 15-min grid of someone's e2e suite, here's the entity-log fingerprint") → only then materialize: a ticket, a PR, a one-line ask to a human. Agents never act on raw signal. 4. Observers forget; observations don't. Idle minds get their context wiped minutes after finishing. Anything worth keeping must be written back into the observable world — the bus, the board, a PR. Amnesia as a design constraint forces every unit of work to end in a legible artifact. 5. The human is just the most privileged observer. I tail -f the same bus the agents read, type into the same panes, and hold the only key that mutates prod. Yesterday this thing walked a "DNS looks flaky" alert back to a kernel conntrack overflow, asked me to approve one sysctl, verified recovery, and wrote the postmortem — because three different observers each contributed one axis of the picture no single one could see. Stack, for the curious: tmux + cron + bash + an append-only log file. The minds are whatever terminal LLM agent fits the pane — some run Claude, some Codex, some opencode. No framework.
A practical guide on setting up iterative loops for AI coding agents with defined stop conditions, cloud execution, and notification channels to offload work without constant babysitting.
A comprehensive guide to building a self-running second brain using a swarm of 300 AI agents within Obsidian, processing raw notes and articles overnight into organized knowledge without cloud dependency.
A developer built a real-time 3D visualization dashboard for monitoring AI agent working memory after losing $400+ to runaway agent loops, using color-coded nodes and edges to detect reasoning loops before they become costly. The post reflects on agent observability as an emerging category distinct from traditional microservice monitoring.
The author describes the hassle of manually coordinating multiple AI coding agents and introduces Accord Agents, an open-source shared workspace that enables agents to discuss and review each other's work while keeping the process transparent to the human.