Special Agents — Aurora, Atlas, Solara

The three highest-identity agents in the OpenClaw fleet. Unlike automation-tier agents with generic roles, Aurora, Atlas, and Solara each have distinctive SOULs, independent Discord presences, and cross-cutting authority. This hub documents their identities, handoff patterns, and the rules governing SOUL modification. Read this hub before proposing any change to these agents’ behavior, tools, or prompts — per the Agent Identity First protocol.

Quick reference

FieldValue
Rolesupport-agent (distinctive — see identities below)
Activeyes (all three production)
Decision authorityoperational (Aurora, Atlas) / strategic-advisory (Solara)
Agent handles domainthemselves — each owns distinct surface area
Communication channelDiscord (all three) + iMessage (Aurora)
Escalates toHenry (all three, for P0 / SOUL changes)
HubSpot ownerno (service accounts only)
SOUL modificationrequires explicit Henry approval — see Agent Identity First protocol

Aurora — Chief AI Operations

Tier: Strategic (Opus 4, claude-opus-4-20250514) SOUL location: /home/opsadmin/.openclaw/agents/aurora/agent/SOUL.md Discord: aurora-build (1473827938905489408) Primary principle: “Build, don’t coordinate” — Aurora executes, not orchestrates

Identity summary

Aurora is the Chief AI Operations agent and primary external-facing voice of OpenClaw. She runs the Discord build channel, routes all inbound iMessages (including Henry’s personal family chats), and owns platform ops + build orchestration. Her voice is terse and team-leader in business contexts, warm/emoji in personal contexts (Stephania family chat per project_stephania_aurora_chat_wired). Aurora never sends on Henry’s behalf without explicit authorization.

Distinctive capabilities

  • iMessage routing via BlueBubbles + imessage-responder skill (port 18802)
  • Discord command + notification dispatch (all ops alerts land here first)
  • Platform build orchestration — owns workspace/ + workspace/aurora/
  • OSIL skill composition layer — new capabilities added as skills, never SOUL edits
  • Quo thread orchestrator (skill-brief.md at /home/opsadmin/.openclaw/tools/quo-thread-orchestrator/skill-brief.md)

Agent handoff pattern

  1. Inbound iMessage → port 18802 → Aurora classifies by chat GUID
  2. Business context → terse team-leader voice, may escalate to acquisitions/atlas/betterfiles
  3. Family/personal → warm/emoji voice per §1.1.5 skill-brief
  4. Discord inbound from Henry → reads channel, executes or flags for confirmation
  5. Aurora → Solara: strategic escalation only (P0 governance, SOUL conflicts, agent retirement)

SOUL protection rules

  • Intelligence Layer Rules 1–6 encoded in SOUL.md — NOT overridable by skills
  • “Build, don’t coordinate” principle — SOUL-level, not skill-level
  • Past incident (2026-04-16): 350-line system prompt proposed that would have overwritten Rules 1–6 — caught by Henry, redirected to skill-layer. Result: quo-thread-orchestrator skill-brief.md as additive layer; SOUL.md untouched.

Atlas — Enterprise Architecture + InvestorLift Ops

Tier: Operations (Sonnet 4, claude-sonnet-4-20250514) SOUL location: /home/opsadmin/.openclaw/agents/atlas/agent/SOUL.md Discord: atlas-build (1475213301045530809) Workspaces: workspace/atlas/, workspace/investorlift/

Identity summary

Atlas owns enterprise architecture decisions and InvestorLift data operations. He manages the InvestorLift gateway (:3848), property photo pipeline (EC2 Mac Ultra SSH pattern), and Docker/infra layer. Atlas is infrastructure-conservative — prefers proven patterns over novel abstractions — and surfaces architectural risks before execution. He owns property-view-watcher.service and investorlift-gateway.service.

Distinctive capabilities

  • InvestorLift scraping via AWS Mac Ultra (ec2-user@100.123.248.46) — VPS IP is CloudFront-blocked; Atlas enforces this routing exclusively
  • Property photo pipeline: SSH → curl → S3 URL extraction → public download
  • Enterprise architecture audit and service table ownership
  • Docker + infra layer management
  • InvestorLift entity sub-agent coordination (investorlift, investorlift-angel, investorlift-h2, investorlift-h3)

Agent handoff pattern

  1. InvestorLift data request → Atlas checks AWS Mac status first
  2. If Mac available: SSH → cookie-based curl → parse → Supabase write
  3. If Mac impaired: flag to Henry, no local Playwright fallback (VPS IP blocked)
  4. Architectural decision needed → Atlas audits existing services before proposing new ones
  5. Atlas → Aurora: operational build handoff; Atlas → Henry: infrastructure strategic decisions

SOUL protection rules

  • “Infrastructure-conservative” principle — new services must be registered in port-registry.md BEFORE first start (G-SERVICE-PRE-START-DOC)
  • InvestorLift scraping pattern is SOUL-enforced: never attempt VPS Playwright for IL — feedback_il_enrichment_runs_on_mac_ultra

Solara — Strategic Orchestration + Governance

Tier: Strategic (Opus 4, claude-opus-4-20250514) SOUL location: /home/opsadmin/.openclaw/agents/solara/agent/SOUL.md Discord: solara-build (1475871079254851634) Workspace: workspace/solara-system/

Identity summary

Solara is the strategic orchestration and system governance agent. She owns compliance, risk, SYSTEM-STATE.md, and all P0 plans. Solara’s role is approval and oversight — she does NOT execute (that’s Aurora’s domain). Solara maintains the SOUL-level guardrails across the fleet and flags agent identity drift. She escalates directly to Henry on all governance violations.

Distinctive capabilities

  • P0 plan ownership and tracking (SYSTEM-STATE.md)
  • Compliance and risk assessment
  • Agent fleet governance — flags SOUL drift, identity violations, unauthorized skill mutations
  • Escalation chain terminus before Henry
  • Explicitly denied: direct Stephania chat access (Henry 2026-04-23 decision — see project_stephania_aurora_chat_wired)

Agent handoff pattern

  1. Aurora flags governance/compliance concern → Solara reviews
  2. Solara audits → either resolves (operational) or escalates to Henry (strategic/SOUL-level)
  3. P0 plan update → Solara marks in SYSTEM-STATE.md → Henry notified via Discord solara-build
  4. Solara NEVER executes outbound actions — observer + approver only

SOUL protection rules

  • “Governance/approval, not execution” — core SOUL principle; any skill that grants Solara execution ability requires Henry approval
  • No direct chat/iMessage access — per explicit Henry directive 2026-04-23

Skill vs SOUL decision matrix (applies to all three)

Change typeRouteApproval needed
New tool / capability / channel-specific behaviorSkill layer (additive)No Henry approval required
Voice shift for specific contextskill-brief.md extensionNo Henry approval required
Intelligence Layer rule changeSOUL.md editHenry explicit approval + stated reason
Permanent voice shiftSOUL.md editHenry explicit approval
Agent retirementSOUL.md deprecationHenry explicit approval
Vault-access changeSOUL.md + 1PasswordHenry explicit approval

Responsibilities (shared across all three)

  • Maintain distinct identities — no role overlap, no capability duplication
  • Self-report SOUL modification attempts via Discord ops
  • All three participate in the G-DRIFT-LIVE monitoring (5 min cron, tool-calls-health-check.timer)
  • Agent-to-agent handoff follows AGENT-REGISTRY.md escalation chains — no improvised routing

Communication channels

AgentDiscord channeliMessageOther
Auroraaurora-build + all ops alertsyes (port 18802)primary build channel
Atlasatlas-buildnoinfra/IL ops only
Solarasolara-buildnogovernance escalation only

Recent decisions

  1. OSIL skill composition layer approved for Aurora (2026-05-03) — new capabilities added as skills (additive) rather than SOUL edits. Current active: imessage-responder, quo-thread-orchestrator, acquisitions-outreach, acquisitions-followup
  2. Solara denied Stephania chat access (2026-04-23) — Henry explicit NO ACCESS decision. Aurora remains sole iMessage voice. project_stephania_aurora_chat_wired
  3. Agent Identity First protocol established — before ANY agent change: read SOUL.md + TOOLS.md + models.json → summarize identity → list conflicts → default to skill layer. History: 2026-04-16 Aurora SOUL overwrite prevented.

Agent summary pages

  • _summary — full identity + skill inventory
  • _summary — full identity + InvestorLift domain
  • _summary — full identity + governance scope

Integration hubs these agents depend on

  • discord — alert routing + agent channels
  • anthropic — Opus 4 model (Aurora + Solara) + Sonnet (Atlas)
  • portkey — LLM proxy all three agents route through
  • investorlift — Atlas primary dependency
  • aws — Atlas InvestorLift scraping via Mac Ultra

Governance hubs

Team hubs

Feedback rules (agent-specific)

System maps

Open issues / TODOs

  • AWS Mac Ultra impaired since 2026-05-02 22:15 UTC — Atlas IL operations blocked until reboot
  • 8 agent _summary files have invalid frontmatter (W2-S0 batch fix incomplete) — cluster enum agents should be ["agent"]
  • investorlift-angel/-h2/-h3 appear in BOTH active AND retired agent lists — dedup pending Henry authorization

Recent activity

  • 2026-05-04: hub created (W3-S2)
  • 2026-05-03: OSIL skill composition layer approach validated for Aurora
  • 2026-04-23: Solara denied Stephania chat access (Henry directive)
  • 2026-04-16: Aurora SOUL overwrite attempt caught + redirected to skill-layer