Advanced Use Cases

Advanced use cases

Use .SYSTEMX when a project needs a reliable relationship between its objective, work, evidence, and next action. Choose a workflow based on dependencies and available authority. More workers are useful only when the task benefits from independent work and their results can be reviewed and integrated.

These examples are patterns for an adopted project, not a prepopulated backlog, new runtime features, or measured performance claims. Start with Daily workflow, Visual Guide, and Subagent processing.

Choose an operating pattern

Situation	Suitable approach	Main control	Acceptance evidence
Small fix or document edit	Agent 0 works solo	One bounded task	Changed behavior or reviewed document
Feature with independent components	Agent 0 coordinates scoped workers	Agreed interfaces and separate write scopes	Integrated feature checks
Unclear defect	Parallel read-only investigations, then a selected repair	Hypotheses stay separate from facts	Reproduction and regression evidence
Research or decision memo	Workers inspect independent sources	Source provenance and reviewed synthesis	Claims supported by cited evidence
Service incident	One operational owner, bounded diagnostic workers	Live-state checks and explicit change authority	Recovery and applicable operational verification
Large migration	Dependency-ordered batches with checkpoints	Versioned plan and recoverable changes	Per-batch checks and final compatibility evidence
Google Drive/shared folder	One authoritative writer during each handoff	Sync verification and conflict resolution	Readback of the same saved records
Chat without writable tools	Attached records and an explicit handoff document	Label unsaved proposals clearly	Owner-saved and reloaded records
Work spanning repositories	Separate project records and explicit coordination references	Selected workspace, owners, and revision boundaries	Each project's evidence plus cross-project acceptance

Example: implement a feature across components

Suppose an app needs a saved-draft feature. Agent 0 first defines the behavior: what is stored, when it is saved, how recovery works, and what should happen on failure. Agree on the interface before dividing implementation. The plan might then separate storage logic, UI behavior, and test design.

flowchart TD
    Contract["Accepted behavior and interface"] --> Storage["Storage task: isolated scope"]
    Contract --> UI["UI task: isolated scope"]
    Contract --> TestPlan["Test-design task: independent expectations"]
    Storage --> Review["Agent 0 reviews and integrates"]
    UI --> Review
    TestPlan --> Review
    Review --> Combined["Run integrated acceptance checks"]
    Combined --> Outcome{"Criteria satisfied?"}
    Outcome -->|Yes| Accept["Accept milestone and save checkpoint"]
    Outcome -->|No| Repair["Record repair task or actual blocker"]

Loading

Text equivalent: agree on the contract, run only independent scoped tasks, review and integrate their outputs, and check the composed behavior before accepting the milestone. A failed integrated check leads to repair or a blocker.

The diagram shows logical dependencies, not proof that all three assignments can always run simultaneously. If the UI needs an unfinished storage interface, first complete that dependency or explicitly define an agreed stub contract. Test design can be independent; execution against the final feature waits for integration. Record dependency IDs in the ledger and shared-resource ownership in coordination notes. A worker passing its own checks does not establish that the whole feature works together.

Example: investigate a difficult bug

Agent 0 records the concrete failure, source revision, environment, reproduction, and acceptance criterion. Give independent workers bounded read-only questions: for example, inspect input handling, inspect state persistence, or compare recent changes. Each worker reports observations and labels hypotheses.

Agent 0 compares the evidence, selects a repair scope, and assigns one owner for the affected files. Avoid letting three investigators independently implement conflicting fixes. After a repair, run the relevant regression and integrated checks, then preserve the cause and evidence in project memory. If the failure cannot be reproduced, record that limit instead of declaring it fixed.

Example: research and synthesis

Create a task for the question and the decision it should inform. Divide sources or hypotheses into bounded investigations. Workers return source URLs or artifact references, dates, relevant findings, contradictions, and uncertainty. Keep private sources within the project's access and retention rules.

Agent 0 checks whether each source supports its associated claim and whether sources are independent. It then produces a synthesis with evidence, limitations, and open questions. Agreement among workers is not independent confirmation when they all rely on the same source. Promote verified durable facts into memory and retain the reason when an earlier conclusion is superseded.

The result might be a reviewed report rather than deployed software. Its acceptance criteria should reflect that actual deliverable.

Example: incident response with an operational owner

Separate observation from authorized change. Diagnostic workers can inspect assigned logs or state within their access. One owner coordinates mutable resources and any approved remediation. Record the environment, observation time, active job handles, and exactly what each check established.

A restart command succeeding does not prove the user-facing service recovered. Verify the applicable service and operational criteria before recording the incident outcome. Task completion and tool access do not grant deployment, spending, credential, or production authority. For a stopped or timed-out job, reconcile its state before launching a replacement. See Evidence and acceptance.

Example: a migration spanning many sessions

Use milestone and task dependencies to move in bounded, reviewable batches. Record the starting version, compatibility assumptions, required checks, and recovery path before each batch. Preserve evidence and the next incomplete step at every handoff. Recheck changing state on resume.

For template-default upgrades, use the existing additive manager and version selection workflow. It preserves project records and earlier defaults; it does not automatically migrate a host application's data or task semantics. See Installation and updates and Upgrading. For a very large ledger, measure the actual environment and preserve dependencies when planning any future archive. See Long-running work.

Example: Drive or a chat-only project

In a locally synchronized Drive folder, use regular local files and one coordinated writer. Let synchronization settle and verify saved records before transferring ownership. A local writer lock does not protect a second machine's copy. Conflicting copies require reconciliation; duplicating .SYSTEMX under another case or folder name creates another source of confusion. Follow Google Drive setup.

In a chat without writable tools, supply the current records or exported packet. Have the assistant return a compact handoff, proposed task updates, and any referenced evidence. The owner saves and reattaches the result. Do not describe memory as persisted until a write and readback actually happen. Use Chat setup and New chat setup prompt.

Example: coordinate more than one project

Within one workspace, use SYSTEMX PROJECTS: .SYSTEMX/Projects/Project-A/.SYSTEMXP and Project-B/.SYSTEMXP. Keep the workspace-wide Global context and Master Plan in the outer records; each child owns its context, plan, ledger, status, decisions, and agent memory. Use explicit --project NAME selection and keep code beside the child's marker or reference external locations. Never nest another .SYSTEMX installation.

Separate existing repository installations can remain independent. Link their verified revisions and handoffs deliberately; there is no automatic migration, portfolio scheduler, or synchronization between repositories.

Before dispatching a worker, identify its target project, checkout, instruction set, task ID, and shared-resource boundaries. A coordinator can reference another project's prerequisite, but the local task ledger's dependency IDs refer to its own tasks; it does not enforce remote cross-project dependencies. Recheck that external prerequisite explicitly. Avoid copying another project's entire backlog or private memory into the current project.

A prompt for applying a pattern

Use .SYSTEMX to plan [OBJECTIVE] in [WORKSPACE]. Select the appropriate
operating pattern from the Advanced Use Cases guide. Preserve the accepted
requirements and existing task IDs. Identify the actual dependencies,
acceptance evidence, and shared resources before assigning work.

Use Agent 0 as coordinator. [CHOOSE: Work solo / Use authorized subagents
up to N, subject to lower harness limits.] Keep assignments bounded and
use only the workers that help. Review and integrate evidence before
completion. Save the exact next step at each handoff and report blockers
without inventing successful execution or persistence.

Replace the bracketed choice before sending; a pattern description alone does not authorize delegation. Measure total usage and time through accepted results, including coordination and rework. See Prompt cookbook and Tokens, cost, and time.

Shared chats, cloud references, and bots

The shared workspace guide covers repository, portfolio, and hybrid ownership; Drive URLs and connectors; cloud snapshots; local/VM bot memory; and explicit handoffs between chats. Every child needs the named path Projects/NAME/.SYSTEMXP. Choose one authority for each task ledger, verify write/readback and transport, and keep workers scoped to the selected project. For start-to-finish execution, use the one-shot project guide.

App-native workers plus a different CLI provider

A coordinator in Codex App or VS Code may assign one non-conflicting task to app-native workers and another to Agent Y using a separately installed Codex CLI, Copilot CLI, or reviewed configured adapter. Select the provider per task, review its account and data access, and give both paths the same canonical scope, accepted objective, evidence contract, and shared resource budget. Distinct worktrees protect code edit scopes; they do not synchronize ledgers or isolate credentials. Agent 0 integrates original check evidence, X records actual run/PR observations, and Z reviews the matching result. An opted-in draft PR may be created before acceptance; readiness requires accepted done. A cancelled unmerged PR keeps its branch/worktree; cleanup requires an external merge and accepted task with verified recovery bundle. Agent Y does not merge. See the current four-part system guide.

On-demand brand, research, and policy detail

Use AUTOBOT and Agent Alpha when a project needs more detail than the compact startup handoff. A UI task can select Design/Brand/Media/ Tokens; a research task can select Research/Data/Rules; a resume can select Memory/Archive. Ten specialists form one bounded panel per explicit scope, not ten permanent workers. Save original source/evidence pointers and reuse matching results. Private large imports and draft assets belong in ignored local DATA, with intentional publication of approved outputs through the actual project's tools.