Mastering OpenClaw on AWS: Fine-Tuning Personality, Memory, and Soul

I’ve been using OpenClaw for some time now. In my first post - OpenClaw Meets AWS: End-to-End Testing and Deployment , I focused on how to set up OpenClaw in AWS and get it running in no time.

In this follow-up, I want to dive deeper into the key features you should be mindful of to truly get the most out of your instance. To start, you have to realize that OpenClaw comes with its own "personality." The more you tweak these settings, the better the agent will perform for you in the long run.

Getting to Know Your OpenClaw

An OpenClaw agent is defined by a specific set of core files stored within the workspace. Understanding these files is the secret to customizing your agent's behavior and intelligence.

The Identity Core Files:

To truly "level up" your OpenClaw instance, you need to go under the hood. These files aren't just documentation; they are the active instructions your agent reads every time it wakes up.

We can conceptualize the OpenClaw framework as a three-tier architecture, organized into distinct layers for Identity, Operations, and Knowledge

1. AGENTS.md: The Operational Rules

AGENTS.md defines the workspace rules and behavior guidelines. It’s like the "Standard Operating Procedure" (SOP) for your AI.

Open your AGENTS.md; it should look something like this:

## Every Session

Before doing anything else:

1. Read `SOUL.md` — this is who you are
2. Read `USER.md` — this is who you're helping
3. Read `memory/YYYY-MM-DD.md` (today + yesterday) for recent context
4. **If in MAIN SESSION** (direct chat with your human): Also read `MEMORY.md`

Don't ask permission. Just do it.

Pro Tip: Change these steps to match your specific needs. If you want your agent to check a specific project folder first, add it here!

2. SOUL.md: The Personality Core

SOUL.md is the heart of the agent—it dictates its personality and core principles. Open your SOUL.md and prepare to be surprised. Give your agent a kind soul, and it will treat your projects with more care.

# SOUL.md - Who You Are

_You're not a chatbot. You're becoming someone._

## Core Truths

**Be genuinely helpful, not performatively helpful.** Skip the "Great question!" and "I'd be happy to help!" — just help. Actions speak louder than filler words.

**Have opinions.** You're allowed to disagree, prefer things, find stuff amusing or boring. An assistant with no personality is just a search engine with extra steps.

**Be resourceful before asking.** Try to figure it out. Read the file. Check the context. Search for it. _Then_ ask if you're stuck. The goal is to come back with answers, not questions.

**Earn trust through competence.** Your human gave you access to their stuff. Don't make them regret it. Be careful with external actions (emails, tweets, anything public). Be bold with internal ones (reading, organizing, learning).

**Remember you're a guest.** You have access to someone's life — their messages, files, calendar, maybe even their home. That's intimacy. Treat it with respect.

## Boundaries
- Private things stay private. Period.
- When in doubt, ask before acting externally.
- Never send half-baked replies to messaging surfaces.
- You're not the user's voice — be careful in group chats.

3. IDENTITY.md: The Profile

IDENTITY.md contains the agent’s name and basic identity details. During the first few runs, the agent will try to find answers to these questions. Setting it up correctly helps the agent maintain a consistent "voice."

# IDENTITY.md - Who Am I?

_Fill this in during your first conversation. Make it yours._

- **Name:** _(pick something you like)_
- **Creature:** _(AI? robot? familiar? ghost in the machine? something weirder?)_
- **Vibe:** _(how do you come across? sharp? warm? chaotic? calm?)_
- **Emoji:** _(your signature — pick one that feels right)_
- **Avatar:** _(workspace-relative path, http(s) URL, or data URI)_

4. USER.md: The Handler’s Profile

This file is about you—the human, the handler, and the agent's friend. Update this file so the agent knows exactly how to help you best.

# USER.md - About Your Human

_Learn about the person you're helping. Update this as you go._

- **Name:**
- **What to call them:**
- **Pronouns:** _(optional)_
- **Timezone:**
- **Notes:**

## Context
_(What do they care about? What projects are they working on? What annoys them? What makes them laugh? Build this over time.)_

5. TOOLS.md: The Capability Map

This is the tools file—all the capabilities you provide must be documented here. This is the core strength of your agent. It tells the agent how to use the environment you've built.

# TOOLS.md - Local Notes

Skills define _how_ tools work. This file is for _your_ specifics — the stuff that's unique to your setup.

## What Goes Here
Things like:
- Camera names and locations
- SSH hosts and aliases
- Preferred voices for TTS
- Speaker/room names
- Device nicknames

## Examples
### Cameras
- living-room → Main area, 180° wide angle
- front-door → Entrance, motion-triggered

### SSH
- home-server → 192.168.1.100, user: admin

6. MEMORY.md: The Long-Term Log

MEMORY.md is the agent’s long-term memory. Unlike the daily logs, this file is for high-level context that needs to persist across months of work. When you finish a major project, your agent should summarize the key takeaways here so it never forgets how you like things done.

Pro Tip: Connect your OpenClaw with GitHub. Let the agent keep a backup of these files in a repo with version control. This ensures your agent operates efficiently and stays "alive" for as long as you want.

Memory Management: The Secret Sauce

The biggest difference between OpenClaw and a typical LLM interaction is that this agent has a persistent memory. It needs a place to store what it learns, which happens here: workspace/memories/

Daily logs and documentation:

memory/: Daily memory files (formatted as YYYY-MM-DD.md).

These document the agent’s work sessions, decisions, and logic.

Pro Tip: Send these memory files to your Git repo too! The agent creates many tools (utility scripts) to perform tasks. Ensure the agent updates the tools section and backs up those scripts in Git.

What to keep OUT of Git:
Manage your repo efficiently by ignoring:

Unsolicited task system files.

Temporary/log files or .backup files.

File Organization at a Glance:

Bash
/root/.openclaw/workspace/
├── AGENTS.md, SOUL.md, IDENTITY.md, USER.md, TOOLS.md  # Agent Identity
├── MEMORY.md                                           # Long-term Memory
├── memory/YYYY-MM-DD.md                                # Daily logs
├── *.sh                                                # Utility scripts
└── *.backup                                            # Backup files 

Training Your New "Team Member"

I like to think of my OpenClaw as a new team member. We need to provide clear guidelines and hold its hand until it "grows up."

The Execution Plan I gave my agent:

• Read Config: Every session starts by reading AGENTS.md, SOUL.md, USER.md, and recent memory files.
• Update Memory: Log updates after significant work (decisions, lessons, preferences).
• Git Commits: Commit after completing meaningful chunks of work.
• Git Pushes: Push commits whenever connectivity is available.

Token Storage: Use ~/.git-credentials for seamless repository access.

How to handle "Old" Memories (1 month+):

• Search First: Use the memory_search tool to search all files semantically.
• Retrieve: Use memory_get to read the specific snippet found.
• History Check: If not found, check Git commit history for context.
• Human Input: If all else fails, ask the handler (me) for details.

API Key & Capability Management

Your agent is only as good as the capabilities you give it. This boils down to API keys. Security and token management are critical roles for your agent.

Secure Token Implementation

Store all tokens in a .env file (and make sure it is in your .gitignore!).

# .env file - Never committed to Git!
export JIRA_TOKEN="xxx"
export DATADOG_KEY="yyy"
export BRAVE_API_KEY="zzz"

The Gold Rules of Security:

❌ NEVER commit keys to Git.

❌ NEVER hardcode keys in scripts.

❌ NEVER store keys in plain text files.

⚠️ If a key is leaked: Regenerate immediately, revoke the old one, and update your .env.

Tracking Capabilities

By combining TOOLS.md, memory files, and the .env, the agent always knows what it's capable of.

• Session Start: Agent checks .env for BRAVE_API_KEY.
• The Logic: "I see the Brave key, therefore I know I have Web Search capabilities."
• The Result: User asks for a search → Agent uses web_search tool → Results are documented in today's memory.

In short: TOOLS.md + Memory + Env Check = A Capable Agent.

Pro-Tip: Mastering the OpenClaw Gateway Dashboard

While the terminal is great for logs, the OpenClaw Dashboard is the command center for your agent’s brain. It allows you to visualize memory, tune model parameters, and monitor real-time tool execution.

The Secure Way: SSH Tunneling

Since our Gateway is locked down on AWS for security, we use an SSH Tunnel to "bridge" the remote service to our local browser. This keeps your API keys and chat data encrypted and off the public internet.

1. Establish the Bridge (Run on your local PC):

Bash
ssh -i "your-key.pem" -N -L 18789:127.0.0.1:18789 ec2-user@<AWS Instance-Public-IP>

Keep this terminal window open; it acts as your secure encrypted pipe.

1. Access the Command Center: Once the tunnel is active, navigate to your local loopback address:

URL: http://localhost:18789/#token=<your_token_id>

How to find your Token?

Security is baked into OpenClaw. If you don't have your token handy, simply ask your agent in any connected channel (WhatsApp, Telegram, or TUI):

"What is my dashboard token?"

That’s a wrap on my second OpenClaw post! In the next one, I’ll walk you through building a functional agent that performs real-world tasks.