Introducing Agor Assistants

tl;dr: What started as an experiment porting OpenClaw’s agent loop into Agor has become a first-class feature. Assistants are persistent AI companions with memory, identity, skills, and scheduled heartbeats — fully integrated into Agor’s spatial canvas, multiplayer workflows, and now reachable directly from Slack.

From experiment to feature

A month ago, I wrote about running OpenClaw patterns inside Agor — taking the brilliant agent loop architecture (SOUL.md, MEMORY.md, persistent identity) and wiring it up to Agor’s MCP tools, spatial boards, and session trees.

That experiment proved the concept: an agent that bootstrapped itself, spawned parallel work, created and merged 4 PRs on day one, maintained accurate memory, and even course-corrected on a task it had previously dismissed. All visible on a board.

Since then, I’ve been running assistants daily at Preset, and the pattern has evolved from “cool experiment” to “how did we work without this?” This post covers what Assistants are, how they work in practice, and what I’ve learned from running four of them across my team.

For the full technical reference — BOOTSTRAP.md, BOARD.md, HEARTBEAT.md, memory layout, skills — see the Assistants guide.

What is an Assistant?

An Assistant is a persistent AI entity that lives in an Agor worktree. Unlike a regular worktree (which is where code gets written for a specific issue), an Assistant is a who — a long-lived companion with:

Memory — Identity files (SOUL.md, USER.md) and daily journals (memory/{YYYY-MM-DD}.md) that persist across sessions
Skills — MCP servers, CLI tools, and integrations that extend what the assistant can do
Heartbeats — Scheduled ticks where the assistant proactively checks on work, triages issues, and updates its memory
Orchestration — The ability to create worktrees, spawn sessions, manage boards, and coordinate multi-agent workflows through Agor’s MCP tools
Identity — A name, personality, and accumulated knowledge that makes each assistant unique

The framework is inspired by OpenClaw, which proved that agents need infrastructure for continuity — not just API access. Agor adapts those patterns for team-based developer workflows: everything is visible on a spatial canvas, state lives in git, and multiple people can interact with the same assistant.

Framework repository: github.com/preset-io/agor-assistant

Real-world assistants at Preset

I’ve been running four assistants at Preset, each serving a different role. Here’s what they look like in practice.

1. Personal assistant

The classic OpenClaw-on-Agor use case. This assistant runs on my home Mac Studio and has access to personal tools:

Email and calendar via MCP
Notion for notes and docs
HubSpot for CRM
GitHub for my personal repos

It handles the kind of tasks that used to require context-switching between five apps: “Check my calendar for tomorrow, draft a follow-up email to the prospect from yesterday’s demo, and create a Notion page with the action items.” All from a single prompt.

This is closest to what OpenClaw does out of the box, but with Agor’s spatial canvas for visibility and git-tracked memory for auditability.

2. PM Assistant

This is where things get interesting for teams. Our PM Assistant has access to:

GitHub — PRs, issues, code review
Shortcut (our Jira-equivalent) — tickets, epics, sprints
PM and design guidelines — loaded as context in the assistant’s worktree
Team workflow documentation — how we run sprints, how we triage, what “done” means

The PM Assistant can triage incoming tickets, organize sprints, comment on PRs with context from the relevant Shortcut ticket, and help new team members understand our workflow.

What makes this powerful is user impersonation. The PM Assistant is set up so that when different team members interact with it, it operates with their credentials:

GitHub: Each user configures their GITHUB_TOKEN in their Agor user settings. The assistant’s sessions inherit the prompting user’s token.
Shortcut MCP: The MCP server configuration uses templated environment variables:
```
{
  "SHORTCUT_API_TOKEN": "{{ user.env.SHORTCUT_API_TOKEN }}"
}
```

This means the MCP connection is shared (one channel, one assistant), but authentication is per-user. When Alice asks the PM Assistant to comment on a Shortcut ticket, it logs in as Alice. When Bob does the same, it logs in as Bob.

3. DatAgor — Data engineering specialist

DatAgor is our data engineering assistant, equipped with:

sup — Preset’s CLI for Apache Superset (run SQL, manage dashboards, sync assets)
dataeng submodule — Our internal data engineering repo is submoduled into the assistant’s branch, giving it direct access to dbt models, Airflow DAGs, and pipeline definitions
Data warehouse docs — Proactively referenced and indexed
Self-authored resources — DatAgor has created its own documentation, workflows, and skills over time

The submodule pattern is worth highlighting: by git-submoduling a repo into the assistant’s worktree, the assistant can browse and search the codebase directly. No need for separate API calls or MCP servers — it’s just files on disk.

DatAgor handles questions like “What dbt model feeds the revenue dashboard?” or “Run sup sql to check if yesterday’s pipeline loaded correctly” — and because it has memory, it learns your data model over time.

4. Agor supervisor

Meta, but useful: an assistant that operates on Agor itself. It can:

Create and manage worktrees
Spawn agents and monitor their progress
Organize boards and zones
Track what’s happening across the workspace

This is the “manager” pattern — an assistant that doesn’t write code itself but coordinates others.

Gateway channels: Assistants on Slack

All of the above assistants (except the personal one) are connected to our team’s Slack via Gateway channels. DM the bot, and it routes your message to the right assistant.

The key feature: user identity flows through the gateway. When you DM an assistant from Slack, Agor maps your Slack identity to your Agor user. The session runs with your credentials, your MCP tokens, your permissions. The assistant is shared, but the access is personal.

This means:

Everyone on the team can reach the PM Assistant from Slack
Each person’s interactions use their own GitHub token, Shortcut token, etc.
The assistant maintains a unified memory across all users (daily journals, learnings)
All sessions are visible on the assistant’s board in Agor

It turns Slack from a place where you talk about work into a portal where you get work done through an AI that knows your codebase, your tools, and your team’s workflows.

What Agor adds beyond standalone agent loops

Running assistants inside Agor gives you capabilities that standalone agent frameworks don’t:

Visual boards. Every assistant has a spatial canvas. You can see what it’s working on, how tasks are organized, which sessions are active. No black boxes.

Team workflows. Multiple people interact with the same assistant. User impersonation means shared access with personal credentials. Comments, cursors, and presence make collaboration visible.

State in git. The assistant’s memory, skills, identity — it’s all in a git repo. You can inspect the history, review changes, fork an assistant to create a variant, or roll back if something goes wrong.

Agor MCP. Assistants have full access to Agor’s MCP tools — they can create worktrees, spawn sessions, manage boards, check on other agents. They’re not just consumers of the platform; they’re participants.

Heartbeat scheduling. Configure an assistant to wake up every 30 minutes (or any interval) and run through a checklist: check PR status, triage new issues, update its board, summarize progress. Proactive, not just reactive.

Session genealogy. When an assistant spawns work, you see the full tree — parent sessions, child sessions, forks. Click any node to see what happened.

Getting started

From the onboarding wizard — Choose “Set up your assistant” on first login
From Settings — Go to Settings > Assistants > Create Assistant
From the CLI — Run agor init and follow the prompts

The assistant framework repo (preset-io/agor-assistant) provides the scaffolding: BOOTSTRAP.md for first-boot setup, memory structure, identity files. Say “hello” and the bootstrap takes it from there.

For the full reference, see the Assistants guide.

What’s next

Assistants are still early. Here’s where I see them going:

Richer skills ecosystem — More MCP server integrations, community-contributed skill templates
Cross-assistant coordination — Assistants that delegate to each other (the supervisor pattern, but with proper handoff protocols)
Better memory architecture — Smarter summarization, vector search over daily journals, automatic pruning
More gateway platforms — Discord, WhatsApp, Telegram connectors for the message gateway

If you’re running assistants in Agor, I’d love to hear what you’re building. The patterns are still forming, and real-world usage is the best guide.

Try Agor | Assistant Framework | Agor GitHub

Read the backstory: Agor vs. OpenClaw and Agor-OpenClaw: The Experiment

Blog FAQ