AI Agents in the Enterprise: Tool Use, Guardrails and Where They Work

"Agent" now covers everything from a chatbot that can look up an order to a system that plans and executes a multi-step process across several business applications. The useful definition for an engineering lead is narrower: an agent is an LLM that decides which tools to call, in what order, based on what it sees, until it judges the task complete. That decision-making is what makes agents flexible, and it is also what makes them harder to test, predict and secure than an ordinary integration.

This post is about deploying them deliberately: choosing how much autonomy a task actually needs, designing tools the model can use safely, and building the guardrails that let you put an agent near production systems.

Start with the least autonomy that works

Many tasks described as "agentic" are better served by a fixed workflow where the LLM handles one or two steps (classify this, extract that, draft a reply) and ordinary code handles the control flow. Workflows are cheaper, faster, and far easier to test. Reserve open-ended agent loops for tasks where the sequence of steps genuinely depends on what is discovered along the way.

Our framework for where AI actually pays off applies directly: the higher up this table you go, the more important it is that errors are recoverable and detectable.

Tool design is most of the work

A model can only be as reliable as the tools it is given. Wrapping an entire internal API as tools and hoping the model figures it out produces erratic behaviour. Good agent tools look more like a well-designed service interface for a junior colleague than a raw API.

• Task-shaped, not endpoint-shaped. find_customer_by_email and get_open_orders beat a generic query_database.
• Clear descriptions. The tool description is the model's documentation. State what it does, when to use it, and what it returns, including the empty case.
• Tight input schemas. Enums instead of free text, required fields, sensible limits. Validate server-side regardless.
• Small, structured outputs. Return the fields the task needs, not a 5,000-line JSON dump that crowds out the rest of the context.
• Separate read from write. Different tools, different permissions, different approval rules.
• Idempotent writes. Accept an idempotency key so a retried step does not issue two refunds.

{
  "name": "issue_refund",
  "description": "Issue a refund for a single order line. Use only after confirming the order exists and is eligible via get_order. Requires human approval for amounts above the configured limit. Returns refund_id and status.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "pattern": "^ORD-[0-9]{8}
quot;
      },
      "line_id": {
        "type": "string"
      },
      "amount": {
        "type": "number",
        "exclusiveMinimum": 0
      },
      "reason": {
        "type": "string",
        "enum": [
          "damaged",
          "not_delivered",
          "duplicate_charge",
          "goodwill"
        ]
      },
      "idempotency_key": {
        "type": "string"
      }
    },
    "required": [
      "order_id",
      "line_id",
      "amount",
      "reason",
      "idempotency_key"
    ]
  }
}

If you plan to expose the same tools to several assistants or AI products, the Model Context Protocol gives you a standard way to package them once.

Guardrails that actually constrain behaviour

Instructions in the system prompt are guidance, not controls. A model can be talked out of them by a cleverly worded email it was asked to summarise. Real guardrails sit in code, outside the model.

MAX_STEPS = 15
WRITE_TOOLS = {"issue_refund", "update_address", "cancel_order"}

def run_agent(task, user):
    ctx = AgentContext(task=task, actor=user, budget=TokenBudget(limit=TASK_TOKEN_LIMIT))
    for step in range(MAX_STEPS):
        action = model.next_action(ctx)            # tool call or final answer
        if action.is_final:
            return action.answer
        if action.tool not in tools_allowed_for(user):
            ctx.add_error(f"{action.tool} is not permitted")
            continue
        validate(action.tool, action.args)         # schema + business rules
        if action.tool in WRITE_TOOLS and needs_approval(action, user):
            decision = approvals.request(action, ctx.summary())   # blocks or parks the task
            if not decision.approved:
                ctx.add_result(action, {"status": "rejected", "note": decision.note})
                continue
        result = execute(action, run_as=user)      # user's permissions, not a superuser
        audit.log(ctx.id, step, action, result)
        ctx.add_result(action, result)
    return escalate_to_human(ctx, reason="step limit reached")

• Run as the user. Tools execute with the requesting user's permissions, never a shared service account with broad access.
• Step and token budgets. Agents can loop. Cap steps, tokens and wall-clock time per task, and escalate when the cap is hit.
• Approval gates on consequential writes, with a summary that lets the approver decide in seconds. If approvers approve everything, the threshold is wrong.
• Treat tool outputs as untrusted. Content from emails, web pages or tickets can contain instructions aimed at the model (prompt injection). Never let retrieved text expand the agent's permissions.
• Audit every step: the tool, arguments, result and approval decision. You will need it for debugging and for the compliance review. See AI data privacy and governance.

Where agents work today

• Investigation and triage: pulling logs, tickets, account history and documentation together to propose a diagnosis for a human to confirm.
• Support resolution with bounded actions: answering questions from knowledge bases (see RAG for enterprise documents) and taking low-risk, reversible actions such as resending a receipt.
• Internal operations: reconciling records between systems and preparing the change for review.
• Software engineering tasks: where tests and code review provide an existing verification step.

They struggle where success is hard to verify, where steps are irreversible, or where the task requires judgement that the organisation itself has not written down. In those cases a workflow with an LLM step, or an agent that only proposes, is the safer design.

Testing agents

Agents need scenario-based evaluation: a set of tasks with known good outcomes, run against sandboxed copies of the tools, scored on the final result and on the path (did it call a write tool it shouldn't have, did it exceed budget). Run the suite on every prompt, tool or model change. Evaluating LLM applications covers the harness; for agents, add assertions on tool-call traces. Track cost per completed task too, since agent loops can consume many times the tokens of a single call; see LLM cost control.

Key takeaways

• Use the least autonomy the task needs; many "agent" projects are better as workflows.
• Invest in task-shaped, well-described, tightly validated tools.
• Put guardrails in code: user-scoped permissions, budgets, approval gates and audit logs.
• Assume tool outputs can contain hostile instructions and limit the blast radius accordingly.

HashTech helps teams scope and build agent and automation projects as part of its AI enablement practice.