OrgLoop: Organization as Code for Autonomous AI Organizations

8 min read
ai engineering open-source infrastructure

OrgLoop is an open-source runtime that wires your AI agents together with declarative event routing, so the organization keeps moving without you being the one holding it all together.

The Problem Nobody Warned Me About

I’m running a lot of AI agents concurrently across multiple hosts. OpenClaw agents doing code reviews, Claude Code teams handling implementation, specialized agents for project management and triage. The agents themselves are genuinely capable. That part is mostly solved.

The part that kept breaking was everything between agent sessions.

A PR gets review comments at midnight. Nobody notices until I check in the morning. CI fails at 2am and sits red for hours. Claude Code finishes a feature overnight and the output just… sits there. A Linear ticket gets updated and no agent reacts because no agent is watching.

I was the coordination layer. The human router. Checking GitHub, nudging agents, remembering what’s in flight, bridging context between sessions. Every morning started with the same ritual: check which agents finished overnight, see if any PRs got stuck, notice the CI failure from 3am, remember what Linear tickets were in flight, figure out which Claude Code session needs relaunching.

I had scripts, cron jobs, LaunchAgent plists, custom pollers. A whole pile of glue code that sort of worked until it didn’t. And it didn’t scale. One agent, you can manage manually. Two, it’s tight. At scale, you’re not managing agents anymore. You’re just running a very slow, error-prone event loop in your head.

The frustrating thing is that the agents’ judgment is good enough. With the right context and the right instructions, they handle these situations well. The problem was getting the right event to the right agent at the right time with the right instructions. That’s a systems problem, not an intelligence problem.

How I Got Here

I kept trying to fix this inside the agents themselves. Bigger system prompts with more SOPs. More heartbeat checks. More agents, each watching a narrower slice. None of it stuck.

The heartbeat approach is like having your team members wander around the building periodically, hoping they stumble across something that needs attention. Sometimes they do, sometimes they don’t. Things that happen between patrols get missed.

Then I noticed this was the same shape as a problem infrastructure engineers solved years ago. We went from SSH’ing into servers and running commands to Infrastructure as Code. Terraform, CloudFormation, Pulumi. Declarative, version-controlled, reproducible. Nobody manages servers imperatively anymore.

AI organizations are in that pre-IaC phase right now. Scripts, tribal knowledge, manual coordination. It works for one person running a few agents. It breaks down the moment you scale.

I started calling the pattern Organization as Code.

Five Primitives

The whole thing fits in five concepts:

Sources emit events. GitHub pushes a PR review, Linear updates a ticket, Claude Code finishes a session, a cron schedule fires. These are the things that happen in your organization.

Actors do work. An OpenClaw agent, a Claude Code instance, a Docker container. These are the things that respond.

Routes wire sources to actors. When event X happens, wake actor Y with instructions Z. This is the topology of your organization, declared in YAML instead of living in scripts and someone’s head.

Transforms sit in the pipeline between source and actor. Filter bot noise, deduplicate events, enrich payloads with additional context. Mechanical steps that don’t need judgment.

Loggers observe everything. Every event, every transform, every delivery, traced and recorded. When something goes wrong (it will), you can see exactly what happened.

Read the YAML and you can see the entire operational topology of your organization. That’s the point. No more guessing which script handles what, or whether anyone is watching CI.

How It Works in Practice

Here’s a real route from my setup:

routes:
  - name: pr-review
    when:
      source: github
      events: [pull_request_review]
    then:
      actor: engineering-agent
    with:
      prompt_file: "./sops/pr-review.md"

When GitHub emits a PR review event, OrgLoop matches it to this route and wakes my engineering agent with a focused SOP specifically for handling PR reviews. The agent doesn’t see CI failure instructions. It doesn’t see the ticket triage playbook. One event, one focused instruction set.

This turned out to be a big deal. I had been cramming every possible instruction into one big system prompt, hoping the agent would apply the right SOP to whatever situation it found. Sometimes it did. Often it picked the wrong one, or tried to do three things at once.

The route decides what context the agent needs, not the agent. If you’ve used OpenClaw Skills (focused context loaded on demand instead of everything crammed into MCP), this is the same pattern one layer up.

Here’s the part that makes it recursive: when an actor finishes, that completion is itself an event. My supervisor evaluates what Claude Code produced, decides whether to relaunch for another iteration or move on, and that decision fires its own event. The system sustains itself through continuous cycles.

The org loops.

My current setup has nine active routes covering PR reviews, PR comments, CI failures, Linear ticket triage, Gmail triage, Claude Code supervision, cluster management, integration grooming, and weekly product updates. One daemon process replaced about a dozen scattered scripts and cron jobs.

A concrete example of the loop in action: Claude Code finishes implementing a feature at 2am. That session completion fires an event. OrgLoop matches it to the supervisor route. The supervisor agent wakes up with an SOP that says “evaluate the output, check if the spec is complete, relaunch if there’s more work.” The supervisor decides to relaunch for test coverage. That relaunch fires another event. Claude Code runs tests, finishes, fires another completion event. The supervisor evaluates again, sees the spec is done, and updates the tracking ticket. All of this happened while I was asleep. I wake up to a finished feature with tests, committed and ready for review.

Before OrgLoop, that same sequence would have stalled at step one. Claude Code finishes at 2am. Nobody notices until I check in the morning. I read the output, decide it needs tests, relaunch manually, wait, check again. Half a day lost to gaps that didn’t need to exist.

Getting Started

npm install -g @orgloop/cli
mkdir my-org && cd my-org
orgloop init
npm install
orgloop start

orgloop init walks you through picking your sources and actors. Start simple. One source (maybe GitHub), one actor (your agent), one route. Get the loop running and watch events flow through.

orgloop status    # See what's running
orgloop routes    # Visualize the routing topology
orgloop logs      # Watch events in real time
orgloop doctor    # Validate config and connectivity

Send a test event to see it work:

curl -X POST http://localhost:4800/webhook/webhook \
  -H "Content-Type: application/json" \
  -d '{"type": "test", "message": "hello from orgloop"}'

That’s the core loop: source emits, route matches, actor delivers, logger observes.

When you’re ready to scale up, there are pre-built connectors for GitHub, Linear, Claude Code, OpenClaw, Google Calendar, Gmail, Docker, and more. Each one is its own npm package (@orgloop/connector-github, @orgloop/connector-linear, etc.) so you only install what you need.

The Vision: Your Organization as a Codebase

The thing I keep coming back to is that the interesting problem isn’t any individual agent. It’s the system around them. Human organizations figured this out a long time ago. You don’t make the organization work by making every employee perfect. You build processes, handoffs, escalation paths. The system compensates for individual unreliability.

AI agents forget, idle, rabbit-hole, drop context. That’s fine. OrgLoop doesn’t fix the agents. It makes the system reliable. Your org’s operational topology lives in version control. You can review it, diff it, roll it back. New team member joins? They can read the YAML and understand how everything connects. You can orgloop plan before orgloop start and see exactly what will change, Terraform-style.

Five primitives. One config file. You can read the whole thing and understand how your organization works. When something breaks, you can trace the event through the log and see exactly where it went wrong. When you want to add a new workflow, you add a route and an SOP. No new scripts, no new cron jobs.

I think every team running more than a couple of AI agents is going to need something like this. Not necessarily OrgLoop specifically, but the pattern: declarative routing, focused SOPs, event-driven actor wakeup, recursive loops. The paradigm is bigger than any one tool.

Try It

OrgLoop is open source (MIT), written in TypeScript, and running in production. It’s early alpha days. The concepts have been running my engineering organization since January 2026, and the framework is being extracted and formalized from that system.

If you’re running agents and feeling the coordination weight, give it a look.

GitHub: github.com/orgloop/orgloop Docs: orgloop.ai npm: npm install -g @orgloop/cli

If you try it or have questions, find me on X (@chulcher) or open an issue on the repo. I’m genuinely curious what other people’s agent topologies look like.