What is an AI harness and why would I need one?

Summary

• An AI harness is the code that runs an agent's loop: it reasons with a model, calls tools, observes the results, and repeats until the agent can respond. Databricks documentation calls this layer the "framework or harness".
• Every agent has a harness. You either write the loop yourself or adopt a framework such as LangGraph or the OpenAI Agents SDK, so the practical question is which one to use.
• The harness is one of three layers in a deployed agent. An agent server wraps the loop in an HTTP service, and an agent runtime provides the managed compute that hosts it.
• Agent Bricks does not require a specific harness. Agent Runtime hosts agents built with any framework or harness, stateful or stateless.
• A meta-harness such as Omnigent composes and coordinates several agents, such as coding agents. Omnigent is in Beta on Databricks.

What is an AI harness and why would I need one?

An AI harness is the code that turns a model into an agent. A single model call returns one response. An agent runs a loop: it reasons about the request with a model, calls tools to gather information or take actions, observes the results, and repeats until it can respond. The harness is your code that runs that loop, together with the instructions and orchestration logic that define how the agent behaves. You need one because the loop has to run somewhere: something must call the model, run the tools it asks for, and decide when to respond.

What does a harness do, and what do the other layers do?

Databricks describes a deployed agent as three layers, and each layer wraps the one above it.

Layer	What it does	Options on Databricks
Framework or harness	Runs the agent loop: calls models and tools and decides what to do next	Any framework or harness, such as LangGraph or the OpenAI Agents SDK, or a meta-harness such as Omnigent
Agent server	Wraps the loop in an HTTP server, exposes the invocation API, manages client connections, and handles durability	DurableAgentServer (recommended), legacy agent servers, or your own server
Agent runtime	Runs the agent server on managed compute and handles hosting, identity, and scaling	Agent Runtime on Databricks Apps

Databricks provides other production concerns as separate components. Unity Gateway applies rate limits, guardrails, and usage tracking to the requests that pass through it. Managed memory and sessions are stores backed by Lakebase that work with any framework. MLflow Tracing records each step the agent takes, and Unity Catalog governs the data and tools the agent uses.

How does a harness fit into code?

The harness is your agent code, and the agent server calls it. In this example from the Databricks docs, run_my_agent stands in for your loop, and the server requires one invocation handler.

from databricks_agentkit import DurableAgentServer, InvocationContext

app = DurableAgentServer()

@app.invoke
async def invoke(input, context: InvocationContext) -> dict:
    await context.emit({"type": "status", "message": "Looking that up"})
    answer = await run_my_agent(input, session_id=context.session_id)
    return {"answer": answer}

DurableAgentServer adds durable execution so that runs survive restarts and crashes. Agents you create with the Agent Bricks CLI use it by default.

Which harness should you start with?

• A new agent. Pick a template. The Agent Bricks CLI (Beta) bundles one per framework: langgraph for LangGraph and openai for the OpenAI Agents SDK. For example, agentbricks init --framework langgraph my-agent.
• An agent you already built. If you built it with LangGraph or the OpenAI Agents SDK, run agentbricks init --framework langgraph --existing . in its directory. The CLI prepares migration instructions for a coding agent to follow. It does not rewrite your code.
• Several agents combined. Omnigent is a meta-harness that composes and coordinates multiple agents, such as coding agents. It is in Beta on Databricks, and the open-source project lists its status as alpha.
• No custom agent code. Genie Agents is a low-code way to build agents that answer questions over your tables and documents. Use it when you do not need custom agent code.

How does Databricks host your harness?

Agent Bricks is the Databricks agent developer platform, built for developers who write code. Agent Runtime runs your agent on Databricks-hosted serverless compute, on Databricks Apps, so you deploy code instead of provisioning servers.

• Identity. The agent runs as the app's service principal. Tools that use auth = "user" run with the permissions of the user who sent the request.
• Scaling. You can run an agent on 1 to 5 instances.
• Tracing. Deployment configures MLflow Tracing to the experiment that the project binds.
• Code execution. Databricks Sandbox (Beta) is a tool your agent calls to run the code it writes in an isolated environment, with scoped access to governed data.

FAQs

Can I run an agent without a harness?

No. Every agent has a loop, and the harness is the code that runs it. You can write the loop yourself and register it with the agent server, or use a framework such as LangGraph. Databricks lifecycle guidance is to start with the least complex design that works.

Does choosing a harness lock me in?

Agent Bricks does not require a specific framework, and you keep your framework, harness, and model choices. The templates keep your framework code separate from the code that connects it to the agent server.

Is Agent Runtime a harness?

No. The harness is your code and runs the loop. Agent Runtime is the managed compute that runs your agent server and handles hosting, identity, and scaling.

Where do guardrails and rate limits come from?

On Databricks they come from Unity Gateway rather than from your harness code. Unity Gateway applies rate limits, guardrails, and usage tracking to the requests that pass through it. It implements guardrails with service policies, which are in Beta.