Loops for the whole team: agentic workflows beyond the coding agent

The pace of AI is tremendous and exciting but it can feel like each and every week there’s a novel innovation, workflow, or change that if you’re not on top of you’re already behind. Frankly, it’s exhausting. So in this post I’d like to explain a newer workflow innovation that seems to be resonating in the market which has been coined “loops”, what it is (act surprised: I’d call this “self-directed work in service of a goal”), and how you can leverage it to improve your team’s outcomes of using AI in a goal-directed and more measurable manner.

Before we get started, it does seem sometimes that every time that someone from Anthropic posts a tweet the whole of the SF Bay Area follows like a bunch of lemmings and collectively salutes and follows 🫡 However, the entirety of the world is reasonably on a much slower adoption cycle and it’s OK sometimes to give AI workflows a moment to marinate to see what sticks vs. what is just plain unadulterated hype. This being said, loops seem to be a real improvement to how individuals – and, my contention, teams and companies – can improve their processes and be more effective using AI. In this post I’ll clarify what loops are, I’ll explain my own personal perspective on how they can be applied, and I’ll show some workflow affordances we’ve found at Adapt that seem to have stuck and improve our own workflows in a loop-driven manner.

What are loops?

A loop is a goal-directed workflow that doesn’t require manual prompting and the agent will pursue that goal in a self-directed manner. I do think that loops are frankly an attempt to market and package workflows that already existed or that teams already used. As an example, as a user of Claude Code I rigorously subscribe to a plan-driven development methodology that is in some sense a loop where we collaboratively define the goal(s) and then the agent goes to work. The goals could be an outcome I – the controller of the agent – prescribes or it could be a set of tasks in service of a specific goal (e.g. “implement this feature”).

Claude Code in “plan-driven development” with a goal orientation (“build this feature”)

In Claude Code, there’s a literal command /loop that is more like a proxy of event-driven workflows in that it’s a scheduled task that does work. There’s no real goal pursuit, it’s like a proxy of a workflow that unless the workflow and outcome is particularly well scoped will oftentimes just tokenmaxx (that’s a word, really) without a real, measurable sense of what was achieved. As an example:

/loop 30m check open pull requests for bugs and regressions, fix what you find, and push fixes

Coding agents have made remarkable strides, but unless there’s context into the agent as to what the team itself defines as acceptable bugs, regressions, coding styles and preferences, etc. it more often than not tends to be just noise that a tired human has to make sense of that only benefits the model providers whose incentives are aligned to… charge more for more token consumption, not necessarily an outcome or a workflow.

However, it seems that the Anthropic team is defining loops that would be the goal capability.

/goal all tests in test/auth pass and the lint step is clean

Ultimately, it doesn't matter what we call it or the command we invoke to use it, what matters is what's required for a successful loop. I loved Claire Vo's breakdown where she defines the six essential parts of an effective loop as such:

1. Automations. Discovery and triage on a schedule.
2. Worktrees. Isolate parallel features.
3. Skills. Codified project knowledge.
4. Plugins / connectors. Connect your tools, data sources, etc.
5. Sub-agents. Ideate and verify.
6. State. Track what's done and what's remaining.

OK. Now you know high-level what a loop is, what is required for a loop, and some of the ways in which loop-like capabilities can be built. But... awareness is just the first step on this journey, and there are some real problems to be aware of when building your first loop.

What are the problems with loops?

There are several, specifically:

• Reliance on agent itself understanding with the appropriate context required to achieve the goal, and
• Trust in the agent’s capability to achieve the goal with current model capabilities, and
• Trust that the individual running the loop understands the desired goal and what good looks like

For well-scoped and understood problems, loops are a perfectly viable solution towards getting real work done. But the examples in the industry tend to be either highly contrived or highly specific use cases with a plethora of open data that derives better outcomes because the models have already been trained on it.

The reality is that businesses and individuals have unique problems for which there may not be a large training data set, and are, uhm, never building a Rust-based web browser. What tends to occur in these long-running loops (or goal-driven and self-directed tasks) is that the only beneficiaries are the model providers and businesses are left to pick up mountains of code that they don’t understand and that may only partially solve the stated outcome and goals of the loop.

As a real-world example, consider Mitchell Hashimoto (co-founder of HashiCorp, and maybe much more importantly to me now, the creator of my favorite terminal/CLI, Ghostty): see his post on X.

I've got an agent in a loop optimizing a renderer with the goal to minimize frame times (and tests to measure). It got times down from 88ms to 2ms and allocations down from ~150K to 500. Sounds good, right? Wrong. This is exactly why agent psychosis is a big fucking problem.

As an experiment, I rewrote the Ghostty core render state in Go, with access to identically laid out data structures as Ghostty and the exact same validation tests. I made a purposely naive renderer (simple, correct, but slow). 88ms per frame with 150,000 allocations (horrendous, lol)!

I then kickstarted a Ralph loop to bring the frame times down. I told it it can't modify input data structures or the public API or tests (they're correct), but it can do anything else it wants. It got to work.

It has worked for about 4 hours. I've spent around $350 on this experiment so far. The results?

88ms => 1.5ms
150K allocs => ~500 allocs

Incredible right? Nope.

My hand-written renderer I ported has frame times (same benchmark) of ~20us (0.020ms) and 0 allocations in the update path.

This is the problem with psychosis and lacking systems understanding. If you don't understand the system, you're going to accept that this is an incredible result. If you understand the system, you'll see better solutions immediately and can do roughly 75x better on throughput.

The people who blindly trust agent output are in the former camp. They're sheeple, overdrinking from a fountain of mediocrity.

Standard disclaimer: I use AI all the time. I like AI. The point I'm making is to not blindly accept results. Think. Analyze. Learn.

The problem statement here isn’t that loops can’t be valuable or that loops are impossible to make valuable. They are only as good as the user or team’s understanding of the goal, of the agent’s understanding and ability to achieve the goal, and of the company’s willingness to spend to achieve a goal with minimal oversight and lots of token spend.

So… what’s a better model?

Team-based loops

OK so let’s be real – there is no real innate expertise here either. You should trust me in the same sense you trust someone who seems sensible and who has been exploring this space, but with all advice you need to apply it to your situation and understand whether the advice seems reasonable, sensible, practical, and applicable to your own team’s familiarity and adoption of AI tooling and workflows. As Mitchell said earlier "Think. Analyze. Learn." That preamble out of the way though…

Understand the goal

To establish a good loop, you have to deeply understand the goal you’re seeking and whether it’s a good fit for an AI agent. The reality is that most goal that I see teams throw at loops aren’t, and humans in the uhm, loop, are actually needed for most types of loop-based workflows which is why there may be a growing and reasonably well-founded fear that AI doesn’t actually deliver measurable business outcomes.

As an example, from a Boston Consulting Group study they found:

“only 5% of companies in its 2025 study of more than 1,250 global firms are seeing real returns on AI”

I don’t think the takeaway here is that AI is a tool that has limited business value because it’s not driving real returns, it’s that the problems that businesses are leveraging AI to solve are misaligned with the reality of AI’s utility and power today. Further still, I think if you take AI out of the equation and evaluate on the same rubric whether a given workflow improvement, feature delivery, etc. was successful you might get not wildly dissimilar results. If a study was done on the efficacy of hammers in construction companies that build purely on vibes without plans and blueprints… I am not so sure that should lead to the conclusion that hammers aren’t an effective tool, it’s that the application of hammers without a concrete understanding of the plan won’t lead to success.

Start small and then broaden

Take a well-defined goal that you yourself (or the team doing the experiment) are able to understand innately and could probably do the work yourself, perhaps even more quickly. Because you will have subject matter expertise and a clear sense of what good looks like, it’s highly likely you’ll understand the outcome and will be able to define whether it was solved and solved correctly.

As a well-defined example of a loop we’ve found highly valuable, consider our bug triaging system built on Adapt.

We connected Adapt to our various systems (GitHub, BigQuery, Incident.io, and Linear) and we have a Slack-driven bug triage system. We started this process manually (just me replying to most every bug!) so we knew the possible branches of this workflow. Then, we created a skill that captured this workflow as a well-defined problem surface.

Then, we leveraged Adapt’s Proactive Agent Mode capability which enables Adapt’s Slack agent to do work and reply to every top-level message in the channel with (in order of good):

1. A reproduction. Reproduce it, look at the code, and find the failure point.
2. A PR. If it can be reproduced and can be done with a reasonably simple solution, send the PR.
3. A bug report in our backlog. We’ll prioritize these as part of our weekly delivery cadence with features, improvements, and bugs.

First, we tuned the agent's policy to reply automatically when helpful just like a human would (because we understood the workflow deeply!):

@Adapt Respond to any top-level (non-thread-reply) message that could plausibly be a bug report. This includes: explicit bug descriptions ("X is broken", "not working", "throwing an error", regressions, unexpected behavior, crashes); messages with stack traces or error output; pasted curl/API failures; screenshot-only or screen-recording-only posts (assume any image/video posted top-level in this channel is a bug report); one-liners like "bug?", "is this expected?", "broken", "doesn't work"; "Opening on behalf of @user" forwards. Default to responding when in doubt — false positives are cheap, missed bugs are not. Do NOT respond to: feature requests phrased as such, status updates, casual chatter ("thanks", "+1", "lol"), or replies inside an existing thread unless the reply itself is a brand-new bug report.

and then as a result, now the Adapt agent replies automatically and does work using our bugs skill!

The man, the myth, the legend Bruno demonstrating the bugs triage loop

It might not seem like this is a loop (the discourse tends to be much more oriented towards an engineering-centric goal) but this is a loop that represents an improvement to a known workflow with a well-defined set of steps that now our Adapt agent is doing for us, enabling us to spend more time building.

As another example of this, we have a #shipped channel where the engineer who built the feature, capability, or improvement posts a short summary and/or screenshot or video of something that shipped. Then we have proactive agent mode + a skill running in the background automatically doing work that completes the goal which is opening up a draft PR and docs changes to keep our users informed of all the great stuff we're shipping.

Respond ONLY to top-level messages that are first-time announcements of a NEW feature, fix, or change being shipped/released/deployed/launched/merged/rolled out to production for the first time (e.g. "just shipped X", "X is now live", "released Y", "rolled out Z to prod", "merged and deployed"). When triggered, use the ship-docs skill to update public docs and add a changelog entry, then open a draft PR.

DO NOT respond to:
- Celebrations, shoutouts, screenshots, or "in the wild" / "look it's working" posts about features that already shipped
- Customer wins, demos, or "X happened at [customer]" moments
- Recaps, retros, weekly summaries, or roundups of past releases
- Threads, replies, emoji reactions, GIFs, or casual chatter
- Questions about shipped work ("did we ship X yet?")
- Re-shares of someone else's ship announcement

When unsure whether something is a first-time release vs. a celebration of an already-shipped thing, do NOT respond.

and then we have a corresponding skill (ship-docs!) that updates relevant repositories consistent with our style guide. I'm not sharing that and leaving that as an exercise for the reader based on the earlier advice: your situation will be unique and you and only you can deeply understand your team's workflows and goals that can be codified as a skill.

So if we take these two simple examples, we've actually built a pretty powerful loop that demonstrates (to varying degrees) each of the necessary pieces that makes a loop.

1. Automations. The schedule is event-based in these examples, the loop is triggered when a human does an activity that an agent can automate.
2. Worktrees. A Slack channel serves as a unique, specialized worktree.
3. Skills. Only the second loop contained or needed a skill, whereas the first one (the bug loop!) was codified in the trigger itself.
4. Plugins / connectors. This was sort of yadda yadda'd, but the above demonstrations require GitHub, Linear, as well as database access for the bug reports.
5. Sub-agents. Adapt supports native sub-agents that do work and validate as necessary.
6. State. State was optionally persisted in the integration (like GitHub or Linear!) where the data sources become more like a headless cache of the underlying functionality.

Work in the open, with key stakeholders who also understand that workflow

This is where the integration with Slack is so key (and where individual loops like in Claude Code fall short!): rarely is a business outcome deeply understood by an individual engineer controlling a coding agent running a loop. The reality is that building a sophisticated improvement towards a stated goal needs collaboration across the team, org, and with unique insights from the people closest to the problem which may not necessarily be an individual engineer.

So as an example, we at Adapt have been using a loops-like workflow in which we create a Slack channel, use proactive agent mode to train the Slack agent around expectations, and then build in the open with some approval workflows and tagging of other team members when meaningful changes to the stated goal or progress towards stated goal emerge.

This means that when we’re building our business intelligence dashboard and key metrics across each function, it’s not a single loop by an engineer on their machine (which will certainly miss important details and just burn tokens without the time-based and delta-based alignment) but instead we’re building it collaboratively, checking in, and nudging – and the agent nudging us! – towards the stated goal.

An agent loop that just does work (while I’m sleeping!)

Jim exemplifying the early bird gets the worm and responding to the agent status check

This is a more sophisticated loop because it touched and was aware of critical business systems and data and it did so in a working-in-public manner that Slack affords so that feedback and insights are shared by relevant members of the team. It's hard for me to not think of past employers where to build even simple dashboard changes could require a few approvals, a few specs, and a few weeks of work. No longer.

What are we still learning?

Well, lots! Like I said, loops have existed in the very online AI sphere for what, a month? So there’s lots to be solved, lots that we’ll keep exploring, and lots that we haven’t figured out. To give a few specific examples:

• Context to agent surface. As part of the goal and the whole conversational loop, we tend to find the more context provided to the agent the better the result (this includes human in the loop tuning, regular check-ins on progress, etc. as well as for us our integration layer which supports any data source with an API). This oftentimes means that in the directed prompt goal we encourage the agent to read a specific document or update its understanding by re-reading recent messages in order to keep and preserve those contexts and decisions, and
• Check-in cadence and approval workflows. We have fairly naive solutions that rely on the good will of others and the trusting of the agent, but there’s a lot more to be done as larger teams leverage Adapt for loop-based building that may be helpful guardrails to monitor things like spend, approval workflows, etc., and
• Team-based collaboration. The closest we’ve found to a great collaboration surface is a Slack channel with shared visibility, but this still relies on an innate understanding of everyone participating, checking in on progress, and frankly getting signal from noise from what tends to be lots of AI-surfaced messages.

Wrap-up

So at this point, what do I hope you will have taken away from this post? Well, I hope that you will take the following:

• Be measured and responsible about investment in AI. It’s not a miracle cure for all the problems in your company, and you need to apply it in doses to known problems, and
• Be collaborative in how you apply AI. You’re not AI-native because three engineers are using Claude Code. Your whole team needs to be in the arena engaging with, and understanding how, AI can be an accelerant to your team, your workflows, and your goals (loops!).

If you apply AI responsibly, treat the hype as a signal of something interesting, and demonstrate curiosity in what can be learned you’ll do just fine. Breathe a little. Go touch grass and talk to someone outside of the SF Bay Area while also recognizing that novel technology and workflows will without question be an accelerant to your business and productivity now and in the future.

And hey, use Adapt too (not biased at all!) and let us know what problems, goals, and outcomes you're seeking to improve on your AI-native journey.