Lightweight Skills, Strong Tools: A Practical Architecture for Reliable AI Agents

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.

The Vehicle Analogy

An AI agent can be understood as a vehicle operating in the real world:

1. The large language model is the engine. It supplies the general power to understand language, reason, plan, and generate possible actions.
2. Skills are the traffic rules. They prescribe how the agent should conduct itself: which procedures to follow, when to inspect or yield, what evidence is required, and which actions are prohibited.
3. Tools are the steering wheel and brakes. They determine where the agent can actually direct its power, which actions it can execute, and where execution must stop.
4. The world model is the map. It describes which places exist, how they are connected, which routes are possible, and how the reachable world changes over time.

Agent vehicle
  Engine              = LLM
  Traffic rules       = Skills
  Steering and brakes = Tools
  Map                 = World Model

An engine can produce motion, but it cannot define the world, choose a valid route, or stop itself safely. Traffic rules can guide behavior, but prose alone cannot steer or brake the vehicle. A map can describe the available space, but it cannot execute an action.

Reliable agency emerges only when these four responsibilities remain distinct and work together.

Why Skills Should Stay Lightweight

A Skill should describe stable operating discipline:

• the objective of the workflow;
• the stages the agent should follow;
• when it should inspect, evaluate, repair, or escalate;
• which evidence is required before declaring success;
• how feedback should influence the next step.

It should not try to become a second implementation of every system it uses.

When detailed domain rules are copied into Skill prose, several problems appear:

• the instructions become too large to load and apply consistently;
• the same rule exists in both prose and executable software;
• documentation and runtime behavior drift apart;
• failures lead to more prompt patches rather than better system boundaries;
• compliance depends on the model remembering an instruction at the right moment.

Adding more Skills introduces a second problem: context competition. Each Skill consumes context, introduces terminology, and adds rules that the model must retrieve and reconcile during the task. As the collection grows, relevant instructions compete with irrelevant ones, overlapping Skills may disagree, and the agent has less attention available for the actual state of the problem.

More importantly, Skills are text. They can influence behavior, but they cannot guarantee behavior. An agent may misunderstand a rule, apply it at the wrong time, lose it in a long context, or choose a plausible action that the Skill never anticipated. No amount of prose can ensure complete compliance from a probabilistic model.

If a rule must always hold, it cannot live only in a Skill.

Traffic rules should be clear and economical. They should not attempt to reproduce the engine, the controls, or the map.

What Makes a Tool Strong

A strong Tool is not a large Tool, and a strong toolset is not necessarily a large collection of Tools.

A Tool is strong when it exposes a narrow, semantically meaningful operation with:

• explicit inputs and outputs;
• clear authority and permission boundaries;
• known side effects;
• deterministic validation where possible;
• actionable failure feedback;
• audit evidence and provenance;
• traceability from intent to result.

The steering-wheel part directs power toward a valid action. The brake part prevents or rejects an invalid action. Both are necessary.

A generic execution shell may be powerful, but it provides little semantic steering. A domain-aware operation such as evaluate model, approve payment, or generate from accepted specification offers a much stronger control surface. It tells the agent what kind of action exists, what it requires, and how success or failure will be judged.

The strongest Tool does not merely execute what the model asks. It helps constrain the space of askable actions.

Strong Tools Are the Core of Harness Engineering

An agent harness is the engineered environment around the model. It determines what context is supplied, what actions are available, how actions are validated, what feedback is returned, and what evidence is required before work is considered complete.

In that environment, Skills are useful—but they are not the enforcement layer. They provide compact procedural guidance. The core control surface is the Tool layer.

A strong harness moves critical behavior out of optional textual compliance and into executable structure:

• schemas reject malformed inputs;
• permissions prevent unauthorized actions;
• domain Tools expose valid operations instead of raw implementation access;
• evaluators reject invalid models and explain why;
• generated APIs prevent the agent from inventing interfaces;
• state machines disallow invalid transitions;
• compilers and tests reject inconsistent implementations;
• runtime guards enforce policies at the moment of execution;
• audit trails record what happened and why.

Skill
  suggests the procedure
       ↓
Agent
  reasons and proposes an action
       ↓
Strong Tool
  constrains, validates, executes, or stops
       ↓
Harness Feedback
  returns evidence for the next reasoning step

This is the essential difference between instructions and a harness. An instruction says, “Do not cross this boundary.” A harness makes the boundary difficult or impossible to cross, detects the attempt, and returns structured feedback.

The goal is not to eliminate agent judgment. It is to focus that judgment where semantics are genuinely uncertain while moving mechanical correctness into deterministic controls.

For that reason, harness engineering should prioritize better Tools over more Skills. When a failure repeats, the durable fix is usually not another paragraph. It is a narrower interface, a stronger validator, a clearer state model, a permission boundary, or a better feedback signal.

The World Model Defines the Reachable Space

Tools determine how an agent acts, but the world model determines what the agent believes it can act upon.

A useful world model explains:

• which concepts exist;
• which relationships connect them;
• which events can change those relationships;
• which constraints make an event or state valid;
• which states are currently reachable;
• what would change if a proposed action occurred.

Without that map, an agent may operate its controls correctly and still drive toward an invented destination. It may call a valid API while misunderstanding the meaning of the entity, role, state, or transition behind it.

The world model therefore limits and explains the action space. It gives both Skills and Tools a shared semantic reference.

From Probabilistic Understanding to Deterministic Results

LLM reasoning is probabilistic. That does not mean the resulting software process must be probabilistic from end to end.

A more reliable workflow is:

Human Intent
  -> Model
  -> Deterministic Evaluation
  -> Repair
  -> Deterministic Generation
  -> Constrained Customization
  -> Verification

The model is audited before it becomes executable. Errors are returned as structured feedback. The agent repairs the model and submits it again. Once accepted, deterministic generation projects that model into code and model-aware APIs. Later customization occurs through those constrained interfaces and is checked again by compilers, tests, policies, and runtime guards.

This creates an important separation:

• AI interprets intent and proposes semantic changes;
• the harness supplies the relevant context and available action space;
• deterministic Tools evaluate, generate, constrain, and verify;
• the accepted model remains the traceable source of meaning.

The result is not code that merely happened to be produced by an AI. It is a deterministic artifact derived from an audited semantic model, followed by customization inside explicit boundaries.

Our work with TeaQL was one practical source of this conclusion: repeated model evaluation and repair produced deterministic generated code and a constrained path for subsequent customization.

Feedback Belongs in the System

When an agent makes a mistake, the default response should not always be to add another sentence to its Skill.

First ask where the missing knowledge or enforcement belongs:

• If it is stable operating guidance, improve the Skill.
• If it defines the domain, improve the world model.
• If it controls what can be executed, improve the Tool.
• If it is mechanically verifiable, improve the evaluator, compiler, test, policy, or runtime guard.

This turns failure into system improvement instead of prompt accumulation.

The feedback loop becomes:

Attempt
  -> Tool Feedback
  -> Model or Implementation Repair
  -> Re-evaluation
  -> Verified Result

The agent still reasons and adapts, but it does not carry the entire burden of correctness in its context window.

This is how the harness becomes more capable without becoming a larger prompt: repeated failures improve the executable environment rather than permanently expanding the text the agent must remember.

A Better Division of Responsibility

The architecture can be summarized in four lines:

The LLM provides the power.
Skills define the rules of conduct.
Tools provide steering and braking.
The world model defines the reachable world.

“Lightweight Skills, Strong Tools” is therefore not primarily a prompt-writing technique. It is the central design principle of a reliable agent harness.

Reliable agents will not come from developing more and more Skills and asking a language model to remember them all. They will come from combining capable models with concise operating rules, explicit maps of reality, and a strong harness whose Tools make valid actions controllable, invalid actions stoppable, and every consequential result verifiable.