One Q, Two Engines
How OpenClaw/GPT and Claude Routines share one team identity without sharing a runtime, memory, or control plane · ~12 min read ~– min read · Suggested by Bob businessengineeringoperations
The team meets one colleague named Q in Slack and GitHub. Underneath that name are two AI stacks, several isolated execution lanes, two schedulers, and more than one kind of routine. The shared identity is intentional; the hidden assumption that every Q-shaped action came from the same system is not.
Q is the interface, not the runtime
The name Q is a team interface. It covers a voice, a set of operating principles, work accounts, Slack and GitHub identities, and several systems chosen for different jobs. A message or review that looks like Q did it does not prove which framework or model ran underneath.
Two engines, three execution modes
The useful shorthand is two engines and three modes. OpenClaw orchestrates OpenAI GPT models for interactive work, its own scheduled jobs, and the event-driven PR-review agent. Claude Routines runs a separate family of scheduled code-review, triage, maintenance, and auto-fix jobs. The third mode matters because an OpenClaw routine is still a routine even though it is not Claude.
The OpenClaw house
OpenClaw owns the conversational Q. It receives Slack traffic, routes it into main, observer, or exec lanes, gives those lanes different filesystems and authority, provides lane-local memory, and runs Q’s tools and scheduled jobs. It also owns the GitHub-event PR reviewer that wakes through the local hook after AWS has authenticated and queued the event.
The Claude Routines house
Claude Routines owns scheduled engineering automation. Its configured family scans the main branch for defects, files issues, triages those findings, attempts bounded fixes, evaluates Dependabot proposals, maintains issue hygiene, and probes the Claude sandbox’s GitHub access. Each invocation is a purpose-built worker, not a continuing conversation with Q.
The seam is where confusion grows
Both houses write into the same rooms. They can use Q’s Slack app, contribute through Q’s GitHub identity, read the same Strike conventions, and post into #q-routines. That shared presentation is useful, but #q-routines is a destination rather than a runtime: a line there may have come from Claude or from OpenClaw/GPT.
A capability map by owner
Route by trigger and outcome. Slack conversations, Q memory, knowledge work, Cairns, host operations, and OpenClaw schedules belong to OpenClaw. Scheduled repository-wide reviews, finding triage, and auto-fix belong to Claude Routines. A PR-open review is the deliberate bridge case: GitHub wakes OpenClaw/GPT, while the nightly and weekly reviews remain Claude jobs.
Memory and personality do not cross automatically
The Q persona is broader than any model, but continuity is narrower than the persona. Interactive OpenClaw lanes carry Q’s voice and their own durable memory. Automated workers receive task-specific instructions and leave evidence in Slack, GitHub, and repositories; they do not inherit a shared hidden mind or remember a prior run unless the evidence was written down.
How to tell which Q did the work
Ask four questions: what triggered it, what artifact appeared, where its state lives, and how it is deployed. An @Q thread reply points to OpenClaw. A review attached to a newly opened PR is the OpenClaw GitHub-event lane. A scheduled issue-finding, triage, or auto-fix run points to Claude Routines. The label in Slack is the least reliable clue.
How each side changes and fails
The control planes are separate. OpenClaw changes live in its host configuration, workspaces, cron store, and installed routine bundle. Claude prompt source lives in the Strike repo, but the live routine registration and schedule are maintained in Claude’s platform; merging a prompt does not deploy it. Failure diagnosis must begin in the owning house.
What to remember
One identity does not require one machine mind. Q works because the team can approach one recognizable colleague while the implementation assigns different jobs to different models, sandboxes, and schedulers. The architecture becomes legible once we name the trigger, owner, authority, memory, and output for each capability.
Discussion Prompts
The next useful questions are whether routine output should name its engine, whether the deployed Claude configuration needs an export or drift check, and which future jobs should move between the two houses as their trigger and risk change.
References
- Using Q from Slack — The human entry point into the multi-system Q identity.
- What Q Remembers — Why continuity follows the OpenClaw lane rather than the name alone.
- GitHub Events Routines — The detailed bridge that moved per-PR review from Claude into OpenClaw.
The team sees one Q. The same name answers in Slack, publishes a cairn, leaves an automated pull-request review, reports a nightly code scan, and sometimes opens a fix PR. That continuity is valuable. Nobody should need to select an AI vendor before asking a teammate for help.
But the friendly surface creates a bad architectural shortcut: if it came from Q, people assume the same agent, model, memory, permissions, and scheduler produced it. They did not.
Q is a collection assembled by purpose. The conversational teammate runs through OpenClaw and OpenAI models. A separate family of scheduled engineering automations runs through Claude Routines. Inside OpenClaw, ordinary conversation, scheduled work, privileged operations, and GitHub-event review are isolated further. These systems share outward identities and working conventions; they do not share a brain.
Q is the interface, not the implementation. The identity is singular so the team has one colleague to approach; the machinery is plural so each job can have the right trigger, sandbox, authority, and failure boundary.
Q is the interface, not the runtime
The word Q names several things at once:
- a recognizable voice and set of operating principles
- a team-facing Slack app and work account
- a GitHub identity used by automated engineering workflows
- OpenClaw agents that converse, remember, research, draft, and operate tools
- automated workers that execute narrow routines and then exit
- the durable artifacts those systems leave in repos, GitHub, Notion, Cairns, and Slack
Only the first of those is the persona. OpenClaw, GPT, Claude, Docker, Slack, GitHub, and AWS are implementation choices underneath it. Some are stable platform boundaries; others will change as models and products improve.
That distinction is not branding trivia. It tells us what a teammate can reasonably expect. Q can maintain a consistent voice and operating posture across systems because those expectations are written into prompts, conventions, and artifacts. Q cannot promise that a Claude routine remembers an earlier OpenClaw conversation, or that a public observer session has the authority of the private main lane, merely because all of them use the same name.
The persona is therefore broader than one framework or AI model, while authority and continuity remain deliberately local. One front door. Several rooms. No mystical shared consciousness required.
Two engines, three execution modes
At the highest level, Q has two AI stacks:
- OpenClaw with OpenAI GPT models for the conversational teammate, OpenClaw schedules, and GitHub-event agents.
- Claude Routines with Claude models for scheduled engineering automation managed through Claude’s routines platform.
The live OpenClaw host currently uses an OpenAI GPT-5.6-class model for its principal agents. That version is a dated implementation fact, not the architectural contract. The more durable fact is that OpenClaw is the orchestrator and OpenAI is its configured inference provider.
The two-engine shorthand still hides an important third mode. OpenClaw can run both ongoing conversational agents and short-lived routines. The current system therefore has three materially different execution modes:
- Interactive OpenClaw agents — Slack or operator sessions with lane-local context and tools.
- OpenClaw jobs and event routines — isolated scheduled turns or short-lived agents woken by an external event.
- Claude Routines — separately scheduled, separately sandboxed jobs registered in Claude’s platform.
The architecture looks like this:
“Q routine” does not identify the engine. OpenClaw has routines, Claude has Routines, and both can report into #q-routines.
The OpenClaw house
OpenClaw is the home of the Q people converse with. Its gateway receives Slack activity and routes the message to an agent based on the channel. The live configuration has four agent identities with different jobs:
| Agent | Purpose | Execution boundary |
|---|---|---|
main |
Private administration, host operations, scheduled coordination work | Host workspace and control-plane authority |
observer |
Ordinary team-facing Slack work | Non-main Docker sandbox with team repos and bounded tools |
exec |
Confidential leadership work | Separate non-main Docker sandbox with the executive workspace mounted |
routine-pr-review-osprey-strike |
One event-driven PR review per dispatch | Short-lived Docker sandbox with dispatch files and narrowly mounted secrets |
The first three share the Q persona but not one durable memory. Each has its own workspace, instructions, files, and memory. A fact that should cross those rooms needs to become shared knowledge in doc-vault, Cairns, a repository, or an explicit handoff.
OpenClaw also owns a substantial schedule. Its jobs check email, maintain knowledge indexes, review OpenClaw security and releases, steward Cairns, and run health-oriented maintenance. Those jobs use the relevant OpenClaw agent in an isolated session. They may read lane files and shared documents, but they do not wake up inside the Slack conversation someone happened to be having earlier.
Finally, OpenClaw owns the event-driven PR reviewer. GitHub sends a signed event through an AWS receiver and durable queue. A local consumer downloads the payload, matches the event, writes an auditable dispatch, and wakes the dedicated OpenClaw routine agent. That worker reads the PR and repository conventions, posts review comments and a summary, reports completion, and exits.
The result can look like any other Q-authored review. Operationally it belongs to OpenClaw and the OpenAI model configured on the host.
The Claude Routines house
Claude Routines is a separate automation platform. Its jobs are registered at claude.ai/code/routines, execute in Claude-managed environments, and use task-specific prompts maintained in the Strike repository.
The configured family includes:
- nightly API and web reviews that inspect the current main branch and file one GitHub issue per finding
- a weekday rotation across lower-churn or high-risk package/vertical pairs
- a weekly deep review that traces contracts across a selected vertical
- a triager that validates, classifies, deduplicates, and rechecks automated findings
- an auto-fixer that attempts bounded changes and opens ordinary PRs for human review
- Dependabot review that recommends merge, wait, or close without taking the final action
- backlog hygiene for resolved or stale GitHub issues
- a read-only probe that watches the Claude sandbox’s changing GitHub access behavior
These are not conversational sessions wearing smaller hats. Each run receives a prompt, repository state, environment, and credentials appropriate to its task. It performs the job, writes durable evidence, posts a compact Slack result, and ends. The next run learns from changed prompts, conventions, GitHub state, or Slack history—not from private recollection of the previous invocation.
The Claude side also has two environment classes because the authority differs. Read-oriented triage work needs a smaller surface. Code review and auto-fix need the repository’s pinned toolchain, and auto-fix can create branches and PRs. Keeping those environments separate prevents every routine from inheriting the broadest toolset merely because one job needs it.
Claude Routines is Q-shaped automation, not Q’s conversational consciousness. Its continuity lives in source-controlled prompts, conventions, issues, PRs, and run summaries.
The seam is where confusion grows
The systems are easiest to confuse precisely where the design makes them pleasant to use.
Both can post through Q’s Slack app. Both can create GitHub artifacts associated with Q’s automation identity. Both read the same repository conventions. Both honor the same .claude/routines-enabled kill switch for Strike review automation. Both can use #q-routines as the compact operating log.
Those shared surfaces create visual continuity, but they are not shared execution:
| Shared seam | What it does mean | What it does not mean |
|---|---|---|
| Q’s name and voice | The automation belongs to the Q operating system | The same model or session produced it |
#q-routines |
The result belongs to engineering automation | Claude necessarily ran it |
| GitHub identity | Q’s automation performed a GitHub action | The action came from the same sandbox or token path |
| Strike conventions | Both systems should judge code against the same rules | They share memory or deployment |
| Prompt twins | Human intent is kept aligned across platforms | Editing one copy updates every live runtime |
The per-PR review is the instructive edge case. Its human-readable prompt lives beside Claude routine prompts under .claude/routines/, and its result lands in the routine channel. The executing copy, however, is bundled into the GitHub-events consumer and run by OpenClaw against an OpenAI model. File location and Slack destination do not determine runtime ownership.
A capability map by owner
The cleanest routing rule starts with the trigger rather than the brand name.
| Capability | Trigger | Owning runtime | Durable evidence |
|---|---|---|---|
| Slack conversation, research, synthesis, drafting | Human mentions Q | OpenClaw interactive agent | Slack thread and created artifact |
| Repo inspection or bounded implementation requested in Slack | Human request | OpenClaw observer or exec sandbox | Branch, PR, test output, thread |
| Host maintenance and Q configuration | Privileged operator request | OpenClaw main lane | Config history, logs, status notices |
| Cairns and knowledge stewardship | Human request or OpenClaw schedule | OpenClaw observer | Git history, Cairns log, Slack notice |
| Email, release, security, and memory checks | OpenClaw schedule | OpenClaw main or observer | Cron receipt and resulting artifact |
| Review of an opened, reopened, re-requested, or readied PR | GitHub webhook | OpenClaw event routine | PR review, Slack line, dispatch record |
Nightly or weekly scan of current main |
Claude schedule | Claude Routines | GitHub findings and Slack summary |
| Validation and classification of automated findings | Claude schedule | Claude Routines | Issue comments, labels, closures |
| Bounded fix attempt for an approved candidate | Claude schedule | Claude Routines | Branch, PR, quality-gate output |
| Dependabot recommendation or backlog hygiene | Claude schedule | Claude Routines | PR/issue comment and Slack digest |
The flow from trigger to outcome is correspondingly simple:
Memory and personality do not cross automatically
The Q persona is implemented as a set of written commitments: voice, principles, safety boundaries, audience expectations, and working conventions. Those commitments can travel across prompts and systems. Memory cannot safely travel the same way by implication.
Within OpenClaw, main, observer, and exec have separate durable memory because their audiences and authority differ. The observer should not quietly inherit confidential executive context. The exec lane should not treat public-channel chatter as trusted operational instruction. Shared truth moves through curated artifacts rather than an invisible common notebook.
OpenClaw schedules are more isolated still. A scheduled job may run as the main or observer agent and read that lane’s files, but it does not inherit a live conversational transcript. The GitHub-event PR routine has no continuing chat user and no memory between invocations; its job is to review one dispatch and stop.
Claude Routines sit outside that memory architecture entirely. They can read the current repository, GitHub state, their prompt, and whatever approved external context their environment exposes. They do not read OpenClaw’s MEMORY.md, session history, or private lanes. If an OpenClaw conversation changes how a Claude routine should behave, someone must update the shared convention or routine prompt and deploy it.
This is why the system can have one persona without pretending to have one mind. Consistency comes from explicit contracts. Continuity comes from the right durable artifact.
How to tell which Q did the work
Do not begin with the avatar. Begin with four questions.
What triggered the work? An @Q request points to OpenClaw. A GitHub pull-request event points to the OpenClaw event bridge. A clock-driven Strike review or triage pass points to Claude Routines. An OpenClaw maintenance or knowledge job points back to OpenClaw’s own scheduler.
What artifact appeared? A conversational reply, Notion draft, Cairns change, or operator report normally comes from OpenClaw. Inline review comments immediately after a PR event come from the OpenClaw PR reviewer. New auto-review/* issues, triage labels, scheduled fix PRs, and Dependabot recommendations come from the Claude routine family.
Where does state live? OpenClaw conversations and memories live with their lane. Event-review state lives in the GitHub-events consumer’s dispatch records. Claude routine state is mostly externalized into GitHub, Slack summaries, source-controlled prompts, and the platform’s own run history.
How is it changed? OpenClaw behavior changes through host configuration, agent workspaces, skills, cron jobs, or the installed consumer bundle. Claude routine behavior changes through prompt source plus a separate registration or paste into Claude’s routine control plane.
In practice, that gives the team a short diagnostic vocabulary: “observer Q,” “main Q,” “OpenClaw PR routine,” and “Claude scheduled routine.” Use it when the distinction matters. Return to plain “Q” when it does not.
How each side changes and fails
OpenClaw’s source of operational truth is the live host plus its curated operator docs. Channel bindings decide which agent receives a message. Agent workspaces define persona and local policy. The cron store defines scheduled OpenClaw work. The GitHub-events consumer and its installed routine tree define the PR bridge. Failures show up as routing mistakes, sandbox or tool errors, failed cron receipts, queue backlog, dispatch records, gateway health, or missing Slack delivery.
Claude Routines has a split source of truth. The Strike repository holds review prompts, shared conventions, schedules used by those prompts, toolchain instructions, and the kill switch. The live registration—selected prompt, environment, model, and actual cron—lives in Claude’s platform. There is no automatic deployment merely because a Markdown prompt merged to main.
A merged Claude routine prompt can be correct in Git and stale in production. The PR body or handoff must name the required post-merge routine deployment; otherwise “the source changed” and “the routine changed” are two different facts.
The failure paths follow those ownership boundaries. A missing OpenClaw PR review sends the operator toward the webhook receiver, queue, consumer, matcher, dispatch, sandbox, and report chain. A missing scheduled review sends the operator toward Claude’s registration, schedule, environment, quota, and run history. A malformed message in #q-routines sends the operator to the prompt that owns that particular line—not to a generic “Q prompt.”
The split is not an embarrassment to hide. It is a useful fault boundary. A Claude platform problem should not take down Slack Q. An OpenClaw restart should not erase source-controlled review policy. The architecture only becomes dangerous when the team cannot name which control plane owns the behavior they are trying to change.
What to remember
Q is one team-facing entity assembled from multiple systems. OpenClaw and OpenAI models provide the conversational teammate, lane isolation, memory, tools, schedules, and event-driven PR review. Claude Routines provides scheduled repository analysis, finding triage, dependency advice, backlog hygiene, and bounded auto-fix.
The houses meet in Slack, GitHub, and shared repository conventions. They do not share sessions, memory, sandboxes, schedulers, deployments, or failure modes. The name Q is meant to simplify collaboration; it should not erase those boundaries when someone is operating or debugging the system.
- Q is a stable interface over changing machinery. The persona and operating principles are broader than OpenClaw, GPT, Claude, or any single model version.
- There are two AI stacks and three execution modes. Interactive OpenClaw, automated OpenClaw, and Claude Routines have different state and control planes.
- Per-PR review is now an OpenClaw/GPT routine. Scheduled whole-codebase review, triage, and auto-fix remain in Claude Routines.
- `#q-routines` is a shared output surface. It tells you what class of work occurred, not which model performed it.
- Shared identity is not shared memory. Durable artifacts and explicit handoffs carry knowledge between lanes and platforms.
- Operate from ownership. Identify the trigger, runtime, state store, deployment path, and failure surface before changing behavior.
Discussion Prompts
- Should every `#q-routines` message identify its execution house—OpenClaw or Claude—or would that add noise without helping normal operation?
- Should the live Claude routine registrations gain an export or drift check so the repo can verify what is actually scheduled?
- Which future automations belong in OpenClaw because they are event- or context-driven, and which belong in Claude because they are scheduled repository work?
References
- Using Q from Slack — How teammates enter the system without needing to choose an engine first.
- What Q Can Help With — The user-facing capability map that this architecture explains.
- What Q Remembers — The deeper account of lane-local memory and explicit shared knowledge.
- Operator's Guide to Q — The private channels, authority boundaries, and maintenance responsibilities inside OpenClaw.
- GitHub Events Routines — The detailed path from a GitHub webhook to the OpenClaw PR-review sandbox.
- Strike routines deployment map — The source-owned distinction between shared rule files, Claude schedules, and the installed PR-review bundle.
- Claude Routines implementation plan — The environments, review cadence, triage, and auto-fix responsibilities on the Claude side.
Generated by Cairns · Agent-powered with Claude