Agentic Workflows: From Prompt to Production

← All Articles

There's a big difference between an LLM that answers questions and an LLM agent that gets things done. The gap between a convincing demo and a reliable production system is where most enterprise AI projects stall. After deploying agentic workflows at Albertsons Companies — connecting Claude to internal tools, automating engineering tasks, and building document intelligence pipelines — I have a clear picture of what that gap looks like and how to close it.

What Makes Something an Agent?

An agent is an LLM that can take actions, observe results, and decide what to do next — in a loop. A chatbot responds to a single prompt. An agent can:

• Call a tool to fetch live data
• Reason about the result and decide whether it needs more information
• Chain multiple tool calls to complete a multi-step task
• Handle failures and retry with different approaches

The tool use capability is what enables this. Claude, like other frontier models, can be given structured tool definitions and will decide when and how to call them.

Designing Tools That Agents Can Actually Use

The quality of your tool definitions directly determines the quality of your agent's behavior. Vague descriptions produce vague tool usage. I follow these rules for every tool we build:

1. One clear purpose per tool

A tool called get_order_info that returns everything about an order is worse than separate tools for get_order_status, get_order_items, and get_order_timeline. Specific tools lead to specific, intentional tool calls.

2. Write the description for the model, not for humans

The description field is read by Claude to decide whether to use this tool. Write it as a complete sentence that explains exactly when this tool should be called and what it returns:

// Bad description
"description": "Gets cart data"

// Good description
"description": "Retrieves the current shopping cart for a user session,
including item list, quantities, applied promotions, and estimated total.
Call this when you need to understand what a customer currently has in their cart."

3. Make required vs optional fields explicit

Always use the required array in your JSON schema. Ambiguous schemas produce unnecessary clarification loops where the agent asks for information it could reasonably default.

Managing Context Windows in Long-Running Agents

Context is finite. An agent that accumulates tool results indefinitely will eventually hit the context limit — often at the worst possible moment, mid-task. Our strategies:

• Summarize tool results before returning them. Instead of returning a full 500-line JSON blob, post-process tool results to extract only what's relevant for the current step.
• Use a scratchpad pattern. Give the agent a dedicated memory tool it can write compressed state to and read back from, freeing the main context window.
• Implement sliding window history. For long conversations, keep the last N turns plus a compressed summary of earlier turns rather than the full history.

Handling Failures Gracefully

Agents will encounter tool failures. The API goes down. The query returns no results. The upstream service times out. How your agent handles these failures determines whether it's production-ready.

We implement three layers of failure handling:

1. Tool-level retry with exponential backoff. Transient failures (network timeouts, 503s) are retried automatically before the error is returned to the agent.
2. Graceful error messages in tool responses. Instead of throwing exceptions that confuse the model, return structured error objects: {"error": "ORDER_NOT_FOUND", "message": "No order found for ID 12345"}. Claude handles these much better than raw error strings.
3. Agent-level circuit breaking. If an agent has failed the same tool call 3 times, we surface a human escalation prompt rather than letting it spin indefinitely.

Human Oversight: Non-Negotiable in Enterprise

Every agentic system we've deployed has a human oversight layer. The architecture:

• Read operations: Fully autonomous. The agent can call any read tool without approval.
• Low-impact write operations: Auto-approved if confidence score > 0.85 (we compute this based on task complexity and tool call consistency).
• High-impact write operations: Always routed to a human approval queue. The agent prepares a proposed action with reasoning, a human approves or rejects within a time window, and the agent proceeds accordingly.

Observability: The Difference Between Demo and Production

You cannot operate agentic systems you cannot observe. Our observability stack for agents:

• Structured trace logging for every tool call: input, output, latency, token count
• Splunk dashboards tracking agent success rates, average tool calls per run, and failure modes
• Alert thresholds on tool error rate, average run duration, and context window usage
• Session replay for failed runs — full tool call history stored in S3 for post-mortem analysis