3 posts tagged with "tools"

Rust does not have a shortage of good crates.

There is uuid for identifiers, chrono for time, rust_decimal for exact decimal arithmetic, serde_json for JSON, and reqwest for HTTP. The challenge in application development is often not finding a capability. It is keeping a team fluent in many unrelated APIs while preventing infrastructure details from spreading through business code.

AI coding makes that problem more visible. A model may understand the operation we want while mixing together method names from another language, another version, or another crate. The generated code looks plausible, but the API does not exist.

TeaQL Tool is our attempt to make that surface smaller and more predictable. It places 52 common utilities behind one T::xxx() facade, separates lightweight and dependency-heavy features, and adds an optional context layer that requires code to state why a value is being read, calculated, or changed.

It is partly inspired by libraries such as Hutool, but the interesting question is not how many helpers we can collect. It is whether a stable, narrow API can serve both application developers and coding agents without hiding Rust's underlying ecosystem.

A foundation model can know a great deal about programming, finance, manufacturing, medicine, and law. It still cannot know the private operating knowledge of a particular organization: an internal approval rule, a proprietary engineering method, an undocumented exception, or the reason one production procedure is trusted while another is prohibited.

This gap is often described as a knowledge-access problem. Give the model the right documents, retrieve the right passages, and it will know what to do.

Retrieval is necessary, but it is not sufficient.

The real enterprise question is not only:

Can the AI find the knowledge?

It is:

Can the AI turn that knowledge into a correct, verifiable, and constrained capability?

Our work with TeaQL suggests a three-layer answer: Skill, Build Harness, and Runtime Harness. A Skill keeps the agent's direction and method sound. A Build Harness makes the constructed artifact mechanically verifiable. A Runtime Harness keeps actual execution inside engineering, security, permission, resource, and audit boundaries.

Together, these layers provide a practical way to give AI capabilities that do not exist inside the model itself.

As AI agents become more capable, it is tempting to make their Skills increasingly detailed. Every new failure becomes another instruction. Every exception becomes another paragraph. Eventually, the Skill tries to describe the domain, encode the workflow, enforce safety, teach the tool interface, and anticipate every future mistake.

That approach does not scale.

Our practical conclusion is different:

Keep Skills lightweight. Make Tools strong.

This is not an argument for fewer safeguards. It is an argument about where safeguards belong.

It is also a principle for harness engineering. The core of an agent harness should not be an ever-growing library of Skills. It should be a set of strong, model-aware Tools and deterministic feedback loops that turn guidance into enforceable action boundaries.