LLMを賢くするのではなく「境界」を作る——AXIOM Framework Prototypeを作ってみたThe author built a prototype called AXIOM Framework to address recurring issues…

A developer publishing on Zenn has described building AXIOM Framework, an early-stage prototype that reframes how to make large language model systems more reliable. Instead of trying to make the model itself smarter, the project concentrates on establishing explicit "boundaries" between the input a system receives and the way that input is interpreted and acted upon. The distinction matters because much of the current effort around LLM applications goes into better prompting or larger models, whereas this work argues that the more tractable problem lies in the surrounding structure.

The author is upfront that AXIOM did not start as an ambition to build a "common foundation for AI." It emerged from the accumulated friction of using LLMs to build ordinary software. As the write-up recounts, several issues kept resurfacing: differences appeared between what was entered and how it was interpreted; the same processing implemented in Python, Rust, and Go yielded inconsistent results; data converted back into text could shift in meaning even though it was supposed to be identical; ambiguous instructions prompted the model to fill in the missing pieces on its own; listing prohibitions one by one caused the instructions themselves to grow enormous; and adding more agents made it progressively harder to know what each was permitted to do.

Taken together, these observations point to a common thread. The unpredictability was not primarily a matter of model intelligence but of undefined edges—the places where meaning is handed off between components, languages, and serialization formats. AXIOM's proposed response is to make those edges explicit rather than to coax better behavior out of the model through ever more elaborate prompts.

This design philosophy sits alongside a broader industry shift toward constraining LLM behavior structurally rather than persuasively. Techniques such as structured outputs, JSON-schema-constrained decoding, and function or tool calling all attempt to narrow the space of valid responses so that downstream code can depend on them. Guardrail libraries and validation layers play a similar role, checking and shaping model output before it is trusted. AXIOM's emphasis on boundaries between input and interpretation appears to fall in this same category, though it frames the problem in terms of handoffs across an entire system rather than a single model call.

The cross-language inconsistency the author describes is a well-known challenge that predates LLMs. Floating-point behavior, string encoding, numeric precision, and serialization rules differ subtly between Python, Rust, and Go, so identical-looking logic can diverge in practice. When an LLM sits in the middle of such a pipeline, translating between natural language and structured data, these small discrepancies can compound. Defining strict boundaries—agreeing on exactly what a given stage accepts and emits—is a conventional engineering answer to that class of problem, and AXIOM seems to extend it to LLM-mediated workflows.

The agent permissions concern is likewise timely. As developers assemble systems from multiple cooperating agents, each able to call tools or trigger actions, the question of who is allowed to do what becomes central to both correctness and safety. Writing an ever-growing list of forbidden actions is brittle, because it defines behavior by exclusion. An approach based on explicit boundaries would instead specify what is permitted, which is generally easier to reason about as a system scales.

It is worth keeping the scope in perspective. AXIOM is described as a prototype and a design exploration rather than a finished product, and the account reads as one developer's reasoning about a set of problems many practitioners recognize. Its placement in the llm">local-LLM context suggests relevance to self-hosted and agent-oriented setups, where developers bear more responsibility for the surrounding infr