# Convergent evolution: the agent environment selects the same parts

> Teams that do not know each other are arriving at the same parts in agent engineering: a traceable record of every step, verification before delivery, human approval at risk points, and fixing the environment instead of the agent. That is not copying. It is the environment selecting the same function.

- Author: Elzo Brito
- Language: en
- Published: 2026-10-04
- Canonical URL: https://elzobrito.com/en/blog/convergent-evolution-in-agent-engineering/
- Translation: https://elzobrito.com/blog/convergencia-evolutiva-na-engenharia-de-agentes/

---
This morning I read two things that have nothing to do with each other and that, read together, describe almost the same architecture. The first was the [v1.3.1 release of Matt Pocock's skills](https://github.com/mattpocock/skills/releases/tag/v1.3.1), published on GitHub this Sunday. The second was a paper-style document, "Prompting Grok Bot: SpaceXAI Blueprint Applied to Loops for an Agent Team," on how to design a team of bots. One is a set of skills for coding agents; the other is a guide to prompts and routines. The release does not mention ESAA, and there is no reason it should. Even so, the parts that show up in them are the ones I tried to formalize in February in the paper [ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering](https://arxiv.org/abs/2602.23193) (implementation in [ESAA-Core](https://github.com/elzobrito/ESAA-Core)): a traceable record of every step, verification before delivery, human approval at risk points, and the decision to fix the environment instead of fixing the agent. When I see that, the question that interests me is not who got there first. It is what the environment is doing that makes everyone arrive at the same place.

## What biology calls convergence

In biology, convergent evolution is the name for independent lineages that develop the same solution because they face the same pressure. The camera eye of the octopus and that of vertebrates is the classic example: the function is nearly identical and the origins are separate. What convergence tells you about is not kinship, it is environment. If two groups with no common ancestor develop the same part, the part says more about the problem both of them face than about either one. I use the metaphor because it forces on me a discipline that the agent discussion tends to forget: similarity of function is not evidence of copying, and whoever reads it as copying loses exactly the useful information.

The pressure, in the case of agents, seems easy to name. Generating code got cheap. What is still expensive is knowing what happened, knowing whether it works, knowing who decided, and making sure the same mistake does not come back. Any team that runs agents at volume meets those four costs, and meets them roughly in that order. The four parts are the answers to them.

## The same part in four places

I start with the record. In Pocock's `implement-spec`, tickets are read as a task graph; implementer subagents each work in their own worktree across the frontier of ready tasks, and everything lands on a single integration branch. Each implementer confirms that its worktree is based on that branch and merges the integration tip into its own before reporting the task done, so that every merge is a fast-forward. The mechanism is git, not an event store, but the function is the one that led me to ESAA's append-only log: every step has to leave a trail that another agent, or another person, can reconstruct without depending on the memory of whoever did the work. The document on bot teams reaches the same function by another route, when it asks for one outcome per bot and requires explicit evidence and handoff.

Verification comes right after. In the same release, each implementer builds its ticket with `tdd`, the flow closes with `code-review`, and the `pr` skill requires the pull request body to carry before and after evidence that the change works. The document attributes to Lauren Tan (@poteto) a practice that puts verification first and pushes deterministic steps into scripts. In ESAA, the same function shows up as the `claim` and `complete` cycle with declared checks, review by a QA role, and the rule that a completed task does not go back. Three ways of saying that "done" is not something the agent declares, it is something the system checks.

The third part is human approval at the point of risk. The `pr` skill asks for an explicit merge-danger call: whether the change is a one-way or a two-way door, and what its blast radius is. Notice that it does not ask the human to read everything. It prepares the human to decide at the point where the decision weighs. The document on bot teams calls this an approval limit and an explicit stop point. The ESAA paper treats the same problem as blast radius containment through boundary contracts per task type. I do not take the shared term as a sign of anything; "blast radius" is old operations vocabulary. What interests me is that three independent designs decided that human attention is the scarce resource and that it should be spent where the error is irreversible.

The fourth part is the one that caught my attention most, because it is the least obvious. The `retro` skill looks back at a coding session and suggests changes to the agent's environment, not to the code: navigation pointers, automated checks, coding standards, steering files, tool economy, information access. And it classifies each finding before acting. A mechanical violation becomes a deterministic check (a linter rule, a pre-commit hook, or a CI job), and `CODING_STANDARDS.md` is kept for genuine judgment calls. The release goes as far as saying that a repository with no guardrail at all is a finding in its own right. The document on bot teams talks about fixing the environment rather than the agent, and the ESAA paper opens with the same bet: the core problem is not improving the prompt, it is restructuring the system around verifiable invariants.

## Why this is not copying

There is a simple test for telling convergence from imitation. Copying transmits form; convergence transmits function. If someone had copied ESAA, I would expect to find the form: an append-only event log, a validated JSON envelope, a hashed projection, an orchestrator as the single writer. I find none of that in Pocock's skills, which work with git, worktrees, and markdown, and the document on bot teams operates at another layer, that of roles, prompts, and routines. The mechanisms are different, and that is precisely why the similarity of function is worth something as evidence. If the mechanism were the same, I could not tell an idea that holds up from an idea that spread.

And I need to be honest about my own place on this tree. ESAA is convergence too. Event sourcing is a pattern Martin Fowler described in 2005, CQRS comes from the same tradition, code review and CI are old software engineering practice. What I did in February was assemble those parts for the specific case of LLM-based agents and write them down as a protocol. I do not claim priority over any of them, and I do not think anyone copied ESAA. What I can say is narrower and, to me, more useful: the same functions keep showing up, in places that do not talk to each other, which suggests they are not a matter of style. They are responses to the environment.

I have already worked through a similar observation in [The prompt describes the cycle; ESAA institutes it](/en/blog/the-prompt-describes-the-cycle-esaa-institutes-it/), starting from the instructions of a commercial agent. There the contrast was between a cycle narrated in natural language and a cycle recorded outside the model. What changes now is the direction of movement. The `retro` skill does not settle for narrating the rule: it asks that everything mechanical leave the text and become a deterministic check. It is the same gesture that motivated ESAA, applied by another team, at a smaller scale, with other tools.

## Where each part should live

The practical consequence of convergence is not "use ESAA." It is a more useful question for anyone operating agents: at which layer is each of the four functions installed? The same function can live in a prompt, a skill, a hook, a CI job, or an orchestrator, and what it guarantees changes with the layer. A rule written in markdown depends on the model following it. A rule in a pre-commit hook depends only on the hook running. An event recorded by an orchestrator that is the single writer depends only on the orchestrator. The difference is not aesthetic; it is the difference between an obligation and an invariant.

The `retro` criterion seems to me the right one for deciding this, and I would apply it beyond coding standards. Whatever is mechanical should leave the prose: recording the step, checking that verification ran, preventing a finished task from being reopened. Whatever is judgment should stay with a person, but the moment of calling that person can be mechanical, triggered by the kind of change or by the size of the blast radius. Fixing the environment, in this sense, means moving each function from the layer where it is requested to the layer where it is guaranteed. ESAA-Security ([paper](https://arxiv.org/abs/2603.06365), [repository](https://github.com/elzobrito/ESAA-Security)) is an example of the same move in a specific domain: instead of asking a model to "find vulnerabilities" in free prose, the audit becomes a pipeline in which a finding only exists after it has been validated and recorded, as I argued in [Stop asking AI to "find bugs" in your project](/en/blog/stop-asking-ai-to-find-bugs-meet-esaa-security/).

The document I read today carries numbers and dates I could not verify, so I do not use them here. It enters this text as a signal, not as proof. Pocock's release, on the other hand, is published and says exactly what I described. Two signals do not make a law. But when lineages that do not know each other start developing the same organ, I would rather study the pressure than argue about authorship, and the pressure here is clear: in a system where generating got cheap, what survives is what can prove what it did.