The DOOR Framework

Jonathan Taylor

Jonathan Taylor

— 4 min read
The DOOR Framework

A Modern AI Interface Surface Manifesto

In 2026, modern software has a strange sense of déjà vu. We’ve quietly circled back to the 1980s.

We are writing more custom software than off-the-shelf tools. We live in terminals again. And the most powerful new users of our systems aren’t humans clicking through browsers — they are AI agents.

The most effective interaction pattern emerging in projects like OpenClaw (and a growing number of OpenClaw-inspired systems) is refreshingly simple and powerful: a complete, sane, all-encompassing CLI that wraps the entire product or service, paired with a single skill.md file that tells any AI exactly how to use it.

I call this pattern the DOOR Framework — short for Declarative Outlined Orchestration Relay.

It’s a great name on its own, and it’s also a deliberate nod to one of the cleanest architectural ideas from 80s computing: BBS doors.

For example, when OpenClaw needs to talk to Google Workspace, it doesn’t import a Google SDK or wrestle with OAuth token refresh logic in-context. It uses gogcli — a single CLI binary that wraps Gmail, Calendar, Drive, Contacts, Sheets, and Docs behind clean subcommands.

Need to search your inbox?
gog gmail search 'newer_than:7d' --max 10.

Create a calendar event?
gog calendar create primary
--summary "YOLO Harder"
--from 2026-03-04T09:00:00Z
--to 2026-03-04T10:00:00Z.

Read a spreadsheet?
gog sheets get <id> "Tab!A1:D10" --json.

The AI agent doesn’t know or care that it’s talking to Google’s sprawling API surface — it just opens the door, runs a command, and gets structured output back.

“Any sufficiently advanced technology is indistinguishable from magic.” — Arthur C. Clarke

Except in this case, the magic is just good architecture rediscovered.

A quick trip back to the BBS era

Before the web, before apps, before cloud APIs — there were Bulletin Board Systems. You dialed in with a modem, landed on a text menu, and that was your entire online world. Communities, file sharing, games, messaging — all menu-driven.

But when you wanted to do something truly powerful — play TradeWars 2002, run a door game, edit messages offline, or launch a full external utility — the BBS didn’t try to do it inside the menu system. It opened a Door.

As Aaron Reed described it: “The user was in essence passing through an invisible portal between one program on the host’s system and the next.”

That’s exactly the pattern we need again.

AI would have loved BBS's.

How BBS Doors worked (and why the pattern still matters)

A Door was a clean architectural hand-off:

  • The BBS passed full control to an external program.
  • That program ran independently with complete access to whatever it needed.
  • When finished, it returned control cleanly back to the BBS with structured results.

Clean entry. Full power. Clean exit. No spaghetti. No leaky abstractions.

Sound familiar? It should. It’s the same pattern behind Unix pipes, microservices, and more.

“Simplicity is the ultimate sophistication.” — Leonardo da Vinci
(and every good systems architect since)

The DOOR Framework for 2026

That’s exactly what the DOOR Framework recreates for the AI agent era.

  • The Declarative CLI is the framed doorway itself — a single binary that exposes every capability of your product or service in clear, intention-based commands. Think of it as your product’s 12-Factor interface for the agent world.
  • The Outlined skill.md is the blueprint taped to the wall — a readable document with examples, capabilities, and usage rules that any AI can understand instantly. Similar to how CLAUDE.md files teach Claude Code about a codebase, a skill.md teaches any agent about your product.
  • The Orchestration happens when the AI uses the door to interact with a system, process, product, or platform. The agent doesn’t need SDKs, REST clients, or authentication libraries — just exec and stdout.
  • The Relay is the reliable hand-off: the agent sends commands via the DOOR, gets structured output back (--json for machines, human-readable by default), and returns richer context to wherever it came from.

Why is DOOR better?

vs. REST APIs: An AI calling curl against 47 endpoints needs auth headers, pagination logic, error handling, and rate limit awareness — all burning precious context tokens. A DOOR command like ecto posts --status published --limit 5 --json does the same thing in one line.

vs. SDKs: Language-specific, version-sensitive, dependency-heavy. A CLI is language-agnostic and version-stable. As long as the commands work, the agent doesn’t care what’s behind the door.

vs. MCP Servers: MCP requires a running server process and protocol negotiation. It makes a mess of your context window. A DOOR is zero-infrastructure — it’s a binary on disk with a markdown file (inside of or) next to it.

“Make each program do one thing well.” — Doug McIlroy, the Unix Philosophy

Internal DOORs and External DOORs

Companies can now ship Internal DOORs for their employees’ personal agents and External DOORs for customer-facing agents — all built from the same clean pattern.

Internal DOORs might look like:

  • hr-cli employee lookup "Jane Smith" — your HR system
  • deploy-cli status production — your deployment pipeline
  • metrics-cli dashboard weekly --json — your analytics

External DOORs might look like:

The pattern is already winning. The best companies just haven’t named it yet.

The recipe

Building a DOOR is straightforward:

  1. One CLI binary that wraps your entire product surface. Every action is a subcommand. Every output supports --json.
  2. One skill.md file that documents capabilities, common workflows, and gotchas in plain language an AI can parse. The door can even carry its own skill.md and output it using the doorname --skill.md command.
  3. Structured output — JSON for machines, human-friendly by default.
  4. Zero external dependencies at the point of use. The agent just needs the binary on $PATH.

No more brittle SDKs. No more version-skew nightmares. No more “please integrate with our 47 endpoints” nonsense.

Just one well-framed door.

This is how serious software should expose itself

The BBS SysOps of the 1980s understood something we’re just now rediscovering: the best way to extend a system is to give it a clean, well-defined exit point to something powerful, and a clean way back.

“Those who cannot remember the past are condemned to repeat it.” — George Santayana

We’re repeating it. But this time, on purpose.

We don’t build APIs for humans anymore. We frame doors for agents.

Welcome to the second era of the software DOOR.

Go build some 🚪’s

Read more