No, but keep reading to understand why.
There is a trend now in the software community called "Software Factories" where people use teams of AI coding agents working on a project. There are two models that I've seen in the wild that are being used by people building software with agents and I want to talk about them and introduce a third. I've been building a system called Abject to explore this third way where agents have more autonomy. We aren't there yet but we are in exciting times of exploration.
By coincidence, Wes McKinney published his update on Kenn's process the same day I finished this, and it sharpened a few of my arguments, so you'll see me respond to it directly below.
The two models I have identified are what I call Orchestrated Agents and Role Agents.
Orchestrated Agents #
In the Orchestrated Agent model, people use multiple coding agents (Claude/Codex/OpenCode/Pi) and command them individually while stitching their coordination via a set of isolated components. This is sort of a "Unix Way" of working. The most popular system to do this is called Superpowers. Superpowers is a set of skills you inject in your coding agent of choice to allow that agent to be much more autonomous. It does this via several guardrails that make the agents act a bit more predictably (like enforcing red-green-refactor TDD cycles). However, interaction of the agent with people is mostly front loaded. First you brainstorm and create a plan, and then the agents will code, only bubbling up interactions when they need clarification or something is blocked. This style fits well with the "switching between multiple terminals" way of development. The ethos is basically "People are involved heavily in the planning then agents autonomously execute". The Vanguard in this approach is Kenn Software. Wes McKinney has a really great post detailing how this works at Kenn which I highly recommend you read. They are creating great tools on making this possible and effective. And it works: Kenn merges hundreds of pull requests a week with a team of three, with a low bug rate across millions of lines of production code.
I call it Orchestrated because the person is a conductor, and the agents are playing the music.
Role Agents #
Unlike the Orchestrated Agents model where you orchestrate the agents, in the Role Agent model, people start with the orchestration layer and add agents with special roles to it, including yourself. The best example of this is Gas Town/Gas City. Gas Town is an open source toolkit created by Steve Yegge for commanding AI coding agents. It's built on top of a ledger called Beads, which is an issue tracker backed by git. Instead of commanding agents individually like the Orchestrated Agents model, you work with a single agent who coordinates the other agents. This coordinating agent will spawn multiple specialized agents in the background to work on tasks autonomously. The commander you interact with will assign different roles to each agent. For example in Gas Town you have roles like the Mayor, Deacon, Dogs, Polecats, etc.
In this system the Mayor is the main agent you talk to most of the time. It creates work tasks (via Beads) and assigns them to workers. Polecats are the worker agents that have persistent identities but ephemeral sessions. The other roles matter less for this discussion. What's important is that in the Role Agents world you don't manage agents individually, the orchestration layer does it for you.
Unlike the Orchestrated Agent model, in the Role Agent model you play another role in this system inside the orchestration layer, you are just another "agent" among the agents.
The Problem With These Two Models: Only the Person Learns #
Both of these models have one central theme, there is no concept of re-planning. In the Orchestrated Agents model, you plan before you execute and orchestrate. In the Role Agent model you plan inside the orchestration layer before agents do the work. Each one has it's unique gates that bubble up decision making to the person. But these serve to unblock agents working on the original plan. This can lead to local-optima for any solution. If I were to summarize how both of these models treat agents, they treat them like smarter compilers that take your words and turn them into code.
What's important here in both of these models is that the meta-learning stays with the person, not the agents. Agents can learn at the micro level, within their session, but the learning stays with the person, and it is up to them to put it in some durable form for the future. Wes mentioned this in his article about Kenn's rule that durable guidance goes in a shared instructions file.
This ultimately limits how autonomous agents can be. This is by design in both of these models because the goal is that agents work for the person as a kind of dumb army. This also makes sense because the SOTA models (Fable and GPT 5.6) still produce buggy code with poor architecture.
However, I believe agents can work more effectively for people if they contribute to this meta-learning because ultimately they are the ones now doing most of the work in building software. When I built and used coding agents over the years to build software (I've been building coding agents since '21), I recognized how important this meta-learning loop is. Since none of the approaches I've found deal with it in a good way, I thought I'd experiment with this kind of meta-learning with my project Abject.
New Model: Learning Agents #
How do we make agents smarter and more effective? Don't treat them like smarter compilers and include them in the learning loop. I understand why most are hesitant to do this. I've been building coding agents since the GPT3 days and understand all the limitations. They don't have a point of view. Most importantly LLMs are not intelligent. Once an LLM is deployed it doesn't learn because its weights don't change. If you can't learn you aren't intelligent.
So why include something that can't learn in a learning loop? Because agents+external memory do learn. Agent + harness is an intelligent system. The LLM core is like a processor in a larger system with memory. This is a slow way to learn (it would be better if the model did update its weights) but it is learning nevertheless.
The key question is how do you represent an agent's acquired knowledge in a way compatible with people and useful for agents?
We Have to Go Way Back #
To understand how we can do this, we have to go way back. I'm talking billions of years way back.
We don't know how life emerged, but we know it eventually had DNA. Nature came up with a learning algorithm called evolution. Early life forms did not learn within their lifetimes, they learned at the species level, with each generation encoding what worked into the genome. You can think of DNA as the first pre-trained model. Biologists call this **phylogenetic learning **which means learning at the level of the lineage.
Eventually life evolved neurons and brains, and individuals could learn within their own lifetimes. This is ontogenetic learning, learning at the level of the organism. Now there were two learning systems running at the same time on different clocks.
Later, species evolved the ability to communicate and pass knowledge directly to other individuals. A behavior discovered by one animal could spread through the group without waiting for evolution. This is social learning.
Then evolution produced humans, and humans produced writing. Writing is external memory. Through it, knowledge passes not just to the next generation but to the next hundred generations. This is **cultural learning. **Where each generation builds on a record no single brain has to hold.
Then we created mathematics to define ideas precisely, and mathematics gave rise to an artificial process of learning called Science, the first AGI. Yes, we've had AGI for over 300 years! This is scientific learning.
And about 70 years ago, we built machines that learn, a discipline we call machine learning. That's where we are today: six learning systems running at the same time on different clocks: phylogenetic, ontogenetic, social, cultural, scientific, and machine, each one interacting with the others.
What I am proposing is that we can improve the interaction between the human learning systems and the machine one, enhancing both.
If we treat agents as fancy compilers, we cut them out of that interaction entirely.
Christopher Alexander and Pattern Languages #
It's clear how machines could contribute to the scientific learning system, and that by using mathematics. What is less clear is how machines can contribute to the societal learning system. Christopher Alexander tried to solve this for architecture. He wanted a way to represent the knowledge of architects, learned over centuries, in a more robust way. He came up with the idea of a Pattern Language to do just that. In the 80s this idea was picked up by software people and now we have Pattern Languages for various domains, including different software domains.
You can think of a pattern language as a solution to a problem in a context. Usually they are connected in a graph which is the "language" and a walk through this graph is a "sentence" in that language.
Here is an example from "A Pattern Language" by Alexander from 1977
Name: Light on Two Sides of Every RoomSource: "A Pattern Language" (Pattern #159) by Christopher Alexander et al. (1977)Context: You are determining the layout of rooms within a building and deciding where to place exterior walls and windows in spaces where people will gather or spend significant time.Problem:
When a room has natural light coming from only one side, the contrast creates a harsh glare around the window. This casts deep shadows on people's faces, making the room feel uninviting and causing people to unconsciously avoid it.Forces:
Natural light is desirable, but a single light source creates high contrast between the bright window and the dark surrounding walls.
When looking toward a single window, a person's face is heavily shadowed or silhouetted, making social interaction difficult and reading facial expressions hard.
People naturally gravitate toward spaces with soft, even lighting that feels comfortable to the eyes.Therefore:
Locate each room so that it has outdoor space on at least two sides, and place windows in these walls so that natural light falls into the room from more than one direction. If you cannot do this, use a skylight or a clerestory window to provide the second source of light.
What is notable about pattern languages is that they are generative. It's not just a toolbox or catalog, but more like a spoken language. You can produce endless "sentences" within a particular language.
They also resolve forces. This is a metaphor from architecture where a building must manage the forces of physics and nature to stay up. Similarly software must manage many forces from hardware and the users to stay working and robust.
Most importantly they capture expert intuition which is what is learned through lots of doing. If we are to move to agentic coding, where much of the doing is done by machines, if we don't capture their learned intuition along with the person's, then we miss a huge part of describing the theory of the software that is built.
The Abject Way #
To experiment with this idea of incorporating the learning from machines along with people you need several elements.
- A place to store learned knowledge
- A way to use the knowledge to predict actions
- A way to evaluate how the actions did against the predictions
- Update the learned knowledge
I'll provide some concrete comparisons with existing ways of building software using the agentic systems I described. I'll use Superpowers as the representative here since Gas Town's re-planning story is similar.
Static Markdown Plans vs. ScrumMaster Sprints
Superpowers, used in the Orchestrated Agents model, operates on a static planning model. The agent executes a plan using upfront rules, following a predetermined plan (typically in Markdown), validating using a test-driven-development (TDD) cycle. This approach ensures high predictability. Wes McKinney affectionately calls agents "Clankers" because they are treated as effectively dumb robots. This predictability is desired because it allows the conductor orchestrating the agents to do their job. If agents veered from a plan, producing completely different output, controlling multiple agents at a time would not be possible for a person or team of people. What is highly valued here is control by the person orchestrating.
In contrast, Abject replaces the static plan with a ScrumMaster and sprints, inspired by Scrum. Work is broken down into dynamic tasks decided by a team of agents. They agree on who does what and work on each task, either failing or completing it. When the tasks are completed (or failed) another sprint is done. The work is reviewed, and then the agents decide to stop or do another sprint round, learning from what failed before, creating their new set of tasks. Rinse and repeat until the goal is completed or failed. For each task, the agent predicts what the result should be. After the goal is completed or failed after several rounds of sprints, the results are compared against what is expected and saved in the knowledge base. The knowledge is captured!
This is very different from both the Orchestrated Agents model and the Role agents model because the agents themselves decide the tasks. The person describes a goal and what they want to achieve, not how to achieve it. If the person has intuition of how things can be achieved from their expertise, they can describe them as a pattern. Human and machine learned patterns live in the same place and are used by the team of agents to decide how to accomplish a goal.
Note there is no detailed design process. This is like the difference between programming in JavaScript vs Prolog.
Circuit Breakers vs. Learning Loops
Learning happens when things go wrong. In the two models I described, the learning is done by the person, and they are responsible for saving what they learn in some durable form. Superpowers employs a strict circuit breaker mechanism. If an agent enters a fix loop and fails to resolve the problem within a set number of rounds, the framework forcibly halts execution and escalates to the person. There is no re-planning. Discovering a blocked path means the current plan is defective in some way and it's up to the person to rewrite it. The person works to unblock the agent so it can continue with the plan, and whatever was learned from the failure lives in the person's head.
Abject replaces the circuit breaker with a learning loop. Mid-implementation discovery isn't treated as a defect in the plan, it's expected! When an agent discovers new facts or fails at a task, it records what it finds on the shared scratchpad. At the end of the sprint, the ScrumMaster reviews what happened, integrates the scratchpad findings, and formulates a new plan with the team. New tasks are spawned and the agents pivot autonomously.
Each sprint round is a re-planning stage, and each one is an opportunity to learn. This continuous re-planning is how Abject jumps out of the local optima that would require a person using Superpowers to step in and unblock. The best part, the lessons don't evaporate when the goal completes, they are distilled into patterns in the knowledge base, ready for future goals.
Aren't Loops Bullshit?
As I was finishing this post, Wes published an article about how his company Kenn builds, and he restated his position from July: "I think loops are bullshit". He believes that fully autonomous pipelines, where agents loop on each other's output with no human in sight, produce garbage, and anyone claiming otherwise is clueless or selling something.
He's right about those loops. But I want to make a distinction, because not all loops are the same kind of thing.
The loop he's describing are blind loops, Retry harder loops. No memory, no expectations, no error signal. Each iteration consumes the slop of the previous one and the errors compound. Blind loops diverge, and no amount of clever prompting fixes that.
A learning loop is a different in kind, not just degree. In Abjet, every task carries a prediction of what should happen. Every sprint compares predicted against actual. The gap between them is the error signal, and the error signal is what gets distilled into durable knowledge. This is not a subtle distinction. It's the difference between every learning system I described earlier and noise.
Evolution is a loop with an error signal called selection. A brain is a loop with an error signal called prediction error. Science is a loop, literally hypothesize, test, revise, and nobody calls science bullshit, because it keeps a durable record of what the error taught us.
A loop without memory is a treadmill. A loop with memory is a ratchet.
To be clear, the human hasn't left the building. You set the goal, You review the result. Your deep knowledge sits as patterns in the same knowledge base the agents draw from. What I'm questioning is narrower than "human in the loop, yes or no.". When the plan breaks, does the lesson have to live only in the person's head?
The Abject Learning Loop: Knowledge Base & Generative Pattern Language
Abject's core ability is to evolve across runs using its persistent knowledge base via its post-task learning loop. There is a special agent that reviews the tasks post goal and amends the knowledge base, creating new patterns and facts, consolidating and validating existing ones.
Rather than treating agent experience as ephemeral session memory, Abject captures operational wisdom in a structured, persistent way that sits alongside human knowledge and intuition.
When an agent completes a task, the TaskReviewer inspects the execution script and evaluates what existing knowledge helped, and distills durable lessons based on what the agent thought would happen and what actually happened. These lessons get saved as structured knowledge base entries, ranging from empirical facts and insights, to generative patterns.
The Weave Query: Context-Aware Pattern Resolution
The knowledge base can get very large. When an agent starts a task, Abject does not dump the entire pattern catalog into the context. Instead, it executes a **weave query. **The weave query matches the task description against the pattern context, then follows the links up to N hops to pull in supporting patterns.
This ensures that agents receive a focused, contextually relevant subset of workspace patterns, along with their linked dependencies, giving them the shape of rules needed to deal with the forces present in their goal.
Architectural Comparison
While Superpowers prioritizes strict human-in-the-loop safety boundaries and predetermined plans, and Gas Town constructs scaled factory pipelines around Bead task units, Abject uniquely bridges autonomous task execution with an organic, pattern-driven learning loop which enables agents to learn from every sprint and dynamically adapt their plans mid-flight.
Are Agents Ready for More Autonomy? #
In my experience, not yet, but the answer won't come from tighter plans but better ratchets. Even with the solutions I outlined above that Abject attempts to solve, it's too soon to tell how well they will work at scale. One consequence of the way I built Abject is that it builds software within its operating system, creating what are called Abjects (AI Objects) as the software artifacts. This is like a Smalltalk or Erlang object-oriented system except objects follow The Ask Protocol.
It's currently not a Claude Code, Codex, or Pi.dev replacement. However, it is a great playground to experiment with some radical ideas that I hope will trickle into the mainstream. If your team is already turning specs into living architecture documents, you're closer to a pattern language than you think.
My hope is that the reader has learned a couple of things about where the frontier of agentic coding is and possibly where it could go.