Before Rails, every web app was a snowflake.

Developers were solving the same problems (e.g. routing requests, querying databases, rendering HTML) but every team invented their own structure. Code was organized by vibes. If you joined a new project, you spent the first few weeks just figuring out where things lived.

Then Rails showed up in 2004 and said, "it's Model-View-Controller." Your data logic goes here. Your presentation goes here. Your coordination goes here. Rails didn't invent MVC - the pattern had existed since Smalltalk in the 1970s - but it codified it into an opinionated framework that made the right architecture the default. Django followed in 2005. Laravel arrived in 2011. Spring MVC found new life. An entire generation of developers learned to think in three layers, and a cambrian explosion of web applications followed.

We're here again.

Right now, teams are building agentic applications. Systems where an LLM doesn't just respond to a prompt but coordinates tool calls, processes inbound messages from multiple channels, and initiates work on its own. Every team is building them differently. Glue code everywhere. Custom abstractions that map to nothing anyone else has built.

Agentic applications are obviously becoming a thing. But few people have formalized the patterns yet.

With the release of OpenClaw, that may be starting to change. OpenClaw launched as a product, not a framework. But when you deconstruct how it's built (i.e. the components, the boundaries, the separation of concerns) a clear architectural pattern falls out. Like MVC before it, once you see it, you can't unsee it.

In a typical web application, nothing usually happens until a user makes a request. The Loop breaks that assumption. It ticks on a timer, on a schedule, on a file change, on whatever trigger you configure, with each tick generating work for the Orchestrator. 

The Loop is not a new invention. Background jobs have existed for as long as web applications have. Developers have been running work outside the request cycle for decades. What's different in an agentic context isn't the mechanism. It's what the Loop feeds into. A traditional background job sends a batch of emails or resizes images. An agentic Loop feeds work into an Orchestrator backed by LLM-driven decision-making. The tick is familiar. What happens after the tick is new. This is the component that got people excited about OpenClaw's heartbeat feature; an agent that checks for new information on a cadence and takes action without being prompted.

To the rest of the system, the Loop is the origin of initiative. Without it, the application only acts when spoken to (i.e. every task begins at the Gateway, triggered by a user or an external event). The Loop is what gives an agentic application a pulse. It's the difference between a tool you use and a system that works alongside you. And architecturally, it's remarkably simple. The Loop doesn't need to know what the Orchestrator will do with the work it generates. It just needs to know when to generate it. That clean boundary is what makes it a distinct component rather than a feature of the Orchestrator itself.

When a task arrives - whether from the Loop or from the Gateway - the Orchestrator handles it. It calls the LLM, parses the response, executes tool calls, handles retries when things fail, and manages the back-and-forth between "what does the model want to do" and "what actually happened when it tried." If you've built an agentic harness, you've built an Orchestrator. Even if you called it main.ts. In MVC terms, this is like the Controller; the logic that turns a raw capability into useful work.

The Orchestrator is where most of the complexity lives, and for good reason. It's the only component that touches all three others. It receives events from the Gateway and the Loop. It calls out to Inference for decision-making. It executes the tool calls that Inference requests. Every retry strategy, every error handling path, and every decision about when to escalate to a human is Orchestrator logic. If the Loop is the heartbeat and the Gateway is the front door, the Orchestrator is the nervous system. It's the component that most teams build first, and the one that most benefits from being extracted into a framework, because getting it wrong means getting everything wrong.

The Gateway is how the outside world reaches your agent. Without it, your application is a terminal script. The Gateway lets your agent receive work via email, Slack, SMS, a JSON API, MCP, a webhook or whatever channels or protocols make sense. Its job is to normalize these different inputs into a common event format the Orchestrator can consume. To the Orchestrator, it doesn't matter whether a task came from a Twilio webhook, email or a Slack message. It's just an event.

What makes the Gateway architecturally significant - rather than just an integration concern - is that it decouples the agent's capabilities from its surface area. An Orchestrator that can research a topic, draft a response, and send a follow-up email doesn't need to change when you add WhatsApp as a channel. The Gateway absorbs that complexity. It handles authentication, protocol translation, and message formatting so the Orchestrator never has to. This is the component that turns a developer tool into a product, and it's the one most likely to develop a rich ecosystem of adapters and plugins as the pattern matures.

The easiest to understand, because it's the one everyone starts with. It's your LLM provider - OpenAI, Anthropic, a self-hosted model, whatever. In the LOGI pattern, Inference is analogous to the database in a web application. No one would call a MongoDB instance a web app. No one should call an API wrapper around an LLM an agent. Inference is the essential underlying capability that everything else is built around, but it's not the application itself.

And much like databases, the choice of inference provider is a first-class architectural decision. Cost, latency, capability, rate limits, and fallback strategies all live here. A well-designed Inference layer lets the Orchestrator call for intelligence without caring which model provides it — the same way a well-designed ORM lets a Controller query data without caring whether it's backed by Postgres or MySQL. This abstraction matters more than it might seem. Models change fast. Pricing shifts. New providers emerge. The teams that treat Inference as a swappable layer rather than a hardcoded dependency are the ones that can adapt without rewriting their Orchestrator every time the landscape shifts.

---

There's a reason software moves in framework cycles. It's not because frameworks make new things possible. It's because they make the right architecture easy and give teams a shared vocabulary.

Before MVC frameworks, a junior developer joining a web project had to reverse-engineer the team's bespoke architecture. After Rails (and others), they could join any MVC project in any language and immediately know where routing lived, where the data models were, and where to find the templates. The pattern was portable across implementations.

LOGI offers the same promise for agentic applications. "We need to add WhatsApp support" - that's a Gateway concern. "The agent keeps retrying a failed API call forever" - that's an Orchestrator problem. "I want the agent to check for new pull requests every hour" - that's a Loop configuration. "We need to switch from GPT-4 to Claude" - that's an Inference swap.

This isn't just organizational tidiness. It's how ecosystems form.

MVC didn't just give us Rails, Django, or Laravel. It gave us an entire generation of ORMs, template engines, middleware patterns, and routing libraries that were interchangeable because they all assumed the same architecture. If LOGI takes hold, the same thing happens. Composable Loop strategies. Gateway adapters for every messaging platform. Orchestrator middleware for logging and observability. Inference layers that abstract over providers.

OpenClaw is a product, not a framework. That distinction matters.

DHH didn't set out to build Rails. He built Basecamp, and Rails was the framework he extracted from it. OpenClaw may be in a similar position - a product whose internal architecture reveals a pattern worth extracting and formalizing.

If that extraction happens, the playbook from the MVC era suggests what follows.

Competing frameworks emerge with different opinions about the same underlying pattern. Rails, Django, and Laravel all implemented MVC with different philosophies. Some more opinionated, some more flexible. The pattern survived. Specific implementations rose and fell.

Then the ecosystem compounds. Once developers share a common architecture, they share components. Gateway adapters become plug-and-play. Orchestrator middleware for approval workflows, human-in-the-loop checkpoints, and cost tracking gets extracted into libraries. Inference providers compete on a well-defined interface rather than proprietary SDKs.

Then a new generation of developers learns to think in LOGI the way the previous generation learned to think in MVC. They won't remember the ad-hoc era. They'll start with the pattern and build from there. 

We've seen this movie before. The architecture is emerging. LOGI: Loop, Orchestrator, Gateway, Inference.