About

About .SYSTEMX

DOT SYSTEMX is an open project operating format for people and AI assistants. It keeps purpose, plans, task ownership, evidence, and reusable knowledge in a portable .SYSTEMX folder. The aim is continuity: make it easier to resume useful work without losing the objective or repeatedly reconstructing the past.

For practical instructions, begin with the user manual, first-time setup, and daily workflow. The current edition 2.2 white paper documents the beta record model and evidence limits. Historical edition 2.0 remains a 24-page alpha.4 baseline with a hypothetical resource example, not measured savings.

Watch the 1:50 .SYSTEMX introduction on YouTube for an animated overview, or use the video guide for the 4K poster, chapters, and downloadable MP4, captions, and transcript. The streaming copy is hosted on the Wayne Tech Lab channel.

Beta prerelease: validate the selected version in your project. See Release policy.

A note from the founder

I started .SYSTEMX as a way to keep my local scripts and TODO folder in sync while working on a project. I wanted one place to see what needed doing, what was underway, and what had actually been completed.

Over the last year, that folder has evolved into a reusable standard for agentic coding. As more of the work moved through AI assistants, the problem became larger than a task list. An assistant needed to retain the project's purpose, understand decisions already made, continue from a reliable checkpoint, and work with other agents without losing track of ownership or evidence.

My main goal is to keep the AI or LLM from drifting, reduce repeated token use, and maintain continuity through 10,000 or more task-based events until a process, idea, or application reaches its agreed outcome. I want a new session to pick up the work with enough context to move forward, while keeping decisions and progress inspectable by the person responsible for the project.

The system grew within a much larger Firebase and Google Cloud template. Extracting .SYSTEMX made the operating format usable on its own. You can keep your own stack and tools while adopting the same planning, Agent 0 coordination, logging, and memory conventions.

What the name means

The visual brand is .SYSTEMX. The repository's logo and workflow graphic use that name alone. Wayne Tech Lab's maintainer attribution is separate from the artwork, in project information and the wiki footer. See the Visual Guide for the graphics and operating diagrams.

“DOT SYSTEMX” is the spoken name of the folder .SYSTEMX. The dot comes from the convention of hiding dot-prefixed names in ordinary Unix-style listings, used on macOS and Linux. For example, the GNU ls manual documents omission of leading-dot names by default. Windows has a separate hidden file attribute.

The name is always uppercase .SYSTEMX in paths and instructions. On a case-sensitive filesystem, a lowercase .systemx sibling can hold a separate set of records. The optional alias routes lowercase access to the canonical folder where supported; it is not a second installation. Follow Exact casing and alias before resolving an existing conflict. Hiding a folder provides no encryption, access control, or automatic Git exclusion.

What the long-term goal means today

“10,000+ task-based events” describes the ambition for sustained project continuity, not a published performance result or a promise that an unattended agent will finish an app. Assignments, status changes, checks, reviews, and handoffs are different kinds of progress; an event is not necessarily a task, a model turn, or a completed outcome.

Today, .SYSTEMX supplies ordinary files and optional local tools. The ledger records task history; agents save evidence references and checkpoints. It does not automatically record every tool call, run an event queue, schedule future work, or provide a model's long-term recall. A later session must load the saved records. The long-running work guide explains how to use bounded batches and the current implementation's scaling limits.

Agent 0, workers, and the host environment

Agent 0 is the coordinator role. It maintains the plan, assigns scoped work, resolves dependencies, reviews results, and promotes accepted facts into shared memory. A worker owns its assignment and returns evidence and a clear handoff. The Agent 0 manual covers the full workflow.

The AI harness supplies actual model calls, file tools, agent processes, permissions, and runtime limits. A prompt can request up to ten subagents, but the harness may allow fewer, and a small task may need none. The template neither enforces that number nor authorizes delegation merely by registering a role. Use Prompt cookbook for examples that make the scope clear.

When separately authorized, Agent Y can carry one task to a selected installed CLI provider and return an isolated Git/draft-PR handoff. Its run and app-native subagents share the same project budget; neither gains the other's private runtime memory automatically.

Design principles

• Give each responsibility one authoritative record and generate status views.
• Keep the active context small enough to use, with links to the full evidence.
• Separate verified facts, hypotheses, historical observations, and current state.
• Make ownership, dependencies, acceptance, and the next action explicit.
• Review worker results before integration and promotion into shared memory.
• Preserve local records and earlier defaults during managed updates.
• Respect the host environment's instructions, access limits, and project approvals.
• Measure useful outcomes; more tasks, agents, or logs do not establish better work.

These practices can reduce repeated context and avoidable rework. They do not guarantee lower bills, faster inference, correct output, or the absence of drift. See Tokens, cost, and time for measurement guidance.

Scope, provenance, and ownership

The standalone format is stack-neutral. It includes no preconfigured Firebase application, Google Cloud deployment, business-specific workflow, or agent runtime. Its source provenance records the extraction from SFWA-WTL-TEMPLATE. That origin repository is private; an anonymous reader may receive a 404. The public dotSYSTEMX repository, release artifacts, and this wiki are the distribution and documentation sources for this standalone template. The provenance link does not imply that the private application template or its project data is published here. Each adopting project supplies its own facts, commands, infrastructure, and acceptance criteria. See Stack Guide.

The CLI and Python library offer current integration points. An MCP adapter is a possible future extension; no MCP server ships with this release. Any extension needs explicit access controls, concurrency handling, and a tested mapping to the canonical records. See Technical Guide.

Maintained by Wayne Tech Lab LLC and released under the MIT License. “Standard” means this project's reusable operating convention, not an external certification or a claim of industry-wide adoption. Retain the license and attribution when redistributing it. Keep populated private records out of the public template and shared examples.

The shared-brain idea

I want .SYSTEMX to make a long project feel coherent even as work passes among people, assistants, bots, and specialized agents. Global context and the Master Plan preserve intent; Agent 0 coordinates; Agent X preserves the timeline; Agent Y can route an external CLI/PR channel; Agent Z provides the same repeatable review. Verified facts and corrections can make the next turn better informed while the current task views stay synchronized.

“Simulated AGI brain” is a metaphor for that organized collaboration, not a claim that the format creates AGI, retrains models, or guarantees self-improvement. The proposed standard is inspectable project memory and evidence-based work. See one brief to a finished project and shared work across clouds and bots.