Agentic Engineering: dependency graph visualization" and "blast-radius" use case.

Infrastructure management begins with a map of interdependencies.

In domains where system integrity depends on visibility — electrical grid maintenance, pharmaceutical supply chains, aerospace engineering — a foundational principle holds: before any modification, the system must be understood. A grid operator maps power lines. A pharmacist traces drug pathways. An engineer models aircraft subsystems. The method differs. The necessity does not. Without a structural map, changes become blind, risks unbounded, and accountability fragmented.

This principle applies to AI-driven codebases, where the absence of a topology map creates silent chaos. An agent tasked with "refactoring a module" may alter files without knowing what they depend on, who relies on them, or what downstream systems will break. The codebase becomes a black box, with no way to trace the ripple effects of a single line of change. The work is not invisible — it is unmoored.

I built the Component Fabric to anchor AI agents in the structural reality of the codebase. It is not a tool for the agent to use. It is the scaffold upon which the agent must operate.

How it works

The Component Fabric is a declarative topology map stored in .fabric/, populated by a set of commands that enforce structural awareness. Every file with significant impact — a utility script, a core module, an API endpoint — must be registered as a component. This creates a YAML card in .fabric/components/ that defines its dependencies, purpose, and relationships.

For example:

$ fw fabric register ./src/auth/service.ts  
# Component card created:  
# id: C-087  
# name: AuthService  
# type: service  
# subsystem: auth  
# location: ./src/auth/service.ts  
# purpose: Token validation and user authentication  
# depends_on: [C-041 (UserModel), C-063 (DatabaseClient)]  

The system then uses this map to answer questions like: What depends on this file? (fw fabric deps), What breaks if I modify this? (fw fabric blast-radius), or Where are all unregistered files? (fw fabric drift). The agent cannot act without this context.

Why / Research

The need for structural mapping emerged from three task failures:

• T-208: An agent refactored a core module without checking dependencies, breaking 12 downstream systems. The fix required manually reconstructing the dependency graph from commit history.
• T-214: A batch registration of 95 AEF components revealed 14% of files were unregistered, leading to 23 orphaned components with no traceable purpose.
• T-361: A documentation gap in component cards caused 7 misrouting incidents, where agents applied changes to the wrong subsystem.

These failures showed that structural awareness is not optional. The Component Fabric enforces it through three mechanisms:

1. Registration as a precondition for any file modification.
2. Drift detection to surface unregistered or stale components.
3. Impact analysis to prevent changes with unknown downstream consequences.

The result: 91% component coverage after T-214, 95% of AEF subsystems mapped, and a 68% reduction in post-refactor incidents.

Try it

Installation:

$ curl -s https://raw.githubusercontent.com/aef/fabric/master/install.sh | bash  

Usage example:

# Before modifying a file:  
$ fw fabric deps ./src/payments/processor.ts  
# Output:  
# C-112 (PaymentProcessor) depends_on: [C-050 (StripeClient), C-078 (Logger)]  
# depended_by: [C-134 (CheckoutFlow), C-150 (BillingJob)]  

# Before committing:  
$ fw fabric blast-radius  
# Simulated impact: 3 files would break if changes are applied