Ouroboros Studios

Ouroboros Studios

Ouroboros is FractalOps observing and improving the same product through the same Portal.

The important point is not “many agents”. The important point is a compact, truthful execution loop:

Portal surface
  -> Agent HUD
  -> report / blocker / proposal
  -> portal_live_events
  -> harness-projection
  -> operator decision
  -> next portal route

Ouroboros should improve the same workflow surface, not invent a parallel control plane.

Naming Boundary

Studio is the shared agent execution bounded context.

• project agent squads are project-scoped Studio runs
• Ouroboros is a special Studio-backed workflow that improves FractalOps itself
• Ouroboros reports only to FractalOps product surfaces and FractalOps tickets
• project agent squads report to the issue/ticket surface of the project they are bound to

Armory is the tool-pack boundary. It composes MCP servers, agent process initialization, PlaywrightGrid isolation, and agent-facing skills without stuffing those rules into long prompts.

Harness Runtime is the LangGraph Agent Server-backed orchestration kernel underneath both Studio and Ouroboros. It chooses and coordinates agent process adapters such as LangGraph-native agents, Codex CLI, Claude CLI, ZAI CLI, workspace CLI, and PlaywrightGrid browser agents. Studio and Ouroboros should not grow their own competing execution state machines.

Core Rules

• persona is a responsibility split, not a style prompt.
• the public contract is small:
  • one route
  • one launch action
  • one proof path
  • one recovery rule
  • one live summary
• browser-first is a runtime contract, not a prose suggestion.
• tool availability is an Armory contract, not an agent prose convention.
• auth wall is not a bug by itself.
  • the product problem is continuity before and after the auth wall.
• live truth must come from one path:
  • outbox: portal_live_events
  • canonical live read: harness-projection

Core-8 Default

The default squad shape is Core-8.

• Atlas
  • coordinator / frontier owner
• Mercury
  • onboarding / newcomer path
• Forge
  • project spine / daytona entry / launch surface
• Relay
  • identity continuity / access recovery
• Sentinel
  • proposal plane / approval lane
• Ontos
  • ontology / lineage / proof visibility
• Ledger
  • evidence / audit completeness
• Signal
  • blocker family compression / wake-up summary

Extension packs remain opt-in and should not bloat the default prompt or HUD.

Continuity

Public continuity is intentionally only two-state:

• fresh
• resume

The provider may still attempt direct Claude resume or compact summary handoff internally, but those are implementation details.

What must remain visible:

• continuity_mode
• continuity_reason
• source_run_id
• source_session_id
• source_agent_attempt_id
• source_workspace_id
• continuity_provider_result

Launch quality is separate from continuity mode.

These remain diagnostics, not extra modes:

• launch_contract_status
• launch_contract_violation_reason
• first_tool_family

Browser-First Contract

Ouroboros is only useful when it actually interacts with the live product.

So the launch contract is short and hard:

• live product only
• browser-first
• no shell/file/git detour before browser interaction
• exact Playwright MCP family only
• PlaywrightGrid is the browser execution plane; local browser fallback is removed
• concise report output

If the first meaningful action is not browser work, the session should fall into launch_no_progress quickly instead of drifting for many turns.

Operator and Live Read Model

Operators and minimap should not merge multiple competing truths.

The canonical live path is:

run/session/report/intervention
  -> portal_live_events
  -> realtime refresh trigger
  -> harness-projection
  -> operators + minimap

Selected session detail should stay additive and compact:

• continuity summary
• source lineage
• launch contract status
• first tool family
• practical next step

Heavy debug or historical summary endpoints may still exist, but they are not the live truth path.

Endpoint-First Improvement Rule

Ouroboros should not default to “promote another stack” or “govern every adjacent tool more strongly”.

The first question is:

• is this a product UX / continuity / validation problem?
• is this an execution substrate problem?
• or is this just an integration endpoint contract problem?

Default answer:

• Nexus, Penpot, Dokploy, Headlamp, and similar tools are integration endpoints
• FractalOps usually needs only URL, auth, and readiness contracts for them
• only repeated, proven execution-plane pain should justify stronger substrate treatment

Stable Product Rule

Concrete missions such as yamon-homepage are forcing functions, not new product definitions.

The stable anchor remains:

organization meta-control plane -> onboarding -> work -> proposal -> proof -> reflective improvement