Independent technical notebook

Systems that think, networks that settle.

Field notes on artificial intelligence, useful agents, and decentralized infrastructure—written for people who prefer mechanisms to slogans.

The journal

Three ideas worth carrying into the next build.

01 / AI systems

The useful boundary of a small model

Capability matters, but a legible failure surface is what makes a model dependable.

Read essay →
02 / Agents

An agent is only as reliable as its tools

The glamorous part is reasoning. The useful part is a boring, inspectable interface.

Read essay →
03 / Protocols

Finality is where protocol becomes product

Users do not experience consensus diagrams. They experience the moment a decision feels irreversible.

Read essay →
Essay 01 AI systems 6 min

The useful boundary of a small model

A model becomes trustworthy when the shape of its uncertainty is easier to understand than the task it performs.

The conversation around language models tends to begin with scale: more parameters, more context, more benchmark wins. Production systems expose a different constraint. A model is valuable when a team can tell where it works, where it hesitates, and where it must stop. Predictable limits often create more usable intelligence than a larger envelope of uneven capability.

Small models make this visible. Give one a narrow vocabulary, a stable toolset, and examples drawn from the real operating environment. Its errors become classifiable. Retrieval can be measured independently from generation. A human reviewer can recognize the handful of ambiguous cases that deserve escalation instead of treating every output as an open-ended judgment call.

The practical design pattern is not “small at all costs.” It is a deliberate boundary: use the smallest model whose failures can be observed, tested, and contained. Scale only after the evaluation set proves which boundary needs to move. Intelligence is useful; legibility is what lets it stay useful.

Essay 02 Agent design 5 min

An agent is only as reliable as its tools

Reasoning can be probabilistic. The interface between intention and action should not be.

An agent demo often celebrates the moment a model invents a plan. Real systems fail one step later: a vague tool name, an overloaded parameter, a write operation disguised as a read, or a success response that does not describe what changed. The model receives ambiguity and returns confidence. That is not an intelligence problem; it is an interface problem.

Good tools are almost boring. Their names expose the action, their schemas make invalid states difficult to express, and their responses provide evidence that another process can verify. Read and write paths are separate. Destructive actions identify exact targets. Retries are safe or explicitly prohibited. A tool should narrow the agent’s choices at the moment precision matters most.

This changes how autonomy is measured. The useful question is not how long an agent can run without intervention. It is how many decisions remain inspectable after it has finished. A reliable agent leaves a trail of small, reversible commitments. Its sophistication appears as restraint.

Essay 03 Blockchains 7 min

Finality is where protocol becomes product

Consensus is an internal mechanism. Finality is the promise a user thinks the system has made.

Blockchains describe finality with careful language: probabilistic confirmation, economic finality, checkpoint finality, or deterministic commitment. Applications usually compress these ideas into a spinner and then a green checkmark. That translation is a product decision, because each visual state tells the user when it is safe to act on a result.

The honest interface separates inclusion from confidence. A transaction may be observed, ordered, confirmed by one layer, and settled by another. Bridges and rollups add their own clocks. Showing one undifferentiated “complete” state hides the part of the system where risk actually lives. A better product names the state, estimates the remaining wait, and explains what can still change.

Protocol designers can help by publishing machine-readable guarantees instead of asking every application to interpret consensus internals. Product teams can help by treating waiting as information, not friction to be disguised. Finality works when the protocol’s certainty and the user’s confidence advance together.

About

Liangria is a notebook for mechanisms.

Short essays about the parts of technology that remain after the launch language fades: boundaries, interfaces, incentives, and the small decisions that make systems understandable. No ads, analytics, trackers, or newsletter pop-ups.

Independent
Static by design
Updated occasionally