Give Agents Primitives, Not Prepackaged Workflows

Published: 2026-08-28 2,509 words 8 min read

When designing a Harness for an Agent, start with a small set of clear primitives and let concrete tools and workflows emerge with the tasks that require them.

Agents Change the Cost of Abstraction

Before AI, an SDK was usually a sensible trade-off. It handled authentication, pagination, retries, and type conversion for developers, wrapping a complex API in easier-to-use functions. Developers wrote less code and did not need to understand every lower-level detail.

Agents change that calculation.

In the past, writing a few dozen lines of adapter code for a specific task took an engineer’s time, so we tried to package common needs into an SDK in advance. An Agent can now read the API documentation, construct requests for the task at hand, and write a parser, adapter, or batch script on the spot. The marginal cost of one-off code is approaching zero.

At that point, excessive abstraction can become a constraint.

An SDK decides the object model, parameter structure, error handling, and invocation style for its caller. Those decisions reduce cognitive load for people, but they can also hide capabilities that the service already provides. As soon as a requirement falls outside the SDK’s assumptions, the Agent must work around the abstraction or wait for the Harness to gain another specialized tool.

Let Agents Build Tools on Demand

A well-documented API with stable behavior and visible state is different. It gives the Agent material it can use directly. The Agent can call an endpoint as needed, inspect the response, and create whatever the current task is missing inside its execution loop: call the API, examine the response, write a small transformation script, and move on.

That script does not need to become a permanent part of the Harness or anticipate every future use case. It only needs to solve the problem in front of it. If the same operation recurs and its behavior becomes stable, it can be promoted into a formal tool later.

The purpose of a Harness, then, is not to predict every capability an Agent might need. It is to provide an open surface: a small set of semantically complete operations, clear and directly readable documentation, raw and observable inputs and outputs, a controlled code execution environment, and explicit boundaries around permissions and irreversible actions.

What Still Deserves Abstraction

Complex and stable mechanisms such as request signing, rate limiting, and transaction consistency still deserve abstraction. What should be reconsidered are the object models and business workflows designed primarily to make programming easier for people. They may not need to be passed unchanged to an Agent.

A good Harness provides stable primitives and safety boundaries; the Agent then creates the task-specific tools it needs.

When the same temporary tool recurs across tasks and its interface and error behavior have stabilized, promote it into the Harness. Until then, primitives should remain the direct source of capability.