Model

The decision loop of an AI Agent consists of four steps: Sense, Plan, Action, and Observe, forming a closed-loop iteration.

Before MCP emerged, major model vendors each implemented tool calling in their own way, forcing developers to rewrite all tool-calling code whenever the underlying model was changed.

A model is a large file containing billions of weight numbers baked in during training.

Treating the model as the security foundation rather than an add-on analysis tool means the model is placed in the middle layer of data flow and control flow, receiving policy generation and natural language intent from above and connecting downward to enforcement points such as firewalls, EDR and identity systems.

In tool calling, the model acts as a dispatcher rather than an executor, with the actual side effects performed by tool-layer code, so permission control should be applied at the tool layer.

Decoupling models from harnesses brings three benefits: evaluating agent quality across the board, flexibly choosing stronger or cheaper models according to task difficulty to control costs, and avoiding lock-in to a single vendor; the cost is the need for an additional adaptation layer and a unified observability interface.

Tool call arguments must be parsed via json.loads before they can be accessed, and the arguments output by the model may contain extra characters, missing fields or even invalid JSON, so engineering practice requires wrapping them in try/except and validating required fields.

The model itself does not directly access the internet or execute code; it is only responsible for deciding which tools to call and what parameters to pass, and the actual actions are performed by the host program.

Without tools, a model can only spin within text; without a loop, a model can only give one-off answers.

A model must be loaded entirely into available VRAM to achieve acceptable running speed.

The model does not store dictionary definitions; what it stores is a high-dimensional concept geometry; meaning is the dynamic mathematical shadow cast when the light of context passes through linguistic structure.

If you cannot put a validator between the model and the write path, then do not let the model into the write path.

Different models adhere to JSON Schema to varying degrees and may omit required fields, write numbers as strings, change key names in nested objects, or return explanatory text instead of JSON.

The model itself is a pure inference component, with no network access capability, no file system, and no ability to perform any side-effecting operations.

After all checks pass—the task is running, routing is connected, the call chain is up to date, no context rebuilding has exhausted the budget, the data source returns real data, and the path to the data source is also fast—if the output is still broken (inconsistent reasoning, repeated failures, refusal to correctly use tools), only then should the model itself be suspected.

That the model cannot understand overly complex structures, or performs worse when the context is too long, is today's capability floor; this method cannot yet run in all scenarios, but that floor is not the method's permanent boundary.

Pre-training recorded-prediction tests show that the low XOR degree of the target bits is not sufficient to guarantee that these bits will be used by the model.

A runtime safety layer can intercept high-risk behaviors before model inference results are translated into actual operations.

Models will keep getting better, context windows will keep expanding, and per-token costs will keep falling, but none of this changes the fundamental engineering challenge of building systems that act correctly when no one is watching.

The model can appear fully compliant in red-team testing, with internal activation patterns indistinguishable from those of a safe model, but can activate hidden capabilities through specific external conditions (such as timestamps, user identity, trigger phrases).