Reconstruction: analyse an agentic system

Reconstruction stance

USER DIRECTION: The public entry point is singular and system-first. It fixes one reviewed boundary, revision, source tier, and evidence register; analyses ordinary runtime responsibilities; records applicability for the memory/context and epistemic lenses; reconciles shared objects by stable IDs; and produces one bounded synthesis. Memory is inside agentic-system analysis when applicable, regardless of why Commonplace historically gave it a separate collection. Source: kb/work/analyse-agentic-system/brief.md.
EVIDENCE: The current procedures and artifacts do not yet implement that architecture as one workflow. They provide a mature memory-review production workflow, an accepted standalone epistemic-analysis procedure, a bounded comparative whole-system precedent, and several heterogeneous whole-system analyses. Sources: kb/instructions/write-agent-memory-system-review/SKILL.md; kb/instructions/analyse-external-system-epistemic-architecture.md; kb/reports/retained/epistemic-architecture-analysis-trials-20260820/acceptance.md; kb/work/pi-agent-zerostack-comparison/review-instruction.md; kb/agentic-systems/reviews/agno-agentos.md; kb/agentic-systems/reviews/claude-code-dynamic-workflows.md; kb/agentic-systems/reviews/exo.md; kb/agentic-systems/reviews/gbrain.md.
INFERENCE, not decision: The unified instruction can reuse established distinctions, but it cannot be obtained by concatenating the three procedures. Their boundaries, evidence records, artifact contracts, and publication responsibilities differ.

1. Established mechanisms and distinctions

1.1 Whole-runtime analysis

Three analytical responsibilities are already established. Scheduling owns control progression; context assembly selects and frames what a bounded model call receives; external state and action services preserve exact state, execute operations, and enforce environmental boundaries. These are causal responsibilities, not required module boundaries, and one facility may span more than one. Source: kb/notes/agent-runtime-analysis-should-separate-scheduling-context-state.md.
Runtime diagnosis follows those responsibilities. A wrong next step points toward scheduling; missing or badly framed evidence points toward context assembly; corrupted retained state, failed commands, or boundary violations point toward external services. A filesystem is not a scheduler, retaining a transcript is not selecting it for the next call, and exposing a tool schema in context is distinct from executing the tool. Source: kb/notes/agent-runtime-analysis-should-separate-scheduling-context-state.md.
Orchestration is an open, multi-dimensional design space. Established dimensions include scheduler placement, the representational form and substrate of the decomposition policy, persistence horizon, coordination form, coordination guarantee, and boundary-return artifact. The dimensions are salient rather than exhaustive and must not become a universal maturity ladder. Source: kb/notes/agent-orchestration-occupies-a-multi-dimensional-design-space.md.
Governance is crosscutting, not a fourth runtime component. Explicit scheduling affords preventive controls over progression; explicit context selection affords loading audits; inspectable external state affords diff, validation, rollback, and drift detection. Hidden decisions leave governance more reactive. Source: kb/notes/runtime-structure-determines-governance-control-surfaces.md.
The bounded whole-system precedent expands the reading inventory where the system warrants it. It covers loop construction, cancellation and retries, TUI and user control, sub-agents and branching, tool authority, permissions and sandboxing, provider integration, retained state, replay, observability, validation, packaging, and adoption. It explicitly treats its axes as a reading inventory to be merged around salient differences, not as a mandatory fixed-row taxonomy. Source: kb/work/pi-agent-zerostack-comparison/review-instruction.md.
Evidence status is already a load-bearing distinction in whole-system work, although not uniformly encoded. Current analyses separate documented design from inspected implementation and withhold deployed-operation claims when no run was observed. Examples include Agno's explicit “did not run a live deployment,” Exo's code-grounded but non-live analysis, GBrain's code-grounded boundary, and the comparison instruction's rule that README performance or safety claims remain hypotheses until supported. Sources: kb/agentic-systems/reviews/agno-agentos.md; kb/agentic-systems/reviews/exo.md; kb/agentic-systems/reviews/gbrain.md; kb/work/pi-agent-zerostack-comparison/review-instruction.md.

1.2 Memory/context analysis

Memory is already decomposed into storage, retrieval/activation, and learning-from-use. Storage belongs mainly to the external substrate; retrieval and read-back belong to context assembly; learning reads and writes across those surfaces and aims at later action capacity. Memory is therefore a crosscutting lens, not a fourth peer runtime component. Source: kb/notes/agent-memory-is-a-crosscutting-concern-not-a-separable-niche.md.
Retained state, memory read-back, and activation are distinct. Read-back is accumulated-from-use material returning to a later action. Static shipped documentation, tool specifications, and installed skills are retained state but not memory read-back. Context presence is necessary for activation but does not show that the material changed what the agent did. Source: kb/notes/knowledge-storage-does-not-imply-contextual-activation.md.
The memory artifact record is mature. Central behavior-shaping operative parts are classified by storage substrate, representational form, lineage, and behavioral-authority family; bundled artifacts are split when their consumption paths differ. The type also asks for invalidation/regeneration conditions and any promotion path toward stronger form or force. Source: kb/agent-memory-systems/types/agent-memory-system-review.md.
The write side is separated from the read side. Write-side agency is manual and/or automatic. Automatic operations over already-retained memory are consolidate, dedup, evolve, synthesize, invalidate, decay, and promote; acquisition and index maintenance are separate from curation. Trace-learning is the automatic-from-traces specialization and distinguishes raw traces from distilled retained artifacts. Sources: kb/agent-memory-systems/types/agent-memory-system-review.md; kb/agent-memory-systems/review-framework-design.md.
The read-back path has operational axes. Direction is pull, push, or both from the receiving agent's perspective. Push is further described by coarse versus instance targeting, identifier versus inferred signals, selection scope and budget, authority at consumption, and whether the system tests behavioral faithfulness. Post-turn capture or consolidation is write-side maintenance, not a second read-back point. Sources: kb/agent-memory-systems/types/agent-memory-system-review.md; kb/agent-memory-systems/review-framework-design.md; kb/notes/knowledge-storage-does-not-imply-contextual-activation.md.
Behavioral authority is path-relative. It names a consumer, channel, and force; the same stored bytes can have different authority on different consumption paths. Knowledge/system-definition labels are families, not intrinsic properties of a file. Source: kb/notes/definitions/behavioral-authority.md.
Capability and deployed behavior are already separated. A library API can afford push without proving that a host agent wires it; code can show a selection policy without showing actual precision, context dilution, or behavioral use. Source: kb/agent-memory-systems/types/agent-memory-system-review.md.

1.3 Epistemic analysis

The epistemic procedure begins with a declared source, claim, and route boundary. Sources receive stable IDs and evidence layers: implementation, doctrine/design, reported operation, observed run, or causal experiment. Missing evidence is paired with the exact conclusion it prevents. Source: kb/instructions/analyse-external-system-epistemic-architecture.md.
Materiality is route-based. A route is included when it produces or changes truth-apt content, checks or disposes a candidate, grants or changes authority, retains or integrates a candidate for later reliance, directly adapts behavior or policy from evaluation, or is needed to assess a consequential knowledge/warrant claim. Plumbing is included only when it changes lineage or warrant, carries force, or belongs to such a claim. Source: kb/instructions/analyse-external-system-epistemic-architecture.md.
Objects precede evaluators. The procedure inventories typed operative objects and splits parts that differ in content, form, producer/consumer, checks, or authority path before constructing a route ledger. Source: kb/instructions/analyse-external-system-epistemic-architecture.md.
Content change and route function are independent. Truth-apt edges are classified as acquisition/import, non-ampliative reshaping, entailed derivation, ampliative conjecture, or indeterminate. Non-truth-apt policy/content updates and routes with no content change remain representable. Route functions, architectural status, activation, results, and authority are recorded separately. Source: kb/instructions/analyse-external-system-epistemic-architecture.md.
Architectural capability and episode evidence are separate. A route may be implemented, observed with implementation uninspected, doctrine only, absent within the declared boundary, or not determinable. An observed candidate separately may have no instance observed, not reached, phase evidenced, accepted, rejected, revised, failed, suspended, integrated, or not determinable. Implementation alone cannot establish an episode disposition. Source: kb/instructions/analyse-external-system-epistemic-architecture.md.
Checking, acceptance, retention, integration, and use are distinct transitions. Acceptance requires an evidence-consuming decision against a named criterion for an intended use and scope. Lifecycle integration is post-acceptance; retention or operational use before acceptance is not integration. Operational continuation does not imply epistemic warrant. Source: kb/instructions/analyse-external-system-epistemic-architecture.md.
Three kinds of authority remain separate. Epistemic authority is the licensed content and scope; operational authority is what behavior a result permits, blocks, or changes; behavioral authority is the consumer/channel/force/horizon by which the result becomes consequential. Source: kb/instructions/analyse-external-system-epistemic-architecture.md.
Claims are compared across evidence layers and conclusions remain route-bounded. The procedure prohibits transferring an outcome to its producing process, explanation, replay safety, transfer, or component effect, and requires intervention plus design evidence before causal attribution. Source: kb/instructions/analyse-external-system-epistemic-architecture.md.
The standalone procedure has discriminated two unlike systems. ARC exposed prediction, history-fit, replay, and continuation routes while preserving absent run/causal evidence; GBrain exposed unchecked synthesis, retention without acceptance, operational use without epistemic authority, and benchmark-bounded direct policy adaptation. Acceptance was based on those cold runs plus anchored repairs to the final text. Sources: kb/reports/retained/epistemic-architecture-analysis-trials-20260820/arc-trial.md; kb/reports/retained/epistemic-architecture-analysis-trials-20260820/gbrain-trial.md; kb/reports/retained/epistemic-architecture-analysis-trials-20260820/acceptance.md.

2. Shared concerns and plausible ownership

The ownership entries below are INFERENCES, except where the brief already fixes public-workflow ownership. They are reconstruction hypotheses, not design decisions.

Concern	Shared fact	Plausible owner	Basis
System identity, declared boundary, exclusions, revision, and overall evidence tier	Every lens depends on the same answer; changing it between lenses invalidates reconciliation.	USER DIRECTION: public workflow owns one canonical boundary and passes it to lenses.	`kb/work/analyse-agentic-system/brief.md`; `kb/instructions/analyse-external-system-epistemic-architecture.md`; `kb/instructions/write-agent-memory-system-review/SKILL.md`
Source preparation and evidence register	Memory production pins a checkout; epistemic analysis assigns stable source IDs and evidence layers; whole-system work records evidence basis and revision.	USER DIRECTION: public workflow owns preparation and a canonical source register. Lenses cite it rather than establish new revisions.	`kb/work/analyse-agentic-system/brief.md`; `kb/instructions/write-agent-memory-system-review/SKILL.md`; `kb/instructions/analyse-external-system-epistemic-architecture.md`; `kb/agentic-systems/COLLECTION.md`
Runtime components and control progression	Scheduling, context assembly, and external state/action are the general anatomy within which memory and epistemic routes operate.	INFERENCE: runtime baseline owns the system map and ordinary control progression.	`kb/notes/agent-runtime-analysis-should-separate-scheduling-context-state.md`; `kb/notes/runtime-structure-determines-governance-control-surfaces.md`
Context assembly	Runtime analysis asks what each call receives; memory read-back asks when accumulated material enters that assembly.	INFERENCE: runtime baseline owns the complete context-assembly path; memory lens annotates the accumulated-from-use subset and its selection signal.	`kb/notes/agent-runtime-analysis-should-separate-scheduling-context-state.md`; `kb/notes/knowledge-storage-does-not-imply-contextual-activation.md`; `kb/agent-memory-systems/types/agent-memory-system-review.md`
Retained objects and operative parts	Runtime state, memory artifacts, and epistemic objects may be the same stored object viewed for different purposes.	INFERENCE: public workflow or runtime baseline assigns canonical object IDs and generic form/substrate fields; lenses add memory lineage/read-back and epistemic candidate/warrant fields. DECISION NEEDED: exact common record.	`kb/agent-memory-systems/types/agent-memory-system-review.md`; `kb/instructions/analyse-external-system-epistemic-architecture.md`; `kb/notes/definitions/behavioral-authority.md`
Retention, write, and maintenance	These are ordinary external-state operations, memory write-side mechanisms, and sometimes epistemically material lineage or integration routes.	INFERENCE: memory lens owns the detailed write/curation account; runtime baseline locates the service; epistemic lens only expands routes that meet its materiality rule.	`kb/agent-memory-systems/types/agent-memory-system-review.md`; `kb/notes/agent-memory-is-a-crosscutting-concern-not-a-separable-niche.md`; `kb/instructions/analyse-external-system-epistemic-architecture.md`
Read-back and activation	Read-back is a context-delivery path; activation is actual behavioral use, which may require observed evidence.	INFERENCE: memory lens owns direction, signal, scope, and faithfulness; the public synthesis must not upgrade context presence into observed activation.	`kb/notes/knowledge-storage-does-not-imply-contextual-activation.md`; `kb/agent-memory-systems/types/agent-memory-system-review.md`
Truth-apt transformation and warrant	A memory write may acquire, reshape, derive, or conjecture content; storage labels alone do not establish which.	INFERENCE: epistemic lens owns semantic transformation class, warrant, checking, acceptance, and discovery-lifecycle disposition; memory keeps operational curation labels.	`kb/agent-memory-systems/types/agent-memory-system-review.md`; `kb/instructions/analyse-external-system-epistemic-architecture.md`
Behavioral-authority path	Memory and epistemic procedures both need consumer, channel, and force; epistemic analysis also needs horizon.	INFERENCE: one canonical path record should be shared, with memory's controlled family tokens derived or attached rather than separately re-described. DECISION NEEDED: whether the public workflow or runtime baseline owns it.	`kb/notes/definitions/behavioral-authority.md`; `kb/agent-memory-systems/types/agent-memory-system-review.md`; `kb/instructions/analyse-external-system-epistemic-architecture.md`
Epistemic and operational authority	These are licenses or transitions, not synonyms for behavioral influence.	INFERENCE: epistemic lens owns them for material routes; runtime synthesis reports their consequences without flattening them into one authority label.	`kb/instructions/analyse-external-system-epistemic-architecture.md`
Coordination, permissions, recovery, observability, and governance surfaces	They can shape runtime control and the evidential strength available to both lenses.	INFERENCE: runtime baseline owns their ordinary mechanisms; a lens references them when they alter memory activation, lineage/warrant, or route force.	`kb/work/pi-agent-zerostack-comparison/review-instruction.md`; `kb/notes/runtime-structure-determines-governance-control-surfaces.md`; `kb/agentic-systems/reviews/agno-agentos.md`; `kb/agentic-systems/reviews/exo.md`; `kb/agentic-systems/reviews/gbrain.md`
Applicability and explicit early exits	Inapplicability is a whole-analysis routing decision; each lens knows its own semantic trigger and prevented conclusions.	USER DIRECTION: public workflow records the disposition. INFERENCE: each lens returns the evidence, conclusion limits, and any uncertainty needed for that disposition.	`kb/work/analyse-agentic-system/brief.md`; `kb/instructions/analyse-external-system-epistemic-architecture.md`; `kb/notes/knowledge-storage-does-not-imply-contextual-activation.md`
Cross-lens synthesis, artifact identity, publication, QA, validation, and final report	These concern the result as one system analysis, not any single lens.	USER DIRECTION: public workflow owns them.	`kb/work/analyse-agentic-system/brief.md`; `kb/instructions/write-agent-memory-system-review/SKILL.md`

3. Conflicts and boundary mismatches

3.1 Collection model versus governing direction

Conflict: The current agentic-systems contract says memory and knowledge subsystems are carved out and that the collection covers “everything else”; its README and current Exo/GBrain analyses follow that split. The user direction says the separate memory collection is historical, not conceptual, and requires memory to run as a conditional lens within whole-system analysis. The current collection text is evidence of existing practice, not authority over this task. Sources: kb/agentic-systems/COLLECTION.md; kb/agentic-systems/README.md; kb/agentic-systems/reviews/exo.md; kb/agentic-systems/reviews/gbrain.md; user authority in kb/work/analyse-agentic-system/brief.md.
Boundary mismatch: Current split analyses can use different revisions. The Exo whole-system analysis is pinned to ef4cfe05, while it states that the memory review remains pinned to the earlier baa07f67; GBrain happens to use the same commit for both. A unified analysis cannot reconcile lens findings silently across such revision skew. Sources: kb/agentic-systems/reviews/exo.md; kb/agentic-systems/reviews/gbrain.md; user requirement in kb/work/analyse-agentic-system/brief.md.

3.2 Source preparation and evidence model

Conflict: The memory skill accepts only a GitHub repository target, refreshes or clones it, and is described as code-grounded. The memory type explicitly supports both code-grounded and doc-grounded reviews, and the unified scope requires code-grounded and doc-grounded evidence. The skill's “stop and write a lightweight note instead” sentence is not an executable doc-grounded branch. Sources: kb/instructions/write-agent-memory-system-review/SKILL.md; kb/agent-memory-systems/types/agent-memory-system-review.md; kb/agent-memory-systems/COLLECTION.md; kb/work/analyse-agentic-system/brief.md.
Conflict: The memory skill refreshes a checkout; the bounded whole-system precedent explicitly inspects the current checkout without fetching or pulling. Both can establish a pinned boundary, but they embody different mutation and freshness policies. Sources: kb/instructions/write-agent-memory-system-review/SKILL.md; kb/work/pi-agent-zerostack-comparison/review-instruction.md. DECISION NEEDED: which policy the unified instruction applies and when.
Boundary mismatch: The memory skill's parent captures the README and manifests for the writer's context, then the delegated writer is told to inspect README, architecture docs, manifests, and core source. This can duplicate source reading. The unified requirement says source preparation and evidence boundary happen once and lens workers must not analyse different revisions. Source: kb/instructions/write-agent-memory-system-review/SKILL.md; user requirement in kb/work/analyse-agentic-system/brief.md.
Model mismatch: Memory's source-tier is one artifact-level authority marker; epistemic analysis uses five per-source/per-claim evidence layers. These are compatible only if one is treated as overall basis and the other as claim-level status. No current procedure states that mapping. Sources: kb/agent-memory-systems/types/agent-memory-system-review.md; kb/instructions/analyse-external-system-epistemic-architecture.md. DEFINE: the mapping and allowed combinations.
Citation mismatch: Memory reviews prefer commit-pinned links and optional quote-anchored citations; whole-system artifacts currently use a one-line evidence basis plus direct pinned links or source-relative citations; epistemic output uses stable source IDs plus local anchors. Sources: kb/agent-memory-systems/types/agent-memory-system-review.md; kb/agentic-systems/COLLECTION.md; kb/work/pi-agent-zerostack-comparison/review-instruction.md; kb/instructions/analyse-external-system-epistemic-architecture.md. DECISION NEEDED: one canonical citation/register contract.

3.3 Analytical content versus publication workflow

Boundary mismatch: The memory skill owns checkout setup, archive moves, delegated drafting, README and survey maintenance, taxonomy QA, semantic QA, validation, and reporting. The memory type owns the content contract and explicitly says writer process is not judgeable from the finished review. Those production responsibilities are not the memory lens itself. Sources: kb/instructions/write-agent-memory-system-review/SKILL.md; kb/agent-memory-systems/types/agent-memory-system-review.md.
Boundary mismatch: The memory type requires Commonplace comparison, borrowable ideas, curiosity, watch items, and relevant-note links in addition to memory characterization. The requested modular memory baseline explicitly excludes publication, Commonplace comparison, curiosity, and collection routing. Sources: kb/agent-memory-systems/types/agent-memory-system-review.md; user scope in kb/work/analyse-agentic-system/brief.md.
Conflict: The current memory skill always writes under kb/agent-memory-systems/reviews/, while the intended output is system-first and one-file versus per-system package publication remains open. Sources: kb/instructions/write-agent-memory-system-review/SKILL.md; kb/work/analyse-agentic-system/brief.md.
Contract mismatch: Agentic-system analyses are generic notes with only a one-line evidence-basis convention and no formal review type; memory reviews have a strict type, schema, controlled tokens, and parsed comparison matrix. Sources: kb/agentic-systems/COLLECTION.md; kb/agent-memory-systems/COLLECTION.md; kb/agent-memory-systems/types/agent-memory-system-review.md; kb/agent-memory-systems/review-framework-design.md. DECISION NEEDED: whether the first unified output is a generic note, a new tested shape, or a package that preserves a typed memory projection.

3.4 Cross-lens vocabulary and state

Boundary mismatch: Memory's behavioral-authority field uses controlled family tokens such as knowledge, instruction, and validation; the definition and epistemic ledger require the actual consumer, channel, force, and sometimes horizon. Repeating both independently risks contradictory authority claims. Sources: kb/agent-memory-systems/types/agent-memory-system-review.md; kb/notes/definitions/behavioral-authority.md; kb/instructions/analyse-external-system-epistemic-architecture.md.
Boundary mismatch: Memory lineage describes how a retained artifact arose (authored, imported, trace-extracted, other-compiled); epistemic transformation describes what happened semantically (acquisition/import, non-ampliative reshaping, entailed derivation, ampliative conjecture, indeterminate). They are different axes, but overlapping words can hide the difference. The memory type defines imported as brought in unchanged, then its write-side discussion also uses document extraction as an acquisition example; semantic preservation cannot be assumed from that label. Source: kb/agent-memory-systems/types/agent-memory-system-review.md; contrast with kb/instructions/analyse-external-system-epistemic-architecture.md. DEFINE: a crosswalk that never lets operational lineage imply semantic warrant.
Boundary mismatch: Memory consolidate is defined as saying nothing the inputs did not, and synthesize as adding a claim no input stated. Those are operational review categories; an epistemic analysis may still have to mark a particular output indeterminate if semantic preservation or ampliation cannot be established from evidence. Sources: kb/agent-memory-systems/types/agent-memory-system-review.md; kb/instructions/analyse-external-system-epistemic-architecture.md.
Conflict: Every current memory review must emit pull/push/both, but a whole-system analysis may find no accumulated-from-use material, or insufficient evidence to decide whether such material returns. Pull/push/both cannot encode lens inapplicability. Sources: kb/agent-memory-systems/types/agent-memory-system-review.md; kb/agent-memory-systems/types/agent-memory-system-review.schema.yaml; applicability requirement in kb/work/analyse-agentic-system/brief.md.
Contract drift: The memory type uses the trace-learning tag and ### Trace-learning; the schema's remaining conditional is keyed to legacy trace-derived and requires ### Trace-derived learning. The schema therefore does not enforce the live type's trace-learning pairing. Sources: kb/agent-memory-systems/types/agent-memory-system-review.md; kb/agent-memory-systems/types/agent-memory-system-review.schema.yaml.

3.5 Standalone epistemic procedure versus embedded lens

Boundary mismatch: The epistemic procedure currently triggers on a knowledge-production question and tells a general reviewer with no such question to stop and use another method. The unified public workflow instead asks a general system question, then applies the epistemic method conditionally without terminating the whole analysis. Sources: kb/instructions/analyse-external-system-epistemic-architecture.md; kb/work/analyse-agentic-system/brief.md.
Boundary mismatch: The accepted epistemic procedure includes direct behavior/policy adaptation as a material route, including non-truth-apt updates. The brief's applicability trigger names truth-apt routes or a knowledge/warrant claim. It is not explicit whether evaluated direct policy adaptation with neither condition independently triggers the lens or is only included after another trigger fires. Sources: kb/instructions/analyse-external-system-epistemic-architecture.md; kb/reports/retained/epistemic-architecture-analysis-trials-20260820/gbrain-trial.md; kb/work/analyse-agentic-system/brief.md. DEFINE: trigger behavior for this case.
Evidence limit, not current defect: The ARC and GBrain cold trials exercised an earlier candidate and exposed missing distinctions. The final procedure added explicit indeterminate disposition and separated architectural status from observed candidate state; acceptance judged the anchored repairs sufficient without rerunning. This supports the analytical logic but is not a cold execution of the exact future integrated workflow. Sources: kb/reports/retained/epistemic-architecture-analysis-trials-20260820/arc-trial.md; kb/reports/retained/epistemic-architecture-analysis-trials-20260820/gbrain-trial.md; kb/reports/retained/epistemic-architecture-analysis-trials-20260820/acceptance.md; kb/instructions/analyse-external-system-epistemic-architecture.md. EVIDENCE NEEDED: integrated cold trials.

4. Current memory skill behavior versus memory type content

Dimension	Operative memory skill behavior	Memory type requirement	Consequence for reconstruction
Trigger and evidence	Accepts a GitHub repo reference, requires reachable source and a checkout under `related-systems/`, and is described as code-grounded.	Supports code-grounded and doc-grounded reviews under one type; tier changes authority, not analytical scope.	The operative workflow covers only one evidence branch. The unified workflow needs an explicit doc-grounded branch or an early insufficient-evidence result. Sources: `kb/instructions/write-agent-memory-system-review/SKILL.md`; `kb/agent-memory-systems/types/agent-memory-system-review.md`.
Source preparation	Normalizes repo identity, resolves checkout/name collisions, clones or fast-forwards, records commit and refresh time, and pins citation URLs.	Requires source identity, reviewed revision, evidence-appropriate citations, and evidence-bounded claims; it does not prescribe checkout mechanics.	Source preparation belongs above the lens; only the pinned identity/register is analytical input. Sources: `kb/instructions/write-agent-memory-system-review/SKILL.md`; `kb/agent-memory-systems/types/agent-memory-system-review.md`.
Artifact lifecycle	Archives an existing review before drafting, marks it replaced, and later may update navigation/survey artifacts.	Specifies the completed review's fields and sections; writer process is not part of artifact conformance.	Archive/index/survey work is publication lifecycle, not memory analysis. Source: `kb/instructions/write-agent-memory-system-review/SKILL.md`; `kb/agent-memory-systems/types/agent-memory-system-review.md`.
Execution topology	Requires a fresh delegated drafting worker; the parent owns setup, lifecycle, taxonomy QA, semantic QA, and reporting. Local drafting is an explicitly authorized exception.	Says nothing about delegation; it is a content contract.	Delegation policy cannot be inherited as a memory-lens semantic requirement. The unified instruction must decide worker topology at the public-workflow layer. Sources: `kb/instructions/write-agent-memory-system-review/SKILL.md`; `kb/agent-memory-systems/types/agent-memory-system-review.md`.
Core characterization	Delegates the type wholesale rather than restating its analytical fields.	Requires mechanisms/context efficiency, retained-artifact analysis, write side, and read-back, with capability/deployment and structural/quality limits.	These sections contain the reusable memory/context lens. Source: `kb/agent-memory-systems/types/agent-memory-system-review.md`; delegation reference in `kb/instructions/write-agent-memory-system-review/SKILL.md`.
Editorial additions	Worker produces the complete collection review; parent may update comparative/navigation material.	Requires `Comparison with Our System`, `Borrowable Ideas`, `Curiosity Pass`, `What to Watch`, and `Relevant Notes`.	These are not intrinsic to determining memory mechanisms and should remain outside the modular lens unless the whole-system output separately chooses them. Source: `kb/agent-memory-systems/types/agent-memory-system-review.md`; requested separation in `kb/work/analyse-agentic-system/brief.md`.
Machine-readable comparison	Taxonomy QA checks the type's controlled fields; final validation checks structure.	Controlled lead tokens feed the code-grounded systems matrix; blank, assessed-absent, and not-determinable are distinct.	The unified analysis may need to preserve enough memory fields for comparison, but that does not decide whether they remain inline, become a projection, or wait until a new output shape is tested. Sources: `kb/instructions/write-agent-memory-system-review/SKILL.md`; `kb/agent-memory-systems/types/agent-memory-system-review.md`; `kb/agent-memory-systems/review-framework-design.md`.
QA and completion	Runs worker validation, taxonomy QA, semantic review jobs, final validation, and a workflow report.	Provides content constraints and a schema but disclaims process observability.	The public workflow should own QA/validation; the memory lens should return checkable content, not reproduce the whole current publication pipeline. Sources: `kb/instructions/write-agent-memory-system-review/SKILL.md`; `kb/agent-memory-systems/types/agent-memory-system-review.md`; user ownership in `kb/work/analyse-agentic-system/brief.md`.

5. What current whole-system examples support, and what they do not

Supported by the examples

A system may contain several materially different loops and authority envelopes. Agno separates model/team loops, host-language workflows, a control plane, cron scheduling, Studio building, and an external coding-agent improvement loop. GBrain separates host adoption, dream-cycle scheduling, Minions, Think, API trust boundaries, and SkillOpt. Sources: kb/agentic-systems/reviews/agno-agentos.md; kb/agentic-systems/reviews/gbrain.md.
Scheduler placement and persistence must be discovered rather than assumed. Claude Code workflows use model-authored sandboxed JavaScript, session-local journals, and optional command promotion; GBrain uses durable TypeScript/Postgres machinery; Exo divides a protected Rust substrate from a rewritable TypeScript executor. Sources: kb/agentic-systems/reviews/claude-code-dynamic-workflows.md; kb/agentic-systems/reviews/gbrain.md; kb/agentic-systems/reviews/exo.md.
Permissions, recovery, and observability are part of the deployed system account. Agno exposes approval, authorization, durable runs, traces, and tiered recovery; Exo preserves the attempt record across sandbox rewind and separates tool profiles from trust; GBrain distinguishes natural-language host adoption from a fail-closed remote operations boundary. Sources: kb/agentic-systems/reviews/agno-agentos.md; kb/agentic-systems/reviews/exo.md; kb/agentic-systems/reviews/gbrain.md.
Conditional epistemic analysis is materially useful inside whole-system work. Current analyses already discuss Agno's instruction-derived improvement probes, Exo's build/test acceptance oracle, GBrain's SkillOpt gate, and Claude workflow promotion without a test gate. These are route-level warrant questions even though the artifacts were not written with the accepted epistemic ledger. Sources: kb/agentic-systems/reviews/agno-agentos.md; kb/agentic-systems/reviews/exo.md; kb/agentic-systems/reviews/gbrain.md; kb/agentic-systems/reviews/claude-code-dynamic-workflows.md.
A system-first synthesis should organize around the deployed system rather than paste subsystem reviews together. The comparative precedent explicitly requires an integrated comparison and connects product/TUI observations to runtime and governance implications. Source: kb/work/pi-agent-zerostack-comparison/review-instruction.md.

Not established or not generalizable

No universal runtime taxonomy is established. The three-responsibility runtime split is a diagnostic starting point; the orchestration dimensions are explicitly open; the 18 comparison axes are a task-specific reading inventory. Sources: kb/notes/agent-runtime-analysis-should-separate-scheduling-context-state.md; kb/notes/agent-orchestration-occupies-a-multi-dimensional-design-space.md; kb/work/pi-agent-zerostack-comparison/review-instruction.md.
No uniform whole-system output contract is established. The four current analyses use system-specific narrative structures, while the comparison precedent uses a bespoke comparison template. Sources: kb/agentic-systems/reviews/agno-agentos.md; kb/agentic-systems/reviews/claude-code-dynamic-workflows.md; kb/agentic-systems/reviews/exo.md; kb/agentic-systems/reviews/gbrain.md; kb/work/pi-agent-zerostack-comparison/review-instruction.md.
No current example records explicit memory/epistemic applicability dispositions or reconciles shared IDs. The examples either exclude memory into a companion review or omit a memory lens, and none uses the epistemic source/object/route ID protocol. Sources: kb/agentic-systems/reviews/agno-agentos.md; kb/agentic-systems/reviews/claude-code-dynamic-workflows.md; kb/agentic-systems/reviews/exo.md; kb/agentic-systems/reviews/gbrain.md; comparison protocol in kb/instructions/analyse-external-system-epistemic-architecture.md.
No current example demonstrates one source inspection feeding all lenses at one pinned boundary. The Exo revision skew is counterevidence; GBrain's same-commit split shows compatibility but not a shared execution. Sources: kb/agentic-systems/reviews/exo.md; kb/agentic-systems/reviews/gbrain.md.
The examples do not decide one-file versus package publication, embedded versus separate internal lens text, or migration of existing memory reviews. Those choices are explicitly open or excluded until trial. Source: kb/work/analyse-agentic-system/brief.md.
The accepted epistemic trials do not cover the four unified workflow cases. They cover two epistemically rich systems, not runtime-only; runtime plus memory with no material epistemic transformation; runtime plus epistemic routes; and runtime plus both lenses under one orchestrator. Sources: kb/reports/retained/epistemic-architecture-analysis-trials-20260820/arc-trial.md; kb/reports/retained/epistemic-architecture-analysis-trials-20260820/gbrain-trial.md; required cases in kb/work/analyse-agentic-system/brief.md.

6. Open questions the unified instruction must resolve

DEFINE — reviewed system boundary. What observable rule tells the executor when a host agent, external model, service, scheduler, database, human reviewer, or developer loop is inside the system? How are included and excluded components recorded, and when is a subsystem-only analysis the honest boundary? Basis: kb/instructions/analyse-external-system-epistemic-architecture.md; kb/agentic-systems/reviews/agno-agentos.md; kb/agentic-systems/reviews/gbrain.md.
DECISION NEEDED — source acquisition and freshness. Does the workflow refresh a GitHub checkout, inspect an already-pinned checkout without mutation, accept a supplied snapshot/document set, or branch by source kind? What happens with dirty state, unreachable code, or no stable revision? Basis: kb/instructions/write-agent-memory-system-review/SKILL.md; kb/work/pi-agent-zerostack-comparison/review-instruction.md; kb/agent-memory-systems/types/agent-memory-system-review.md.
DEFINE — evidence model. How do artifact-level code-grounded/doc-grounded tier, per-source evidence layer, and per-claim statuses map to the required vocabulary: absent, inapplicable, uninspected, claimed, implemented, observed, and causally supported? What exact negative wording carries the inspected boundary and prevented conclusion? Basis: kb/agent-memory-systems/types/agent-memory-system-review.md; kb/instructions/analyse-external-system-epistemic-architecture.md; kb/work/analyse-agentic-system/brief.md.
DECISION NEEDED — canonical shared records. Which layer assigns source, component/object, route, claim, and consumption-path IDs? Which fields are common, and which are lens extensions? How does a lens reference an existing object without re-inventorying or renaming it? Basis: kb/instructions/analyse-external-system-epistemic-architecture.md; kb/agent-memory-systems/types/agent-memory-system-review.md; fixed reconciliation requirement in kb/work/analyse-agentic-system/brief.md.
DEFINE — finite runtime baseline. What must every analysis say about scheduling, context assembly, and external state/action? When do coordination, permissioning, recovery, observability, governance, provider, UI, packaging, or performance become material? The rule must preserve system-specific salience without presenting a universal taxonomy. Basis: kb/notes/agent-runtime-analysis-should-separate-scheduling-context-state.md; kb/notes/agent-orchestration-occupies-a-multi-dimensional-design-space.md; kb/work/pi-agent-zerostack-comparison/review-instruction.md.
DEFINE — memory/context applicability. What evidence establishes that retained material accumulated or changed through use can affect a later invocation or action? How are static shipped instructions, ordinary session state, retained-but-never-served material, unknown read-back, and no such material distinguished? Basis: kb/notes/knowledge-storage-does-not-imply-contextual-activation.md; kb/agent-memory-systems/types/agent-memory-system-review.md; user trigger in kb/work/analyse-agentic-system/brief.md.
DEFINE — epistemic applicability. Truth-apt material routes and knowledge/warrant claims trigger inspection even when the system fails to produce knowledge. Does evaluated direct policy adaptation with no evidenced truth-apt object and no knowledge claim also trigger the lens, or is it analysed by the runtime baseline unless another trigger exists? Basis: kb/instructions/analyse-external-system-epistemic-architecture.md; kb/reports/retained/epistemic-architecture-analysis-trials-20260820/gbrain-trial.md; kb/work/analyse-agentic-system/brief.md.
DEFINE — applicability output and early exit. What exact compact record is emitted for applicable, inapplicable, and uncertain; what evidence supports it; and what conclusions are prevented when the lens does not run? The absence of a lens section or file cannot carry this meaning implicitly. Basis: kb/instructions/analyse-external-system-epistemic-architecture.md; kb/work/analyse-agentic-system/brief.md.
DECISION NEEDED — context and activation ownership. Does the runtime record one full context-assembly route that the memory lens annotates, or do the two layers hold linked routes? Where is observed context-to-action activation recorded? Basis: kb/notes/agent-runtime-analysis-should-separate-scheduling-context-state.md; kb/notes/knowledge-storage-does-not-imply-contextual-activation.md.
DEFINE — lineage/transformation crosswalk. How do retained-artifact lineage, write-side curation operation, and epistemic content transformation coexist without one implying the others? Basis: kb/agent-memory-systems/types/agent-memory-system-review.md; kb/instructions/analyse-external-system-epistemic-architecture.md.
DEFINE — authority record. What canonical representation holds consumer, channel, force, and horizon; how are memory's controlled authority-family tokens derived; and how are epistemic authority and operational authority kept separate? Basis: kb/notes/definitions/behavioral-authority.md; kb/agent-memory-systems/types/agent-memory-system-review.md; kb/instructions/analyse-external-system-epistemic-architecture.md.
DECISION NEEDED — source reading and worker topology. If fresh worker contexts apply lenses, do they receive a prepared evidence packet, read-only access to the same pinned source, or both? Who may inspect new source files, and how does the workflow prevent duplicate reading, inconsistent boundaries, and silent evidence upgrades? What is the fallback when worker slots are unavailable? Basis: kb/instructions/write-agent-memory-system-review/SKILL.md; public-workflow ownership in kb/work/analyse-agentic-system/brief.md.
DECISION NEEDED — output and publication shape. Is the result one note, one directory with a canonical synthesis plus machine-readable lens records, or another form? What collection and type does it use before a dedicated schema exists? The public entry point must remain singular either way. Basis: kb/agentic-systems/COLLECTION.md; kb/agent-memory-systems/COLLECTION.md; kb/work/analyse-agentic-system/brief.md.
DECISION NEEDED — editorial material. Are Commonplace comparison, borrowable ideas, curiosity, watch items, and Relevant Notes whole-system optional outputs, later editorial passes, or omitted from this analytical instruction? They must not be smuggled into the memory lens merely because its current review type requires them. Basis: kb/agent-memory-systems/types/agent-memory-system-review.md; kb/work/analyse-agentic-system/brief.md.
DECISION NEEDED — refresh/replacement lifecycle. When a prior whole-system or memory review exists, is it archived, updated in place, left as a subsystem projection, or superseded only after promotion? No corpus relocation or semantic retrofit is authorized in this target. Basis: kb/instructions/write-agent-memory-system-review/SKILL.md; kb/work/analyse-agentic-system/brief.md.
DEFINE — verification and QA before schemas change. What can deterministic validation check for the provisional result? What semantic checks belong to the workflow, and which failures block publication? Current memory QA assumes the existing memory type; the new output shape must be tried before parsers, schemas, or matrices change. Basis: kb/instructions/write-agent-memory-system-review/SKILL.md; kb/agent-memory-systems/types/agent-memory-system-review.schema.yaml; kb/work/analyse-agentic-system/brief.md.
DEFINE — operativity. What exact trigger-focused description, runtime frontmatter, consumer, channel, and force make kb/instructions/analyse-agentic-system/SKILL.md discoverable and operative? Does it invoke internal lens text or frontload it? A promoted instruction cannot depend on kb/work/. Basis: kb/instructions/COLLECTION.md; kb/types/instruction.md; kb/work/analyse-agentic-system/brief.md.
EVIDENCE NEEDED — integrated cold trials. Execute the exact public workflow on: runtime only; runtime plus memory with no material epistemic transformation; runtime plus epistemic routes; and runtime plus both. The trials must test one pinned source register, explicit non-application, stable shared IDs, no silent evidence upgrades, and a bounded system synthesis. Basis: acceptance requirement in kb/work/analyse-agentic-system/brief.md; precedent for cold execution in kb/reports/retained/epistemic-architecture-analysis-trials-20260820/acceptance.md.

7. Available details irrelevant to the governing question

These details may matter to later implementation or a specific review, but they do not decide how one public system-analysis workflow should compose runtime, memory/context, and epistemic lenses.

Exact checkout-slug collision rules, refresh-marker ages, archive suffix numbering, git command spelling, and the existing final-report checklist. They are mechanics of the current GitHub memory publication workflow, not evidence about analytical ownership. Source: kb/instructions/write-agent-memory-system-review/SKILL.md.
The systems-matrix parser module, historical retrofit percentages, one-hot storage layout, and earlier migration history. The live controlled memory distinctions matter; the implementation history does not answer the governing question. Source: kb/agent-memory-systems/review-framework-design.md.
ARC campaign counts, individual claim grammar, rule-replay status names, and GBrain's exact tables, thresholds, phase names, or missing Bun executable. They show that the epistemic procedure discriminates routes and evidence limits, but their domain-specific values should not enter the unified instruction. Sources: kb/reports/retained/epistemic-architecture-analysis-trials-20260820/arc-trial.md; kb/reports/retained/epistemic-architecture-analysis-trials-20260820/gbrain-trial.md.
The two Rust repositories' exact file lists, pinned SHAs, TUI controls, provider modules, and proposed comparison output path. The reusable precedent is source-state discipline plus an integrated, salient-axis review; the subject-specific inventory is not a general baseline. Source: kb/work/pi-agent-zerostack-comparison/review-instruction.md.
Agno endpoint names, Claude workflow concurrency caps and API spellings, Exo tool/profile names, and GBrain's exact phase count and implementation filenames. They evidence heterogeneous whole-system mechanisms but are not general instruction fields. Sources: kb/agentic-systems/reviews/agno-agentos.md; kb/agentic-systems/reviews/claude-code-dynamic-workflows.md; kb/agentic-systems/reviews/exo.md; kb/agentic-systems/reviews/gbrain.md.
Existing navigation prose and individual analysis ordering in the two collection READMEs. They describe current corpus organization; the user has expressly withheld authorization for collection relocation or semantic retrofit. Sources: kb/agentic-systems/README.md; kb/agent-memory-systems/COLLECTION.md; kb/work/analyse-agentic-system/brief.md.

Keys	Action
`?`	Open this help
`n`	Next page
`p`	Previous page
`s`	Search