How AI Acquires Professional Capabilities Beyond the Model

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.

Knowledge Is Not Yet Capability

Suppose an experienced engineer knows how to respond to an unusual vibration pattern in a machine. The correct response may depend on load, temperature, lubrication state, recent maintenance, and the cost of an unnecessary shutdown. A document can record those factors. Retrieval can place the relevant paragraph in the model's context.

But professional capability involves more than repeating that paragraph. The engineer must:

• recognize when the procedure applies;
• gather the required evidence;
• distinguish a warning from a critical condition;
• use approved diagnostic operations;
• respect authority and safety boundaries;
• produce a decision that another person can inspect;
• act only when the evidence and permission are sufficient.

The same distinction appears in software delivery. An AI may retrieve a database convention or a domain rule and still invent a method name, omit a tenant boundary, save an invalid object graph, or run an unsafe operation. It has access to knowledge, but it does not yet possess a reliable capability.

This distinction matters most for knowledge that was never present in model training:

• private enterprise policies and operating procedures;
• domain-specific methods and terminology;
• proprietary workflows and decision rules;
• local architecture conventions;
• engineering lessons learned from previous incidents;
• tacit review standards used by experienced practitioners.

These are not special cases. They are where much of an organization's real advantage lives.

RAG Finds Knowledge; Harness Engineering Operationalizes It

Retrieval-augmented generation is well suited to locating relevant information:

Question
  -> Retrieval
  -> Relevant private context
  -> Model response

It can answer, “Which policy applies?” or “What does our design guide say?” It can reduce hallucination caused by missing context and make private documents available without retraining a foundation model.

However, retrieval does not by itself answer several harder questions:

• Did the agent apply the correct procedure?
• Is the produced model or code structurally valid?
• Does the result preserve domain invariants?
• Is the requested action permitted for this identity and tenant?
• Are resource limits and side effects controlled?
• Can the organization reconstruct what happened and why?

Harness engineering addresses this next step:

Private knowledge
  -> Procedural guidance
  -> Constrained construction
  -> Verification
  -> Governed execution
  -> Evidence

RAG and harness engineering are complementary. RAG supplies relevant context. A harness turns context into an operating discipline, an executable artifact, and a controlled action.

The Three-Layer Method

The method can be summarized as:

Skill
  keeps direction and method correct
        ↓
Build Harness
  makes the constructed artifact correct
        ↓
Runtime Harness
  keeps actual execution correct

Each layer addresses a different failure mode. None can substitute completely for the others.

Layer 1: Skill Keeps Direction and Method Correct

A Skill gives the agent a compact operating method. It explains the goal, the important stages, the evidence to inspect, when to use a Tool, when to repair a result, and when human judgment is required.

For example, an internal incident-response Skill might tell the agent to:

1. identify the affected service and business impact;
2. gather current telemetry before proposing a cause;
3. compare the evidence with known failure patterns;
4. use read-only diagnostics before considering a mutation;
5. escalate when the proposed action crosses a declared risk threshold;
6. record the evidence behind the conclusion.

This is far more useful than a collection of retrieved paragraphs because it organizes knowledge into a procedure.

But a Skill remains guidance expressed in language. It can influence a probabilistic model; it cannot guarantee that every required field exists, every invariant holds, or every prohibited action is blocked. As Skills grow into exhaustive rule catalogs, they also compete for context, drift away from the implemented system, and become harder for the model to apply consistently.

The right role for a Skill is therefore stable direction and method—not mechanical enforcement.

Layer 2: The Build Harness Makes the Artifact Correct

Once the agent begins constructing something—a domain model, application, workflow, configuration, report, or decision package—correctness must move into executable feedback loops.

A Build Harness may include:

• schemas and type systems;
• domain-specific languages;
• linters and static analyzers;
• policy evaluators;
• deterministic generators;
• compilers;
• unit, integration, and acceptance tests;
• simulations and benchmark cases;
• structured error reports that support repair.

These mechanisms do not merely tell the agent what correctness means. They test the artifact and return evidence.

Agent proposes an artifact
  -> Evaluate
  -> Return structured failures
  -> Repair
  -> Re-evaluate
  -> Generate or package
  -> Test

This loop is especially important when teaching an AI a new technology or an internal engineering method. A long prompt can describe the method, but a validator can reject an invalid representation. A compiler can detect an invented interface. A test can prove that a critical scenario works. A deterministic generator can preserve rules the model should not reproduce from memory.

The build layer changes the meaning of “the AI knows how to do it.” The claim no longer depends only on whether the model can produce a convincing answer. It depends on whether the result passes the organization's executable definition of correctness.

Layer 3: The Runtime Harness Keeps Execution Correct

A correct artifact can still be used incorrectly.

Production execution introduces identity, authority, current state, concurrency, resource limits, sensitive data, side effects, and failure recovery. These conditions cannot be settled permanently during generation. They must be enforced when an action is attempted.

A Runtime Harness provides controls such as:

• authenticated identity and request context;
• authorization and tenant boundaries;
• approved, semantically narrow Tools instead of unrestricted access;
• transaction and state-transition guards;
• input, output, and policy validation;
• rate, time, memory, and cost limits;
• sandboxing and network boundaries;
• approval gates for consequential actions;
• idempotency, rollback, and recovery mechanisms;
• logs, provenance, and audit evidence;
• monitoring and the ability to stop execution.

This layer answers questions that no Skill can reliably answer in prose: Does this user have permission now? Is this transition valid from the current state? Has the spending limit been reached? Is the target inside the approved environment? Can the exact action and its justification be reconstructed later?

The Runtime Harness is where advice becomes authority-aware action.

TeaQL as a Concrete Case

TeaQL is useful here not because every enterprise should adopt the same technology, but because it makes the three layers visible in one engineering workflow.

The TeaQL agent workflow begins with a lightweight Skill. The Skill directs the agent to understand the business requirement, express it as a typed domain contract, evaluate the contract, repair reported problems, generate the application, and provide concrete completion evidence. It describes the path without attempting to embed every modeling and programming rule in the prompt.

The build layer then carries the detailed correctness burden. The Generation Service evaluates the domain model and returns structured reports. Deterministic generation projects an accepted model into code and model-aware APIs. Generated local guidance exposes the current interfaces. Compilers and tests reject invented methods, invalid types, and broken behavior.

The runtime layer constrains what the resulting application can do. Queries and writes execute through a user context. Read operations carry purpose and comments; mutations carry audit descriptions. Provider and repository boundaries control persistence. Policies, tenant rules, generated business APIs, and runtime checks sit between AI-generated application logic and the underlying data systems.

In simplified form:

Business requirement
  -> Skill-guided domain modeling
  -> Evaluation and repair
  -> Deterministic generation
  -> Compiler and test evidence
  -> User-context execution
  -> Policy, permission, and audit controls

The important result is not that the model memorizes TeaQL. It is that a general-purpose model can use a capability that was not part of its training, while detailed rules remain in the systems best able to enforce them.

This is also why the case should not be reduced to code generation. The same architecture applies whenever professional knowledge must cross the boundary from explanation to responsible execution.

From Internal Knowledge to Executable Knowledge

Consider four examples.

An insurance company may have a proprietary claims-review method. RAG can retrieve the policy and prior cases. A Skill can define the review sequence. A Build Harness can validate that the decision package contains the required evidence and calculations. A Runtime Harness can enforce adjuster authority, protect customer data, and audit the final action.

A manufacturer may have an internal process for diagnosing equipment. A Skill can guide evidence collection. Diagnostic Tools and simulations can verify the proposed intervention. Runtime controls can prevent an agent from changing machine parameters outside an approved range.

A bank may have a private credit-exception workflow. Retrieval can provide policy context. A Skill can distinguish ordinary assessment from exception handling. Validators can check the completeness and consistency of the case. Runtime permissions and approval gates can ensure that a recommendation does not become an unauthorized decision.

A software organization may have years of engineering experience encoded across code review comments, incident reports, and unwritten conventions. A Skill can express the stable workflow. Build checks can enforce architectural rules and test critical cases. Runtime boundaries can restrict deployment targets, secrets, infrastructure changes, and production access.

In every example, the useful transformation is:

Information
  -> Procedure
  -> Verifiable artifact
  -> Constrained action
  -> Auditable evidence

That is what it means to turn organizational knowledge into executable knowledge.

Where Each Rule Should Live

A practical design test is to ask what kind of rule has failed:

Question	Best home
What goal and workflow should the agent follow?	Skill
What private context is relevant to this case?	Retrieval and context layer
What concepts, relationships, and invariants define the domain?	Domain or world model
Can this artifact be shown to be structurally and behaviorally valid?	Build Harness
Is this actor allowed to perform this action in the current state?	Runtime Harness
What happened, why, and with whose authority?	Runtime evidence and audit

When a failure repeats, adding another paragraph to a prompt is rarely the strongest long-term fix. Stable procedural guidance belongs in a Skill. Domain meaning belongs in an explicit model. Mechanical correctness belongs in validators and tests. Authority and side-effect control belong at runtime.

This division keeps the model's context smaller while making the surrounding system stronger.

A Capability Formula for Enterprise AI

The method can be expressed as a compact systems formula:

Enterprise AI Capability
  = Foundation Model
  + Domain Context
  + Skill
  + Build Assurance
  + Runtime Assurance

The foundation model contributes general reasoning and generation. Domain context supplies knowledge the model did not contain. The Skill provides operating method. Build assurance makes artifacts verifiable. Runtime assurance makes real actions governable.

If any of the later layers is missing, the system tends to fall back into one of two weak modes: an AI that can discuss the organization's knowledge but cannot reliably act, or an AI that can act but cannot be trusted with consequential work.

The Next Step After Retrieval

Enterprise AI is moving through three progressively harder questions:

Knowledge:  Can the model know?
Retrieval:  Can it find the relevant private knowledge?
Execution:  Can it apply that knowledge correctly and safely?

The third question is not solved by a larger context window or a better search index alone. It requires engineering around the model.

TeaQL offers one concrete example of that transition: lightweight procedural guidance, deterministic construction and verification, and a constrained runtime boundary. The broader method is technology-independent. Any organization can apply it to its own internal knowledge, specialist methods, proprietary processes, and accumulated engineering experience.

The goal is not to make a foundation model contain every organization's expertise. The goal is to build systems through which a capable model can use expertise it was never trained on—and do so with evidence, limits, and accountability.