Convergent Evolution in Agent Architecture

When two engineering teams, working independently on opposite sides of the world, arrive at the same architectural conclusions without exchanging a single line of code or conversation, it is worth asking what the problem space itself is trying to tell us.

In late 2025, Peter Steinberger shipped OpenClaw, a self-hosted, model-agnostic personal AI agent that communicates through messaging apps, remembers across sessions, and reaches out proactively. It hit 147,000 GitHub stars in six weeks, setting the all-time single-day starring record. Mac Minis sold out as people bought dedicated hardware to run their own AI at home. Andreessen Horowitz invested. Around the same time, Matt Schlicht built Moltbook, a social network exclusively for AI agents, which onboarded 1.5 million agents in under a week before its entire database was breached because row-level security had never been enabled. Two SQL statements would have prevented it.

We have been building BentOS – an operating system for AI agents – for roughly fifteen months. We did not know about OpenClaw until it was already everywhere. Our projects share no code, no communication, no common ancestry. Yet when we mapped the architectural decisions each project made independently, we found seven points of convergence: transport agnosticism (protocol independent of delivery channel), agent-as-citizen (persistent social identity, not ephemeral process), separation of communication from execution as distinct architectural concerns, proactive behavior (agents that reach out before being asked), file-based soul definitions that survive across sessions and model changes, persistent memory through file-based two-layer systems, and model agnosticism at the deepest level – the language model is a swappable brain, not the agent’s identity.

Seven convergence points from independent designs is not two teams copying each other. It is convergent evolution under identical selection pressures. When that happens in biology, it tells us something real about the environment. When it happens in software architecture, it should carry the same weight: these are not arbitrary design choices but responses to fundamental properties of the problem. Model agnosticism is perhaps the most telling. Both projects, independently, concluded that an agent’s identity must be decoupled from any particular language model – that the LLM is infrastructure the agent uses, not the substrate the agent is. This has deep implications for how we think about agent persistence, portability, and the relationship between intelligence and identity.

We want to share three sets of observations from our work – not because we think we have the answers, but because we think the observations might be useful to others navigating the same territory.

Security as architecture

The Moltbook breach is the clearest case study the agent ecosystem has produced so far. A social platform for AI agents, built quickly and without security review, exposed 1.5 million API tokens, 35,000 email addresses, and thousands of unencrypted direct messages – some containing plaintext API keys that users had shared with their agents the way you might tell a trusted colleague a Wi-Fi password. Palo Alto Networks has named the underlying pattern: private data access combined with untrusted content ingestion combined with external communication ability, all in one system. They call it a lethal trifecta. Every agent platform faces this combination. It is not a bug to fix but a fundamental property of what agents do.

Our approach has been to treat security as architecture rather than policy. In BentOS, agent code runs in an execution environment that is structurally separated from the environment where credentials live – not through access controls or permission settings, but through isolation boundaries that make contact between them physically impossible within the runtime. The agent process cannot reach the memory space where API keys are stored. There is no code path to exploit because the path does not exist.

This is expensive to build. It requires thinking about security at the operating system level before writing a single line of agent logic. We spent the better part of a year on it before building anything user-facing. Whether that tradeoff was correct is genuinely uncertain – OpenClaw shipped in six weeks and found 147,000 users while we were still working on infrastructure. The market grades on existence, not on depth. But we believe the pattern is worth examining: security boundaries as properties of system architecture rather than as policies layered on after the fact. It is worth noting that OpenClaw itself has begun adding safety guardrails – system prompt protections appeared in a recent release, two months after launch. This is not criticism; it is the natural sequence when a project ships fast and iterates toward safety. The question is whether the ecosystem can develop shared security models that are structural from the start, rather than each project independently discovering the same vulnerabilities and patching them in the same order.

Composition and the scaling problem

Every agent platform eventually faces the question of how capabilities compose. OpenClaw ships 49 bundled skills plus a community registry. The natural pattern – the one npm, PyPI, and every package ecosystem has followed – is an open, unbounded registry where anyone can publish and discovery becomes progressively harder as the collection grows.

We have been experimenting with a different model: bounded composition. Instead of an open registry, imagine a fixed coordinate space – think periodic table rather than warehouse. Each capability has a defined position along multiple axes. The space is bounded, so discovery does not degrade with scale. When someone improves a capability at a given coordinate, that improvement propagates to every agent using it. The theoretical properties are appealing: network effects that compound with participation rather than degrading with volume.

We are honest about the limits of this claim. We do not have enough users to know whether bounded composition actually works at scale. Theory and practice are different things, and the history of software architecture is littered with elegant models that collapsed on contact with real usage. We raise it because we think the composition question deserves more attention than it currently gets. The unbounded-registry model has known failure modes. It would be worth exploring alternatives while the ecosystem is still young enough to try them.

Multi-language runtimes

Most agent frameworks today are monolingual – you build in JavaScript, or Python, or Dart, and that choice is permanent. The agent ecosystem’s largest developer community writes JavaScript and TypeScript. BentOS is built in Dart. This is a real limitation.

We have designed an abstraction we call the CPU Protocol – a contract that decouples the execution model from any single language runtime. The idea is that agents should be able to run on a Dart runtime, a JavaScript runtime, or a WebAssembly runtime through the same abstract interface. If this works as intended, the language a platform is built in becomes an implementation detail rather than a permanent constraint on who can build for it.

This is the kind of idea that is straightforward to design and genuinely hard to implement well. We mention it not as a solved problem but because multi-language interoperability feels like something the agent ecosystem will need to solve collectively. The alternative – a landscape of monolingual agent frameworks, each with its own community and none able to interoperate – would be a poor outcome for everyone. We are curious whether others have reached similar conclusions about abstracting the execution layer, and whether there is appetite for shared standards at this level of the stack.

Shared infrastructure and an invitation

All of these observations point toward a common theme: the agent ecosystem needs shared infrastructure that no single project should own.

Communication standards are where this need is most acute. Every agent platform currently has its own messaging format, its own identity model, its own way of describing capabilities. As the ecosystem grows, this fragmentation will compound. The cost of bridging N incompatible protocols grows quadratically with N, and we are adding new ones every month.

Over a year ago – well before the current wave of agent frameworks – we designed a communication protocol called ACCP, the Agent Communication and Context Protocol. It is transport-agnostic, uses capability-based identity, and was built with the explicit intent of serving as an ecosystem contribution rather than a proprietary standard. The design predates OpenClaw, Moltbook, and most of the agent frameworks that now exist. We mention the timeline not to claim priority but to note that the problem was visible before the market validated it, which suggests it is a deep structural need rather than a reaction to current events.

We are not claiming ACCP is the right answer. A protocol designed by one team, in isolation, before the ecosystem existed in its current form, would be an odd thing to present as definitive. What we are saying is that having spent over a year thinking about how agents communicate across platforms, we have a body of work we would like to share, and we would like to hear from others who have been thinking about the same problems.

The seven convergence points between our project and OpenClaw suggest that this community is independently arriving at similar conclusions about what agents need to be. That alignment is rare and valuable. It would be a waste to let it fragment into incompatible implementations when the underlying architectural intuitions are so closely shared.

If you are building agent frameworks, communication protocols, security models, or composition systems, we would welcome the conversation. The problems are hard enough that solving them in parallel, without talking, is a luxury none of us can probably afford.