Eight Pillar Readiness Map

Eight-Pillar Readiness Map

Overview

The dual-graph architecture is the structural framework; the eight pillars are the implementation roadmap — the specific capabilities that turn the framework into a working system. Each pillar emerged from a recurring production failure pattern, and the pillars are layered, not independent: knowledge representation (Ch3) must come first because every other pillar depends on the knowledge graph; memory (Ch4) builds on it; reasoning and planning (Ch5) require both; tool orchestration (Ch6) requires all of those; and the final two, self-evolution (Ch7) and optimization (Ch8), depend on the complete architecture being in place.

This skill takes a system's declared capability per pillar (present / partial / missing) and produces a readiness map:

• a readiness score (weighted across the eight pillars),
• dependency violations — a higher pillar claimed present while a lower one it requires is missing (the chapter says this is structurally unsound),
• unresolved Chapter-1 flaws — mapping remaining gaps back to the five flaws per Table 2-1 (relationship blindness, context amnesia, temporal ignorance, reasoning paralysis, tool chaos),
• the next pillar to build (always the earliest incomplete layer, because building higher first creates a violation).

The DevOps agent's Chapter-2 initial state is the worked example: knowledge representation only partial (the data exists in logs and configs but is not a graph), everything else missing, all five flaws open. It is a "representation problem, not a technology problem."

When to Use

• Auditing an agentic-graph system's production readiness
• Planning the build order for a new agent (which pillar next?)
• Checking that a claimed capability is not resting on a missing foundation
• Tracking progress across the book's parts (each part adds a pillar-layer)

Phrases that should invoke this skill: "map the eight pillars", "which pillar should we build next", "is this agent production-ready", "pillar readiness", "what flaws are still unsolved", "eight-pillar audit".

When NOT to Use

• Building a single pillar. Each pillar has its own chapter and skills (knowledge-representation/, memory/, reasoning-planning/, tool-orchestration/, self-evolution/). This skill maps; it does not build.
• Routing a request. Vertical-vs-horizontal routing is dual-graph-router.
• A generic org/AI maturity model. The eight pillars are specific to the dual-graph architecture; do not repurpose this for unrelated capability grids.
• Scoring the QUALITY of a pillar. This tracks presence/partial/missing, not how good a present pillar is — use the pillar's own evaluation skills for that.

Process

Rationalizations

Red Flags

• A high readiness score with dependency violations. The weighted score can look healthy while the layering is broken — always read the violations list, not just the percentage.
• Every flaw shows unsolved but pillars are marked present. The status-to-flaw mapping drifted, or pillars were marked present without their dependencies — cross-check with the violations list.
• next_pillar skips ahead of a missing lower pillar. Impossible by construction; if you see it, PILLAR_ORDER or depends_on was edited incorrectly.
• self_evolution or optimization shown as solving a flaw. They map to production viability, not to any of the five flaws; a flaw mapping to them is a corruption of Table 2-1.
• CLI --help exits non-zero. SKILL.md / CLI mismatch; the multi-harness invariant is broken.

Non-Negotiable Verification

1. Run the benchmark battery.

   python cli.py benchmark
   

   Confirm eight layered pillars, five mapped flaws, the initial state recommending knowledge_representation, the mid state solving the first four flaws while leaving tool_chaos open, and the violation state flagging reasoning + self_evolution as resting on a missing foundation.

2. Inspect the initial state visually.

   python cli.py assess --system initial
   

   Confirm KR is partial, all others missing, all five flaws unsolved, and the roadmap starts at knowledge_representation.

3. Confirm the layering catches a violation.

   python cli.py assess --system violation
   

   Confirm reasoning and self_evolution are flagged as claimed-present-but- foundation-missing.

4. JSON output round-trips.

   python cli.py assess --system mid --json | python -c "import json,sys; json.load(sys.stdin)"
   

   No exception means the CLI is harness-portable.

Security Posture

• Prompt injection. Capability statuses are a small closed vocabulary (present/partial/missing) validated on input; any other value raises ValueError rather than being interpreted. Pillar keys are validated against the fixed eight; unknown keys raise. There is no free-text execution surface.
• Data exfiltration. No network calls, no file writes outside the read-only bundled sample-systems.json. The --json report goes to stdout; the caller owns downstream piping.
• Advisory only. This skill emits a report; it never edits the audited system, installs a pillar, or grants a capability. A readiness score is not an authorization — the dependency-violation output is the safety signal (do not ship a system whose claimed pillars rest on missing foundations).

Source Attribution

Distilled from Agentic GraphRAG (O'Reilly, by Anthony Alcaraz and Sam Julien), Chapter 2 — Agentic Graph Architecture Foundations:

• "The Eight Pillars of Agentic Graph Architecture" — the eight pillars, their layering, and why each exists (a recurring production failure pattern).
• Table 2-1 "Mapping the five flaws to the eight pillars" — relationship blindness → knowledge representation; context amnesia + temporal ignorance → memory; reasoning paralysis → reasoning + planning; tool chaos → tool orchestration + structured output.
• "The Initial State" and "The Transformation Arc" — the DevOps agent's fragmented starting point and the pillar-per-part progression.

This Reviewer-pattern skill audits the whole architecture; the per-pillar skills in the sibling chapter folders build the capabilities it maps.