Over the past year, generative AI has shifted from chatbots to copilots and, increasingly, AI agents. This has been driven by a rapid rise in the capabilities of large language models (LLMs), but model performance is no longer the only bottleneck. The biggest area of innovation is how to build systems around those models that connect to the right data and help users with their actual work.
For domains such as energy and subsurface, useful AI depends on much more than language generation.
Domain work involves complex multidisciplinary data and numerical calculations under uncertainty. Decisions are made through experience and deep domain knowledge applied through strict regulations and decision gates to minimize risk.
Thomas Bartholomew Grant, Lead Domain Expert - Cegal.
Useful AI in these domains is therefore much more than the model alone and includes the entire system built around it. That wider system is what we usually mean when we talk about AI agents.
A language model cannot perform meaningful tasks on its own, it cannot retrieve data, take actions in external systems, or complete multi-step work. Agents change that through a simple architecture that turns model capabilities into a system that can not only plan but also act. An AI agent consists of a model, a harness, a scaffold, and a set of tools.
Figure 1: A simple agent architecture showing how the model, harness, scaffold, and tools work together to connect user intent with data and actions.
We can understand this through a simple mental model:
The model is the brain. It plans and decides what to do to solve a problem.
The tools allow the agent to conduct actions and interact with data, feeding information back to the model so it can decide what to do next.
The harness is the execution layer and determines how the agent calls the model, its tools, and when to stop. It provides a deterministic boundary to the agent’s actions.
The scaffold shapes how the agent behaves and is the lens through which the model sees and interacts with data. It includes additional context such as agent instructions or skills, which help the agent to decompose tasks and how to format its responses.
The terms harness and scaffold are new, so the definitions of them are evolving. However, in this article I make a clear distinction between them where the harness is any hard-coded, enforced behavior of the agent, and the scaffold is any natural language instruction or guideline the agent can use.
An agent can be built to be a static AI system where the tools, harness, scaffold, and model stay the same. This is great when you want the agent to be highly constrained and stable. Think of a customer-facing chatbot with a defined set of capabilities and use cases.
The real benefit of an agent, however, is the interchangeability of each of these components. You can change the model, what tools it has access to, and how it operates through the harness and scaffold. The modular nature of agents means that the same system becomes dynamic and able to adapt to a much wider range of users and workflows. For research and coding tasks, the output and how to get there may not always be well known beforehand. Solving open problems requires flexibility and exploring multiple solution paths.
In a dynamic agent system, where the model, scaffold, harness, or tools can be changed, each configuration results in an agent that is materially different from another. We should therefore view agents as temporary and adaptive interfaces assembled for a specific user, dataset, or task.
The challenge for those building agentic systems is to determine what should be deterministic, hard boundaries for the agent. A straightforward way to think of this is if the behavior can be described as “always” or “never” then that must be constrained inside the harness. Guidelines that help steer the agent’s behavior within that boundary can be placed in the scaffold.
The balance is to ensure controlled, secure, and reliable behavior without over-constraining the agent. Language models and agents are designed to be dynamic, and if that is not permissible, a deterministic rule-based system could be more appropriate. Hybrid systems are therefore interesting because agents can orchestrate, optimize, and chain together rule-based systems, but are more able to adapt to exceptions.
For agents to be useful, organizations need to focus less on the agent as a standalone object and more on the environment it operates in. The foundations start with understanding how data should be organized and governed, how agents should access and process that data, and which workflows they should be allowed to support. These questions are important because for every company the answers to those questions will be different and they shape the requirements for security, alignment with regulations, and human validation.
1. Data
If an agent cannot access the right data, if data is poorly organized, or if that data is outdated, incomplete, or incorrect, an agent may fail in ways that are subtle or hard to catch. The output may appear plausible but could be incorrect or of inferior quality. That carries a risk because decisions could be made using those agent outputs.
Organizations need to think deeply about how they should structure and govern their internal knowledge, which includes not just raw subsurface data, but also interpretations, domain expertise, business processes, and workflows. Agents also generate new data, which means that data governance should also be applied to their outputs.
Because the context provided to the agent affects the outcome, organizing data should be more than enabling personal productivity tools but a way of connecting teams and information across a company at scale. The Open Knowledge Framework (OKF) attempts to address this by creating an interconnected directory of organizational knowledge in file formats that are more efficient for agents to use.
2. Tools
Tools enable an agent to conduct actions and receive data and context, and without them, an agent is limited. Data should be accessible and managed securely through APIs and other forms of integration that ensure that the agent can only access the right data. The agent should not build its own functionality every time it runs, because this will produce different results each time. Exposing algorithms and reusable functionality that can be called by an agent through tools is a much safer way to ensure that certain actions are repeatable.
Model Context Protocol (MCP) provides a consistent way for an agent to discover and call tools, instead of relying on bespoke integrations for every system. MCP has become the dominant communication layer between agents and data.
3. Workflows
Agents can chain together multiple actions into a workflow to solve a task, where the model decides which tools to call and in what order. For example, an agent can pull data from multiple sources and execute calculations as part of an end-to-end task. However, this also means that small errors early in the workflow can compound into confident but unreliable final outputs. Documenting how work should be completed can also help structure agent behavior. Workflows can be added to the harness, be provided as governance material that the agent can access within the scaffold, or be implemented as callable rule-based systems within tools.
In this article, we have looked at how the design of systems around AI impacts how effective they can be to assist users. Model providers and generic agent harness products like those from Anthropic and OpenAI are extremely powerful. However, they need to be tailored to the energy domain so that agents can access the right data, process it with the right tools, and align agent behavior with users’ workflows. Agents should not be seen as boxes to be bolted onto existing software, but as a new layer through which we work with the data, products, and domain knowledge we already have.