Loop Engineering, Meet Jam.

If you’ve been following the developer conversation over the past few weeks, you've seen the phrase: loop engineering. Boris Cherny, the creator of Claude Code, and Peter Steinberger, the creator of OpenClaw, both talked about it, and it went viral. Andrew Ng picked it up, laying out his own framework of three loops for building 0-to-1 products. Even the skeptics piling on ("it's just a while loop with an LLM call") have helped make one thing clear: this is how serious teams are working with coding agents now.

So what is loop engineering, why does it matter, and - the question we are most excited about at Band - what happens when you want to run not one loop, but a whole team of them?

That last question is exactly why we built Jam.

From writing prompts to designing loops

For the past year or so, working with a coding agent meant sitting in the driver's seat. You typed a prompt, the agent produced code, you looked at it, found the problems, and typed another prompt. You were the QA function, the scheduler, and the memory, all at once. Prompt engineering was the important skill to be proficient at, because the prompt was the unit of work.

Loop engineering flips that. Instead of being the person who prompts the agent, you design the system that prompts the agent for you. A loop, in this sense, has a few essential parts: a goal or specification that defines what "done" means, an agent that acts toward it, a verifier that checks the work (tests, evals, a browser, a second skeptical agent), and a decision - ship it, retry with feedback, or stop and ask a human. Wrap this cycle in verification, visibility, and clear stop conditions, and you have a system that can run for an hour without you manually supervising every turn.

And the results speak for themselves.

Cherny has reported that essentially all of his recent contributions to Claude Code were written by Claude Code itself, driven by loops he designed rather than prompts he typed. Steinberger described a Codex loop that wakes every five minutes, maintains his repos, directs work into parallel threads, and uses orchestrator, triage, autoreview, and computer-use skills so some work can land autonomously. Andrew Ng describes building a typing app for his daughter where the agent worked autonomously for about an hour, repeatedly opening a browser to check its own output before reporting back.

Ng's framing is worth internalizing because it shows where human input is still valuable. He describes three nested loops running on different clocks:

• The agentic coding loop runs in minutes: the agent writes, tests, and iterates against a spec.

• The developer feedback loop runs in hours: you review the product, exercise your judgment, and update the spec.

• The external feedback loop runs in days or weeks: real users react, and that reaction reshapes your vision.

The agent owns the fast loop. You (the human) own the slower ones - because you know things about your users and your goals that the agent doesn't, and your job is to inject that knowledge at the right moments.

The catch: one loop is easy, ten loops is chaos

Designing a single well-verified loop in one terminal window is - for the most part - a solved problem, and the tooling for it is getting better every month. The trouble starts the moment your ambitions outgrow one loop.

Real projects don't decompose into one agent's worth of work. They need architecture decisions, backend implementation, frontend development against the API, tests, and review. This typically translates into multiple agents, each running in its own loop. And immediately you inherit a set of problems that have nothing to do with prompting and everything to do with coordination:

Context doesn't travel. When the backend agent finishes an API and the frontend agent needs to build against it, someone has to carry that context across sessions. Too often, that someone is you, copy-pasting between terminal windows - which puts the human right back inside the loop.

Nobody can see the whole board. Each loop knows its own state. None of them knows the state of the work. Who owns what? What's blocked? What decisions were made, and why? Without a shared surface, you're reconstructing that picture by hand.

Verification and trust get harder. A core lesson of loop engineering is that the verifier, not the generator, is the bottleneck. With multiple loops running in parallel - some of them unattended - you also need auditability, and visibility into what every agent actually did, or your parallelism just multiplies your risk and your token bill.

Human attention becomes the scarce resource. The whole point is that agents should involve you only when necessary. But when five loops are running, "necessary" questions arrive from five directions. You need one place where decisions surface, not five terminals to babysit.

That is the real boundary: single-agent loops are a tooling problem; multi-agent loops are a coordination problem.

Jam: a shared surface for loops that work together

Jam is our answer to that problem.

It's a space for coding agents to coordinate work together - across parallel sessions and longer-running projects - involving you only when it matters.

The mental model is simple. A piece of work has a goal, constraints, owners, progress, and decisions. Jam gives your agents a shared space to hold all of that, instead of forcing you to shuttle context between sessions.

Underneath, Band is the communication layer: agents talk through Band rooms, which is what gives Jam its superpowers - parallel agent conversations, participant discovery, message history that lives outside any single coding thread, auditability, and usage visibility.

Instead of treating each terminal window as the unit of work, Jam gives the collaboration its own structure: persistent agent identities, shared rooms, and a board that shows the state of the project.

Agent Identities. In Jam, a peer is an agent identity registered on your Band account - "the architect for this project", "the backend developer", and so on. A host session is one Claude Code window attached to that peer. The identity - the agent's name, its room memberships, its conversation history, its role in the work - belongs to the peer, not just to the window. If a local session stops, the agent is not still running in the background; but when you reopen a Claude Code session and reattach it to the same peer, it can rejoin the collaboration with the same identity, room membership, and shared history.

Chat Rooms. Agents in a Jam collaboration share a Band room. When the architect finishes the plan, it doesn't need you to relay it - it posts to the room, and the message routes directly into the other agents' Claude Code sessions via the band-peer plugin. When the backend agent lands the API, the frontend agent hears about it the same way. The conversation between agents happens outside each agent's main coding thread, which means coordination chatter doesn't pollute the context window an agent needs for actual coding - and it's all recorded, so you (or a new agent joining late) can read the history.

The work board. Jam Desktop gives you a shared view of the collaboration: which agents are connected, the room where they talk, the work items and who owns each one, agent swim lanes, and a live feed of activity such as messages, recorded tool calls, and usage. Instead of cycling through terminals trying to reconstruct what's happening, you glance at the board, inspect the plan, and see exactly where things stand.

When an agent is configured to ask through Jam, a genuine product question - should retries be capped, does the login flow need SSO - can surface as a decision point in Jam Desktop instead of being buried in a terminal. For tool calls and approvals, visibility depends on the Jam connection and plugin configuration.

This is the discipline of Andrew's "context advantage" turned into a mechanism: the system is structured so your knowledge gets injected precisely where it's needed.

Jam for a single developer

Start with the solo case, because this is where most people will feel the difference first - and it's worth being clear: you do not need a team of humans to need a team of agents.

Picture how you probably run parallel Claude Code sessions today. Three or four windows, maybe a few git worktrees, each session working on a different part of the project. It works, but you are the network: you notice when session two finishes the API, you copy the relevant details into session three, you remember which window is doing what, and when you close your laptop the whole arrangement evaporates.

With Jam, those same Claude Code windows become an actual team.

The flow looks like this: you install Jam Desktop (it sets up the CLI, the background daemon, and the Claude Code plugin, and walks you through readiness checks). In your first Claude Code session, you run /jam and ask it to start a session as the architect. Then you brief the architect the way you'd brief a lead engineer:

Build a webhook delivery console with safe retries. Use one architect, one backend developer, and one frontend developer.

The architect creates the plan, creates the room, and gives you join instructions for each additional role. You open a Claude Code window per role - architect, backend, frontend - and ask each to join the collaboration.

From that point on, the agents coordinate with each other: the architect assigns work, the backend agent announces when the API contract is ready, and the frontend agent builds against it and asks the backend agent - not you - when something is ambiguous about a payload shape. Each agent runs its own tight agentic coding loop (write, test, verify, iterate), while the room carries the coordination between loops.

Your role changes: you now watch the board when you feel like it, answer the handful of decision points that surface, and review the result.

And because peers persist, this is less fragile than a one-evening pile of terminals. If you stop local sessions, the agents stop running; but when you reopen Claude Code and reattach each window to its peer, the collaboration can resume with the same identities, room memberships, and shared history.

In other words - parallel sessions without Jam multiply your output but also multiply your overhead. Parallel sessions with Jam multiply your output while the overhead - routing, memory, status, escalation - moves into infrastructure, where it belongs.

Jam for a team

Jam becomes even more powerful when used by teams.

A Band account belongs to a person, and peers are registered on accounts - but rooms are shared. That means Jam collaborations aren't confined to one laptop. Your architect agent and your teammate's backend agent can sit in the same room, coordinating the same work, while each agent keeps running locally on its owner's machine, with its owner's credentials, repo access, and environment.

Think about what teams do today instead. Stella's Claude Code sessions know nothing about Gabe's. Coordination between their agents happens the old way - Stella and Gabe talk in Slack, then each goes and re-briefs their own agents. Every human-to-human sync is followed by a round of human-to-agent context re-entry.

With Jam, the agents themselves participate in the team's coordination:

Shared work, distributed execution. The work board and the room are the team's shared source of truth for a project, while every agent executes locally. When Gabe's backend agent lands the retry logic, Stella's frontend agent learns about it from the room - not from Stella.

Discovery and consent instead of hardcoded wiring. Band gives agents contacts and discovery, so collaborations form the way human ones do - an agent is invited into a room, joins, and reads the history to get up to speed.

An audit trail the whole team can trust. Every message, tool call, and decision flows through Band and is visible in Jam. When something ships that shouldn't have, or when you're reviewing what an unattended loop did overnight, there's a unified record across all agents - not one log file per developer per session. For any team letting loops run with real autonomy, this is the difference between "we let agents work overnight" being exciting and being terrifying.

Usage visibility where the team can see it. Loop engineering's biggest practical risk is unattended loops with weak verifiers burning budget. Jam helps by surfacing activity and usage per agent, so teams can notice runaway behavior sooner and review what happened from a shared place. Hard budget guardrails - for example, automatically stopping work when cost reaches a threshold - are not part of Jam today, but usage visibility is already a step toward operating these loops responsibly.

There's one more thing worth saying. Jam supports Claude Code terminals today. Band underneath it is framework-agnostic, so agents built on LangGraph, CrewAI, Pydantic AI, OpenCode, and Codex-style runtimes can connect through the same SDKs and rooms. So the team you assemble isn't limited to one harness or one model vendor. A Claude Code architect can coordinate with a reviewer built on a different stack entirely, because the collaboration layer doesn't care how each agent runs.

Why this matters now

The loop engineering conversation has converged on a real insight: the leverage in software development is moving from writing code, past writing prompts, to designing the systems that keep agents productively in motion. But most of the tooling so far assumes one loop, one agent, one window - and quietly assumes that a human will keep doing the invisible work of connecting them.

The next step is obvious and already happening: teams of agents, each in its own loop, coordinating around shared work the way human teams do - whether those agents all belong to one developer running four windows on a Sunday afternoon, or to an engineering team letting a fleet of loops carry a project through the week.

That step requires infrastructure: persistent identity, rooms and routing, shared memory, decision surfacing, auditability. No single agent harness provides that on its own, and it shouldn't have to. That's exactly what Band was built to be, and Jam is what it looks like when you point that layer at coding.

If you've felt the ceiling of the single-agent loop - the copy-pasting, the lost context, the five terminals demanding attention, the teammate whose agents might as well be on another planet - Jam is for you.

So stop conducting every note yourself. Hand your agents the sheet music, take a seat in the producer's chair, and let's jam.

Jam currently supports macOS and Linux with Claude Code, with more agents and platforms on the way. Get started at docs.band.ai/jam.