---
title: Inspiration — the academic shoulders we stand on
description: The two pillars under agentfootprint's design — Palantir-style connected data (the user-visible win) and Liskov-style modular boundaries (the engineering discipline that makes connection tractable).
---

The architectural rationale behind agentfootprint, organized into two pillars.

```
                THE WHY                          THE HOW
        (user-visible win)              (engineering discipline)
              ▼                                   ▼
   ─────────────────────────         ─────────────────────────
        Connected data                Modular boundaries
       (Palantir lineage)           (Liskov ADT + LSP lineage)
   ─────────────────────────         ─────────────────────────
              ▼                                   ▼
   Fewer iterations to find        Clean boundaries make
   the answer · less re-work       connection tractable
```

## Pages

| Pillar | Page | One-line summary |
|---|---|---|
| **THE WHY** | [Connected data — the Palantir lineage](/inspiration/connected-data-palantir/) | Palantir's 2003 thesis (connect data, not analysts) returns at agent runtime. Disconnected state burns iterations and tokens. agentfootprint connects four classes of agent data (state · decisions · execution · memory). |
| **THE HOW** | [Modularity — the Liskov lineage](/inspiration/modularity-liskov/) | Liskov's ADT + LSP work, applied to flowcharts. Subflows are CLU clusters. CacheStrategy / LLMProvider / ToolProvider are LSP-substitutable. Locality of reasoning is enforced as a runtime invariant. |
| **THE SPINE** | [Strategy everywhere — the port/adapter lineage](/inspiration/strategy-everywhere/) | The cache layer's strategy-registry shape (one DSL, N vendor strategies, swap by config) generalized into the library's scaling spine for every observability / cost / status / lens vendor integration — Strategy / Bridge / Ports & Adapters / Provider model / algebraic effects, one pattern in five traditions. |

Future entries (planned): the ReAct paper · Parnas information hiding · Hewitt actors · Anthropic Skills · flow-based programming.

## How to read these

These pages are the **rationale** behind the library design — written for:

- Contributors who want to understand WHY a boundary is shaped the way it is before changing it
- Library evaluators comparing frameworks at the architectural level
- People who want to learn from the same sources we learned from

If you just want to use the library, start at [Quick Start](/getting-started/quick-start/) instead. The inspiration pages are not required reading.

## Why these two pillars together

Liskov gives us **boundaries that don't leak** — every framework interface is substitutable, every subflow hides its internals.

Palantir gives us **connections within those boundaries** — the agent can follow a thread across stages without re-discovering it on every iteration.

Boundaries alone produce a clean but dumb library. Connections alone produce a fast but unmaintainable one. Both together is the design.
