If you build agents in OpenClaw, it’s tempting to implement “habit agent”, “todo agent”, and “reminder agent” as separate projects. It works—until behavior drifts across agents, state fragments, and every feature requires updating three codebases.
Buffy is designed to invert this: one behavior core (habits/tasks/routines + reminders + memory) exposed via API, with OpenClaw and channel bots acting as thin interfaces.
This guide explains the integration mindset and the practical architecture you want if you care about correctness, consistency, and expanding to new channels later.
Integration goal: OpenClaw orchestrates, Buffy owns behavior
Think of the boundary like this:
- OpenClaw: orchestration, agent UX, tool calling, workflow composition.
- Buffy core: durable behavior state + logic:
- Activity model (habit/task/routine)
- Scheduling + reminders
- Event history
- Memory (short-term + episodic + semantic)
That separation is what keeps feature work from duplicating across agents.
For the product-level explanation of the same boundary, see:
The data shape that keeps everything consistent
A reliable multi-channel agent platform needs a unified message format. Even if OpenClaw calls tools differently per workflow, you want to normalize to a single shape before hitting the core.
Minimum fields you typically need:
- Identity: user_id (and optionally workspace/team ids)
- Channel metadata: platform (chatgpt/telegram/slack/internal), conversation/thread ids
- Message: user text or structured command
- Timestamp: when it happened
- Context: optional (locale, timezone, user preferences)
Buffy’s existing engineering narrative for this pattern:
Recommended integration architecture
At a high level:
- OpenClaw receives a user intent (create habit, add task, update routine).
- OpenClaw normalizes it into a message envelope.
- OpenClaw sends it to Buffy’s API.
- Buffy updates activities, logs events, and schedules reminders.
- Reminders are delivered via the channel adapters (Telegram/Slack/etc).
The important part is that the behavior core owns the logic (parsing → persistence → scheduling → memory updates), not the adapter.
Keeping channel bots thin (and why it matters)
When channel adapters get “smart”, you pay for it later:
- Bugs appear only in one channel.
- New features roll out unevenly.
- Your “habit agent” and “todo agent” disagree about what happened.
Keep adapters focused on:
- Receive events
- Normalize into the unified format
- Call Buffy API
- Render responses
Everything else belongs in the core.
Testing strategy (pragmatic)
To avoid regressions across OpenClaw workflows:
- Test the core behavior via API using a set of canonical conversation scripts:
- Create habit + complete + skip + snooze
- Add task + due date + reschedule
- Routine with nested habits
- Run the same scripts through each adapter (ChatGPT/Telegram/Slack) to ensure the interface layer does not fork behavior.