Agents, Skills and OKF

This post explores how Agents can be powered by skills. It will also explore how we can provide knowledge to augment the skills and boost performance on complex tasks. The fast evolving Open Knowledge Format (see the spec here) provides one option to represent knowledge.

Part 1 of this post goes through the building blocks. Part 2 focuses on OKF concepts, Part 3 will focus on the code.

Building Blocks

There are three major building blocks for the system described above:

1. The AI Model powering the agent.
2. Knowledge Tools available to the agent.
3. Skills and Knowledge artefacts available to the agent.

Let us tackle the two easy ones first.

AI Model

The AI model for this needs to be able to follow instructions, operate tools and have a fairly decent context window size (at least 16k for basic tasks). Reasoning mode also needs to be supported by the AI Model harness as well as conversational state management.

Context window size

This defines the amount of information the AI model can keep in view at a given time. This is super critical especially for complex tasks where lot of this precious space is taken up by summaries of linked content, planning outputs, reasoning hints, and guidance text.

The best way to visualise this is that the AI agent is building a bridge from the request to the required output one step at a time. The size of the step it can take is determined by the context window size.

Trade-off: when we use million token context models like Gemini Pro it gives some breathing room to the amount of information you can store. At the same time it can also create information overload, divergence, and mis-direction.

Overload happens when there is too much information about the task.

Divergence happens when two information items contradict.

Mis-direction happens when one particular information item dominates the landscape and prevents a smooth transition from explore (finding the best solution) to fulfil (executing the solution in an optimal manner).

Reasoning mode

Without reasoning mode context window size is of limited use. If the context window size is the step size as the AI agent builds the bridge from the request to the required output then the reasoning mode defines the effort spent in building each step.

Reasoning mode at its simplest is all about moving away from request-response of Gen AI to more of a request-reason-response expected from AI agents. It also provides a multi-layered safety net and improves output quality where the request and candidate response is further studied by the AI model, tools are used to fetch validation data, fetched data is compared with the request and candidate response, candidate response is re-written with added references and so on.

Trade-off: As with everything this kind of loop can take an AI agent down the wrong track leading to either wasted effort of generating and reviewing content that is irrelevant or (even worse) taking decisions that leave a longer term impact.

This is usually seen when weaker models are used with reasoning loops. I have had several instances of Gemma4 spinning its wheels attempting to decide whether I wanted it to solve a question or explain how to solve it without solving it.

Reasoning loops are also impacted by the amount of stuff in the context window. If it has previous turns from the current conversation and if those turns end up feeding overload, divergence or mis-direction then reasoning is like adding fuel to the fire.

The Gemma4 example above was because previously in the same conversation I was talking about solving a problem and the model was not able to detect conversational drift and therefore focus on the current ask.

Tool Use

This requires the model to be able to embed tool use within the reasoning loop. Tool use allows external information to be brought in as well as information to be persisted during the reasoning and generation process.

Trade-off: the big trade-off here is that tools can also add confusion to the process and be a mechanism that starts the overload, divergence, or mis-direction fire. When content is pulled from different sources we often are not in control of what is pulled.

Similarly when content is written we are not sure what is being persisted and what will be the context when read.

Knowledge Tools

Knowledge tools are tools that enable access to knowledge as well as ability to create and persist knowledge.

Read: Agents that Educate Themselves

Tools that enable the AI agent to read from a directory structure (usually sandboxed filesystem with strict permissions) on demand. This provides some flexibility around sourcing knowledge. This moves away from the older concept of prompt templates where all the information had to be in there or loaded piece by piece.

The concept of prompt templates only works for prior knowledge and not for runtime-required knowledge. With these kinds of tools prompt templates become prior knowledge injection points, more to bootstrap than actively run the agent. For example prompt templates can provide information about the task, guardrails, knowledge sources (e.g., directory structure and files), and tools to access those knowledge sources (read directory, read file).

An extension of this would be tools that allow some form of guarded web-search which allows AI agents to retrieve knowledge from curated sources. This is specifically important to enable the time-axis of knowledge where the AI agent can reacquire knowledge when a time threshold is crossed (e.g., latest interest or currency conversion rates).

Write: Agents that Leave Notes For Themselves

Tools that enable the AI agent to write files is the next step in knowledge fluidity. This allows the AI agent to write intermediate notes (within a request-reason-response cycle) to guide generation and to trace out its approach for explainability and human in the loop.

It can also be used to create long running guidance artefacts that persist across multiple interactions tracking past actions, outputs, user preference, and reasoning traces. This can then form the basis of a customer independent long term agent memory.

Skills and Knowledge Artefacts

This is perhaps the toughest section. Because we come from format to semantics.

Skills are based on one or more agreed definitions that explain the how of a task including tools to be used, process flows, sequencing, guardrails and supporting knowledge. Knowledge artefacts using formats such as OKF represent an ‘agent navigable wiki’ that stores a set of related concepts and metadata around it.

Given this concept is pretty fluid you could actually have a skills wiki that allows an agent to learn all the skills available and then those skills themselves could link to specific knowledge artefacts that educate the agent regarding the task.

As you start building out skills -> knowledge artefacts -> skills graphs you start defining what I call a skills network. Your AI application then simply navigates this network.

That’s all folks (for this part)…

Part 2 of this post is now live – around OKF concepts.

Part 3 of this post will focus on the technical implementation of some of these concepts including OKF (and lots of code!).