Inspiration — the academic shoulders we stand on
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 tractablePages
| Pillar | Page | One-line summary |
|---|---|---|
| THE WHY | Connected data — the Palantir lineage | 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 | 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 | 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 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.
Dependency graph (8-layer DAG)
How the library is structured. Each layer depends only on the ones above it; consumers can reach any layer directly without going through the others. The architecture diagram + the principles behind it.
Connected Data — the Palantir lineage
THE WHY behind agentfootprint's design. 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 so the next token compounds the connection instead of paying for it again.