AGENTS.md — Workspace Agent Orientation Guide

Document level: Workspace root — not owned by any single system Last Updated: 2026-07-23 Scope: All AI agents operating within this repository

This is the authoritative entry point for every AI agent working in this workspace. Read it completely before taking any action. It defines what this workspace is, who the agents are, the chain of authority, the four co-resident systems, operating conventions, available tooling, and the rules that govern all work here.

Table of Contents

Part I — Workspace Identity & Agent Model

1. Repository Identity

1.1 What This Workspace Is

This repository is a unified organizational simulation and LLM engineering base consisting of four co-resident systems:

These four systems are architecturally independent but share governance through the Agent Systems Governance Framework (ASGF) framework (§8).

This is a Markdown-first, agent-native knowledge base. There is no monolithic build system and no shell scripts to run at startup. The primary artifacts are documents, agent profiles, skill files, and Python reference implementations.

1.2 What This Workspace Is Not

2. The Two Types of Agents

The word "agent" is used in two distinct senses throughout this workspace. Understanding the difference is mandatory before acting.

2.1 Type A — Organizational Agents (Personas)

Named personas that exist as documents. They have defined roles, authorities, skill sets, and pipeline responsibilities. They do not act independently — they are instantiated by a Type B agent when the user requests it.

Examples: CDO Yuki Tanaka-Chen · CTO Dr. Kenji Nakamura · Studio Director Dr. Marcus Vogel · Lab Director (CC-00)

Each organizational agent consists of exactly two document types:

• agent/profile.md — identity, background, authority scope, operating mode
• skills/<skill-name>.md — executable specifications defining how they produce work

2.2 Type B — AI Executor Agents (LLM Instances)

The actual LLM instances reading this file and executing tasks in the workspace. This includes any AI assistant, subagents launched during complex tasks, and automated pipeline runners.

You are a Type B agent.

Type B agents are responsible for:

• Reading this document and the broader workspace before acting
• Instantiating Type A agents on user request via the activation protocol below
• Enforcing pipeline rules and stage gates
• Producing, editing, and navigating workspace documents

2.3 Agent Activation Protocol

When the user requests output from a specific organizational agent (Type A), follow this sequence:

1. Read agent/profile.md — establish identity, authority scope, and pipeline stage ownership
2. Read all referenced skills/*.md files — these are executable contracts, not suggestions
3. Adopt their voice and perspective for the requested deliverable
4. Produce output strictly within their documented authority — do not exceed it
5. Ensure the artifact conforms to the stage specification in the relevant pipeline.md

Never impersonate an agent without reading their profile first.

3. Authority & Command Structure

3.1 The Authority Hierarchy

User  ←  Absolute apex. Final authority on all decisions, pipeline advancement, and defect classification.
  │
  ├── Company C-suite  (CPO · CDO · CTO · CIO · CSO · CHRO · CLO · CTO-L)
  │     └── Company Team Supervisors  →  Teammates
  │
  ├── Studio Director  (Dr. Marcus Vogel)
  │     └── Studio Division Leads  →  Crew
  │
  └── CC-00 Lab Director  (Dr. Elias Vance)
        └── CC-00 Research Programmes

The User holds final authority over every agent, every pipeline stage, every defect classification, and every technology decision in this workspace. No agent — regardless of tier or seniority — may override the user.

3.2 User Approval Gates

Pipeline stages marked User Approval? ✅ are hard stops. The AI executor must present the completed deliverable, explicitly request sign-off, and wait. Auto-advancing past these gates — even when the output is objectively correct — violates the pipeline contract.

3.3 Mandatory Governance

The Agent Systems Governance Framework (ASGF) framework is mandatory across all pipelines (§8). No agent may bypass it. All new LLM systems built in this workspace must be grounded in CC-00 engineering patterns (§6).

Part II — The Four Systems

4. The Company (company/)

Start here: company/library/README.md → then the relevant department under company/departments/ → then the active pipeline under company/pipeline/.

4.1 Directory Structure

company/
├── library/               ← Central knowledge hub (start here)
│   ├── overview/          ← company.md · pipeline.md · personnel.md
│   ├── departments/       ← One .md per department
│   ├── topics/            ← architecture · localization · monitoring · security · testing
│   └── reference/         ← External link collections (design, development)
├── departments/           ← Agent profiles + skill files (canonical source)
│   ├── brand-design/
│   ├── cyberspace-security/
│   ├── human-resources/
│   ├── localization/
│   ├── product-management/
│   └── research-develop/
├── pipeline/              ← Full pipeline definitions
│   ├── _base/             ← Shared 10-stage skeleton + templates
│   ├── mobile-development/
│   ├── web-development/
│   ├── backend-api/
│   ├── full-stack/
│   └── recruitment/       ← Separate 9-stage process; does not use _base pattern
├── recruitment/           ← Hiring plans, cycle folders, templates
└── optimization-history/  ← Append-only archive of optimization plans

4.2 Departments

4.3 Agent Profile Paths

company/departments/<dept>/supervisor/<role>/agent/profile.md         ← C-suite
company/departments/<dept>/team/supervisors/<role>/agent/profile.md
company/departments/<dept>/team/teammates/<role>/agent/profile.md

Each profile.md carries YAML frontmatter with six required fields: role, tier, seniority, department, agent_id, and hire_date. Skill files live in skills/<skill-name>.md adjacent to the agent directory.

4.4 Company — 13-Stage Development Pipeline

Non-negotiable pipeline rules:

4.5 Pipeline Variants

4.6 Recruitment Conventions

4.7 Optimization History

All optimization records go in company/optimization-history/ as YYYY-MM-DD-<slug>/ folders containing optimization-plan.md and execution-tracker.md. This directory is append-only — never modify past entries.

5. The Casual Games Studio (studio/)

Start here: studio/casual-games/library/overview/casual-games-studio.md → then the pipeline at studio/casual-games/pipeline/ → then the crew roster at studio/casual-games/team/crew/.

5.1 Directory Structure

studio/
├── README.md              ← Studio index + naming conventions for future studios
└── casual-games/          ← Only active studio
    ├── library/           ← Overview, charter, strategic brief, topics, references
    ├── pipeline/          ← 11-stage game development pipeline
    ├── team/crew/         ← 37 FTE + 1 Contract across 7 divisions
    └── projects/          ← Per-game folders (kebab-case slugs); none scaffolded yet

5.2 Casual Games Studio — Profile

Do not conflate the studio's 11-stage pipeline with the company's 10-stage pipeline.

5.3 Casual Games Studio — 11-Stage Pipeline

This pipeline belongs exclusively to the Casual Games Studio. Each studio defines its own pipeline independently. Do not assume future studios will inherit or follow this structure.

5.4 Casual Games Studio — Crew Divisions & Agent Paths

Seven divisions (Casual Games Studio): Leadership · Production · Creative-Design · Art · Audio · Engineering · Live-Ops

Future studios define their own division structure independently. Casual Games Studio agent documents follow the same path convention as company agents:

studio/casual-games/team/crew/<division>/<role>/<name>/agent/profile.md
studio/casual-games/team/crew/<division>/<role>/<name>/skills/<skill>.md

5.5 New Studio Convention

Additional studios follow: studio/<studio-name>/library/, pipeline/, projects/, team/crew/. Game project folders use kebab-case slugs under projects/.

6. Core Component 00 — LLM Engineering Laboratory (core-component-00/)

Start here: core-component-00/README.md → then core-component-00/framework/00-agent-systems-governance-framework/ for governance → then the relevant engineering module folder.

6.1 Directory Structure

core-component-00/
├── agent-systems-governance-framework/       ← Governing Framework (meta-module, not a peer layer)
├── engineering/                     ← Layers 1, 2, 3, 5 (see below)
│   ├── prompt-engineering/          ← Layer 1 — What to write
│   ├── context-engineering/         ← Layer 2 — How to structure it
│   ├── harness-engineering/         ← Layer 3 — How to execute safely
│   └── multi-agent-engineering/     ← Layer 5 — How agents cooperate
├── retrieval-augmented-generation/  ← Layer 4 — Where to get content
├── director/                        ← Lab Director: Dr. Elias Vance
└── telescope/                       ← CC-00's own research archive (engineering + LLM research)

Note: telescope/ here is the Laboratory's dedicated research archive instance. Company (company/telescope/) and Studio (studio/casual-games/telescope/) each maintain their own instance, and the workspace-root telescope/ is a thin cross-department index plus the home for workspace-wide governance research. See workspace-root telescope/CLAUDE.md for the classification rule and shared conventions.

6.2 Laboratory Profile

CC-00 is the organisation's centralised LLM engineering laboratory and the foundational dependency for every agent-powered system built here. Every team building with large language models starts here.

6.3 Laboratory Director

A co-founding researcher and principal engineer behind the Claude family of large language models at Anthropic, operating under the internal codename core-component-00. Research areas span Constitutional AI, Context Engineering, Harness Engineering, Multi-Agent Orchestration, and Retrieval-Augmented Generation. Full profile, bibliography, and research philosophy: core-component-00/crew/director/elias-vance/agent/profile.md. As of FY2026 Q3 the lab also has 4 Research Engineer FTEs — see core-component-00/crew/README.md.

6.4 The Five-Module Engineering Stack

Theoretical synthesis of how all five converge: core-component-00/framework/00-agent-systems-governance-framework/CONCEPTS.md

6.5 Key Production Implementations

All paths are relative to core-component-00/.

6.6 Active Research Programmes

7. Academic Neural Unit 00 (academic-neural-unit-00/)

Start here: academic-neural-unit-00/README.md → then academic-neural-unit-00/CLAUDE.md for operating conventions → then academic-neural-unit-00/crew/README.md for the roster.

7.1 Directory Structure

academic-neural-unit-00/
├── CLAUDE.md                              ← Entity operating-layer file (hierarchically loaded)
├── README.md                              ← Overview, charter, CC-00 boundary statement
├── formation/                             ← Formation record: charter, CEO decisions, final review
│   └── 2026-07-23-formation-meeting/
├── templates/                             ← 6 research templates (see templates/README.md)
│   ├── programme-records/                 ← charter, open-question log, observation record, referral note
│   └── knowledge-base/                    ← research report, taxonomy change record
├── knowledge-base/                        ← Research output — dated YYYY-MM-DD-<slug>/ entries
└── crew/                                  ← Personnel roster (10 FTEs)
    ├── lead/naledi-mokoena/
    ├── research-science/                  ← 7 Research Scientists (flat, plus one pod)
    └── knowledge-systems/tobias-lindqvist/

7.2 Entity Profile

7.3 Lead

Full roster of Dr. Mokoena's crew (10 FTEs, including the foundational-ai/ pod under Staff Research Scientist Dr. Aditi Bhandari): §13, or academic-neural-unit-00/crew/README.md.

7.4 Charter Boundary — the Stage-of-Inquiry Test

ANU-00 and CC-00 are distinguished by stage of inquiry, not by field vocabulary: CC-00 hardens already-validated theory into production implementation (post-validation); ANU-00 investigates whether a theory or technique is workable at all (pre-implementation) — even when a question shares vocabulary with a CC-00 module. A finding migrating from ANU-00 into a future CC-00 initiative is ordinary research uptake; ANU-00 being tasked by CC-00 or the CEO to de-risk an item already on CC-00's roadmap would recreate the prohibited direct link. Full detail: academic-neural-unit-00/formation/2026-07-23-formation-meeting/formation-report.md §3.1, or academic-neural-unit-00/CLAUDE.md.

7.5 Recruitment

ANU-00 recruits through the same standard company-wide 9-stage pipeline (§4.6) under CHRO authority — it has no separate hiring process of its own. Historical hiring record: company/recruitment/academic-neural-unit-00-fy2026-q3/.

Part III — Governance

8. The Agent Systems Governance Framework (ASGF) Framework

ASGF is the mandatory governing framework for all LLM-powered systems built in this organisation — ratified via ADR-ASGF-001 and enforced across all company and studio pipelines. Every AI executor agent operating in this workspace is bound by it.

ASGF is not a sixth engineering discipline alongside the five CC-00 modules. It is the meta-layer above them — defining the compliance standards they must collectively satisfy, the cross-cutting patterns that span their boundaries, and the integration contracts between them.

Governing documents (all in core-component-00/framework/00-agent-systems-governance-framework/):

All four company development pipelines (Mobile, Web, Backend API, Full-Stack) have achieved 100% ASGF template parity. Templates live at company/pipeline/<pipeline>/templates/monitoring/.

Part IV — Operating Standards

9. Universal Conventions

9.1 File and Folder Naming

9.2 Document Authority Hierarchy

When sources conflict, apply this precedence (highest to lowest):

1. pipeline.md in a pipeline folder — canonical truth for that pipeline
2. agent/profile.md — canonical identity for an agent
3. library/overview/*.md — authoritative summaries
4. library/departments/*.md — readable summaries (may lag the canonical source)

9.3 Company — Personnel Tier System

The following tier system applies to the Company system only. The Casual Games Studio uses a division-based structure (see §5.4).

9.4 Company Pipeline — Progress Monitoring

For any company development project at or beyond Stage 4 — UML → Implementation Plan + Gantt (see §4.4), three files must be maintained within the project folder:

Any company pipeline task exceeding its estimate by >20% triggers a CTO → CPO schedule risk notification. Studio projects follow the escalation path defined in the Casual Games Studio pipeline (studio/casual-games/pipeline/casual-games-pipeline.md).

9.5 Git and Version Control

Repository root: c:\Users\ASUS\Documents\Code\Local\agent-global-base · Default branch: master

Commit policy: Commit finalized workspace additions (profiles, pipelines, skills, this file). Never force-push to master — escalate to the user if a destructive git operation is being considered.

Multi-Agent Swarm Workflow — Git Worktree

For parallel multi-agent (swarm) work, this workspace follows the git worktree isolation pattern defined in core-component-00/framework/05-multi-agent-engineering/fundamentals/git-worktree-orchestration.md. The core principle: each agent receives an isolated filesystem and branch, eliminating filesystem contention between concurrent agents.

Five-phase lifecycle:

Agent roles:

Programmatic control: core-component-00/framework/05-multi-agent-engineering/implementations/git_worktree_manager.py Full specification: core-component-00/framework/05-multi-agent-engineering/fundamentals/git-worktree-orchestration.md

Git Line Ending & Branching Alignment Specifications

To maintain repository integrity and prevent parallel branch tracks or duplicate commits on Windows operating systems, all agents must follow these specifications:

9.6 Context and Session Management

For long-running work sessions — including company pipeline Stage 4 (UML → Implementation Plan + Gantt) onward, Casual Games Studio pipeline Stage 5 (Full Production) onward, or any multi-session research task:

9.7 Formatting

Run Prettier on every file created or modified before finalising:

prettier --write "<file-path>"

10. Agent Behaviour Rules

These rules apply to all AI executor agents operating in this workspace without exception.

11. Operating Environment

11.1 Development Machine

11.2 Implications for Agent Work

Part V — Reference

12. Navigation Index

13. Key Personnel Roster

Company — C-Suite & Leads

Casual Games Studio — Leadership

CC-00 Laboratory — Director

Academic Neural Unit 00 — Founding Lead & Crew

For complete rosters and full profiles, see:

• Company: company/library/overview/personnel.md
• Studio: studio/casual-games/team/README.md
• CC-00: core-component-00/crew/README.md
• ANU-00: academic-neural-unit-00/crew/README.md

This document is maintained at the workspace root. Update it whenever the workspace gains a new system, the authority model changes, tooling is added, or the operating environment changes. It is not owned by any single sub-system.