CLI Left, Dashboard Right: How to Layer Interfaces in the Agent Era

#agents #ai #opensource #softwareengineering

Andrej Karpathy recently said on X: 99% of products and services still don’t have an AI-native CLI.

Sharp observation, but only half the story. Our take: CLI alone isn’t enough. Products in the Agent era need two interface layers simultaneously — one that lets Agents execute with low friction, and one that lets humans understand the big picture and make decisions. The former is the operation layer. The latter is the cognition layer. A product with only one is incomplete.

This article is about that layering, and how we put it into practice with PowerMem 1.0.0.

Agents Don’t Click Buttons — They Run Commands

OpenClaw is a prime example. It’s not a chatbot — it’s an autonomous Agent that takes tasks, runs commands, reads and writes files, and calls external systems. The interface it naturally gravitates toward: one command, a few parameters, one structured result. Not HTML pages. Not form controls. Not a GUI that requires simulated clicks.

This isn’t an OpenClaw quirk — it’s a universal Agent trait. An Agent’s work loop is: observe environment, call tool, read result, decide next step. In that loop, CLI is the lowest-friction interface — predictable I/O, text-based results, no session state to maintain.

When designing PowerMem’s CLI (pmem), we deliberately built it to satisfy five conditions:

Predictable. Every command has deterministic behavior: parameters in, stdout out, exit code signals success or failure. No guessing required.

# Agent call: search memories, get JSON, parse directly
pmem memory search "user preferences" --user-id user123 --json

Discoverable. pmem --help, pmem memory --help, bash/zsh/fish completions — an Agent can understand what's available and how to call it on first contact. No need to read the entire documentation before getting started.
Composable. A single command is useful; chaining them is more useful. Agents can pipe pmem into scripts, CI/CD, workflow orchestration — not just point-and-call.

# Agent orchestration: backup → cleanup → stats, one pipeline
pmem manage backup -o backup.json && pmem manage cleanup --dry-run && pmem stats --json

Controllable. pmem isolates via --user-id and --agent-id — different Agents operate in different memory spaces. Permission boundaries are drawn at the command layer, no extra gateway needed.
Human-Agent isomorphic. The commands a developer uses to debug in the terminal are the same commands an Agent invokes during orchestration. Same semantics, same config, same state — no split-brain between what humans see and what Agents operate on.

These five conditions aren’t our invention. They’re Unix philosophy, naturally extended into the Agent era. CLI is the most native interface for Agents not because it’s old, but because its design patterns inherently match how Agents work.

But CLI Alone Isn’t Enough

If an Agent writes 100,000 memories via CLI, then what?

As a developer or operator, you need answers: How many memories total? What’s the distribution by user, Agent, type? Which memories are frequently retrieved? Which are stale and should be cleaned up? Is the system healthy?

CLI can answer these questions, but not well. pmem stats --json gives you raw numbers, but numbers aren't understanding. You need trends, distributions, anomaly detection, correlation analysis — the kind of thing visual interfaces excel at.

Our OpenClaw memory plugin memory-powermem is a concrete example. It uses autoRecall to retrieve relevant memories before each session and autoCapture to extract key facts after each session. In testing, token consumption dropped to 18% of the default approach. The plugin works precisely because PowerMem's CLI and API are predictable and composable — it calls pmem commands internally to read and write memories, no proprietary protocol to learn.

But even with the Agent side running smoothly, developers still need to see: What did the plugin write into PowerMem? Which memories are recalled most? How do you quantify the token savings?

That’s why Dashboard exists. It’s not a graphical wrapper around CLI — it’s a fundamentally different layer of interface: CLI solves how to operate. Dashboard solves how to understand.

In PowerMem 1.0.0, Dashboard provides:

Real-time stats on memory volume, write rate, and retrieval frequency
Distribution analysis by user_id, agent_id, and type
System health monitoring
Memory browsing, filtering, and detail inspection

CLI could theoretically provide all of this (via --json output piped to visualization), but Dashboard turns it into a one-second visual judgment. One glance tells you system status — no scripts, no command assembly required.

Operation Layer and Cognition Layer: Not Style, but Responsibility

When you look at CLI and Dashboard together, they aren’t two styles of interface — they’re two layers with different responsibilities:

CLI is the operation layer. For execution, orchestration, automation. Serving Agents and developers who need scriptable operations.

Dashboard is the cognition layer. For understanding, analysis, decision-making. Serving humans who need a global perspective.

This layering becomes critical in the Agent era because users are no longer just humans. When Agents become regular users of your product, you must answer two questions simultaneously: How does an Agent use your product? How does a human understand what happened after the Agent used it?

The former requires an operation layer — executable, predictable, composable interfaces. The latter requires a cognition layer — observable, analyzable, judgment-ready views. Neither alone is sufficient.

A product with only an operation layer: Agents can use it, but humans have no visibility. A product with only a cognition layer: humans can see, but Agents can’t plug in. Only when both layers coexist does a product truly transform from “software for humans” into “a system where humans and Agents work together.”

Beyond CLI and Dashboard

This layering isn’t specific to PowerMem or memory systems.

Any Agent-era infrastructure — databases, search systems, deployment tools, monitoring, task orchestrators — will face the same question: How do Agents access your capabilities? How do humans understand your state?

The answer isn’t “open another API” or “build another admin panel.” It’s deliberately designing two interface layers that share the same semantics and state, each facing its most natural consumer.

Karpathy said 99% of products lack an AI-native CLI. We’d add: even with CLI, if there’s no cognition layer to help humans understand what the Agent is doing, the product is still only half done.

Our Choice

Back to PowerMem 1.0.0. We shipped five interfaces in this release: Python SDK, CLI (pmem), HTTP API, MCP Server, and Dashboard.

They’re not five separate products — they’re five expressions of the same capabilities:

SDK for embedded development — three lines to start
HTTP API for cross-language integration — RESTful + Swagger
MCP Server for model ecosystems — Claude Desktop and other MCP clients read/write memories directly
CLI for the shared operation layer between humans and Agents
Dashboard for the human cognition and analysis layer

All five share the same config, storage, and semantics. A human debugs via CLI, an Agent calls via MCP, ops checks distribution on Dashboard — all seeing the same world.

This is our understanding of interfaces in the Agent era: not more interfaces for their own sake, but each interface returning to its natural responsibility, semantically consistent across the board.

CLI left, Dashboard right. One makes the system run. The other makes the value visible.

If you’re using OpenClaw, try our memory plugin to experience this layering firsthand: after one-click install, the Agent manages memories through the operation layer (CLI / API), while you observe what it remembers and how much tokens it saves through the cognition layer (Dashboard).