Analyse Agentic System

---
name: analyse-agentic-system
description: "Use when asked to analyse, review, or refresh an external agent runtime, orchestration system, agent operating layer, agent memory/knowledge/context-engineering system, or narrower model-dependent operational mechanism from inspectable sources."
type: kb/types/instruction.md
user-invocable: true
argument-hint: "<system identifier> plus source input (repository, checkout, snapshot/bundle, or documents) and optional authorized output path"
allowed-tools: Read, Write, Grep, Glob, Bash, Task
context: fork
model: opus
---

# Analyse an Agentic System

Analyse one external agentic system at one frozen evidence boundary so the result identifies what the system actually wires, where its responsibilities end, and what its memory/context and epistemic routes support. Run a mandatory runtime baseline, then run both the memory/context lens and the epistemic lens at a depth proportionate to the evidence, reconcile shared records by stable IDs, and return one bounded system synthesis. Describe mechanisms in the external system's own terms, then use Commonplace ontology to normalize the distinctions that improve comparison. When the selected target is itself a memory, knowledge, or context-engineering system, also invoke the established legacy review workflow against the same frozen sources. A separately commissioned transfer scan may select current implications for Commonplace after the stable analysis is complete; it never changes the analysis or its comparison fields. The consumer is an analysing agent or maintainer; the channel is explicit invocation or trigger-matched skill loading; the force is a prescriptive analysis and result-writing policy.

Do not put product rankings, generic adoption advice, a Commonplace delta, a universal taxonomy or maturity ladder for agentic systems, or any claim beyond the declared evidence boundary into the stable analysis. This skill owns orchestration of the run inside the caller's existing authority: source preparation, target routing, lens scoping, lens execution, conditional legacy-review invocation, reconciliation, stable-result verification and freezing, optional transfer-scan routing, and reporting. It does not itself authorize source acquisition or refresh, mutation of a supplied checkout, file publication, or retained report creation. The agent executing this skill is the orchestrator referred to below; lens workers and the legacy-review workflow execute inside its boundary and never establish a different revision or publication authority.

## Prerequisites

- A named target system and at least one source input (repository reference, existing checkout, snapshot or document bundle, or accessible live documents).
- If no source input is reachable at all, allocate the run ID, stop substantive analysis, and emit a `blocked` result conforming to `kb/types/agentic-system-analysis-result.md`. Leave boundary-dependent frontmatter fields null, keep every required section, and point each unreached record to the missing-source blocker. Do not analyse from recollection.

## Steps

### 1. Open one run and declare the boundary

1. Accept a system identifier, the source inputs, the intended use of the result, and any authorized output path. Record separately whether the request authorizes a legacy agent-memory review under `kb/agent-memory-systems/`; authorization for a whole-system file does not imply authorization for that second artifact. When it is authorized, record either the caller-supplied review path or authority to derive the collection's default path after `source-tier` is known; its replacement/archive scope; any separately authorized README or survey path; authority for the generated matrix/table pair or the required stale disposition; any separately commissioned current landscape-synthesis path and reconstructable snapshot; authority for workflow-owned semantic-QA state; and whether local drafting is authorized if no worker is available. Also record separately whether the caller commissioned a Commonplace transfer scan, the exact current interest brief, the Commonplace surface it may inspect, response-only or state-output authority, whether a response-derived state scan may retain the exact delimited stable response block as its input capture, and whether fresh-worker delegation is authorized. Analysis or review publication authority never implies comparison, synthesis, or transfer-scan authority, and a transfer request without a bounded interest brief is incomplete. Default to a response-only result when no file target was requested or supplied by an owning workflow. Allocate one run/result ID before any analysis, in the form `AAS-<YYYY-MM-DD>-<system-slug>-<nn>`, where `system-slug` is lowercase ASCII words joined by hyphens and `nn` disambiguates runs against the same system on the same date. Every record the run produces belongs to that run, and the emitted result carries the ID as its canonical identity.
2. Confirm the subject is in scope. In scope are agent runtimes, orchestration frameworks, agent operating layers, and external memory, knowledge, or context-engineering systems that supply retained material or bounded-call context to agent work; separately, so is any narrower system whose operational behavior depends on model calls it issues **or serves**. The model-call test admits narrower systems — it does not restrict the named kinds. Under either route, a system stays in scope when the model call it depends on runs outside its own boundary: deterministic machinery driven by a model that lives elsewhere qualifies, and so does a component that only serves a call it never issues, such as an MCP server or tool. If the subject matches neither route, emit an `out-of-scope` result conforming to `kb/types/agentic-system-analysis-result.md`, retain every required section with explicit unreached dispositions, and stop.
3. Classify the selected target before assessing it: `enclosing runtime`, `embedded inner runtime`, `runtime client`, `returning computation`, `workflow`, `extension or tool mechanism`, `builder or improvement plane`, `host integration`, `memory/knowledge/context-engineering system`, or another explicitly defined class. This is an analysis result, not an administrative precondition. A non-runtime target may still be in scope, but do not manufacture runtime deficiencies from lifecycle, authority, client, durability, or recovery responsibilities owned by its enclosing system.
4. Define the reviewed boundary by function. Locate the bounded model call, agent runtime, runtime client, host application, memory subsystem, and builder or improvement plane; one process or repository may contain several roles, and one role may cross repositories or services. Include the components or actors whose scheduling, context selection, retained state, action execution, checking, acceptance, or authority decisions produce or constrain the behavior under review. List inclusions, exclusions, and external dependencies explicitly. Preserve **harness** only when it is the source's own term; use **agent runtime** for the operational role that owns execution state and turns model judgments into situated work.
5. Name the boundary kind. Three are available, and the choice bounds what the result may conclude:
   - **whole-system** — every material loop under review sits inside the boundary; conclusions may be system-wide.
   - **subsystem-only** — the subject is one part of a larger system that is not fully inspected; conclusions cannot be whole-system.
   - **complete artifact, partial loop** — the subject is a complete, independently distributed artifact, but a material loop producing the behavior under review crosses declared external dependencies. This is the ordinary shape for an MCP server, plugin, or tool whose model and host ship separately, and for a system whose advertised loop runs partly in a host platform outside the checkout. Conclusions may be whole-artifact; they may not describe the behavior the crossing loop produces. List the external participants as named exclusions, each with the conclusion it prevents.
6. If no coherent system or subsystem boundary can be stated, set the result disposition to `blocked`, retain every section required by `kb/types/agentic-system-analysis-result.md` with explicit unreached dispositions, report the blocker, and stop.

### 2. Freeze sources once

1. Do not acquire, refresh, or capture evidence unless the caller's task or an owning workflow authorizes it. A repository reference supplied as a source input authorizes read-only resolution of that named source, subject to the environment's permissions; it does not authorize mutation of an existing checkout. Within that authority, branch by source kind:
   - Repository reference: resolve an immutable revision.
   - Existing checkout: inspect it without mutating it by default.
   - Supplied snapshot or document bundle: preserve its identity, version, or fingerprint.
   - Live or mixed documents, where capture is permitted: capture a dated inspectable boundary.
2. Record one analysis cutoff for the whole run. A dirty checkout is usable only when the exact inspected state can be identified and retained. A stable but old or partial boundary is allowed with an explicit result limitation. If no stable inspectable boundary can be established, emit a blocker report instead of a substantive analysis.
3. Build one canonical source register with `SRC-*` IDs. For each source record: kind, identity/location, revision or capture, evidence layer, inspected scope, citation anchors, and access gaps. A source whose parts carry different layers — a checkout with implementation under `src/` and doctrine under `docs/` — records each layer against the inspected scope it covers instead of flattening the whole source to one layer.
4. Freeze the sources here; finalize the evidence packet after step 4. The packet carries canonical records, and the runtime baseline is what mints them, so complete steps 2.1–2.3 and the step-3 rules, run the step-4 runtime baseline, then assemble the packet once. The packet comprises the source register, the boundary declaration, the canonical records registered by the runtime baseline, and the citation anchors relevant to each lens; anything beyond it is a targeted read under this step's rule. Lens workers must not reacquire, refresh, or widen sources. Targeted reads inside the frozen boundary are permitted, but they are added centrally to the register and they invalidate affected downstream findings, which must be redone. The packet is amendable as corrections arrive: a correction registered while a worker is in flight is checked against that worker's return on receipt, and only findings that rested on the superseded text are redone.

### 3. Fix truth conditions, definitions, and shared records

Apply these rules for the rest of the run; they keep every lens using the same words and the same objects.

#### Evidence vocabulary

- Overall tier: the analysis is `code-grounded` only when the material ordinary routes, claim-relevant alternate routes, and warranted forcing routes recorded in the step-4 runtime baseline rest on inspected implementation material; otherwise it is `doc-grounded`. The tier is relative to the declared boundary — judge it over the routes the boundary includes. A route the boundary declares an external dependency neither raises nor lowers the tier, but record it as a limitation naming the conclusion it prevents, typically any claim about the behavior that route produces. Report one tier; do not split it into parts. Mixed inspection gaps stay claim-local limitations; they do not change the tier silently.
- Per-source evidence layers: `implementation`, `doctrine/design`, `reported operation`, `observed run`, `causal experiment`.
- Conclusion statuses (use exactly these):
  - `absent` — not found within the named, recorded search boundary;
  - `inapplicable` — the stated trigger conditions are false inside that boundary; this is a finding about the system under review, never a reason to skip a lens;
  - `uninspected` — the evidence needed to decide was unavailable or not inspected;
  - `claimed` — doctrine or reported operation asserts it;
  - `afforded` — inspected code exposes an API, hook, or path that could support it, but no shipped entry path was established;
  - `wired` — inspected implementation routes a shipped entry path through it, without proving operation in a deployed instance;
  - `observed` — a run exhibits it, without proving cause;
  - `causally supported` — an observed interventional comparison plus design evidence supports the attribution at the grain of the actual contrast.
- These statuses are this instruction's namespace, and no value in it collides with the epistemic procedure invoked at step 7. That procedure carries its own vocabulary, in which `implemented` is an *architectural* status contrasting with `doctrine only`; this instruction says `afforded` or `wired` for the neighbouring implementation findings, so the vocabularies can never be silently merged. Record each vocabulary in its own terms.
- Every negative or uncertain result names the inspected boundary and the exact conclusion it prevents.
- Never upgrade: context presence to activation, a claim to an affordance, an affordance to shipped wiring, shipped wiring to observed operation, observation to causality, or operational continuation to warrant.

#### Definitions

- **Memory read-back**: material accumulated or changed through use returns to a later invocation or action. Static shipped material (documentation, tool specifications, installed skills) and ordinary current-run state are retained state, not read-back. The exclusion is per instance, not per kind: where the system itself rewrites such material using material accumulated through use, the rewritten instance is read-back and the as-shipped instance remains retained state; keep the two apart. "Current run" is the consuming agent's invocation boundary, not the host process's lifetime: material that survives from one consumer invocation to the next is read-back even when a long-lived process holds it in memory, and even when only a derived value — a count, a label set, a summary — returns rather than the content itself. Read-back is therefore easy to trigger: where it turns out to be degenerate, that is itself the finding and belongs in a brief memory lens output.
- **Activation**: evidence that delivered material changed behavior, not merely that it entered context.
- **Truth-apt**: capable of truth or falsity. A material epistemic route produces or changes truth-apt content, checks or disposes such a candidate, changes its authority, retains or integrates it for later reliance, or is required to assess a consequential knowledge or warrant claim. Operational curation labels name what a mechanism does to retained material; they do not establish semantic transformation or warrant.
- **Behavioral authority**: one consumption path, recorded in four parts — consumer (who or what receives the material), channel (how it reaches them), force (what it obliges, permits, or merely suggests), and horizon (the span over which the path keeps that force). These four definitions are complete as given; apply them without opening any other document. Example record: `{consumer: spawned lens workers; channel: injected system prompt; force: binding instruction; horizon: the single run that spawned them}`. **Epistemic authority** licenses content and scope; **operational authority** permits or blocks behavior. Keep all three separate; never collapse them into one authority label.
- **Guarantee strength**: a separate dimension from evidence status. Record whether a load-bearing property is an `invariant` over the declared paths, a participant `protocol`, a replaceable `policy`, `best effort`, a `deployment guarantee` supplied by the actual environment, or carries `no claimed guarantee`.

#### Ontology mapping discipline

Commonplace ontology supplies analytical names, not facts about the external system. State the source-native mechanism first, then name the Commonplace concept or controlled value, explain why its defining conditions fit, and qualify the mapping as partial or unresolved when needed. A reader must be able to reject the mapping without losing the operational account.

Closed comparison dimensions require the value, assessed absence, or explicit uncertainty their contract defines. An open-ended mechanism such as frontloading is an evidenced instance only: failure to name it is not evidence that the system lacks it. Record a repeated poor fit as ontology stress in the synthesis or collection projection; never force it into the nearest term or silently invent a new universal category during one review. Ontology normalization may determine what distinctions the analysis exposes, but it never turns the stable result into a comparison with Commonplace.

#### Canonical records and ownership

| Canonical record | Owner | Lens rule |
|---|---|---|
| `SRC-*` source | Orchestrator | Lenses cite; never replace boundary or evidence layer |
| `CMP-*` component, `OBJ-*` operative object | Orchestrator/runtime owns generic identity, form, substrate | Lenses extend by ID |
| `RTE-*` control/context/state/action route | Runtime owns common endpoints and progression | Memory and epistemic lenses annotate, or register one new route centrally |
| `CLM-*` claim | Orchestrator owns identity and claimed operation | Epistemic lens owns truth, scope, and warrant fields for claims inside its boundary |
| `ABS-*` evidenced absence | Orchestrator | Lenses return absences with their recorded search boundary for central registration; cite by ID |
| `BAP-*` behavioral-authority path | Orchestrator | Lenses reference; epistemic and operational authority remain lens-owned |

A record's **generic identity** is what the thing is and what it is made of — its identity, its representational form, and its storage substrate — independent of any lens's annotations. No lens may rename or independently re-inventory a registered object or route. Any new material record returns to the orchestrator for one canonical ID.

Only the orchestrator allocates canonical IDs. A lens needing a new record proposes it under a lens-local tag — `MEM-1`, `EPI-2`, unique only inside that lens — and cites it that way throughout its own return. Each proposal states the record's identity — file path, table name, route endpoints — so the orchestrator can rewrite it to a canonical ID on registration, record the mapping, and merge any proposal whose identity is already registered rather than issuing a second ID for it. Workers never mint a canonical ID: lenses running in parallel cannot see each other's numbering, so unguarded minting collides two different objects on one ID. A proposal tag is not a parallel ID namespace in the sense step 7 forbids — it is discarded at registration and never appears in the emitted result.

A lens return is a **sparse overlay** on the canonical register. For an existing record, return its canonical ID, at most one source-native short label and one local evidence anchor for readability, and only the lens-owned annotations, evidence, and limits. The repeated label and anchor are non-authoritative; any conflict with the register is a correction, not an alternative inventory. Do not repeat generic identity, representational form, storage substrate, common route endpoints or progression, or claimed-operation identity. Only a new-record proposal carries the full generic identity needed for central registration.

Register an evidenced absence as an `ABS-*` record: a finding whose status is `absent`, carrying the named, recorded search boundary that was searched and the conclusion the absence prevents or supports. An `uninspected` gap is not an absence — it stays a limitation and gets no `ABS-*` ID. Register an absence only when it bounds a conclusion someone would otherwise draw; an absence that prevents nothing has no reason to exist, and for any system infinitely many things are absent.

A lens that finds a registered record defective returns the correction with its evidence anchor instead of re-inventorying. A record is defective when it is false, when it is misclassified by the very criterion the record states, or when it is accurate as far as it goes but misleading at the scope it is stated — not only when it is outright wrong. The orchestrator amends the canonical record, preserves the superseded value, and reruns only the work that relied on it. This correction branch is distinct from the targeted-read invalidation in step 2.4: a lens that already derived its findings from the corrected source facts does not repeat its own work.

A material lens return that fits none of the record kinds — a finding *about* a registered record rather than a new component, object, route, claim, absence, or authority path, such as an output asserting something false or a lineage break between two registered records — registers as an **amendment** to the record it attaches to. An amendment carries its evidence anchor and any superseded value, and is cited through the ID of the record it annotates. Never discard a material return for lack of a namespace, and never inflate one into a new record to give it somewhere to live.

#### Worker topology

These rules govern both lenses (steps 6 and 7). The orchestrator retains scheduling, integration, canonical-ID allocation, publication, and recovery. Use fresh worker contexts when they provide independent lens judgment and keep the worker inside the bounded evidence packet; otherwise execute the lens sequentially in the current context against the same registers. If neither path can run a lens, stop with an explicit capacity or dependency blocker — never record the lens as unnecessary, never let a thin scoping record stand in for an unrun lens, and never widen the evidence boundary to compensate.

When delegating, give each worker a task packet that is a delta from the Commonplace doctrine its runtime verifiably supplies. If that baseline is not supplied, include the needed rules instead of assuming them. Freeze the packet before dispatch and assign an immutable packet identity. On every later dispatch, change that identity whenever any supplied boundary, source register, canonical register, instruction, or accepted return field changes. Its header carries the run ID, lens, packet identity, reviewed boundary, source-register identity, and canonical-register identity. A register identity is its digest or an immutable packet-local version that changes with any record or amendment. Do not relabel an in-flight packet; after its return passes the original header check, apply step 2.4's correction check against changes registered during execution. State the lens contribution and its purpose; the accepted return blocks and their required fields; the frozen read-only inputs; any worker-owned output path; the no-reacquisition and no-publication boundary; the sparse-overlay, proposal-tag, and correction protocols; verification; and the stop or escalation condition. Accepted blocks are canonical-ID annotations, locally tagged new-record proposals, corrections or amendments, evidenced absences, and evidence limitations or targeted-read requests. The worker may inspect evidence only inside the frozen boundary and may write only its assigned lens artifact when one exists. It does not edit canonical registers, publish, or delegate again. The worker chooses evidence-supported lens findings. The orchestrator fixes source scope, canonical identity, mutation authority, and acceptance of the worker return.

Require the worker return to echo the complete packet header. Before merging any return, verify exact equality of its run ID, lens, packet identity, reviewed boundary, source-register identity, and canonical-register identity; then verify that every top-level block is accepted, every required field is present, every canonical ID resolves against the supplied register, and every proposal tag is declared once and unique inside the lens. Do not merge a mismatched return or silently discard an unrecognized material block; request a corrected return or redo only the affected lens work. Record the accepted packet identity and header match in reconciliation.

If a worker terminates after producing output whose header matches, its written artifact is authoritative over its own self-report and over any harness failure notice. Verify the artifact against the record set that lens was required to return; accept it when complete and redo only what is missing or unverifiable. A failure notice alone is not grounds for redoing work already written.

### 4. Run and challenge the runtime baseline (always)

1. Treat scheduling, context assembly, and external state/action as causal responsibilities, not mandatory module boundaries; one facility may span more than one. Use the role and target classification from step 1 so an embedded runtime, returning computation, workflow, tool, or builder is assessed at the horizon it actually owns.
2. Begin from claimed work. Register each consequential work story or guarantee as a `CLM-*` record and identify the shipped entry path that would have to uphold it. Claims select the traces and conditional surfaces to inspect; they do not create a universal feature checklist. Separate default entry paths, optional adapters, examples, test fixtures, and integrator hooks.
3. Trace one ordinary invocation end to end: principal and input, identity creation, state transitions, bounded-call context and action surface, model response, effect dispatch, events and runtime-client controls, terminal result, and retained or lost state. For an embedded runtime, trace both the inner invocation and the host contract around it.
4. Before assessing a guarantee, enumerate materially equivalent alternate paths: direct model calls, provider-native tools, raw host callbacks, broad shell access, trusted or generated extension code, subprocesses or remote workers, manual graph control, and durable variants where present. A guarantee covers only the paths its enforcement point covers. Register a path when it changes the analysis question, a control route, evidence strength, or a lens result; do not inventory irrelevant possibilities.
5. When the target's claims or effect risk warrant it, trace the smallest set of forcing cases that challenges the load-bearing conclusions — ordinarily two to four for a full code-grounded runtime pass. Cases may include denial or unresolved authority, interruption or retry, child escalation, process loss, generated execution, or later activation of a durable change. Prefer static inspection. When it cannot establish the behavior and the caller's authority permits execution, select a focused test or probe but do not run it before the preflight in item 6. A doc-grounded run traces the declared route and records the missing implementation or operation evidence instead of simulating certainty.
6. Before executing each selected test or probe, populate the execution-preflight record required by `kb/types/agentic-system-analysis-result.md`. Check the exact command, test, or script; required tools and packages; services; credential availability; relevant configuration; and execution authority. Record only whether a credential is available, never its value. If a dependency is unavailable or authority is absent, set the execution disposition to `not run`, record the run-dependent conclusion as `uninspected`, and add the limitation and conclusion prevented. A wrapper command that starts but stops before the target check executes — during collection, import, dependency, or configuration setup — still leaves that target check `not run`; record the wrapper failure separately. Only a target check that executed may have a passed, failed, or inconclusive outcome.
7. For every executed test or probe, register a `SRC-*` probe evidence capsule satisfying the result type's Source register contract before using its output. Classify it as `observed run` by default; use `causal experiment` and `causally supported` only when the recorded intervention, comparison, and design limits license that attribution. A failed check establishes target behavior only when the capsule shows that the subject route actually executed and the design supports the inference. Retain the capsule and its exact output only inside the already authorized result carrier: inline in a response or one-file result, or in a canonical package part. Do not create a workshop, `cache/`, `state/`, or `retained/` artifact solely to preserve probe output. If a response cannot include the exact output bytes, record the missing-output limitation and do not use that probe to upgrade a finding to `observed` or `causally supported`; a digest without resolvable retained bytes is not inspectable run evidence.
8. For each material loop, record: trigger/input and principal; identities; next-step owner; decision policy and its representational form; context selection and framing; state reads and writes; action executor and boundary; runtime-client signals and controls; persistence; coordination and return; retry, cancellation, and recovery; and terminal output. Split routes when controller, context projection, effect boundary, guarantee, or terminal semantics differ; one facility may therefore produce several linked `RTE-*` records. For each load-bearing guarantee, also record its owner, enforcement point, conclusion status, guarantee strength, alternate paths, and required external contract. Link every record by canonical IDs and cite its evidence. Register the `CMP-*`, `OBJ-*`, and `RTE-*` records this baseline discovers as you go: these are the canonical records the step-2.4 packet carries. For a loop crossing a declared external dependency, record what the in-boundary artifact contributes to each field, mark the remainder as owned by the named external participant, and do not infer that participant's policy; append the limitation naming the conclusions the crossing prevents.
9. Within operational authority, distinguish the **capability surface** exposed to a model, generated program, extension, or worker; the current **grant set** permitted by policy; and the deployed **isolation envelope**, which sets the maximum effects the environment permits regardless of policy. A tool-name allowlist can establish exposure or dispatch without establishing path confinement, secret separation, or attenuated delegation.
10. Keep the anti-conflation rules: a filesystem is not a scheduler; retaining material is not selecting it into context; a tool schema present in context is not tool execution; an API hook is not shipped wiring; a returning computation is not automatically an operational runtime.
11. Inspect permissions, approval routing, delegation, dynamic extension, builder or improvement paths, reliability, observability, providers, runtime clients, packaging, performance, and other surfaces only when they materially alter the claimed work, a control path, evidence strength, or a lens result — and state that materiality when you include one. Define every persistence horizon at the level actually evidenced: model call, top-level run, runtime instance, operating-system process, or later process through discovery and activation. For generated or self-changing behavior, record authorship, byte persistence, later activation, and change target separately. Do not turn this conditional inventory into a universal taxonomy, fixed template, maturity ladder, ranking, or adoption advice.

### 5. Scope the two lenses

Both lenses always run. This step does not decide *whether* — it decides *how deep*, and it is where the trigger evidence is named before any lens worker sees it.

For each lens (memory/context; epistemic), emit one scoping record: `{lens, trigger evidence IDs, inspected boundary, the routes and objects that evidence points the lens at, warranted depth, rationale}`.

- Warranted depth follows the evidence. Rich trigger evidence warrants a full pass; thin or degenerate evidence warrants a brief one. Thin evidence never warrants skipping a lens, and a brief pass is a result, not an omission.
- **The floor for a brief output.** However degenerate the case, a lens output states what was inventoried, what was found, and what conclusions the thinness prevents. Brevity never licenses dropping the prevented-conclusion pairing. A complete brief finding looks like "retention is total, retrieval of content is nil; branch labels are the only accumulated caller-authored text that returns" — short, specific, and bounded.
- **`uncertain` is not a scoping value and not an exit.** Evidence you cannot resolve becomes an explicit evidence limitation *inside* the lens output, paired with the conclusion it prevents. Never let it end a lens: an exit that means "we could not tell" reads to every later reader as "there is nothing there."
- An absent lens section or file must never carry meaning implicitly. Every run emits both scoping records and both lens outputs.

**Memory/context evidence.** Look for a path by which material accumulated or changed through use can affect a later invocation or action, in code, documentation, or observation. Static shipped material, ordinary current-run state, and retained material with no later delivery path are not such paths — where these are all you find, scope the lens brief rather than absent, and say so. A merely claimed path is trigger evidence; the lens output preserves whether the path is `claimed`, `afforded`, `wired`, or `observed`.

**Legacy memory-review routing.** Separately decide whether the selected target is itself an external memory, knowledge, or context-engineering system. Detect it when the target's primary offered work is to retain, transform, organize, select, or deliver material or bounded-call context for later agent work. Also detect an explicitly requested, independently bounded subsystem with that role. Do not detect one merely because a general runtime has session state, one read-back route, or an incidental memory component; the embedded memory/context lens still covers those. Record `{selected subject, detected or not detected, evidence IDs, rationale, legacy publication authority}`. If the evidence cannot establish the classification, record the gap and the conclusion it prevents; never let uncertainty silently skip the conditional invocation.

**Epistemic evidence.** Look for a material route that handles truth-apt content, and for any consequential knowledge-production or warrant claim the system makes — including where the eventual finding is failure or absence. Successful knowledge production is never a prerequisite for running the lens.

**Direct-adaptation exception.** Evaluated direct behavior or policy adaptation with no truth-apt object and no knowledge or warrant claim is not an epistemic object. The exception scopes what the epistemic lens treats as its objects; it does not decide whether the lens runs. Such a route stays in the runtime account, and the scoping record names it for the orchestrator. Hand it to the invoked epistemic procedure tagged **classify-only**: that procedure classifies every content-changing edge it meets and carries a class for exactly these routes, so withholding one would leave a silent hole in its ledger. Classify-only means the route is recorded in its content/update classification and is *not* analysed for warrant, transformation, or acceptance. If the lens concludes the route is in fact truth-apt, that comes back as a correction under step 3's correction branch — never as a silent expansion of the lens's own scope.

### 6. Run the memory/context lens and the detected-memory workflow

Always analyse accumulated-from-use mechanisms in the embedded lens. Work at the depth the step-5 scoping record warrants: the items below are the full pass, and a brief pass covers the same ground proportionately rather than skipping items silently.

1. Annotate retained operative parts already in the canonical register and propose any newly discovered part under a lens-local tag, splitting bundled artifacts whenever content, form, producer/consumer, checks, or authority path differs. For an existing part, cite its canonical form and substrate without copying them, then record persistence, lineage, producer and consumer, invalidation/regeneration conditions, and any promotion path toward stronger form or force — movement toward a more binding representation, such as natural-language note to schema or code, or toward a stronger consumption force, such as suggestion to binding instruction. For a proposal, also supply the generic identity, storage substrate, and representational form — natural-language, symbolic (code, schema, grammar), distributed-parametric (model weights), or mixed — needed for central registration.
2. Separate the write side from read-back. Record whether write agency is manual, automatic, or both; separate acquisition and index maintenance from curation; where applicable, identify consolidation, deduplication, evolution, synthesis, invalidation, decay, and promotion; where relevant, distinguish raw traces from distilled retained artifacts.
3. Annotate the runtime-owned context route with: read-back direction (pull, push, or both, from the receiving agent's perspective), selection signal, targeting, selection scope and budget, delivery and consumption point, and any behavioral-faithfulness test. Post-turn capture or consolidation is write-side maintenance, not a second read-back point.
4. Record context presence, shipped wiring, observed operation, activation, and causal effect as separate findings with separate evidence.
5. Reference `BAP-*` records for authority; do not let authority-family labels substitute for consumer, channel, force, and horizon. Keep lineage and curation labels independent of epistemic transformation, acceptance, and warrant — a `consolidate` or `import` label never establishes semantic preservation.
6. Omit entirely: checkout, archive, and publication mechanics; Commonplace comparison; transfer suggestions; curiosity passes; watch items; collection routing. Commonplace ontology remains available under step 3's mapping discipline because it classifies the external mechanism rather than comparing systems.

When the step-5 routing record says `detected`, always invoke [Write an agent memory system review](../write-agent-memory-system-review/SKILL.md) with a prepared-source packet. With no publication authority, pass the run ID, selected subject and stable slug, source register, and no-authority disposition; the invoked procedure returns `not published — legacy review output not authorized` before mutation.

For an authorized publication, prepare the remaining packet as follows:

1. Derive the legacy review's `source-tier` for the selected subject from the frozen evidence.
2. Use the caller's path, or derive `kb/agent-memory-systems/reviews/{subject_slug}.md` for `code-grounded` and `kb/agent-memory-systems/lightweight/{subject_slug}.md` for `doc-grounded`. If that path belongs to another source identity, derive an owner- or source-qualified slug from the canonical `SRC-*` identity. Use the resulting path only when it is free or already belongs to the selected subject; otherwise return a path-collision blocker. Fix the mutation set after this check.
3. Derive the citation format from the frozen register's anchors: for example, commit-pinned file URLs for a GitHub checkout or identified snapshot/document links for doc-grounded evidence. If no publishable format can be derived, carry that limitation so the invoked procedure returns its citation blocker.
4. Pass the run ID; selected subject and stable slug; publication-authority disposition; `source-tier`; frozen `SRC-*` register and inspectable locations or bundle; reviewed revision or capture; citation format; evidence limitations; exact review and auxiliary mutation set; matrix/table authority or stale disposition; separately commissioned landscape-synthesis path and reconstructable snapshot or no-commission disposition; and local-drafting fallback disposition.

The invoked procedure must reuse the boundary. It must not clone, fetch, refresh, capture, or widen it.

The embedded lens remains the canonical memory contribution to this run; the invoked workflow produces the existing collection-specific review and its QA report. Do not substitute one for the other. Record the invocation's review path and validation result, downstream matrix/table and landscape-synthesis disposition, or its no-publication, unsupported-boundary, unavailable-delegation, or other blocker disposition, inside the memory lens output. A legacy-publication blocker does not erase a complete response-only system analysis, but a requested legacy review is incomplete until that blocker is cleared.

### 7. Invoke the epistemic procedure

1. Invoke the procedure in `kb/instructions/analyse-external-system-epistemic-architecture.md` to run the accepted route-analysis method inside this run's boundary. Every run invokes it. Do not copy or restate its object-inventory, route-ledger, transformation, lifecycle, claim-comparison, or authority method.
2. Pass to the invocation: a bounded epistemic subquestion, the run and system boundary, the frozen revision, the `SRC-*` register and evidence packet, the existing canonical records, the step-5 scoping record with its trigger evidence, and any classify-only routes the direct-adaptation exception named. The scoping record governs the invocation's depth: it tells the invoked procedure whether it is building a full route ledger or bounding and confirming a thin finding. Depth is the only thing it governs — the wrapper rules below hold identically at either depth.
3. Enforce the wrapper rules: no source reacquisition, no boundary widening, no revision change, no silent evidence upgrade, no parallel ID namespace, no independent publication decision, no system-wide epistemic grade. Its status vocabulary stays its own: record its architectural `implemented` under that name and this run's conclusion statuses under theirs. The two sets share no value, so a return that needs both carries both.
4. Require sparse linked returns under the worker-topology contract: material objects, routes, and claims by canonical ID; transformation class and route function; architectural status and observed candidate state; checking, acceptance, and retention/integration findings; the three authority records kept separate; and missing evidence paired with the conclusions it prevents — or, where the invoked procedure takes one of its early branches, that branch's own required substitutes, the no-candidate statement and the explicit no-claim comparison, which satisfy this requirement. Any new record or targeted-evidence request returns to the orchestrator for registration, and affected work is rerun.

### 8. Reconcile and synthesize

1. Merge duplicate objects and routes by canonical ID. Preserve anchored evidence conflicts as conflicts; never resolve one by selecting the strongest-sounding status. Record independently convergent findings as convergence and name the two derivations.
2. Keep ownership: the runtime baseline owns complete control and context routes; the memory lens annotates read-back and activation; the epistemic lens annotates transformation, checking, warrant, acceptance, integration, and its two authorities.
3. Check every shared route for one revision, consistent sources, endpoints, objects, and `BAP-*` references. Memory curation labels cannot determine epistemic transformation; behavioral influence cannot imply epistemic or operational authority.
4. When the legacy memory-review workflow produced a review, verify that its source identity and revision equal this run's frozen boundary, then compare its central artifact, write-side, and read-back claims with the canonical memory records. Treat its controlled fields as a collection projection, not a second record namespace. Resolve a material contradiction from the frozen sources and redo the affected review QA or run finding; never preserve two incompatible current claims merely because the outputs have different forms.
5. Write the synthesis as an evidence basis and boundary, an architectural characterization and claimed work, a runtime map, only the discriminating mechanism sections this target needs, a scenario-relative assessment, and concrete changes that would alter the assessment. Organize the mechanism account around the operational progression — scheduling, context, state and action, memory return where applicable, truth-apt and warrant routes where applicable, and governing controls — not as concatenated lens reports. Where Commonplace ontology improves comparison, preserve the source-native mechanism, ontology mapping, rationale, and qualification together. Surface a poor fit as ontology stress rather than a forced label. Preserve affordance-versus-wiring-versus-operation and evidence-layer limits inside the synthesis. Mention a lens's thinness only where it bounds conclusions. Do not assign a system-wide epistemic grade or add current Commonplace implications.
6. In the assessment, distinguish a supported mechanism for a named work story, a responsibility deliberately externalized through a named contract, a tradeoff, a gap relative to claimed work, an unknown, and a misleading implication. Do not treat a non-runtime mechanism as a deficient runtime or turn the assessment into a total ranking.

### 9. Assemble the stable result

Assemble one entry artifact conforming to `kb/types/agentic-system-analysis-result.md`. That type is the single authority for the result's frontmatter, eleven-section reading order, shared-record subdivisions, lens subdivisions, status-field separation, blocker shape, and package-pointer convention. Do not maintain a second run-result template in this skill. This skill owns how the records are produced and how their lifecycle is selected; the type owns what the finished result contains.

Rules:

- Set `result-disposition` to `complete`, `blocked`, or `out-of-scope`. Every disposition uses the same typed entry artifact and retains all required headings. A stopped run marks records as unreached because of its named stopping condition; it does not invent findings or switch to an unstructured blocker report.
- Give the run result one canonical identity, with IDs resolvable across all physical parts. A response's delimited stable block is the complete typed entry artifact. A one-file result is the typed entry artifact. A package has exactly one typed entry artifact; each distributed logical record is reached through the type's section-local pointer convention.
- A transfer scan is a separate side report, not a twelfth logical record. Neither its disposition nor its selected findings are needed to complete the stable result.
- Without an authorized whole-system file target, return the logical run result in the response and create no whole-system staging artifact. A separately authorized legacy memory review from step 6 may still be emitted under its own existing contract. If the run belongs to an active investigation, working ledgers and drafts may live only in its authorized `kb/work/<workshop>/` boundary. Retain the exact run record under `kb/reports/retained/` only when a named future operation consumes that exact record; use `kb/reports/state/` or `cache/` only when an existing owning workflow defines its integrity and cleanup rules. Read the applicable `COLLECTION.md` before writing under any of these paths.
- A durable external-system analysis belongs under `kb/agentic-systems/` only when the caller authorized publication and that collection's current contract can represent it. Distill the compact synthesis from the run result; the library artifact need not reproduce working ledgers, but it must carry the evidence basis and limits needed for its claims and must not depend on ignored `state/` or `cache/` files. Do not improvise a collection or type contract, and do not reuse the agent-memory review schema.
- No file publication is a blocker only when the caller requested a file result and no authorized lifecycle owner can place the typed result or a permitted compact projection. Publishable limitations include doc-only evidence, inaccessible components, no observed run, no causal experiment, trigger evidence too thin to resolve, and conflicting evidence — each naming its scope and prevented conclusion. Result blockers include missing required records, ID collisions, unsupported material claims, and failed validation.

### 10. Verify and freeze the stable result

1. Verify conformance to `kb/types/agentic-system-analysis-result.md`, then verify: source anchors; every conclusion-status field contains exactly one of the eight values listed in step 3; epistemic architectural status and observed candidate state occupy separate fields; no record carries `implemented` as a conclusion status; unique, resolving IDs; every delegated lens return matched its run and frozen-packet header before merge; every selected dynamic check has one preflight record and every executed check has one resolving probe evidence capsule; no `not run` check is treated as failure or absence; no probe with missing exact output supports `observed` or `causally supported`; one target classification, boundary, and revision across all records; ordinary and material alternate routes covered; each warranted forcing case completed or bounded, with a rationale when none is warranted; load-bearing guarantees name their owner, enforcement point, strength, paths, and external contract; both lens scoping records present; both lens outputs present, each meeting the brief-output floor; one legacy memory-review routing record; invocation of the legacy workflow whenever that record says `detected`; source-native mechanisms retained beneath ontology mappings; prevented conclusions stated for every thin, negative, or unresolved finding; shared-route ownership respected; and no forbidden evidence upgrades.
2. Check each distinction explicitly: a target mechanism is not automatically a runtime; an API affordance is not shipped wiring; shipped wiring is not observed operation; a capability surface is not a grant set or isolation envelope; retention is not read-back; context presence is not activation; observation is not causality; curation is not warrant; use is not acceptance; behavioral authority is not epistemic or operational authority.
3. Run `commonplace-validate` on the typed entry artifact and run any additional deterministic validation required by the selected lifecycle target. For a response, assemble the exact stable block as the typed Markdown artifact, copy those unchanged bytes to a temporary `.md` validation target outside the repository, validate that target from the repository root, and remove the temporary copy after freezing or authorized capture. For a package, validate the one typed entry artifact after every section pointer resolves. Record the exact target and result under `### Deterministic validation`. Do not change the schema, omit frontmatter, or adopt another type to make a failed result pass.
4. Correct and reassemble the stable result after any failed check. If a result blocker remains, set `result-disposition: blocked`, populate every required section with the blocker-relative disposition, revalidate, freeze that typed result, and do not run a transfer scan. Otherwise freeze the exact verified result before transfer work begins: write an authorized file or package, or hold the stable response block unchanged for the final response.
5. Fingerprint the frozen analysis when the result is a file or package, a transfer scan was commissioned, an owning workflow requires byte identity, or the caller requested a digest. One file gets its byte length and SHA-256; a package gets the canonical manifest and manifest digest required by `scan-agentic-system-transfer`. For a response, read and apply [Fingerprint a response analysis](references/response-fingerprint.md): hash only its delimited stable block and put the digest outside that block. Otherwise record `fingerprint: not required — response-only result with no downstream byte-identity consumer`. Any correction after fingerprinting invalidates the digest and returns here before transfer.

### 11. Route a selective transfer scan only after stable verification

1. The verified stable result and any durable system or memory review are complete without a Commonplace delta. Never add transfer findings to canonical records, controlled fields, the matrix, or the public system synthesis.
2. When no transfer scan was commissioned, record `transfer scan: not requested` and continue. When the request lacks an explicit current interest brief, digestible complete analysis input, or output authority needed for its requested form, report that transfer-specific gap without weakening the completed stable analysis.
3. When commissioned, invoke [Scan an agentic system for current transfer](../scan-agentic-system-transfer/SKILL.md) only after step 10 has frozen and fingerprinted the stable result with no result blocker. Pass the exact analysis file and digest, the complete package manifest and digest, or the exact delimited stable response block and digest; the run/result identity; the exact interest brief; permitted Commonplace read scope; response-only or state-output and response-capture authority; and the prohibition on source reacquisition, canonical-analysis edits, matrix input, and automatic promotion. Use a fresh worker when the caller authorized delegation; otherwise invoke it in the current context and report that the transfer judgment was not independently isolated.
4. The scan owns only its response or authorized file under `kb/reports/state/agentic-system-transfer/`. The orchestrator verifies the output against the scan contract, records only its path or response disposition in the final operator report, and leaves every promotion candidate undecided. If the scan uncovers a possible stable-analysis defect, do not patch around it: invalidate the scan, return to the affected analysis step, reverify and refingerprint the stable result, then rerun the scan against the new digest.

### 12. Emit and report

Emit the frozen response result now when the run was response-only; do not alter its stable block after fingerprinting.

In the operator report outside that block, include this explicit notice for a response-only run: `canonical-result commit visibility: none — no standalone repository artifact was written; the canonical result exists only in this response unless a separately authorized downstream operation captures it.` Report any such capture by its separate path and state that it does not convert the response-only result into a published analysis. The notice does not grant write, capture, retention, or publication authority.

Also report: result identity and response or authorized locations; target classification; boundary, revision, and tier; both lens scoping records and the depth each lens ran at; legacy memory-review detection, invocation, path, and validation or blocker disposition; stable-result verification and digest or not-required disposition; transfer-scan not-requested, response, state path, or transfer-specific blocker disposition; retention disposition for any files; limitations; and blockers.

## Verify

- The run has one run/result ID, one declared boundary, one frozen revision or capture, and one source register that every lens record cites.
- Both lenses ran. Both scoping records and both lens outputs exist as explicit records; nothing is implied by an absent section, and a brief output still names what was inventoried, what was found, and what its thinness prevents.
- The run records whether the selected target is a memory, knowledge, or context-engineering system. When detected, the legacy review procedure ran against the same frozen boundary and returned either a validated review path or an explicit blocker/no-publication disposition.
- No conclusion status was upgraded; every negative or uncertain finding names its inspected boundary and prevented conclusion.
- Commonplace terms normalize evidenced external mechanisms; no label replaces the source-native account, and open-ended omissions carry no absence claim.
- The runtime account classifies the target, traces the ordinary and material alternate paths, and attributes every load-bearing guarantee to its owner and enforcement point.
- A response-only operator report states that no standalone canonical result is commit-visible, reports any separately authorized downstream capture by its own path, and grants no write or lifecycle authority through that notice.
- The synthesis is organized around the system, contains no system-wide epistemic grade, and the emitted entry artifact conforms to `kb/types/agentic-system-analysis-result.md` for every result disposition. Any file output follows an authorized collection and retention contract.
- The stable result passed semantic and applicable deterministic verification, was frozen, and, when byte identity was required, was fingerprinted before any transfer scan began.
- Any Commonplace transfer scan is separately commissioned, interest-conditioned, keyed to the complete analysis digest, held as operational state until disposition, excluded from the canonical result and matrix, and reported only by disposition.

---

- [Agent-runtime analysis should separate scheduling, context assembly, and external state](../../notes/agent-runtime-analysis-should-separate-scheduling-context-state.md) — rests-on: the three causal runtime responsibilities behind step 4
- [Agent orchestration occupies a multi-dimensional design space](../../notes/agent-orchestration-occupies-a-multi-dimensional-design-space.md) — rests-on: why the runtime inventory stays open rather than becoming a taxonomy
- [Runtime structure determines the control surfaces available to governance](../../notes/runtime-structure-determines-governance-control-surfaces.md) — rests-on: why governance surfaces are conditional, crosscutting inspections
- [Agent memory is a crosscutting concern, not a separable niche](../../notes/agent-memory-is-a-crosscutting-concern-not-a-separable-niche.md) — rests-on: why memory is a lens inside system analysis, not a peer category
- [Knowledge storage does not imply contextual activation](../../notes/knowledge-storage-does-not-imply-contextual-activation.md) — rests-on: the retention/read-back/presence/activation distinctions in steps 3, 5, and 6
- [Behavioral authority](../../notes/definitions/behavioral-authority.md) — rests-on: the consumer/channel/force path definition behind `BAP-*` records
- [Skills are instructions plus routing and execution policy](../../notes/skills-are-instructions-plus-routing-and-execution-policy.md) — rests-on: the SKILL.md packaging that gives this instruction discovery, user invocation, and execution policy
- [Frontloading spares execution context](../../notes/frontloading-spares-execution-context.md) — rests-on: why the runtime and memory/context procedures are embedded rather than left for the executor to reassemble
- [Model-resolved indirection adds interpretation work to LLM execution](../../notes/model-resolved-indirection-adds-interpretation-work-to-llm-execution.md) — rests-on: the interpretation cost weighed when embedding lenses versus invoking the epistemic instruction by path
- [Scenario decomposition drives architecture](../../notes/scenario-decomposition-drives-architecture.md) — rests-on: why claimed work selects ordinary and forcing traces before architectural guarantees are assessed
- [Intent-framed delegation is a control regime; prompt length does not establish it](../../notes/intent-framed-delegation-is-a-control-regime-not-a-short-prompt.md) — rests-on: the retained-orchestrator ownership and task-packet rules for lens workers