Building Agentic AI That Actually Ships: Patterns From the EagerHQ Workshop

Agentic AI is having a moment. Every other Twitter thread is a demo of an agent doing something impressive. Most of those demos never make it into production. The gap between a working prototype and an agent a customer can rely on is enormous, and most of it lives in the unglamorous parts of the stack.

This is a short tour of the patterns we use at EagerHQ to close that gap. It is drawn from the agent layer inside Voxlit and from the automation work we do for clients. It is opinionated, and it is aimed at engineers who already know what a tool call is.

A demo needs an agent to succeed once. Production needs it to succeed on the ninetieth attempt of the day, on a flaky network, with a user who typed the wrong thing.

The single highest-leverage decision in any agent is what tools it can call. We have one rule: every tool does exactly one thing, and that thing has a clear success condition.

• No do_stuff(input) tools. If you cannot name what it does in five words, split it.
• Return structured, verifiable output. { ok: true, inserted_chars: 42 } beats a free-text success message every time.
• Idempotency where possible. send_slack_message with a client-generated dedupe key prevents double-sends on retry.

Every additional tool multiplies the failure surface. We have shipped agents with three tools that outperformed agents with thirty.

The agent loop itself is not where the cleverness lives. It should be boring, explicit, and easy to reason about under failure.

async function runAgent(goal: string) {
  const history: Turn[] = [];
  for (let step = 0; step < MAX_STEPS; step++) {
    const response = await model.complete({ goal, history, tools });
    if (response.finish_reason === "stop") return response.text;

    for (const call of response.tool_calls ?? []) {
      const result = await invokeTool(call, { timeoutMs: 10_000 });
      history.push({ call, result });
      if (result.fatal) return abort(result);
    }

    if (tokenBudgetExceeded(history)) return summariseAndReturn(history);
  }
  return abort({ reason: "max_steps" });
}

• A hard step cap. Infinite loops are the default failure mode for agentic systems. Pick a number, enforce it.
• A token budget that triggers summarisation before truncation does. Truncated context silently changes behaviour.
• A tool timeout. Slow tools will lie to you about whether they finished.

Agents fail in ways traditional services do not. The tests pass, the tool calls return 200s, and the output is still wrong. You need logs that tell you why.

• Log every tool call with inputs, outputs, and duration. Redact PII at the logging boundary, not upstream of it.
• Log the model's reasoning text where the provider gives it. You will spend hours reading these logs, and they are worth every minute.
• Track a small set of outcome metrics. For us: task completion rate, mean tool calls per task, retry rate, and user correction rate.

User correction rate is the most honest metric you can track. If users keep fixing the agent's output, the agent is failing, regardless of what the benchmarks say.

Provider outages

Your primary model provider will go down. Plan for it. We run a short fallback chain: primary, secondary, then a degraded local mode for read-only tasks.

Tool loops

The agent calls a tool, gets an error, calls the same tool with the same arguments, gets the same error. We detect repeated identical calls and inject a synthetic observation into the history: you just made this same call and it failed for reason X, try something else.

Hallucinated tools

The model invents a tool name that does not exist. We return a structured error listing the real tool names. Nine times out of ten the next step picks the correct one.

Silent success

The most dangerous failure. The agent reports success, but the downstream effect never happened. The fix is to have tools return verifiable evidence, not self-reports.

• A fixed set of at least 100 tasks with known-good outcomes. More if the domain is wide.
• Automated graders where possible. LLM-as-judge is fine for fuzzy outcomes as long as you sample and audit.
• Regression runs on every prompt or model change. One surprise regression is enough to justify the whole pipeline.
• A small "hard" set of real-world failures you have seen. This catches more real regressions than synthetic tasks ever will.

• Start with a read-only version. Let the agent observe and suggest before it acts.
• Require explicit user confirmation for any irreversible action in the first release. Relax later when confidence is earned.
• Rate-limit per user aggressively. Agents that go infinite will happily spend your budget before you notice.
• Feature-flag the model version. Being able to roll back a prompt in 30 seconds has saved us more than once.

The prompt is maybe 10 percent of the work. The rest is tool design, loop management, observability, evaluation, and deployment. If you want help building agentic systems that actually survive contact with real users, we build exactly this at EagerHQ. Write to hello@eagerhq.com.