Why Lightweight Scripting Is the Right Fit for Template-Driven Workflows

In publisher operations, recurring reporting workflows are often deceptively complex. On the surface, they may appear repetitive: pull data, calculate KPIs, populate a report, and share insights with stakeholders. However, in practice, each client, business unit, or publisher stakeholder may require a slightly different reporting format, KPI definition, template structure, naming convention, or commentary style.

Business Context

Weekly reporting is a critical operating rhythm in publisher monetization. It typically sets the tone for the week by helping internal teams and stakeholders understand recent revenue performance, delivery trends, pacing behavior, demand health, and optimization opportunities.
The reporting workflow involved consolidating data from multiple sources and preparing outputs for different stakeholders. These reports supported visibility across key publisher monetization areas, such as:

• Programmatic revenue performance
• Fill rate and CPM trends
• Demand partner contribution
• Inventory performance
• Delivery and pacing observations
• Weekly performance summaries
• Client-specific reporting views

Since the reporting had to be prepared at the beginning of the week, any delay or manual dependency directly impacted stakeholder visibility and decision-making.

The Problem

The existing workflow required manual intervention across multiple steps. Data had to be gathered, cleaned, consolidated, structured, and then populated into different reporting templates. While the process was repeatable, it was not fully standardized.

The initial idea was to use agentic automation to generate these reports automatically. The assumption was that AI agents could be created to handle report generation, reduce manual effort, and potentially produce client-ready outputs with minimal human involvement.

However, during solution evaluation, a key operational constraint became clear: each client or report followed a different format. Some reports had different layouts. Some required specific KPI groupings. Others had unique commentary expectations, customized tabs, or stakeholder-specific formatting.

At first glance, this feels like a problem agents are well-suited for. If formats vary, an agent with routing logic could theoretically detect the format type, apply the right template rules, and generate the appropriate output, all from a single flexible system. That assumption is worth examining carefully, because it’s where the reasoning starts to break down.

Where the Agent Argument Falls Short

It’s worth addressing the stronger version of the agent argument, not just the obvious one. A well-designed system wouldn’t be one model handling everything end to end. It would use a coordinator for routing and orchestration, with separate fixed tools handling calculations and formatting. That’s a more credible design, and it avoids some of the straightforward failure modes.

But it still doesn’t resolve the underlying problem.

Even when built well, an agent system still requires prompt upkeep, testing, monitoring, and guardrails for an output that never meaningfully changes. When a client template changes (a new KPI column, a renamed line item, a different date format), the coordinator logic has to be updated and re-validated alongside the script. Unlike code, prompts don’t have unit tests or predictable behavior at edge cases.

Each template variation adds a maintenance surface in two places rather than one.

The more fundamental issue is that there’s no reasoning for the agent to contribute. The inputs are structured. The logic is fixed. The output is fully predictable every time. An agent earns its complexity when a workflow involves ambiguity, judgment, or unstructured inputs. None of that is present here. Strip out the reasoning requirement, and what remains is orchestration overhead sitting on top of operations a script already handles cleanly.

The conclusion isn’t that a well-architected agent system can’t be built. It’s that building and sustaining one for a workflow this predictable creates overhead the problem doesn’t call for.

When Not to Use Agents

Before exploring the solution, it’s worth being explicit about the criteria that shaped this decision. Not every problem requires full AI automation, and the cost of misapplying it is real: higher latency, higher operational cost, and lower output reliability.

A workflow is a poor candidate for agentic automation when:

This reporting workflow met every one of those criteria. The decision to use lightweight scripting wasn’t a limitation, but it was the appropriate engineering response to the problem as it actually existed.

The main challenge was not only report creation. The deeper issue was workflow fragmentation.

Each client-specific reporting template introduced its own operational variation. If the team had pursued an agent-based model (whether single or multi-agent), the automation would have become difficult to maintain over time. Any template change, KPI change, naming update, or stakeholder preference would require modifications at the logic or prompt level.

This would create several compounding risks:

• High maintenance overhead across agent versions
• Increased dependency on prompt tuning and exception handling
• Lower scalability across clients
• Higher cost and latency on every execution, for tasks where the output is already fully predictable

The Approach

The first step was a detailed analysis of the client’s reporting files, covering both raw exported datasets and finalized templates, to map out the KPIs required at each stage of the process. Some metrics were used to filter and classify raw data, while others were needed for the final presentation in the report output.

The primary KPIs identified for display campaigns include spend, impressions, clicks, and CTR. Video campaigns include additional KPIs such as video start (2-second views), first quartile, midpoint, third quartile, and video completes. Additional dimensions such as campaign dates, line items, and creative names were also mapped, as they determined how the data would be grouped and summarized.

Once the data structure and KPI requirements were finalized, the reporting logic was translated into a lightweight automation script. The script was structured around modular functions: one set for raw data ingestion and KPI calculation, another for filtering and date/spend parsing, and a final layer responsible for generating the formatted output tables. This kept the logic readable, maintainable, and easy to update when templates or KPI definitions changed.

The script was configured to produce six performance reporting tables:

Each table automatically populates the finalized KPIs, including spend, impressions, clicks, CTR, and so on, ensuring consistency across all reporting outputs.

It’s worth noting that scripting doesn’t eliminate every use case for AI in this workflow. One area where an LLM step could genuinely complement the script is narrative commentary. If stakeholders expect written insights alongside the performance tables, that’s a natural fit for a lightweight AI step embedded within the existing pipeline. The goal isn’t to avoid AI; rather, it’s to deploy it only where reasoning and language generation add something a script cannot.

Results

The impact was immediate and measurable. The manual pivot-building and KPI calculation step is fully eliminated. The team now pulls data, runs the script, and pastes directly into the client template, delivering approximately 50% faster turnaround per report and significantly reducing the weekly reporting load. KPI output is now 100% consistent across all reports; every client template receives the same correctly calculated metrics without variation or manual correction. Maintenance overhead dropped, and the model scales cleanly across different client formats without rebuilding logic from scratch.

Conclusion

An agent-based approach was technically possible here. But operationally, it would have introduced complexity the problem didn’t require and reliability the workflow couldn’t afford. When the inputs are structured, the logic is fixed, and the output is fully predictable, the right answer is usually simpler than it first appears.

The decision was not “AI vs. no AI.” The decision was “What level of automation is appropriate for the problem?” In this case, the answer was clear, and the results confirmed it.

Frequently Asked Questions