ATM

INTEGRATION CORE · OPEN SOURCE · PYTHON

A stable framework for LLMs in real systems.

ATM (Agentic Thinking Map) is an integration core for agentic systems. It keeps context, roles, evidence, and transitions as explicit structure so the model can use its capabilities freely without mixing meanings, states, or authority. The map does not generate, rewrite, or influence what the model produces — it only checks, before and after, whether the proposed move is allowed.

Python 3.12+ · MIT · zero runtime dependencies

LOCAL TRAVERSAL SLICE SEMANTIC FRAME
context
deploy_decision
state
review_ready
candidate
verify_release_gate
evidence
current / 3 hops
gate
satisfied
outcome
CONTINUE
{"kind":"CONTINUE","can_fire":true}

WHO WE ARE, REALLY

“All speech is vain and empty unless it be accompanied by action.”
— Demosthenes

We are developers — we build many things, and this is just one of them. We are proud of it. We are not a brand built around it.

WE DON'T DESCRIBE, WE SHOW

The engine really decides this, in real time.

Below runs the real step() decision engine, across four test-backed traces: evidence recovery, waiting on PendingInput/AWAIT, state-bound authorization via MoveIntent and AuthorizationReceipt, and a direct comparison of ABSTAIN (undecided gate) versus BLOCK (explicit denial). Every branch it weighed is drawn — not just the one it chose.

fpf-agentic-thinking-map / ARCHITECTURE.mdSee the continuous trace, more visual →

WHY THIS EXISTS

We did not start from a theory. We tested it.

FPF (First Principles Framework) was the starting point — 51,000 lines written for a human reader, not for a model at runtime. The reason is simple, not a sales story: the model needs less semantics at runtime, not more — traversal itself is not semantics, it is logic. The model stays fully free in generation and reasoning; what we do not do is make it reason about its own reasoning forever, whether that would improve or damage the result — it simply does not happen. It keeps state in memory and applies a simple FPF-style logic to its own next move — without the traversal junk that accumulates when heavy semantics enters the loop.

4,668.8×smaller than the full raw FPF spec
288.7×smaller than the exact quoted spec fragment, per decision
80%of tested cases came out correct — versus 40% for the raw fragment

Measured with tiktoken and live runs, not estimated. · Full methodology (TRIPLE_TAX_CALCULUS.md) ↗ · Read the full reasoning →

THE PRODUCT PRINCIPLE

The model (LLM) stays free in generation. The system keeps only its frame.

We do not adjust the meaning of what the user writes, and we do not make the model reason about its own reasoning. The hard part — keeping state, rules, and evidence in memory across multiple steps — moves into code at runtime, starting from a finding the model itself signals as a typed result, not extra text. That is how a loop searching for a solution avoids filling its path with redundant semantics.

INTEGRATION CORE

The structure between the LLM and the system

The map gives each step exactly the operational frame it needs: where the agent is, what it knows, what it may do, and which conditions must hold. Integration becomes inspectable, extensible, and compatible with different models, domains, and flows.

We do not question the user input or the model's generation (LLM) — we leave those alone. What moves into code at runtime is the cognitive load of heavy semantics: a finding the model signals after its own inspection becomes a typed result, not extra text. The model solves this through code, not by adding useless semantics during execution — so a loop that searches for solutions does not clog its path with garbage in generated text.

We did not give up semantics — we moved it. The raw spec does not fit any practical context window and costs real money on every step. The solution was not to cut meaning, but to turn it into a traversal map that the model walks itself: it keeps its generation, its reasoning, everything that belongs to it — but it applies logical restrictions to its own next move.