Overview

Looped Agent Framework

   ██╗      ██████╗  ██████╗ ██████╗ ███████╗██████╗      █████╗ ███████╗
   ██║     ██╔═══██╗██╔═══██╗██╔══██╗██╔════╝██╔══██╗    ██╔══██╗██╔════╝
   ██║     ██║   ██║██║   ██║██████╔╝█████╗  ██║  ██║    ███████║█████╗
   ██║     ██║   ██║██║   ██║██╔═══╝ ██╔══╝  ██║  ██║    ██╔══██║██╔══╝
   ███████╗╚██████╔╝╚██████╔╝██║     ███████╗██████╔╝    ██║  ██║██║
   ╚══════╝ ╚═════╝  ╚═════╝ ╚═╝     ╚══════╝╚═════╝     ╚═╝  ╚═╝╚═╝

Overview

The Looped Agent Framework is a framework for building and deploying AI agents as services. These are generally single-purpose agents that sit in an infinite feedback loop. The agent waits for an event (a Discord message, a webhook, a cron tick), does its job, delivers the result and then goes idle again.

The core idea is that an agent is a file. A simple config file defines the agent's purpose, the model, the tools and the boundaries it operates within.

handle: issue-bot     # agents name themselves; you just pick the handle
description: Turns team Discord messages into GitHub issues.
model: { provider: openai-compatible, id: gpt-5.4-mini }
triggers:
  - type: discord
    channels: ["issues"]
skills:
  - ./skills/gh-issues.md
permissions:
  net: [discord.com, gateway.discord.gg, api.github.com]
  run: [gh]

Docker as the deployment platform

We use Docker as the deployment platform: one agent is one container, so an agent can run on a VPS, a homelab machine or any cloud, on any OS that can run Docker. Restart policies, health checks, secrets and logs are problems the container ecosystem solved years ago, so agents inherit those answers instead of us reinventing them. A fleet is just more containers. The mechanics live in Docker run and Docker compose.

A more important reason is containment. An agent that runs unattended is eventually going to be handed hostile input, so we built the runtime as nested layers of enforcement, where each layer assumes the layer inside it can fail.

A hardened base image

We created a minimal image that contains the Deno runtime, the framework and bash. Nothing extra. Anything that isn't in the image can't be misused, so the attack surface stays small and every capability your agent has is one you added deliberately. The process runs as a non-root user, and a built-in healthcheck surfaces each agent's state in docker ps. What the base image gives you has the full list.

A permission system built on Deno

Most runtimes give a process everything the OS user can do. Deno works the other way around: the process starts with nothing and only holds what you granted it at launch. The permissions: block in the agent file compiles down to Deno permission flags, and the framework's own deny-by-default engine handles what flags can't express: network egress per host, shell commands gated per executable, secrets injected server side. This means that the boundaries you write in the agent file are enforced at runtime. The full story is in The permission model.

The container as the outer boundary

The layers nest: the permission engine sits inside the Deno sandbox, which sits inside the container, and whatever slips past an inner layer meets the next one. Bash subprocesses escape the Deno sandbox by design, and the container is what contains them; that's also why there is no "run on the host" mode. A misbehaving agent is one container. You can stop it and it's gone, and neither your host nor the rest of the fleet ever feels it.

The Manifesto

Start with the manifesto - it's a short read and outlines the philosophy behind the framework.

Next Steps

The framework is built in the open at loopedautomation/agent-framework. The examples are complete, runnable agents, from a minimal REPL bot to a Discord to GitHub agent deployed with docker compose up.