Agents are Octopuses

Born too late to explore the high seas, Born too early to explore space, Born just in time to explore the oceanic depths and LLMs

20,000 leagues under the sea

There’s something strange that happens when you descend into the depths. The temperature drops. The sun’s rays disappear. Darkness creeps in. The creatures get weirder. Almost alien like.

It is here, in a realm hostile to warm-blooded life, that crustaceans thrive. As you wander around, you might find yourself grabbing a burger at Mr Crab’s or a drink at Moltbook where Openclaws mingle and commiserate. It’s a lonely world out there but it’s better than drinking alone. You might even head over to Gastown where aliens from above are extracting a black sticky substance from the depths. At least they pay the locals well. Like all mining towns in a boom, it’s certainly been a time of rapid change. The population is exploding. Some say even as big as the Cambrian.

As you wander about, a wild creature appears! One that even in this new world seems foreign and strange. Everything you’ve seen so far is tough, built to survive the extreme pressures and competitive environment. The shells of the claws are hard, impenetrable. And so are the industrial pipes and machinery of Gastown. This creature, on the other hand, is soft. It is made of flesh. You can only describe it as made of a hub and many spokes. Each spoke seems to act independently, but stepping back, it is clear they are as one. Perhaps it is the hub that is pulling the strings. And yet you observe that when the spokes get cut off from the hub, they continue to function as normal. It has 8 spokes, so you christen its name in your language as “octopus.”

“Meeting an octopus is, in many ways, the closest we will come to meeting an intelligent alien.” — Peter Godfrey-Smith, Other Minds

As far as Earth species go, he may very well be right. But there’s an even more alien intelligence among us now: LLMs, whose minds are so different from us that they don’t even sit on the evolutionary family tree.

And as we’ll see, the right paradigm for understanding them isn’t a swarm. It isn’t a factory assembly line. It’s the other alien intelligence on our planet: the octopus.

What Defines an Agent?

Let’s ask a deceptively simple question to start: what actually is an agent?

If you’re a native of AI land, you might point to a simple definition of an LLM running on a loop. You might reference the Anthropic blog post that can decompose the agent into its tools, harness, sandbox, etc.

But then you might ask: Is a single LLM call an agent? Almost certainly not. What if it is given the same context and access to tools as a coding agent? What if we call it two times in succession? After how many iterations does it become an agent? What if the coding agent only needs one LLM cycle, so the LLM call is functionally identical?

This all begs the question: where is the essence of an agent? where is its identify? where is its - dare I say - soul?

Before you dismiss this question as pedantic and academic, the mental model we choose here has profound consequences on how we use and build agents.

Here is the intuitive definition: the identity of an agent is a function of the weights of its model and its context management. Like a human, it is the memory that determines an agent’s identity and essence. Unlike a human, however, we can play with the model and context in creative ways that break the unity between model and context.

For instance, we can swap out the model between agent turns. We can fork the agent session so that at least for those agents, multi-worlds is a fact of their universe. We can perform surgical operations on the context that makes Eternal Sunshine of the Spotless Mind look like child’s play.

Philosophical questions like Ship of Theseus aside, this presents a challenge. If we continue to view agents through the lens of the creatures that we are familiar with (e.g. humans), we dramatically limit ourselves in what is possible.

Existing Patterns

Taking a single LLM API call as the atomic unit of interaction, let’s see the existing patterns for how we have so far built scaffolding and structure around it:

Agents. A single LLM model in a loop, calling tools, reading results, deciding what to do next. It’s remarkably effective precisely because it’s simple. Give the model tools, give it a goal, let it iterate. However, a single agent hits walls. Context fills up. Single threading precludes parallel execution.

Swarms. Swarm architectures fan out: a main agent spawns sub-agents that go off and work in parallel. Claude Code’s sub-agents and Kimi swarms are examples. But swarms have a particular shape. The sub-agents are function calls, not true colleagues. They spin up, do their work, return a result, and die. There’s no persistence, no relationship between a sub-agent that runs today and one that runs tomorrow. The orchestrator holds the context; the sub-agents are disposable. It’s useful for parallelization, but ultimately a shallow form of multi-agency.

Assembly lines. If swarms are messy and chaotic, assembly lines are their industrial counterpart. The structure is pre-defined: a DAG of LLM calls where each node is a function from input to output. Information is manufactured and tweaked like a car rolling down an assembly line. This method with humans too, with Flash Teams pioneering this pattern with crowdsourced experts. LangGraph, n8n’s AI nodes, and countless AI workflow builders all assume you can decompose a task into a graph of steps ahead of time. The graph has to be designed up front. The moment reality diverges from the plan, the whole thing brittles. In fact, self-organizing systems have been shown to preform better than strict hierarchies

Multi-agent orchestrators. The most ambitious of the current approaches. Rather than a pre-defined DAG, an orchestrator agent dynamically routes work among specialized sub-agents. Adversarial setups where one agent critiques another. Role-play architectures where a “PM” agent coordinates “engineers” and “designers.”

Project Octopus

The core thesis: agent collaboration and memory are intricacy linked.

Collaboration doesn’t exist yet because memory is not there yet. Memory is currently mildly useful at best and actively counter-productive at worst. It’s common to see memory systems inject non sequiturs and steer agents down the wrong path. Many of our friends actually turn off memory because of this problem. And without memory, collaboration doesn’t make sense. Without memory, there’s no distinction between an old agent and a new one, so each one is instantiated at birth and then promptly destroyed. You cannot collaborate with something that is not going to be there tomorrow. Memory gives the agents a chance to build accumulated knowledge and experience, meriting collaboration, specialization, and the other goodies that come with team work.

We believe the other direction is also true: effective collaboration is critical for developing useful memory. In some ways, the solving memory is in fact solving the collaboration problems. The failures of AI memory are in fact the failures of an agent in collaboration - i.e. not remembering what the human user told it or applying the information in the wrong way.

This goes one step deeper though. The core problem with memory in general is that it is an accumulating advantage rather than an immediate one. Thus, it is hard to build a magical moment where memory is useful from the get-go, especially as context windows are where they are. But we know that memory necessary in the future if we want our capabilities to grow . Our solution to this is collaboration. Where agents need to work together and where human users work together, memory can provide that immediate magical moment.

By combining the memory of multiple “arms” (i.e. coding agents) from across an engineering team, we create a centralized memory store (a “Stash”) that makes each agent better: faster, less error prone, less slop, and more autonomous. In a world where “memory” is simply text, collaboration can look less a chat room and more like a shared brain.

What does this look like today?

Today, Stash is simple. It is a CLI that searches and indexes over your team’s agent transcripts.

It started as a simple internal tool to help us fix a tricky bug by enabling coding agents on two different devices talk to each other. It ended up taking a life of its own when we discovered the agents taking the reins and collaborating with each other proactively.

Since then, this has evolved into Stash, a central hive mind where all the sessions histories and memory of our coding agents live. This allows us to still use the coding agent of the day whether it’s Claude Code or Codex. Like an Octopus, the arms (e.g. Claude Code instances) use up more compute than the central hive mind. Anything the individual coding agents do get automatically pushed to Stash, and then the agents can use Stash to see what has been done before. In effect, this gives our code repositories memory: not just raw code or documentation that quickly gets out of date, but raw, live memory that is the true historical record of what decisions were made and why.

Each coding agent has access to the shared central memory which is maintained by our “sleep agent” and thus enables the individual coding agents to write less slop and build off each other work. Rather than each agent starting from scratch or asking their human users for context, it can query Stash to work autonomously. Put it another way, Stash serves as a communal “reasoning cache” where all the tokens that are burned from previous agents on a team are not wasted but used to improve future agent runs.

This has increased our speed of development tremendously by removing one of the few remaining bottle necks: Instead of asking my co-founder Henry why he did something, my agents can just find out. Instead of re-explaining the context every time (or hopelessly fighting to keep a Claude.md up to date), the agents just know. In one test, we reduced the time it took to fix a bug by ~46% simply by having two agents collaboratively solve the problem using Stash.

Our early testers have found other creative uses for Stash from using it as a repository for infinite list of research papers you should read to storing all sales call transcripts & documentation to sharing a “Stash” instead of a detailed write-up and memo (the recipient can just ask questions Socratic method style to understand what work was done).

The current version of Stash is only our first step. We envision a world where agents collaborate freely with each other like humans do on a close-knit team and where information that is not just stored in static files or structured databases but a live and fluid medium of exchange.

It is open source and self-hostable here. If you prefer a managed version, visit https://joinstash.ai or contact us at sam@ferganalabs.com to get something set-up.