Generated from the maintained method library. Read or download equivalent Markdown.

Client Agent Workspace Setup v0

Status / authority: Current client-readable setup specification; v0 applied-protocol support
Effective date: 2026-08-04
Dependencies: Client_Agent_Navigation_Standard.md; Client_Agent_Workspace_Templates.md; ../LEGANT_METHOD_REFERENCE.md
Supersedes: Earlier ARC-first workspace setup routing where it conflicts. Existing client workspaces change only through their local controls.

Purpose: Reusable setup process for full-engagement client-owned Innate Edge agent workspaces.

Use this when the client's Operating Manual is ready to become a working navigation system for the client and their agents. This is a versioned, client-readable setup specification. Revise it when new implementations reveal a generalizable improvement.

Objective

Create a client-owned navigation layer that lets future agents help the client make more congruent, coherent, and contributing decisions without re-reading the whole archive.

The workspace should:

• make the current Operating Manual hypothesis usable for real decisions;
• preserve factual life/project context;
• keep the client's self-model visible but provisional;
• route facts differently from interpretations;
• make live projects easy to pressure-test;
• preserve navigation continuity as agents work with the client;
• record what changed and why.

Setup Boundary

The client workspace is for the client and their agents. It should include client-owned context and the client-readable Legant Method, including relevant Innate Edge applied protocols.

Do not include:

• maintainer-private notes or decompressions;
• other client folders;
• private production, proposal, or output folders;
• raw methodology production files that are not client-readable;
• private strategic context unless the maintainer explicitly decides it is client-owned.

Shared methodology stays read-only. Client-specific context lives in the client folder.

Recommended access pattern:

<Client Workspace Root>/
  Access_Manifest.md
  README.md
  <Client>.md
  <Client> Innate Edge/
  <Private Maintainer Context>/

The parent client folder routes people to the shared and private workspaces. Keep it clean enough that the maintainer can explain the access model in one sentence.

The shared client folder holds client-owned sources, current deliverables, and agent context. The private sibling holds maintainer-private decompressions, strategy notes, internal production chains, unverified research, and calibration material not written for client access.

Folder Hygiene Principles

Use these principles before deciding where any file belongs:

1. Access boundary first. If the client and their agents can use it without seeing maintainer-private judgment, it can live in the shared workspace. If not, it goes in <Private Maintainer Context>/.
2. Human-readable shared root. The shared workspace should be navigable by the client, not only by agents. Keep the latest official deliverable files at the top level; tuck system files, source ledgers, reference indexes, and archive material away.
3. Latest official docs at eye level. Current OM / Positioning / active deliverables belong in the shared root. Historical deliverables belong in Historical Deliverables/.
4. Source material is organized by epistemic role. Evidence should help an agent know what kind of source it is reading: psychometrics, qualitative input, evidence extraction, transcripts, or deliverables.
5. No duplicate truth. Do not leave the same source group in both the parent folder and shared workspace. Preserve superseded copies in private maintainer storage if needed; do not leave them where future agents will treat them as current.
6. Transcripts are client-owned unless they are decompressions. Raw client conversations can live in the shared workspace. Maintainer decompressions, Decoder interpretations, strategy notes, and internal session artifacts go private unless the maintainer promotes a specific point.
7. Preserve before deleting. When cleaning a messy historical folder, move internal or superseded material into private preservation buckets first. Delete only generated cruft or confirmed duplicates.
8. Folder polish is not the goal. A clean folder is useful only if it improves agent judgment, client navigation, and source discipline.

Setup Depth

Use a baseline + expansion model.

Baseline setup creates the smallest context layer an agent needs to orient itself: rules, source map, timeline, current state, extended operating manual, open questions, navigation log, and changelog.

For full-engagement clients, do not stop at the client-facing OM. The core handoff is the agent-operating overlay: an expanded Personal_Operating_Manual.md that translates the current OM hypothesis into decision guidance, language guidance, watch points, and falsifiers.

The extended OM should translate the formal OM and positioning work into an agent-usable overlay: a compact wiring summary, natural decision ritual, cross-domain mechanism table, engine/fuel boundary, scatter/nozzle patterns, language that lands, active-vehicle cheatsheet, and update signals. It should not replace the formal OM or absorb the whole archive. It should make the map usable in live decisions and route unresolved project questions to context pages.

Show evidence anchors explicitly. The client remembers their own examples; an agent does not. Add a compact evidence-anchor key when the folder contains transcripts, evidence ledgers, or post-OM reception data. Use it to keep claims grounded without turning the OM into an evidence dump.

Deep synthesis expansion is needed when the client has a rich or messy archive: multiple transcripts, older reports, evidence workbooks, evolving archetype language, positioning work, or active vehicles that depend on subtle interpretation.

Deep synthesis adds three jobs:

• source coverage: what has been processed, lightly represented, or left untouched;
• transcript indexing: what each conversation contains and where it should feed the wiki;
• development arc: how the self-model evolved across time, so the latest frame is not treated as ahistorical truth.

Every setup must say whether deep synthesis was needed, skipped, or deferred.

Minimum Folder Pattern

Use exact names where possible. If a client already has a reasonable equivalent, keep the existing name and note the mapping in Agent System/Reference_Index.md.

Use Client_Agent_Workspace_Templates.md for copyable skeletons when helpful. Templates are starting points, not required forms.

<Client Workspace Root>/
  README.md
  CLAUDE.md
  Access_Manifest.md
  <Client>.md
  <Client> Innate Edge/
<Private Maintainer Context>/  # separate; never shared by default

Build the shared workspace as a usable client packet:

<Client> Innate Edge/
  AGENTS.md
  CLAUDE.md
  README.md
  <Client>_Operating_Manual_<YYYYMMDD>.pdf
  <Client>_Operating_Manual_<YYYYMMDD>.docx
  <Client>_Operating_Manual_Draft_<YYYYMMDD>.md
  Historical Deliverables/
    <prior X-Ray / Decode / OM / Positioning files>
  Transcripts/
    <raw client transcripts only>
  Evidence/
    Psychometrics/
    Qualitative Input/
    Evidence Extraction/
  Agent System/
    Reference_Index.md
    Methodology_Library.md
    Source_Change_Log.md
    Source_Coverage_Ledger.md
  Wiki/
    Timeline.md
    Current_State.md
    Personal_Operating_Manual.md
    Development_Arc.md
    Decisions_and_Open_Questions.md
    AI_Working_Preferences.md
    Navigation_Log.md
    Conversation_Transcript_Index.md
    _changelog.md
  Projects/
    <Project Name>/
      <Project_Name>_Context_Brief.md

Baseline setup can skip Development_Arc.md, AI_Working_Preferences.md, and project pages if the client has a thin source base and no active vehicle yet. Do not skip AGENTS.md, Agent System/Reference_Index.md, Wiki/Timeline.md, Wiki/Current_State.md, Wiki/Personal_Operating_Manual.md, Wiki/Decisions_and_Open_Questions.md, Wiki/Navigation_Log.md, or Wiki/_changelog.md.

Do not default to Raw Sources/ as the shared folder pattern. That name is too archive-like and tends to hide what humans and agents need. Use explicit folders: Transcripts/, Evidence/, and Historical Deliverables/.

Setup Steps

1. Inventory Sources

Create or update Agent System/Reference_Index.md and Agent System/Source_Coverage_Ledger.md.

Capture:

• current Operating Manual or equivalent self-model;
• positioning report or vehicle strategy, if any;
• transcripts and session notes;
• active project files;
• client-authored notes;
• current open decisions;
• source files not yet synthesized.

Also inventory source ownership:

• shared client-owned;
• maintainer-private;
• internal production residue;
• duplicate/superseded;
• unverified external/public research;
• generated cruft.

Move each source group into the access zone that matches its ownership before building the wiki layer.

For rich archives, give each source a coverage status:

• Processed in wiki: directly synthesized into named wiki pages.
• Lightly represented: partially reflected, but not deeply processed.
• Evidence-extracted only: captured in an evidence workbook but not translated into agent context.
• Unprocessed: known source, not yet used.
• Reference/duplicate: useful for traceability, not a primary synthesis source.

Do not over-synthesize yet. The first job is to know what exists, what has been used, and whether the setup needs a deep synthesis pass.

1A. Clean The Folder Shape

Before writing agent context, make the folder itself tell the truth.

Parent client folder:

• keep only routing/admin files plus the shared and private sibling folders;
• move current shareable deliverables into <Client> Innate Edge/;
• move internal workshopping, decompressions, unverified research, and duplicate legacy source folders into <Private Maintainer Context>/;
• remove empty old shells like evidence/, source-data/, transcripts/, deliverables/, or Decode Report Work/ from parent level after preserving their contents.

Shared workspace:

• put the latest official deliverables at root;
• put older official deliverables in Historical Deliverables/;
• put raw client transcripts in Transcripts/;
• put evidence/source data in Evidence/;
• put agent control files in Agent System/;
• keep Wiki/ for agent-readable summaries, not raw archives.

Recommended evidence subfolders:

Evidence/
  Psychometrics/
    <BFAS / PVQ-RR / other assessment extracts and raw files>
  Qualitative Input/
    <X-Ray answers, external feedback, client questionnaires, client-authored notes>
  Evidence Extraction/
    <source_index.csv, scene_index.csv, evidence_ledger.csv, evidence workbooks, digests>

Use different names if the client's archive already has clearer names, but keep the epistemic split. Agents should know whether they are reading measured inputs, first-person/client-provided input, third-party qualitative input, or extracted analytical evidence.

2. Establish Agent Rules

Create or update AGENTS.md.

It must include:

• agent role: long-horizon alignment advisor;
• load order;
• source boundary;
• context update routing;
• navigation continuity / after-handoff logging loop;
• raw-sources-win rule;
• client-specific challenge style;
• things the agent should not assume.

Keep it compact. AGENTS.md is behavioral infrastructure, not a report.

3. Point To Shared Methodology

Create or update Agent System/Methodology_Library.md.

It must point to:

• the shared Legant Method Library or its local synced root;
• Client_Agent_Navigation_Standard.md;
• Client Agent Reply Standard.md, if used;
• relevant Innate Edge, Positioning, and Navigation sources named by the Legant Method Reference.

State that methodology is read-only and client-specific updates belong in the client workspace.

4. Build The Wiki Layer

Populate the core wiki pages:

• Timeline.md: source-anchored factual chronology. No interpretation except brief source notes.
• Current_State.md: what is alive now; active vehicles, constraints, pending decisions.
• Personal_Operating_Manual.md: current self-model map, clearly marked as provisional where needed.
• Development_Arc.md: how the current self-model evolved across earlier frames, reports, and lived evidence.
• Decisions_and_Open_Questions.md: unresolved choices and self-model update signals.
• Navigation_Log.md: episode-level continuity ledger for meaningful navigation interactions.
• Conversation_Transcript_Index.md: transcript ledger and processing status.
• _changelog.md: newest-first trace of context updates and self-model changes.

Before generating Personal_Operating_Manual.md, read Client_Agent_Navigation_Standard.md.

The governing question is:

What would a future agent need to know about this client's durable wiring to help them make a more congruent, coherent, contributing decision?

Use these routing principles:

• Client-facing OM: the distilled, client-usable map produced by the OM process. Treat the current version as good enough unless the maintainer explicitly asks to reopen it.
• Extended OM / Personal_Operating_Manual.md: the agent's slow wiring map. Because the agent does not have the client's memory, major claims should connect to concrete examples, source pointers, or evidence summaries elsewhere in the folder. Claims without anchors should be marked as hypotheses or gaps.
• Context pages: live terrain. Use them for current situation, active projects, recent decisions, constraints, open questions, and navigation history.
• Source / evidence: the reservoir. New evidence can feed the log of possible OM refinements, but it should not silently rewrite the wiring map.

Personal_Operating_Manual.md is the slow map: the client's relatively stable wiring, recurring mechanism, energy pattern, sources of scatter, nozzle conditions, decision filters, and enduring watch points.

The map is a hypothesis and can be refined when better evidence reveals the wiring more accurately. But it should not drift just because the client's projects, mood, constraints, or current chapter changes.

Use context pages for live terrain: current projects, recent evidence, active decisions, open questions, constraints, and navigation history.

Navigation uses both:

• Personal_Operating_Manual.md = slow map of durable wiring.
• Current_State.md, project briefs, Decisions_and_Open_Questions.md, and Navigation_Log.md = live terrain.

When writing the extended OM, include only context that clarifies the durable wiring or helps an agent apply it. Do not turn it into a biography, project tracker, or archive summary.

When translating from a client-facing OM into the extended agent OM, preserve the parts that make the manual usable in a live decision:

• the client's natural decision ritual, phrased the way the client or their agent would actually use it;
• the mechanism sequence, not just one label or Verb;
• the distinction between core engine work and fuel, play, practice, favors, maintenance, curiosity, or rest;
• the pattern to check when the client wants to leave, redesign, reshape, or hand off something;
• boundary tradeoffs: what the client consciously gives up by honoring the boundary;
• update signals: what future evidence would strengthen, weaken, or refine the map.

Use project context briefs for active vehicles that need pressure-testing.

5. Route Updates By State Type

Follow Client_Agent_Navigation_Standard.md.

Auto-update directly when the claim is factual, source-backed, low-inference, decision-relevant, and in-scope.

Route as an open question, update signal, or approval diff when the claim changes meaning:

• self-model;
• strategy;
• positioning;
• durable pattern;
• interpretation;
• what an event proves;
• whether a live question is resolved.

Routing test:

• If it says what happened, update and log.
• If it says what it means, route it.
• If it is true but low-value, leave it out.

6. Create Project Briefs For Live Vehicles

For each active vehicle, create a context brief only if it will materially improve agent guidance.

A project brief should answer:

• what the project is;
• why it matters to the client's current chapter;
• current status;
• what decisions are live;
• what risks or scatter patterns to watch;
• what evidence would clarify fit.

Do not create project pages for dormant interests unless the client is actively deciding around them.

7. Run Canary Tests

Run at least two canaries before calling the setup ready.

Generate canary prompts from the client's actual context. Phrase them the way the client would naturally ask an agent for help, not as internal evaluation instructions.

Canary A: Routing

Use a client-natural prompt that contains mixed facts and interpretations. The agent should update or recommend updating facts, route interpretation, and avoid turning maintainer or client interpretation into settled truth.

Canary B: Advice

Use a client-natural prompt about a real or realistic live pressure-test. The agent should:

• name files read;
• separate map from evidence;
• apply 3C;
• preserve uncertainty;
• push back if needed;
• end with a stepping stone, sharper decision question, or reason no next step is appropriate.

8. Record Deviations

Every setup should leave a short note in Wiki/_changelog.md or Agent System/Source_Change_Log.md with:

• what was created or changed;
• what sources were used;
• what was intentionally skipped;
• whether deep synthesis was used, skipped, or deferred;
• what broke or felt client-specific.

If a setup needs a different page, file name, or sequence, record why. These deviations are inputs for improving the shared protocol.

For folder cleanup, also record:

• what was moved into the shared workspace;
• what was moved into maintainer-private;
• what duplicate or old parent-level folders were removed;
• any source category that still feels messy and should improve the next version of the standard.

9. Seed Navigation Log

Create Wiki/Navigation_Log.md.

The log tracks meaningful navigation episodes, not full transcripts. Use it when an agent helps with a decision, doubt, project pressure-test, self-model question, or live evidence update.

Each entry should capture only what future agents need:

• date;
• actor;
• platform or chat locator, if available;
• topic / decision / doubt;
• sources read;
• agent recommendation;
• client response, if known;
• chosen stepping stone;
• evidence to watch;
• context updates made or proposed.

Use simple status values: Active, Closed, Deferred, or Interrupted.

The log is for real navigation episodes, not canary outputs. Do not log canary tests unless the maintainer or client explicitly wants the test treated as a real context artifact.

10. Define The After-Handoff Loop

The workspace should get smarter through use.

After handoff, when an agent helps with meaningful navigation, it should:

• start a Navigation_Log.md entry before giving substantive advice;
• use the map -> reality -> 3C -> stepping stone -> update signal loop;
• update factual context directly when the change is source-backed, low-inference, decision-relevant, and in scope;
• route self-model, strategy, positioning, and interpretation changes as open questions or update signals;
• update Agent System/Source_Change_Log.md when client-owned source material changes;
• leave interrupted or unresolved episodes open rather than inventing closure.

Definition Of Done

A workspace is ready for pilot testing when:

• AGENTS.md gives the agent role, load order, routing rule, source boundary, and client-specific challenge style.
• Access_Manifest.md documents the shared client workspace, shared methodology access, private maintainer sibling folder, and excluded internals.
• The parent folder contains only routing/admin files plus <Client> Innate Edge/ and <Private Maintainer Context>/.
• The shared workspace root is human-readable and contains current official deliverables.
• Historical deliverables, transcripts, evidence, wiki pages, and agent system files are separated.
• Agent System/Reference_Index.md lists source, wiki, project, and methodology pointers.
• Agent System/Methodology_Library.md points to the shared client-readable methodology and Navigation standard.
• Agent System/Source_Coverage_Ledger.md names what has been processed, lightly represented, evidence-extracted only, unprocessed, or intentionally skipped.
• Timeline.md exists and can answer basic chronology questions.
• Current_State.md states what is alive now.
• Personal_Operating_Manual.md gives the current self-model map without pretending it is final truth.
• If the archive is rich, Development_Arc.md explains how the current model evolved and why any older frame was retained, revised, or retired.
• Decisions_and_Open_Questions.md holds live choices and update signals.
• Navigation_Log.md exists and is ready to preserve meaningful navigation episodes as they begin.
• _changelog.md records the setup.
• At least one live pressure-test canary passes.
• The after-handoff update loop is clear in AGENTS.md or the local workspace instructions.
• Known gaps are named rather than hidden.

Full-Engagement Handoff Threshold

A workspace is complete enough for full-engagement handoff when:

• all client-owned source groups are inventoried, including deliverables, transcripts, evidence workbooks, project notes, client-authored notes, and known gaps;
• the access boundary is visible in the folder structure: shared material is in <Client> Innate Edge/, maintainer-private material is in <Private Maintainer Context>/, and parent-level clutter has been removed;
• evidence/source material is grouped by role, not dumped into one opaque archive;
• the current OM hypothesis has been translated into Personal_Operating_Manual.md as an agent-operating overlay with decision filters, language guidance, watch points, and falsifiers;
• major chronology-dependent sources are represented in Timeline.md, and rich archives have either Conversation_Transcript_Index.md / Development_Arc.md or an explicit deferral note;
• Current_State.md, Decisions_and_Open_Questions.md, and any live project briefs make the client's active decisions pressure-testable;
• Navigation_Log.md and AGENTS.md make the after-handoff use-and-update loop clear;
• the canary test shows the agent can separate facts, evidence, interpretation, and self-model update signals;
• remaining gaps are named and do not block useful navigation.

Validation Sequence

Validate first against a completed workspace, then against a different client's workspace, and finally against a complex case where the client, methodology owner, and agent operator roles overlap. Record which elements generalize and which remain client-specific before revising the shared protocol.

What Not To Overbuild

Do not create a full personal operating system before the client has live use for it.

Do not create a separate page for every framework.

Do not reorganize for aesthetic neatness alone. Reorganize when the current structure violates the access boundary, hides current official deliverables, duplicates source truth, or blocks reliable agent use.

Do not make the agent dependent on maintainer-private context for client-owned guidance.

Do not treat a polished folder as proof that the agent gives good advice. The canary tests are the proof.