Introduction
Most people know that they send a message and the AI replies within a few seconds but what happens during those few seconds does the message directly go to the LLM?, How does the AI remember previous conversations?, How does it know when to search the web or read a file?, How are Skills selected?
These are the questions that separate someone who uses AI from someone who builds AI systems.
The Internal Request Flow
A simplified internal workflow looks something like this:
User
│
▼
Communication Channel(Telegram, CLI, Dashboard)
│
▼
Gateway
│
▼
Planner / Agent Runtime
│
├──────── Memory
│
├──────── Skills
│
├──────── Tools
│
▼
LLM
│
▼
Final Response
│
▼
Gateway
│
▼
User
This may look like a simple pipeline but in reality every component has a completely different responsibility. Understanding these responsibilities is much more important than memorizing it.
Why Do We Even Need So Many Components?
Imagine if the architecture looked like this instead:
User → LLM
It looks simple but Unfortunately, it wouldn't work in a real application because the LLM has no idea about:
- Who is the user.
- Which conversation is active.
- Where project files are stored.
- When it should search the web.
- Which tool should execute.
- What happened in previous conversations.
LLM only understand the text and other things has to be managed by the surrounding system. That surrounding system is what OpenClaw provides.
Why Gateway?
After user inputs the prompt gateway is the first component who receives every request. For example think of it as the front desk of a company nobody enters the office without passing through reception.
Gateway is responsible for:
- Receiving requests
- Identifying users
- Validating incoming data
- Finding the correct session
- Loading the correct workspace
- Calling the Agent Runtime
- Returning the final response
- Creating logs
- Handling errors
Without Gateway, there is no controlled entry point into the system.
Why Planner (Agent Runtime)?
Once Gateway accepts the request, it forwards it to the Planner, often referred to as the Agent Runtime. This is where the actual orchestration begins. The Runtime doesn't immediately ask the LLM for an answer. Instead, it first asks several questions internally.
For example:
- Do I already know the answer?
- Should I load previous conversation history?
- Do I need Memory?
- Is there a Skill that matches this request?
- Should I execute any Tool?
- What prompt should finally be sent to the LLM?
You can think of Runtime as a project manager. It doesn't perform every task itself. Instead, it decides who should do what and in which order. A typical Runtime workflow looks like this:
User Message
│
▼
Read Session
│
▼
Retrieve Memory
│
▼
Find Relevant Skills
│
▼
Execute Required Tools
│
▼
Build Prompt
│
▼
Call LLM
│
▼
Generate Response
This orchestration is one of the most important parts of any AI agent framework.
Why Memory?
Imagine asking the AI: My name is Rahul.
Five minutes later you ask: What's my name?
Without Memory, the AI would have no idea. Memory allows the system to remember information beyond the current message. Memory generally exists in multiple forms:
- Current prompt context
- Session history
- Long-term user preferences
- External knowledge sources
Memory makes conversations feel continuous instead of starting from zero every time.
AI With Memory:
User: what is my favorite Programming language?
AI: Your favorite language is Java.
That's why Memory is such an important component in modern AI systems.
Why Skills?
One of the biggest misconceptions is that Skills are code. Actually, Skills are instructions. They describe how the AI should solve a particular type of problem. For example, a Browser Skill may contain instructions like:
- When should browsing be used?
- Which tool should be called?
- How should results be summarized?
Runtime discovers available Skills and includes the relevant instructions while preparing the prompt. The LLM then follows those instructions during reasoning. Think of Skills as giving the AI experience. Instead of figuring everything out from scratch, the AI receives a predefined strategy for solving specific tasks.
Why Tools?
LLMs are excellent at reasoning but they cannot directly interact with your computer. For example, an LLM cannot:
- Read your local files
- Search the internet
- Execute Python
- Run shell commands
- Send emails
That's where Tools come in. A Tool performs the real world action.
example:
User asks: Summarize my project folder.
The LLM cannot magically read your project. Instead, Runtime calls a File System Tool. The Tool reads the files. The contents are then sent back to the LLM for summarization. Without Tools, the AI would only be able to generate text it wouldn't actually be able to do anything.
Why Workspace?
Workspace is the AI's working directory. Think of it as the AI's office. Whenever OpenClaw creates a project, reads files, stores reports, or generates documents, it usually works inside the Workspace. A typical Workspace may contain:
- Project files
- Skills
- Generated reports
- Temporary outputs
- Logs
- Knowledge resources
Keeping everything inside a Workspace makes projects organized and isolated from one another.
Why Sessions?
Sessions keep conversations separate. Imagine two users chatting with the same AI.
X says: My name is X.
Y says: My name is Y.
If both users shared the same Session, the AI wouldn't know whose name belongs to whom. Sessions solve this problem by isolating conversations. Each Session usually stores:
- Conversation history
- Tool outputs
- Temporary variables
- Context
- Metadata
This allows multiple users to interact with the same AI system independently without interfering with each other's conversations.
How Everything Together Works
Let's walk through one complete example.
User asks: Summarize my project folder.
Here's what happens internally.
User
│
▼
Telegram
│
▼
Gateway
│
▼
Find Session
│
▼
Load Workspace
│
▼
Agent Runtime
│
├── Retrieve Memory
│
├── Discover Skills
│
├── Execute File System Tool
│
▼
Build Prompt
│
▼
LLM
│
▼
Generate Summary
│
▼
Gateway
│
▼
User
Notice something interesting. The LLM is only one step in the entire process. Most of the intelligence comes from how the surrounding system prepares the request before the LLM ever sees it.