For any service-based business—from commercial cleaning to landscaping —revenue volatility is a constant. When revenue drops 70% month-over-month, standard BI dashboards are great at telling you what happened, but fall short of explaining why. Was it a failed marketing campaign, a seasonal slump, or an operational bottleneck? Answering this requires a manual, time-consuming data-pulling and analysis process.

This post details how we built a "Marketing Analyst Agent" using the AWS Strands SDK to automate this root cause analysis. This agent moves beyond simple data reporting to autonomously diagnose the underlying drivers of business performance, providing clear, evidence-backed insights on demand.

Why We Chose AWS Strands

We selected AWS Strands for several key reasons that make it ideal for developing production-ready, customizable AI agents:

• Code-First and Open Source: Strands is an open-source SDK that empowers developers with a code-first approach. This gives us complete control over the agent's logic and tool integration, avoiding the constraints of low-code platforms and preventing vendor lock-in.
  
• Multi-Model and Hybrid Environment Support: The framework is model-agnostic, supporting LLMs from Amazon Bedrock, Anthropic, OpenAI, and local models via providers like Ollama. This flexibility allows us to choose the best model for the task and cost. Because Strands is open source, agents can be developed locally and deployed anywhere—on-premises or in any cloud environment—making it perfect for hybrid architectures.
  
• Customizable Tool Orchestration: Strands excels at letting the developer define a set of custom tools (e.g., Python functions) and then leverages the LLM's reasoning to plan and orchestrate how those tools are used to solve a problem. This model-driven approach is more flexible than hard-coding rigid workflows.
  
• Production-Ready Observability: For enterprise use cases, observability is non-negotiable. Strands has built-in support for OpenTelemetry, providing native metrics, logs, and distributed tracing out of the box, which is essential for monitoring agent performance and diagnosing issues in production.

Observability in Action with OpenTelemetry and Langfuse

Tracing is a fundamental component of the Strands SDK's observability framework, providing detailed insights into the agent's execution. Using the OpenTelemetry standard, Strands captures the complete journey of a request, including every LLM interaction, tool call, and processing step.

For our project, we used Langfuse, an OpenTelemetry-compatible platform, to visualize these traces. This gave us a hierarchical view of the agent's execution, allowing us to:

• Track the entire agent lifecycle, from the initial prompt to the final synthesized response.
• Monitor individual LLM calls to examine the exact prompts and completions.
• Analyze tool execution, understanding which tools were called, with what parameters, and the results they returned.
• Debug complex workflows by following the exact path of execution through multiple cycles of the agent's reasoning loop.

As seen in our Langfuse dashboard, the trace for a single query like "invoke_agent Strands Agents" provides a clear, visual breakdown of the Agentic Loop. We can see the agent executing its plan, making sequential calls to tools like execute_tool_run_sql, and processing the results. This level of transparency is invaluable for identifying performance bottlenecks and ensuring the agent behaves as expected

The Agentic Loop: Core of the Autonomous Reasoning

At the heart of Strands is the Agentic Loop, the iterative process that enables the agent to function autonomously. Instead of following a predefined script, the agent cycles through a loop of reasoning, acting, and observing until it completes its task.⁸ For a complex query, this looks like:

1. Plan: The LLM first analyzes the user's prompt and creates a multi-step plan.
2. Act: It selects and executes the most appropriate tool to accomplish the first step of its plan.
3. Observe: It takes the output from the tool (e.g., raw data, an error, a calculation result) and adds it to its context.
4. Repeat: Based on the new information, the LLM re-evaluates its plan, decides on the next best action, and continues the loop—calling more tools or synthesizing an answer—until the initial prompt is fully resolved.

This loop is what allows the agent to handle complex, multi-step analyses that would otherwise require a human analyst.

Architecture: A Two-Tool Approach for Analysis

To give our agent the ability to both retrieve and analyze data, we designed a clean, two-tool architecture. The tools are simple Python functions exposed to the agent using the @tool decorator.

1. sql_tool (The Data Retriever): This tool's sole responsibility is to fetch raw data. It contains functions that connect to our data warehouse (in this case, on Azure) and execute specific, parameterized SQL queries. It can pull job counts, revenue figures, lead sources, and job completion statuses. It doesn't perform any analysis; it just provides the facts.
   
2. ds_tool (The Analyst): This is the agent's analytical engine. It takes the structured data retrieved by the sql_tool as input and applies statistical methods to find meaningful relationships. It can run a correlation analysis to determine if a drop in jobs is statistically linked to a reduction in marketing leads while simultaneously showing no significant correlation with adverse weather patterns.

Use Case: Diagnosing a Revenue Drop for a Cleaning Service

To validate the agent, we generated a synthetic dataset modeling the operations of a multi-location cleaning service, complete with seasonal trends and marketing campaign variables.

User Prompt: agent.ask("Why was cleaning revenue down in Seattle during February 2024?")

Agent Output:

**#1. Dramatic Drop in Job Volume (Primary Factor)**
- February 2024: **8 jobs** vs January 2024: **20 jobs** (60% decrease)
- **Confidence: High** - Job count is directly measurable and clearly shows the primary issue

**#2. Revenue Impact Analysis**
- February 2024 revenue: **$1,577.46** (down 71% from January's $5,367.34)
- Average revenue per job was also lower: **$197.18** vs January's **$268.37** (26% decrease)
- **Confidence: High** - Clear mathematical relationship

**#3. Marketing Campaign Performance**
- February had significantly fewer campaign-driven jobs: **2 campaign jobs** vs **7** in January
- **Confidence: High** - Clear reduction in marketing effectiveness

**#4. Weather was NOT a Factor**
- February 2024 and 2023 had nearly identical weather patterns (avg temp ~10.5°C)
- **Confidence: High** - Weather data rules this out as a cause

**## Root Cause (Most Likely):**

1.  **Reduced Marketing Activity**: Only 2 campaign-sourced jobs vs 7 in January suggests marketing campaigns may have been scaled back or performed poorly.

**## Recommendations:**

- Investigate marketing campaign performance and budget allocation for February 2024.
- Analyze technician scheduling and availability.

This output demonstrates the agent's effectiveness. It correctly identified the primary issue (a drop in job volume), traced it back to a specific cause (reduced marketing activity), and, just as importantly, proactively ruled out a plausible but incorrect hypothesis (weather).

Conclusion

Using AWS Strands, we were able to build a powerful analytical agent with a simple, modular architecture. Its code-first, open-source nature provided the flexibility and control we needed, while features like multi-model support and built-in observability make it a production-ready framework. By leveraging the model-driven Agentic Loop to orchestrate a clear separation of concerns—data retrieval (sql_tool) and analysis (ds_tool)—we created a system that can effectively diagnose business problems, moving beyond the limitations of traditional dashboards to provide true causal insights.