Every Arm Is Still Searching: The Octopus Model of Agency

There's a video by Mark Rober where he builds an underwater maze just to watch an octopus solve it. What stays with me isn't the outcome — it's the animal's process along the way. The octopus doesn't stop when the obvious path fails. One arm explores a gap. Another circles back from a dead end. Another investigates a surface it hasn't touched before. Nothing about the animal looks frozen by the fact that it doesn't yet know the answer. It just keeps exploring until the environment hands it new information.

I've written before about turtling — looking directly at a problem and deciding, I can't solve this, someone else has to. It isn't avoidance. It's surrendering ownership of an outcome while remaining fully aware of the obstacle in front of you. The octopus is the opposite move. Not louder, not busier. It simply keeps searching.

Here's the management insight underneath the video: persistence isn't the mechanism. Distributed search is. What looks from the outside like an animal stubbornly refusing to quit is actually many local searches running at once, each one reporting back what it learned. That distinction matters more than it sounds like it should, because it's the difference between a team that grinds on one failing approach and a team that's actually exploring.

The Octopus Model of Agency, defined

"Octopusing" doesn't just mean "keep trying" — it's a specific pattern, and it holds together only when four things are true at once.

• Shared outcome. Every arm's search ultimately serves the same organism-level need — food, escape, safety — even though no single arm is choosing that objective on its own.
• Distributed exploration. No single arm carries the whole plan. Each one senses, tests, and adjusts locally, and the organism integrates what the arms are learning in real time.
• Informational failure. A dead end isn't a verdict on the mission. It's data. An arm that hits a wall has just eliminated one possibility and, in doing so, told the rest of the animal something it didn't know a moment ago.
• Continued agency. The arm that just failed still owns finding the next move. It doesn't retreat and wait to be picked up — it tries something else, informed by what it just learned.

Lose any one of these and it stops being octopusing. Lose the shared outcome and it's chaos. Lose the distribution and it's just one plan with a stubborn owner. Lose the informational failure and every dead end becomes a reason to quit instead of a reason to adjust. Lose continued agency and you're back to turtling — an arm that understands exactly where the wall is and stops anyway.

The biology is part of what makes the metaphor hold rather than just being whimsical. Roughly two-thirds of an octopus's neurons live in its arms rather than its central brain — a finding that underpins decades of research into octopus arm autonomy, including neuroscientist Binyamin Hochner's work on arm-level motor control at the Hebrew University of Jerusalem. That doesn't make each arm an independent mind, and I don't want to overclaim what's actually understood about octopus cognition, or imply every twitch of every arm is a deliberate, food-seeking decision. What the biology does support is narrower and more useful: real local search, running without a central bottleneck, that still adds up to one coordinated objective.

What this looked like in practice: DevSpark's knowledge problem

The clearest example I have isn't the octopus. It's a problem I've been circling in DevSpark, the framework I use for spec-driven, AI-assisted development. The objective never moved: give a project durable knowledge that stays accurate and doesn't require an agent to reload the entire history to act correctly. Every arm that went after that objective, though, looked completely different from the one before it.

The first arm was archiving. Move completed specs somewhere tidy so they're not cluttering the working directory. It felt responsible. It solved nothing — a well-organized pile of specs nobody rereads is still a pile of specs nobody rereads. Dead end, but an informative one: the problem was never where specs live, it was what happens to the knowledge inside them.

The second arm was /devspark.release — give a completed spec a real, versioned home instead of an ad hoc one. Genuine progress, and still just relocating a document. Dead end again, but a narrower one this time.

The third arm was /devspark.harvest — stop treating the spec's text as the valuable thing and start extracting the decisions, rules, and patterns worth keeping before the source material gets cleaned up. That was the first arm to separate a spec's value from its text, and it's still shipping today. But living with it exposed a new wall: it runs as a periodic sweep, and the narrative documents it extracts into — the constitution, an ADR folder — go stale in exactly the way I was trying to avoid in the first place.

The fourth arm reached for embeddings and a vector store, the standard answer to "find the relevant knowledge cheaply." That one hit a wall fast: it trades transparency for convenience, and it introduces a second thing that can drift out of sync with the truth, on top of the one I already had.

The current arm — atomic, single-responsibility knowledge objects, one canonical file per fact, merged in by a step I'm calling assimilation — is the furthest any arm has gotten. Retrieval, deciding which handful of those files a given task actually needs, is still unresolved. That arm hasn't found the food yet. It's still searching.

Five arms. Five different shapes. One objective that never wavered. That's the lesson in one sentence: the objective didn't change. The arms did.

What octopusing isn't

It isn't stubborn persistence. Retrying the identical thing after it fails, expecting a different outcome, is the arm that never got the memo from the wall it just hit. Persistence means continuing to push. Octopusing means continuing to own the problem while changing the search based on what the last attempt taught you. Archiving taught me the problem wasn't storage. Harvest taught me extraction without a stable destination just relocates staleness. Each arm in the DevSpark example only counts as octopusing because it changed shape in response to what came before, not because it kept moving.

It isn't random experimentation either. The arms have real autonomy over how they search, but not over what they're searching for. An arm doesn't get to decide the octopus should be looking for shelter instead of food because shelter seemed more interesting. That's the same failure mode I've written about as Sidetracked by Sizzle — curiosity is a genuine asset right up until it substitutes for the actual objective. Octopusing without a locked destination isn't agency. It's just motion with better PR.

And it can run in parallel or in sequence — both count. Several people can investigate a blocker simultaneously, each taking a different angle. Or one person can work through several approaches over time, the way the DevSpark example did, one arm at a time, months apart. What makes it octopusing either way is the same thing: the arms own the search. The organism owns the outcome. No individual arm gets to redefine success. It gets to decide how to search for it.

Turtling and octopusing, side by side

Same obstacle, two different responses. The turtle sees the wall clearly — often more clearly than anyone else in the room — and stops, quietly deciding the outcome now belongs to somebody else. The octopus sees the same wall, logs what it just learned, and tries the next reasonable thing.

Obstacle → ownership stops. That's the turtle.

Obstacle → information gained → next reasonable move. That's the octopus.

An obstacle does not transfer ownership. You still own the problem, and you still own finding the next reasonable move. Turtling transfers ownership at the obstacle. Octopusing retains ownership and changes the search.

Ownership doesn't end because a dependency stalls, a requirement is ambiguous, or an attempt fails. It ends when the outcome is achieved, or when responsibility is deliberately handed to someone else — not because something got hard.

They're easy to tell apart if you watch closely, and almost impossible to tell apart from a single glance. A stalled ticket and a ticket mid-search can look identical in a status update. The difference only shows up in what happens next: does the person generate another informed attempt, or do they explain, again, why the last one didn't work?

A smaller example than DevSpark

Not every instance needs a multi-year framework redesign to make the point. Say a team is blocked on an unclear requirement from a stakeholder who's slow to respond. The turtle move is one person filing a question and waiting, ticket frozen until an answer arrives. The octopus move is several legitimate paths running at once: one person prototypes against the most likely interpretation, another checks whether an existing API contract already implies the answer, a third looks at how a comparable feature handled the same ambiguity last quarter. Nobody is guessing wildly — every arm is still constrained by the same requirement, the same deadline, the same definition of done. But nobody is frozen waiting on a single response either. When the stakeholder does answer, the team usually already knows more than the answer alone would have told them, because two of the three arms turned up something useful even if their guess wasn't exactly right.

The same shape applies to an unresponsive API dependency or a production defect with no obvious root cause: multiple reasonable hypotheses get worked in parallel instead of the whole team stacking up behind one blocked path.

What management style actually produces this

Organizations turtle for the same reason people do. Somewhere along the way, they teach employees that trying isn't worth it — that generating another attempt doesn't get treated any differently than quietly waiting for someone else to solve it.

The environments that produce octopusing instead tend to share three things, and I've watched teams get one or two of these right and still stall out, because getting all three at once turns out to be the hard part.

Ownership stays with the person or team responsible for the outcome. A blocker doesn't get reassigned to the leader just because it's hard. Routing every reasonable next step through three layers of approval doesn't distribute the search — it just adds latency to the same single-threaded decision that was always there. The job of a leader here isn't to grant permission for the next attempt. It's to notice the difference between someone who's blocked and has stopped, and someone who's blocked and still searching, and to leave the second one alone.

Failed attempts are treated as information, not incompetence. This is where the failure mode actually starts: punish a miss as if it were the failure itself, rather than a data point on the way to one, and people stop exploring after the first attempt. Ignore an attempt instead of learning from it, or escalate every miss into a review nobody wants to sit through, and the lesson lands just as hard. An organization that punishes, ignores, or endlessly escalates its arms' attempts is teaching those arms to stop searching — and it will get exactly the compliance it rewarded, delivered as a ticket that sits untouched until someone else picks it up.

The objective stays genuinely shared and stable. Distributed ownership without a shared objective doesn't produce arms searching in parallel toward the same outcome — it produces arms flailing in different directions, each certain its own direction is correct. I've written about how the Methodology Tax shows up here — organizations that reject the tools best equipped to solve a real problem, not because the tools fail technically, but because of how they arrived, without executive sponsorship, without the right ceremony. That's the shared-objective failure from the other direction: the organization itself loses track of what it's actually optimizing for, and punishes an arm for reaching the right answer the wrong way.

The test

Every team, every project, every organization eventually reaches a dead end. That part isn't optional and isn't a sign anything went wrong. It's just what happens when you're doing something hard enough to be worth doing.

The question was never whether the first attempt works. Almost nothing important works on the first attempt.

The real question is what happens next. When the obvious path closes, does anyone generate another informed attempt? Does someone try the next reasonable thing, based on what the last attempt just taught them? Or does everyone retreat into their shell and wait for someone else to flip them back over?

Every arm won't find the answer. Most of them won't. But if every arm is still searching, one of them usually does.

Explore More

• Turtling: When a Team Stops Looking for the Door — a related exploration of what it looks like when a team quietly surrenders ownership of a blocker
• The Beaver Builds a Pond — a third relationship with agency: reading the environment and changing it, rather than searching within it or surrendering to it
• The New Era of Individual Agency: How AI Tools Empower Self-Starters — how AI lowers the cost of sending another arm down a path
• Sidetracked by Sizzle: Staying Focused on True Value — why curiosity only counts as agency while it stays aligned with the actual outcome
• The Shark Stops When It's Done — the other half of this argument: knowing when the search is over, versus knowing when to keep searching
• DevSpark's Next Evolution: Rethinking Where Knowledge Lives — the full walk through the five arms behind this article's central example
• Accountability and Authority: Walking the Tightrope — what happens when the authority to act and the accountability for the outcome don't line up
• When the Pressure is On: Late Sprint Hotfix Governance — holding onto ownership and rational decisions when everyone is screaming "rush"
• AI and Critical Thinking in Software Development — the quiet erosion that happens when we stop doing the hard thinking
• The Managed Transition Model: Leadership Promotion as Power Exchange — Six Honest Servingmen, a structured version of the same distributed search