2 posts tagged with "tools"

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.