What an agent is in production

An agent is a system around a prompt

A chatbot answers one question and stops. An agent keeps going until a task is done. It plans, calls a tool, reads the result, checks it, and decides what to do next. That loop is what makes an agent useful, and it is also what makes it risky: every pass can touch a real system.

At NexOps, we start every agent project with one sentence: which task, for whom, and how do we measure that it went well? If you cannot answer that, you are not ready to pick a model. The model is one part of the system, and it is the part you can replace with the least work.

This course follows one agent from design to operation. In this first lesson we define the loop and the eight building blocks. We do not cover framework choices in depth, because the blocks stay the same whichever framework you pick.

The loop

Every production agent runs the same six steps.

1. Goal. A task with a success measure, for example "classify the incoming request and draft a reply that a person can approve".
2. Plan. The model breaks the task into steps. Keep plans short. A long plan is a long list of places to go wrong.
3. Call a tool. The model asks the harness to run a tool. The harness, not the model, executes it, with the permissions of a scoped service account.
4. Observe. The harness returns the result, together with its source.
5. Check. Rules, guardrails and an evaluation set decide whether the step is acceptable.
6. Answer or hand over. The agent finishes, or a person decides.

The important design rule is that the loop is bounded. Set a maximum number of steps, a maximum duration and a token budget. An agent without a bound will, sooner or later, loop on a tool error and spend your budget on it.

The eight building blocks

The same parts appear in every agent we build. Treat each one as something you configure, test and own.

Lessons 2 to 8 take these blocks one by one.

A minimal loop in code

The sketch below shows the shape of a bounded loop. It is schematic: it shows the control flow, not the API of any framework.

# Schematic agent loop. The names are placeholders, not a real framework API.
MAX_STEPS = 8          # hard bound on passes through the loop
TOKEN_BUDGET = 40_000  # hard bound on tokens for one task
 
def run_agent(task, model, tools, checks):
    state = {"task": task, "history": [], "tokens": 0}
    for step in range(MAX_STEPS):
        decision = model.decide(state)               # plan or answer
        if decision.kind == "answer":
            return checks.final(decision.text, state)  # last gate before the user
        if decision.tool not in tools:               # deny by default
            state["history"].append(("error", "unknown tool"))
            continue
        result = tools[decision.tool].run(decision.args)  # runs with a scoped identity
        state["history"].append((decision.tool, result))  # result and its source
        state["tokens"] += model.last_usage
        if state["tokens"] > TOKEN_BUDGET:
            return handover(state, reason="budget")  # a person takes over
    return handover(state, reason="step limit")

Three details matter. The tool list is an allow list, so an unknown tool is an error and never an improvisation. Every result goes into the history together with its source. And both exits, budget and step limit, hand the task to a person instead of failing silently.

Where the agent loop connects to the platform

On Databricks, the pieces line up like this. Tools are reached through MCP servers, which can be Databricks-managed, custom or external, and Unity Catalog permissions govern the managed ones. Conversation state and long-term memory are stored in managed stores backed by Lakebase. MLflow Tracing records each step with its inputs, outputs, latency and token usage. Unity Gateway sits in front of the models and adds access control, budgets, limits and logging. The current documentation calls it Unity Gateway; many teams, and our site, still say Unity AI Gateway.

Do not treat this list as a shopping list. Start with the task and the measure, then add only the blocks the task needs. A reply drafter for an internal service desk needs fewer tools than an agent that updates your ERP.

Common mistakes

• Starting with the framework. Pick the task and its evaluation set first. Frameworks come and go; the loop stays.
• One big agent. Several small agents with one job each are easier to test than one agent with twenty tools.
• No bound. Always set step, time and token limits.
• No handover. Define who takes over, and how they see what the agent did.

Summary

An agent is a bounded loop around a model with scoped tools, memory, guardrails, evaluation and a person who can approve. The model is replaceable. The loop, the bounds and the evidence are what you keep.

In the next lesson we look at the block with the most risk: tools.