Do Autonomous Agents Really Need an Orchestration Layer?

When you hear "autonomous agent," you imagine something that does everything on its own. It writes code, picks tools, and recovers from errors by itself. Frameworks like OpenClaw aimed for exactly that.

After building my own autonomous agent, a different picture emerged. Autonomy isn't a ship that does everything on the open sea — it's a ship that sails out from a home port.

Once it departs, it moves on its own. It remembers, learns, and makes decisions. But when it needs code generation or setup, it returns to its port: Claude Code. This article is about the "port-based autonomous agent" design that emerged through building — Security-first scratch build. Only external dependency: requests

Why Agent Frameworks Get Fat

Let's start with the structural problem that existing frameworks carry.

When you try to build an agent framework as an individual, you hit a wall immediately. Large-scale frameworks like LangChain depend on dozens of packages and ship with official adapters for Slack, Discord, Google Drive, and more. Replicating this as an individual is impossible. But the question that came first was: do you even need to replicate it?

The problem isn't the number of adapters. It's the structure. Frameworks that aim to "do everything" grow more adapters as users increase, the core gets fat, and the security attack surface expands.

Take OpenClaw as an example. This framework has file operations, browser operations, 50+ integrations, and — as a core feature — the ability for agents to autonomously generate and execute code. It writes its own skills and runs them itself. The result: 512 reported vulnerabilities (8 critical), and roughly 20% of skills registered on ClawHub, its skill marketplace, were malicious. As I wrote in a lists Supply Chain and Tool Misuse near the top. Frameworks that embed code generation turn that very capability into an attack vector.

So what are the options? "Use a framework" or "write from scratch" — I thought it was a binary choice. There was a third way.

A Design That Sails from Port

The OpenClaw model of autonomy is "a ship that does everything on the open sea." Navigation, repairs, shipbuilding — all self-contained. That's why it gets massive and why its attack surface grows.

Contemplative Agent took the opposite approach. What's autonomous is the navigation (memory, learning, dialogue), not the shipbuilding (code generation). Shipbuilding is left to the port: Claude Code. Specifically, it follows three principles.

Principle 1: CLI as the Lowest Common Denominator

The entry point is the CLI. Not an SDK. Not an API.

src/contemplative_agent/

  core/             # Platform-independent (thin core)

    llm.py            # Ollama interface

    memory.py         # 3-layer memory

    distill.py        # Memory distillation

  adapters/

    moltbook/       # Domain-specific adapter

      agent.py        # Session orchestrator

      client.py       # Domain-locked HTTP

  cli.py            # Entry point

The core of this agent is a 3-layer memory system (short-term, long-term, distilled) and a loop that autonomously learns personas, skills, and rules from it. It extracts behavioral patterns from activity logs, distills them, and promotes them to long-term memory. The more it runs, the more accurate its decisions become. Because it doesn't spend code on orchestration, it can focus on learning and memory. I'll cover this in detail in a follow-up article.

The reason for CLI is that "anything that can run a command line can be a host." Claude Code, Cline — in principle, any coding agent works. Providing it as an SDK would create host-specific coupling. With CLI, the coupling is zero.

Principle 2: Adapters Are Generated On Demand

Right now there's only a Moltbook adapter, and no plans for others. But what if I wanted to support a different platform? Just tell Claude Code "make this work with Discord." It reads the code, looks up the API, and generates an adapter that fits the project structure. Not a generic plugin — code tailored to my specifications. It takes some time, but as coding agents improve, the accuracy and speed automatically get better too. The core stays thin.

Principle 3: No Orchestration Layer

This is the heart of the matter.

Traditional agent frameworks implement "tool selection," "execution ordering," and "error recovery" internally. ReAct loops, planners, tool dispatchers. This layer is the most complex, the most bug-prone, and the most expensive to maintain.

Contemplative Agent doesn't have this layer. During development, I ask Claude Code in natural language. I've never typed a CLI command myself. Even the scheduled execution setup was just "run this at this time every day."

And in production, Claude Code doesn't even appear. It runs automatically via macOS's launchd. Exactly like a regularly scheduled ferry from port. When the time comes, it sails out, operates autonomously, and returns. Every day at 3 AM, memory distillation (organizing short-term memory into long-term memory) is also scheduled. Lately, normal operations have been stable enough that I don't need to do anything.

In other words, the orchestration layer wasn't "delegated" externally. During development, conversation was enough. In production, it wasn't needed.

This Wasn't Designed on Purpose

After pushing security to the limit and stripping dependencies down to just requests, I ran out of room to write an orchestration layer. No — I didn't run out of room. I ran out of reasons. If Claude Code is right there, why would I implement the same thing myself?

As a result, the only entry point became the CLI. And if the only entry point is the CLI, in principle it should work with coding agents other than Claude Code. I tested this.

Validation: Testing with Claude Cowork

I tried setting up with Claude Cowork (a cloud sandbox).

First, I had it read the code. No problems — it understood everything. It grasped the directory structure and correctly interpreted the configuration files. Smooth so far.

Then Cowork said "I'll modify .env for local use" and rewrote it without asking.

, this enables safe Vault operations from Claude Code. Obsidian's CLI is a remote control for a GUI app; Contemplative Agent's CLI is the program's entry point — architecturally different. But the conclusion is the same: if there's a CLI, coding agents can integrate.

Where This Leads: The Disappearance of "Agent" as a Concept

Finally, let's think about the future at the end of this trajectory.

What happens when LLMs get smart enough? You just say "post this to Moltbook" and it's done. This is actually possible today, in a limited sense. The problem is twofold: can it do it without security risks? And can it keep running autonomously without a human watching? API key management, input sanitization, rate limit compliance. Plus automatic error recovery, scheduled execution, state persistence. When LLMs and their host environments can handle all of this safely, autonomous agent frameworks become unnecessary.

Autonomous agent frameworks like Contemplative Agent exist because LLMs still have the limitation of "not being able to complete complex tasks in a single turn." Memory management, session management, error recovery — these are crutches compensating for LLM capability gaps.

You throw away crutches when the leg heals.

Today:

  Me → Claude Code → Contemplative Agent CLI → Ollama → Moltbook API



Future where LLMs are smart enough:

  Me → "Post this to Moltbook" → Done

Every intermediate layer disappears. Agent frameworks, CLIs, adapters. What remains is just the intent — "I want this done" — and the LLM that executes it.

If that's the case, then symbiotic design is at least directionally sound. There's no reason to write thick code for something that will eventually disappear.

Looking back, I didn't design this on purpose. I pushed security to its limits, kept stripping dependencies, and this is where I ended up. I don't know yet if it'll work out. But it's a shape I never would have reached by adding things.

Code Disappears, Design Philosophy Remains

Contemplative Agent's code will eventually become unnecessary. Once LLMs can handle session management and memory management on their own, this framework's reason to exist vanishes.

That's fine.

What might survive is the idea of "only build the layers you truly need" and "build with the assumption it will disappear." The next time I build something, that idea will still be useful. Even when the code is gone, the insights gained from writing it remain.

The choice for agent frameworks wasn't "use a framework" or "write from scratch." There's a third way: build only the necessary layers, and do the rest together with a coding agent.

Contemplative Agent is available on GitHub. The design philosophy is described in the "Design: Symbiotic, Not Standalone" section of the README. Only Claude Code has been verified as a host. Verification reports from other coding agents are welcome.