Oslo Agent System

The Problem

Most AI assistants are stateless. You open a chat, ask a question, close the tab. No memory. No continuity. No ability to act without being asked.

We wanted something different: an AI system that runs continuously, remembers context across sessions, monitors multiple communication channels, handles recurring tasks autonomously, and has specialized capabilities that go beyond generic chat.

The challenge isn't getting an LLM to respond to messages. It's building the operational layer around it — the skills, memory, scheduling, and observability that turn a chatbot into a reliable system.

What We Built

Oslo is an AI operations system built on top of OpenClaw. It runs 24/7 on a Mac mini, monitors Discord, iMessage, and Slack simultaneously, and operates with 20+ custom skills that handle everything from market research to fitness coaching.

The Skill System

Each skill is a self-contained module with its own instructions, scripts, and data. When a message comes in, the system scans skill descriptions, picks the most relevant one, loads its instructions, and follows them.

Skills we built:

Category	Skills
Business	Market research, SEO research, community monitoring, CRM, content calendar
Content	Tweet craft, humanizer (voice alignment), LLM judge (quality scoring), OG image generation
Development	Coding agent orchestration, GitHub operations, skill creator
Trading	Autonomous intraday trading via Alpaca API with risk management
Knowledge	Knowledge base with embeddings, Obsidian vault integration
Personal	Fitness coaching, career coaching, weather
Communication	Discord, Slack, iMessage, email (Himalaya)
System	Health checks, video frame extraction, web automation

Each skill follows a standard structure:

skill-name/
  SKILL.md          # Instructions the agent loads
  scripts/          # Executable tools
  data/             # Persistent state
  templates/        # Reusable prompts

The key design decision: skills are loaded on demand, not all at once. The agent reads a skill's full instructions only when it's selected. This keeps context windows small and focused while allowing the system to have deep expertise across many domains.

Memory Architecture

Oslo wakes up fresh every session. These files are its continuity:

Daily notes (memory/YYYY-MM-DD.md) — raw logs of what happened each day. Decisions made, tasks completed, things to remember. Written throughout the day, consolidated at night.

Long-term memory (MEMORY.md) — curated insights distilled from daily notes. Significant decisions, learned preferences, project context. Periodically reviewed and updated, like a human reviewing their journal.

Hot facts (memory/hot-facts.md) — auto-generated index of frequently needed context. Loaded every session for instant access to common references.

Regressions (memory/regressions.md) — documented failures with rules to prevent repeats. When the system makes a mistake, the fix gets encoded as a regression rule that's loaded every session.

Semantic search — all memory files are indexed with embeddings. When a question touches prior context, the system searches memory before responding, pulling relevant snippets with source citations.

This layered approach means the system has both fast access to recent context (daily notes) and deep recall of historical decisions (semantic search across all files). No fine-tuning required. The memory lives in plain markdown files that humans can read and edit directly.

Multi-Channel Orchestration

Oslo operates across Discord, iMessage, and Slack simultaneously. Each channel has different behavior:

• Discord — full access, responds to all messages in allowed channels and DMs. Supports reactions, threads, polls, file attachments.
• iMessage — DM-based, personal communication. Handles contacts, scheduling, quick questions.
• Slack — workspace integration for professional contexts.

The system adjusts its behavior per channel. Private context stays private. Group chat behavior follows social norms — it doesn't respond to every message, uses reactions when appropriate, and stays quiet when there's nothing useful to add.

Autonomous Operations

The system doesn't just respond to messages. It operates independently:

Heartbeat checks — every 60 minutes during active hours, the system runs through a checklist: check email, review calendar, scan channels for urgent items, verify running build sessions, update daily notes.

Cron jobs — scheduled tasks that run in isolated sessions. Market scans during trading hours. Nightly memory consolidation. Weekly fitness reviews.

Proactive monitoring — if a build session fails, the system captures the error and auto-restarts with context. If an important email arrives, it alerts without being asked. If a calendar event is approaching, it flags it.

Build orchestration — spawns and monitors coding agent sessions (Claude Code) for development tasks. Tracks progress, captures errors, restarts on failure, and reports results.

The Dashboard

With 20+ skills, persistent memory, multiple channels, and autonomous operations, we needed visibility into what the system was actually doing.

Design

We built a monitoring dashboard following Linear and Stripe's design language:

• Pure zinc dark mode — no blue tint, just clean neutrals
• Glass-like cards with subtle borders and backdrop blur
• Monospace accents for technical data (timestamps, IDs, counts)
• Status pulse animations for live indicators
• Keyboard shortcuts for power users (⌘K command palette, number keys for navigation)
• SVG grain overlay for texture

Pages

Skills Overview — grid of all installed skills with search and category filtering. Each card shows the skill name, description, category badge, and source (built-in vs. custom). Click through to the full skill documentation.

Activity Feed — timeline of agent decisions and actions. Which skill was selected, what triggered it, what happened. Filterable by skill and time range.

Memory Explorer — browse all memory files with a split-pane interface. File tree on the left, rendered markdown on the right. Visual timeline of daily notes with clickable date dots. Full-text search across all memory.

System Health — gateway status, channel connectivity, model configuration, resource usage (CPU, memory, disk), cron job status and history.

Technical Implementation

The dashboard is a Next.js app running on localhost:3333. It reads directly from the filesystem:

• Skills are parsed from SKILL.md frontmatter across two directories (custom and built-in)
• Memory files are read and rendered as markdown
• System status is proxied from the OpenClaw gateway API
• No database — it's a real-time lens on top of existing files and APIs

API routes handle the data fetching:

• /api/skills — parses SKILL.md files, extracts frontmatter, categorizes
• /api/memory and /api/memory/[id] — reads memory directory, returns file content
• /api/system — proxies gateway status endpoint

Architecture Decisions

Skills as files, not code

Every skill is a markdown file with optional scripts. Not a plugin API. Not a module system. Plain files that the agent reads and follows. This means:

• Anyone can write a skill (it's just instructions)
• Skills are version-controlled in git
• The agent can read and understand its own capabilities
• No compilation, no deployment, no dependency management

Memory as markdown, not a database

All memory lives in .md files. This was deliberate:

• Humans can read and edit memory directly
• Git provides full history and diffing
• No schema migrations, no database maintenance
• Semantic search via embeddings gives database-like query capabilities
• The agent itself can review and reorganize its memory (and does, during heartbeats)

Dashboard as observer, not controller

The dashboard reads but doesn't write. It's a monitoring tool, not an admin panel. Agent behavior is controlled through the workspace files (AGENTS.md, SOUL.md, HEARTBEAT.md) and chat commands, not through a GUI.

This keeps the source of truth in one place (the workspace) and prevents divergence between what the dashboard shows and what the agent actually does.

Results

• 20+ custom skills covering business, content, development, trading, and personal domains
• Persistent memory across sessions with semantic search and citation
• 3 communication channels monitored simultaneously
• Autonomous operations running 14 hours/day (9am-11pm heartbeats)
• Zero downtime — runs continuously on a Mac mini
• Full observability via the monitoring dashboard

What We Learned

Start with the memory system. Without memory, nothing else works well. The agent forgets context, repeats mistakes, and can't build on previous work. Memory was the first thing we built and the most valuable.

Skills should be narrow. Early skills tried to do too much. The best skills handle one specific domain deeply. The selection system handles routing — individual skills don't need to be general-purpose.

Regression tracking prevents repeat failures. Documenting failures as explicit rules ("never do X because Y happened") is more effective than hoping the agent learned from context. Regressions are loaded every session, guaranteeing the fix sticks.

Observability matters more than you think. Without the dashboard, we were guessing about what the agent was doing. With it, we can see patterns: which skills get used most, where failures happen, how memory grows over time. You can't improve what you can't see.

---

This system was designed and built by Parallel Studio. We build AI agent architectures that run reliably in production — from skill systems to memory to monitoring. Tell us about your project.